Actions:

Run git config user.name and git config user.email to detect developer info.
If both are detected, store as developer_name and developer_email for renderer arguments and proceed to Phase 3.
If either is missing, ask the user directly through conversation:
- If name is missing: "I couldn't detect your name from git config. What name would you like to use? (or reply 'skip' to omit)"
- If email is missing: "I couldn't detect your email from git config. What email would you like to use? (or reply 'skip' to omit)"
Store the user's responses (or empty values if skipped) as developer_name and developer_email for renderer arguments.

Phase 3: Testing Methodology

Goal: choose the testing approach.

Actions: Ask with header Testing Methodology:

BDD first, then TDD (Recommended) -> BDD-driven TDD with Red-Green-Refactor
BDD only -> Gherkin scenarios without TDD cycle
TDD only -> Test-driven development without BDD scenarios
None -> No specific testing methodology Store the choice as testing_mode (bdd-tdd | bdd | tdd | none) for Phase 7 renderer arguments.

Phase 3.5: Memory Management (Optional)

Goal: decide whether to add CLAUDE.md memory instructions.

Actions: Ask with header Memory:

Skip (Recommended)
Include memory rules Store boolean include_memory for renderer arguments. Do not append memory text manually.

Goal: choose languages and package managers.

Actions:

Use AskUserQuestion (multiSelect: true) for technology stacks.
Generate options from detected technologies and mark detected ones as recommended.
For selected languages with multiple managers, ask preference:

Store ordered stack selections as language:::package_manager for renderer arguments.

Goal: prepare deterministic renderer inputs from user selections.

Actions:

Normalize each selected stack into ordered renderer input format language:::package_manager.

For languages without explicit package manager choice, use language::: (empty manager).
Keep language keys exact (Node.js, Python, Rust, Swift, Go, Java) when available; do not invent aliases.
Never call online search in this phase.

Goal: choose emoji usage policy in generated CLAUDE.md.

Actions: Ask with header Style:

No Emojis (Recommended)
Use Emojis Store boolean use_emojis for renderer arguments that control emoji policy text in output.

Goal: generate final content through one renderer script.

Actions:

Let the renderer handle all assembly concerns: fragment assembly, testing content injection, developer profile, technology stack section, optional memory section, and final write.
Do not manually post-edit renderer output; if output shape is wrong, fix inputs or renderer behavior.

Goal: report write and backup results from renderer.

Actions:

File and backup locations.
Developer info and testing mode.
Selected technology stacks and package managers.
Renderer rule-application summary: which stacks received local rule lines and which did not.