feat(cli): add specify extension init scaffolding command

[mvanhorn]

Description

Add a specify extension init <name> subcommand that scaffolds a new extension directory from the built-in template (extensions/template/), substituting user-provided metadata into all placeholder values.

The extension ecosystem has 23+ community extensions published to the catalog, each manually created by copying extensions/template/ and hand-editing 7 files. Every other stage of the extension lifecycle has CLI support (search, add, remove, enable, disable, update, set-priority, catalog management) - except creation. This closes that gap.

What it does:

• Copies extensions/template/ to spec-kit-<name>/ in the current or specified directory
• Substitutes placeholders: extension ID, display name, author, description, repository URL, date
• Validates extension ID format (lowercase, hyphen-separated, ^[a-z][a-z0-9]*(-[a-z0-9]+)*$)
• Replaces EXAMPLE-README.md as the new README.md
• Optionally initializes a git repo (--no-git to skip)
• Prompts interactively when CLI args are omitted
• Prints a next-steps panel matching the style of specify init

Usage:

specify extension init my-linter
specify extension init my-linter --author "Jane Doe" --description "Lint spec files"
specify extension init my-linter --output ~/projects --no-git

This command does NOT require a spec-kit project - you can scaffold an extension anywhere, then test it with specify extension add --dev /path/to/extension.

The template source is resolved from the installed package first (works in wheel/air-gapped), falling back to the source tree layout.

Testing

• Ran existing tests with pytest - all 810 existing tests pass
• Added 23 new test cases in tests/test_extension_init.py:
  • Extension ID validation (10 tests): valid names, uppercase rejection, special chars, leading numbers, empty strings
  • Title case conversion (3 tests)
  • Template discovery (2 tests)
  • CLI integration (8 tests): full scaffold, placeholder substitution, invalid name rejection, existing directory rejection, --no-git, README replacement, next-steps output, date substitution
• Tested locally: specify extension init my-test --no-git produces a working extension directory with all placeholders replaced

AI Disclosure

• I did use AI assistance (describe below)

This contribution was developed with AI assistance (Claude Code). The implementation follows existing patterns from the specify init command and extension add subcommand.

[mnriem]

When an extension gets added / removed / enabled or disabled this should happen automatically. So while this is indeed needed it should not be a separate command as it will easily be forgotten. If that is not happening it is a bug.

[mvanhorn]

Good point - auto-scaffolding on extension add/remove/enable/disable would be more reliable than a separate command. I can rework this to hook into the extension lifecycle instead. Would you prefer the scaffolding runs as part of specify extension add, or as a post-install hook that fires automatically?

[mnriem]

@mvanhorn As part of the add if the extension is auto-enable (most are) or at enable time

[mvanhorn]

Got it - I'll rework this to run scaffolding as part of extension add when the extension is auto-enabled, and as part of extension enable otherwise. The standalone init command goes away. Will update the PR.