Charm huh forms

Skill peternicholls/Charm-Skills/charm-huh-forms

Agent Skills and reference patterns for building premium, responsive terminal applications using Charm libraries. Independent and optimized for AI-driven TUI development.

Install

npx -y skills add peternicholls/Charm-Skills --skill charm-huh-forms

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build polished terminal forms, prompts, setup wizards, confirmations, and accessible input flows with Charm Huh. Use when Codex needs standalone prompts, multi-page forms, select/multiselect/input/text/confirm fields, validation, dynamic fields, accessible screen-reader mode, or Huh embedded in a Bubble Tea application.

SKILL.md

3.1 KB, as published. Nobody here has run it

Charm Huh Forms

Overview

Use Huh when the user needs to collect structured input in the terminal. Prefer it over hand-built prompt loops unless the flow requires custom full-screen behavior that belongs in Bubble Tea.

Workflow

Read references/form-patterns.md before implementing non-trivial forms.
Model the answers first, then choose fields: input, text, select, multiselect, confirm, or file picker if available in the current Huh version.
Group fields into pages by task and cognitive load.
Add validation and limits where invalid answers would cause downstream failure.
Provide an accessible mode controlled by config or environment.
Verify with keyboard-only entry, invalid input, cancel/error handling, and accessible mode.

Choose Huh When

The task is a setup wizard, config generator, survey, confirmation, selection, or one-off prompt.
Users need validation, defaults, choices, and clear field-level errors.
Accessibility matters and a plain prompt mode is acceptable.
The form can run standalone or as a bounded subflow inside a larger app.

Prefer Bubble Tea Instead When

The UI needs custom navigation, live dashboards, split panes, background updates, or persistent multi-screen state.
Form fields must interact with non-form components continuously.
The user spends most of the session browsing, comparing, or manipulating data rather than answering fields.

Implementation Rules

Store field results in typed variables or a config struct.
Use typed options rather than stringly typed sentinel values when possible.
Validate near the field so the user sees the error before submission.
Use dynamic field functions for dependent questions, but bind recomputation narrowly to the values that actually change.
Offer an explicit accessible mode through environment or config, not as a hidden code path.
Theme forms to match the surrounding app when a brand/theme exists; otherwise use a restrained default.

Avoid

Avoid asking too many questions on one screen.
Avoid making destructive confirmations default to "yes".
Avoid dynamic option functions that perform expensive work on every field update.
Avoid accessibility as an afterthought. Wire it before final verification.
Avoid using Huh for long-running progress or real-time dashboards.

Verification

Unit-test validation functions.
Manually run the form through happy path, invalid input, cancel, empty/default values, and dynamic-field changes.
Run with accessible mode enabled, for example an ACCESSIBLE=1 project convention if present.
Confirm output/config serialization is deterministic and does not include prompt-only labels where machine values are expected.

References

references/form-patterns.md: field selection, dynamic forms, accessible mode, and verification checklist.