feat(init): prompt to install AI DevKit built-in skills during interactive init#60
Conversation
Manual smoke test in a scratch directoryBuilt the CLI from this branch and ran it against a fresh scratch dir to confirm the prompt actually appears and both paths work end-to-end. Accept path (user presses
|
|
@nnhhoang Thanks for the contribution, this is a good one. I have a concern that if ai-devkit init runs in a CI pipeline or any environment without a TTY, We need to detect no TTY (!process.stdin.isTTY) and skip the prompt (default to no); the logic of checking can be extracted from SkillManager to a utility for reusability. Other than that, I think we can add an option so that it will automatically install the built-in skills without prompting.
The flag gives CI users explicit control, and the TTY detection is the safe fallback. |
|
Addressed both feedback points in d5821b7. Changes
Test coverage
Smoke test evidenceScenario 1 — Non-interactive (piped stdin), no flag: AI DevKit initialized successfully! $ ls .claude/skills Scenario 2 — Non-interactive + `--built-in`: $ ls .claude/skills Interactive paths are covered by the existing unit tests plus the earlier end-to-end smoke test I posted above. |
…ctive init Before this change, `ai-devkit init` without a template only set up environments and phases — built-in skills were never installed, even though agents need them for the guided SDLC workflow. Users had to discover and run `ai-devkit skill add codeaholicguy/ai-devkit` separately, or init with a specific template. Now the interactive init prompts the user after phase setup asking whether to install the built-in AI DevKit skills (dev-lifecycle, debug, capture-knowledge, memory, simplify-implementation, technical-writer, verify, tdd). Default is Yes so fresh users get the expected experience out of the box, but users who want a lean setup can decline. Reuses the existing installTemplateSkills helper so failures are reported as warnings instead of aborting init — matches the behavior already established for template-driven installs. The prompt only appears in interactive mode. Template mode (`-t some.yaml`) is unchanged: templates that declare skills still drive the install, and templates without skills still skip the interactive prompt. Fixes codeaholicguy#56
…n skills flow
Addresses PR review feedback:
- Detect non-interactive environments via a new isInteractiveTerminal()
utility shared with SkillManager, so inquirer.prompt is never called
when stdin is not a TTY. Prevents the init command from hanging
in CI pipelines or any piped execution context.
- Introduce a --built-in CLI flag so users can opt in to installing the
curated built-in skills without an interactive prompt. Behavior matrix:
Interactive, no flag -> prompt Y/n (default Yes)
Interactive, --built-in -> install without prompting
Non-interactive, no flag -> skip, log a hint pointing at --built-in
Non-interactive, --built-in -> install without prompting
- Extract BUILTIN_SKILL_REGISTRY and BUILTIN_SKILL_NAMES into
packages/cli/src/constants.ts so future commands (doctor, upgrade, ...)
can import the same canonical list instead of duplicating names.
BUILTIN_SKILLS in init.ts is now derived via .map() over the shared
names array.
- Extract the previously-private isInteractiveTerminal() logic from
SkillManager into util/terminal.ts. SkillManager now delegates to
the shared helper so both commands see identical TTY semantics.
Adds three unit tests covering the new non-interactive paths and the
--built-in flag in both interactive and non-interactive contexts.
nnhhoang
force-pushed
the
feat/auto-install-skills-on-init
branch
from
d5821b7 to
0e05326
Compare
|
Test organization misleads future readers ( Both new Recommendation: Move the two new |
|
No test for If a user runs |
…n + template Addresses review feedback on PR codeaholicguy#60: - Move the 'built-in skills prompt (interactive init without template)' and 'built-in skills in non-interactive environments (CI)' describe blocks out of 'init command template mode' and make them siblings under a single outer 'init command' describe. The previous nesting implied these scenarios ran under template mode when they test the opposite, which is misleading when a single describe is selected by name. - Add two test cases in the 'template mode' describe that pin down the silent-ignore behavior of --built-in when a template is in play: once with skills declared (template skills install, no built-in path), once without (no install at all). This closes a previously untested invariant that future refactors could otherwise break. No production code changes. 14 init tests across 3 sibling describes.
|
Done in 50559f2 — pulled the two new describes out so they sit next to |
|
LGTM. Thanks for your contribution. |
2 participants
Summary
Fixes #56. Before this change, `ai-devkit init` without a template never installed any skills into `.claude`/`.cursor`/etc., even though agents need them for the guided SDLC workflow. Users had to discover and run `ai-devkit skill add codeaholicguy/ai-devkit` separately, or init with a specific template.
This PR adds a single `Y/n` prompt after phase setup asking whether to install the built-in AI DevKit skills. Default is Yes so fresh users get the expected experience out of the box; users who want a lean setup can decline.
Behavior
Built-in skills
Hardcoded curated list from the `codeaholicguy/ai-devkit` registry:
Matches what `templates/senior-engineer.yaml` already declares as the recommended devkit set.
Implementation
Test plan
Notes
Happy to adjust the default (Yes → No), the skill list, or expose a `--skip-builtin-skills`/`--with-builtin-skills` flag for CI/non-interactive use if you prefer a different UX.