init

name	init
description	Analyze project structure, write the thick requirements doc (.claude/docs/DESIGN.md), and populate the thin "Repository Identity" pointer in CLAUDE.md (Zone B).
disable-model-invocation	true

Initialize Project Configuration

Analyze this project and:

1. Generate the thick 要件定義書 at .claude/docs/DESIGN.md (macro requirements & design — what this project builds and why).
2. Populate the thin Repository Identity (Zone B) pointer in CLAUDE.md (a brief identity line + a pointer to DESIGN.md — no thick content here).

Document hierarchy (where content lives)

• CLAUDE.md = orchestrator contract. Zone B holds only a thin identity + pointer.
• .claude/docs/DESIGN.md = 要件定義書 (thick macro requirements/design). This is where rich project content belongs.
• PROGRESS.md = micro work progress (maintained by /checkpointing).
• AGENTS.md = template-owned discovery pointer to the canonical .agents/ contract. /init never modifies it.

CLAUDE.md zones

Zone contract (3-zone layout, markers, ownership, markers-missing rule): .claude/rules/claude-md-zones.md. This skill writes ONLY Zone B (between the two markers) — never Zone A or Zone C.

Steps

1. Project Analysis

Run the bundled detector instead of hand-scanning manifests:

python3 .claude/skills/init/detect_stack.py

Interpret the JSON:

• languages, package_managers, manifests — detected tech stack (pyproject/package.json/Cargo.toml/go.mod/setup.py/requirements.txt, Makefile, Dockerfile).
• commands — inferred lint/test/format/typecheck commands.
• libraries — top-level dependencies.
• ci — CI systems (e.g. github-actions).
• claude_md_markers — boundary-marker presence (see Step 4).

Exit codes: 0 normal · 2 CLAUDE.md boundary markers missing (handle per Step 4 before writing Zone B). Use this JSON to fill DESIGN.md (Step 3) and Zone B.

2. Ask User

Use AskUserQuestion tool to ask:

1. Project overview: What does this project do? (1-2 sentences)
2. Code language: English or Japanese for comments/variable names?
3. Additional rules: Any other coding conventions to follow?

3. Generate the thick DESIGN.md (要件定義書)

.claude/docs/DESIGN.md is the macro requirements & design document. This is where the rich project content goes (not CLAUDE.md). Read the existing template first, then fill each section as far as the project evidence allows, using the analysis from step 1 and the user's answers from step 2. Leave a section as its placeholder only when there is genuinely no basis to fill it.

Map your findings onto the fixed section structure (keep the Japanese+English headings and the leading document-map links intact):

Section	What to fill in
## 背景・目的 (Background & Purpose)	The user's project overview answer; the problem it solves and for whom.
## スコープ (Scope)	In Scope / Out of Scope bullets inferred from the overview and codebase.
## 機能要件 (Functional Requirements)	Table rows (ID / 要件 / 優先度 / 備考) for features evident in the code or stated by the user.
## 非機能要件 (Non-Functional Requirements)	Table rows (カテゴリ / 要件 / 指標) for performance, security, maintainability, etc.
## アーキテクチャ (Architecture)	Overview narrative + the Agent Roles table (orchestrator / delegated agents).
## 技術選定 (Tech Stack & Rationale)	Table rows (領域 / 採用技術 / 理由 / 代替案) from the detected stack.
## 制約 (Constraints)	Bullets for technical / org / compatibility constraints.
## Key Decisions	Seed any decisions already made (with today's date).
## TODO / Open Questions	Items needing follow-up.

Do not fabricate requirements for a distribution-template repo: when initializing a real project, prefer concrete evidence; when nothing is known, leave the placeholder.

Note: /init creates DESIGN.md content directly (the file may not exist yet). For post-creation appends (e.g. adding tech-stack rows to Key Decisions or section content later), use python3 .claude/skills/_shared/update_design.py instead of editing DESIGN.md by hand.

4. Update CLAUDE.md Zone B (thin pointer only)

First verify the 3-zone markers exist. Reuse the Step 1 detector output: claude_md_markers.template_boundary and claude_md_markers.repo_boundary must both be true (equivalently, detect_stack.py exits 0, not 2). If either is missing (exit code 2), stop per .claude/rules/claude-md-zones.md (user runs ./scripts/update.sh).

Replace the content between the two markers with a thin identity + pointer (keep the marker lines and their ━ separators intact). The thick content lives in DESIGN.md — do not duplicate tech stack / requirements here. Use the Edit tool by anchoring on the full block between the two boundary box lines.

## Repository Identity

<!-- Managed by /init. Re-run /init to refresh. -->

{One-line identity: what this project is, in a single sentence}

Macro requirements & design live in **[.claude/docs/DESIGN.md](.claude/docs/DESIGN.md)** (要件定義書).
Keep this section thin — a brief identity line + pointer. Thick content belongs in DESIGN.md.

5. Check Unnecessary Rules

Check rules in .claude/rules/ and suggest removing unnecessary ones:

• Non-Python project → dev-environment.md (uv/ruff/ty) may not be needed
• No-test project → testing.md may not be needed

6. Report Completion

Report to user (in Japanese):

• Detected tech stack
• Files updated (.claude/docs/DESIGN.md, CLAUDE.md Zone B)
• Recommended rules to remove (if any)