mcpField
I
init-config

init-config

github.com/fradserAgent workflows596104 installsUpdated 5w ago
Repository

About init-config

init-config is an initialization skill for developers setting up project guidance in CLAUDE.md. It gathers environment, testing, and stack choices in stages, then passes them to a renderer to assemble the file.

Key features

  1. 01Detect installed languages and package managers
  2. 02Collect developer identity details
  3. 03Choose testing mode and memory rules
  4. 04Select technology stacks and package managers
  5. 05Generate CLAUDE.md through a renderer

Use cases

  1. 01Create CLAUDE.md for a new development setup
  2. 02Configure project guidance for selected stacks

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/fradser/dotclaude --skill init-config

After installing, type/init-configin Claude Code to confirm it loaded.

Details

From the project README

Initialization

Run phases in order because later phases depend on saved choices from earlier phases.

Phase 1: Environment Discovery

Goal: detect installed languages, tools, and package managers.

Actions:

  1. Detect installed languages (Node.js, Python, Rust, Go, Java, Docker, and others).
  2. Detect package manager options for selected ecosystems.
  3. Store detection results for Phase 4 option generation.

Phase 2: Developer Profile

Goal: detect or collect developer identity for personalization.

Actions:

  1. Run git config user.name and git config user.email to detect developer info.
  2. If both are detected, store as developer_name and developer_email for renderer arguments and proceed to Phase 3.
  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)"
  4. 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.

Phase 4: Technology Stack & Package Manager Selection

Goal: choose languages and package managers.

Actions:

  1. Use AskUserQuestion (multiSelect: true) for technology stacks.
  2. Generate options from detected technologies and mark detected ones as recommended.
  3. For selected languages with multiple managers, ask preference:
  • Node.js: npm, pnpm (Recommended), yarn, bun.
  • Python: pip, uv (Recommended), poetry.
  • Only show managers detected on the machine.
  1. Store ordered stack selections as language:::package_manager for renderer arguments.

Phase 5: Renderer Input Preparation

Goal: prepare deterministic renderer inputs from user selections.

Actions:

  1. Normalize each selected stack into ordered renderer input format language:::package_manager.
  • Keep selection order unchanged.
  1. For languages without explicit package manager choice, use language::: (empty manager).
  2. Keep language keys exact (Node.js, Python, Rust, Swift, Go, Java) when available; do not invent aliases.
  3. Never call online search in this phase.

Phase 6: Style Preference

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.

Phase 7: Assembly & Generation

Goal: generate final content through one renderer script.

Actions:

  1. Run ${CLAUDE_PLUGIN_ROOT}/scripts/render-claude-config.sh with:
  • --target-file $HOME/.claude/CLAUDE.md
  • --testing-mode <bdd-tdd|bdd|tdd|none> (from Phase 3)
  • --include-memory <true|false>
  • --use-emojis <true|false>
  • Optional --developer-name and --developer-email
  • Repeated --stack "language:::package_manager" entries from Phase 5
  1. Let the renderer handle all assembly concerns: fragment assembly, testing content injection, developer profile, technology stack section, optional memory section, and final write.
  2. Do not manually post-edit renderer output; if output shape is wrong, fix inputs or renderer behavior.

Phase 8: Write CLAUDE.md

Goal: report write and backup results from renderer.

Actions:

  1. Use renderer output to confirm:
  • Target path written.
  • Backup path created when an existing target file was present.
  1. Report:
  • 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.

Best Practices

  • Keep workflow progressive and deterministic.
  • Prefer local references over generated prose for stack guidance.
  • Keep generated constraints concise and enforceable.
  • Always back up existing files before overwrite.

Comments

Markdown supported