[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71SZ41SBB4YKVKP4G9JS1XT":3,"skill-same:01M71SZ41SBB4YKVKP4G9JS1XT":89},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":55,"ownerDescription":56,"updatedAt":57,"install":58,"resources":70},"01M71SZ41SBB4YKVKP4G9JS1XT","init-project",null,"Use when setting up a new project or adding shared project instructions (CLAUDE.md or AGENTS.md), CHANGELOG.md and documentation to an existing project.","Claudfather\u002FclauDNA","Claudfather","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F281278891?v=4","01M71SX82K0TBGQ394AB2G1T5Z","01M71SX83CE1S8YC06K9P3P962",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"init","init project","project","write","read","dependency","command","changelog","functional","documentation","log","Bash","when","new","only","up","mkdir","branch","shared","ls","2026-11-10 13:02:02",false,"---\nname: init-project\nuser-invocable: true\ndisable-model-invocation: true\ndescription: \"Use when setting up a new project or adding shared project instructions (CLAUDE.md or AGENTS.md), CHANGELOG.md and documentation to an existing project.\"\nallowed-tools: Read(*), Write(*), Edit(*), Glob(*), Grep(*), Bash(git log *), Bash(git tag *), Bash(ls *), Bash(mkdir *), Bash(command -v *), Bash(claudron status *)\nrequires:\n  - cli: claudron\n    reason: \"Optional — Step 6.5 vault detection only; every ladder branch degrades when absent and announces it with the standard notice in ..\u002F_shared\u002Fclaudron-engine.md §3.1 (this is a soft dependency, not a functional requirement)\"\n---\n\n# Initialize Project\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nSet up a project with standard clauDNA configuration: `CLAUDE.md`, `CHANGELOG.md`, `PROJECT_MISSION.md`, the `documentation\u002F` planning structure, and the shared-docs seam (a `## Shared Documentation` section in CLAUDE.md — Step 6.5). Works for both new repos and existing projects that lack these files.\n\nThe files this user explicitly asks to initialize (`AGENTS.md`\u002F`CLAUDE.md`, `CHANGELOG.md`, `PROJECT_MISSION.md`, setup templates, and the requested project scaffold) remain project-owned outputs at the selected project root. Follow `..\u002F_shared\u002Forchestration-guide.md` §1 only for private intermediate research or a generated status report; do not relocate project instructions\u002Fconfig or user-authored files into session artifacts. If a status report is requested, persist its sanitized copy under `\u003Cartifacts>`; missing\u002Fconflicting\u002Funverified native identity or permission denial means omit that persistence, with no cwd\u002Foperation fallback. No session-only report means no session allocation.\n\n## Codex project target\n\nOn Codex, use `AGENTS.md` as the instruction target in Steps 1–3 and 7, with\n`references\u002FAGENTS_MD_TEMPLATE.md`. Read and preserve existing AGENTS.md and approved\nCLAUDE.md instructions before offering additions; never replace or silently copy\na whole file over existing project policy. Fill only facts supported by the project\nor user. Existing authorization to initialize and commit persists; ask only about\nmissing decisions or replacing existing instructions.\n\nDo not create `.claude\u002Frules`, `.claude\u002Ftodo` or Claude notification configuration\non the Codex path. Use project-owned `.claudna\u002Ftodo.md` only if a task file is needed.\nThe shared-documentation resolver still consumes the existing CLAUDE.md seam or the\ndeclared environment root: do not claim that writing an AGENTS.md section changes\nthat contract. In Step 6.5, reuse a declared root; if absent, offer the existing\nCLAUDE.md seam only within authorized scope, or leave it unprovisioned with a clear\nnext step. Never invent a second vault resolver or mutate a vault during setup.\nSteps 4–6 still create ordinary project documentation. Claude-specific template,\ncache and notification rules below apply only to the Claude Code target.\n\n## Procedure\n\nFollow these steps exactly in order.\n\n### Step 1: Assess Current State\n\nScan the project root for existing configuration:\n\n- `CLAUDE.md` — project instructions for Claude Code\n- `CHANGELOG.md` — structured change history\n- `PROJECT_MISSION.md` — project mission statement\n- `documentation\u002Fplanning\u002F` — planning structure for skills\n- CLAUDE.md `## Shared Documentation` section — the shared-docs seam (Step 6.5)\n\nAlso scan for signals about the project:\n\n- `README.md` — project description, tech stack\n- `package.json`, `Cargo.toml`, `pyproject.toml`, `*.xcodeproj`, `go.mod` — tech stack detection\n- `.git\u002F` — is this a git repo?\n- Existing source directories — understand the project structure\n\nPresent findings:\n\n```\nProject Assessment\n═══════════════════════════════════════════════════════\n  Project root:    \u002Fpath\u002Fto\u002Fproject\n  Git repo:        yes\u002Fno\n  Tech stack:      [detected from manifest files]\n\n  CLAUDE.md:            ✓ exists \u002F ✗ missing\n  CHANGELOG.md:         ✓ exists \u002F ✗ missing\n  PROJECT_MISSION.md:   ✓ exists \u002F ✗ missing\n  documentation\u002F:       ✓ exists \u002F ✗ missing\n  Shared docs seam:     ✓ declared (\u003Croot path>) \u002F ✗ not declared\n═══════════════════════════════════════════════════════\n```\n\nIf everything already exists, tell the user and ask if they want to align any of it to the clauDNA template. If none exist, proceed to Step 2. If some exist, note which will be created vs. skipped.\n\n### Step 2: Gather Project Context\n\nAsk the user these questions (skip any that are obvious from Step 1):\n\n1. **Project name and one-line description**\n2. **Key commands** — build, lint, test, dev server (whatever applies)\n3. **Any known \"gotchas\"?** — things Claude should NOT do, common mistakes, domain-specific traps\n\nKeep the interview short. If the codebase is readable, infer what you can and confirm with the user rather than asking from scratch.\n\n### Step 3: Create CLAUDE.md\n\nGenerate `CLAUDE.md` using the template at [references\u002FCLAUDE_MD_TEMPLATE.md](references\u002FCLAUDE_MD_TEMPLATE.md).\n\n**Customization rules:**\n- Fill in the Project Overview section with real project details\n- Populate the Architecture section by scanning the actual directory structure (use `ls` and `Glob`). Show the real tree, not a placeholder.\n- Fill in Development Workflow with the actual commands from Step 2\n- Fill in Commands Reference with the actual commands\n- Add any gotchas from Step 2 to \"Things Claude Should NOT Do\"\n- Keep all static sections (Workflow Orchestration, Core Principles, etc.) exactly as templated — these are universal\n- Remove placeholder comments (`\u003C!-- Customize -->`) after filling in — but leave the commented `## Shared Documentation` block alone; Step 6.5 owns it\n\n**For large projects** (200+ lines after customization): Consider creating `.claude\u002Frules\u002F` files with `paths:` frontmatter to scope domain-specific rules to matching files. Keep CLAUDE.md under 200 lines — only universal rules and safety constraints.\n\n**Cache efficiency guidelines** (these affect prompt cache hit rates across every API call). For detailed scoring criteria (PASS\u002FWARN\u002FFAIL for each check), see [cache-checks.md](cache-checks.md) in this skill directory.\n- Static sections first, dynamic sections last. Add `\u003C!-- Static sections above, project-specific sections below. Keep this order for prompt cache efficiency. -->` at the boundary.\n- Keep CLAUDE.md under 200 lines (WARN). Over 350 lines is a FAIL — significant token cost per call.\n- Don't add instructions to edit CLAUDE.md mid-session — defer edits to session boundaries (`\u002Fclaudna:session handoff`).\n- Don't add instructions to switch models or tools mid-session — both invalidate the entire prompt cache.\n- If using `.claude\u002Frules\u002F`, ensure each file has `paths:` frontmatter (not `globs:`) to scope when each rule loads.\n\n**Do NOT:**\n- Leave `[bracket placeholders]` in the output\n- Remove static sections the user didn't ask about\n- Over-fill sections with speculation — empty with a note is better than wrong\n\n### Step 4: Create CHANGELOG.md\n\nGenerate `CHANGELOG.md` using the template at [references\u002FCHANGELOG_TEMPLATE.md](references\u002FCHANGELOG_TEMPLATE.md).\n\n**Customization rules:**\n- If this is a new project, create a single `## [Unreleased]` section\n- If the project has existing git history, create version sections from tags and populate with summaries of the commits\n- Use `git log --oneline` and `git tag` to build history\n- Follow the Keep a Changelog format: `### Added`, `### Fixed`, `### Changed`, `### Removed`, `### Refactored`\n- Entry format: `- **Feature Name** — Description`\n\n### Step 5: Create PROJECT_MISSION.md\n\nIf `PROJECT_MISSION.md` doesn't exist, create it. Use the project name and description from Step 2:\n\n```markdown\n# [Project Name] — Mission\n\n[One-paragraph mission statement: what this project does, who it's for, what success looks like.]\n```\n\nIf the user provided a clear description in Step 2, write a real mission statement. If not, create the stub and note that `\u002Fclaudna:product-vision` will flesh it out. This file anchors `\u002Fclaudna:product-vision` ideation and gives all skills a shared understanding of the project's purpose.\n\n### Step 6: Scaffold documentation\u002F\n\nIf `documentation\u002Fplanning\u002F` doesn't exist, create the standard planning structure. This is the shared directory layout that planning and audit skills write to (see `..\u002F_shared\u002Fdocumentation-standard.md` for the full spec).\n\nCreate these directories with `.gitkeep` files:\n\n```\ndocumentation\u002F\n├── planning\u002F\n│   ├── phases\u002F.gitkeep\n│   ├── tech_debt\u002F.gitkeep\n│   ├── security\u002F.gitkeep\n│   ├── access-paths\u002F.gitkeep\n│   ├── product-vision\u002F.gitkeep\n│   └── investigations\u002F.gitkeep\n├── decisions\u002F.gitkeep\n├── specs\u002F.gitkeep\n├── guides\u002F.gitkeep\n└── archive\u002F.gitkeep\n```\n\nIf `documentation\u002F` already exists, scan for missing subdirectories and create only what's missing.\n\n**Directory purposes:**\n- `planning\u002F` — project-owned docs explicitly exported by a user-selected `--output docs`; the default generated reports for `\u002Fclaudna:audit`, `\u002Fclaudna:product-enhance`, and `\u002Fclaudna:product-vision` live in the owning session's artifacts. Existing project planning files are not moved by setup.\n- `decisions\u002F` — Architecture Decision Records (ADRs). Why we chose X over Y. Permanent, not archived.\n- `specs\u002F` — Technical specifications, API contracts, data schemas. Living docs.\n- `guides\u002F` — Setup guides, onboarding, runbooks. Living docs.\n- `archive\u002F` — Completed planning sessions moved here after all phases merge.\n\n### Step 6.5: Shared Knowledge Seam\n\nProvision the `## Shared Documentation` CLAUDE.md section — the root that `\u002Fclaudna:recall` and `\u002Fclaudna:index` resolve. The section format, `(claudron vault)` annotation semantics, and env-over-section precedence are contract-bound in `..\u002F_shared\u002Fdocumentation-standard.md` §10 — write exactly that format.\n\n**Idempotency first.** If CLAUDE.md already has a `## Shared Documentation` section, show it and offer to update it by re-running the detection below — never write a second section. (The CLAUDE.md template ships the section as a commented placeholder — treat that as absent, and replace the commented block with the real section when writing.)\n\n**Pre-ladder: an existing raw tree via env.** If `SHARED_DOCS_PATH` is set (`printenv SHARED_DOCS_PATH`) and no vault resolves in (a), the raw tree already exists — offer to write the unannotated section with *that* path and skip the ladder; never scaffold a new default beside an env-declared root.\n\nDetect which of three states applies, in order:\n\n**(a) Vault resolvable.** `CLAUDRON_VAULT_PATH` is set (check with `printenv CLAUDRON_VAULT_PATH`), or `claudron` is on PATH (`command -v claudron`) and `claudron status --json` reports a vault path. Write the section with the resolved path (prefer the `~`-relative form when it's under the home directory) and the `(claudron vault)` annotation:\n\n```markdown\n## Shared Documentation\n\n~\u002Fvault  (claudron vault)\nCross-project knowledge lives here — see \u002Fclaudna:recall.\n```\n\nDetection is read-only (`claudron status` is safe to run). **Print-not-execute for anything mutating:** never run `claudron init`, `claudron migrate`, or any other writing claudron command — show the command and let the user run it.\n\n**(b) claudron present, no vault.** `claudron` is on PATH but no vault resolves (no env var, and `claudron status` exits non-zero with a stderr message — it never emits JSON on the no-vault path). Emit the standard degradation notice (`..\u002F_shared\u002Fclaudron-engine.md` §3.1 — the `\u002Fclaudna:init-project` row, `present-no-vault` wording), then print the remedy — do not run it, and do **not** scaffold a raw tree (it would shadow the vault the user is about to create):\n\n```\nclaudron is installed but no vault is initialized. Run:\n\n  claudron init ~\u002Fvault --personal\n\n(the path is where your vault will live — pick your own; if the command is\nrejected, the CLI has moved — `claudron --help` shows the current form) then\nre-invoke \u002Fclaudna:init-project — Step 6.5 will detect the vault and write\nthe CLAUDE.md section.\n```\n\nOffer to re-run this step's detection once the user has initialized.\n\n**(c) No claudron.** Emit the standard degradation notice (`..\u002F_shared\u002Fclaudron-engine.md` §3.1 — the `\u002Fclaudna:init-project` row, `absent` wording) so the user knows a vault was looked for and not found, rather than inferring it from being offered a raw tree. Then offer the minimal raw-tree scaffold. Ask where the shared root should live, defaulting to the **stable absolute `~\u002Fshared`** — never a cwd-relative sibling like `..\u002Fshared`, which fragments the store per parent directory. If the user picks a path *inside this repo*, warn once before proceeding: shared docs are cross-project by doctrine (documentation-standard §10) — an in-repo root silently scopes them to this repo. On yes:\n\n1. Create `\u003Croot>\u002Fknowledge\u002F\u003Crepo-name>\u002F`, `\u003Croot>\u002Fplanning\u002Factive\u002F`, and `\u003Croot>\u002Fdecisions\u002F` (`mkdir -p`).\n2. Invoke `\u002Fclaudna:index \u003Croot> --recursive` to write the stub INDEX.md files — index is the sole INDEX.md writer; don't write them by hand.\n3. Write the section into CLAUDE.md with the path only, **no annotation** (raw trees are INDEX-discovered):\n\n```markdown\n## Shared Documentation\n\n~\u002Fshared\nCross-project knowledge lives here — see \u002Fclaudna:recall.\n```\n\nThe scaffold is the only write this skill makes outside the project, and only at the path the user chose. If the user declines, skip the seam entirely and point at SETUP_GUIDE's \"Claudron Integration\" section for setting it up later.\n\n### Step 7: Verify & Confirm\n\nShow the user what was created:\n\n```\nProject Initialized\n═══════════════════════════════════════════════════════\n  Created:\n    ✓ CLAUDE.md              (N lines — project instructions)\n    ✓ CHANGELOG.md           (N lines — change history)\n    ✓ PROJECT_MISSION.md     (N lines — mission statement)\n    ✓ documentation\u002F         (10 directories: planning, decisions, specs, guides, archive)\n    ✓ Shared docs seam       (## Shared Documentation → ~\u002Fshared; raw tree scaffolded)\n\n  Skipped:\n    - CLAUDE.md (already exists)\n═══════════════════════════════════════════════════════\n```\n\nReport the seam line as whichever Step 6.5 branch ran: the annotated vault section, the raw-tree scaffold + section, printed `claudron init` guidance (nothing written), or skipped.\n\nAsk: **\"Want me to commit these files?\"**\n\nIf yes, stage only the created\u002Fmodified files and commit with:\n```\ndocs: initialize project configuration (CLAUDE.md, CHANGELOG.md, .claude\u002F, documentation\u002F)\n```\n\nA Step 6.5 raw-tree scaffold lives outside the repo — never stage it; only the CLAUDE.md section ships with the commit.\n\n---\n\n## Rules\n\n- **Never overwrite existing files without asking.** If `CLAUDE.md` already exists, ask before replacing or merging.\n- **Infer before asking.** Read the codebase first. Ask the user to confirm\u002Fcorrect, not to describe from scratch.\n- **Keep static sections intact and ordered first.** The Workflow Orchestration, Core Principles, and Task Management sections are universal clauDNA conventions. They must appear before project-specific dynamic sections for cache efficiency.\n- **Architecture must be real.** Scan the actual directory tree. Don't write a placeholder tree structure.\n- **CHANGELOG must reflect real history.** Use `git log` and `git tag`. Don't invent entries.\n\n---\n\n## Optional: Notification Setup (macOS)\n\nDuring Step 7, if the user is on macOS, mention notification options:\n\n**iTerm2 (recommended):** Profiles → Terminal → check \"Send notification when idle\" (set idle time to ~5 seconds). iTerm2 will alert when any terminal tab is waiting for input.\n\n**Hook-based:** The clauDNA plugin ships a notification hook in `plugin-hooks\u002Fhooks.json` that fires a macOS notification when Claude needs input. It activates automatically when the plugin is enabled.\n\n**Manual trigger:** `osascript -e 'display notification \"Message\" with title \"Claude Code\"'`\n\n**iTerm2 tab management tips:**\n- Right-click tab → \"Edit Tab Title\" to name Claude sessions\n- Right-click tab → \"Tab Color\" to color-code worktrees\u002Ftasks\n- Profiles → General → Badge → `\\(session.path)` for directory badges\n\nThis is informational context — do not block initialization on notification setup.\n","# Initialize Project\n\n> **Codex:** Read `..\u002F_shared\u002Fcodex-tools.md` before following this skill. Apply its tool, root and dispatch mappings throughout.\n\nSet up a project with standard clauDNA configuration: `CLAUDE.md`, `CHANGELOG.md`, `PROJECT_MISSION.md`, the `documentation\u002F` planning structure, and the shared-docs seam (a `## Shared Documentation` section in CLAUDE.md — Step 6.5). Works for both new repos and existing projects that lack these files.\n\nThe files this user explicitly asks to initialize (`AGENTS.md`\u002F`CLAUDE.md`, `CHANGELOG.md`, `PROJECT_MISSION.md`, setup templates, and the requested project scaffold) remain project-owned outputs at the selected project root. Follow `..\u002F_shared\u002Forchestration-guide.md` §1 only for private intermediate research or a generated status report; do not relocate project instructions\u002Fconfig or user-authored files into session artifacts. If a status report is requested, persist its sanitized copy under `\u003Cartifacts>`; missing\u002Fconflicting\u002Funverified native identity or permission denial means omit that persistence, with no cwd\u002Foperation fallback. No session-only report means no session allocation.\n\n## Codex project target\n\nOn Codex, use `AGENTS.md` as the instruction target in Steps 1–3 and 7, with\n`references\u002FAGENTS_MD_TEMPLATE.md`. Read and preserve existing AGENTS.md and approved\nCLAUDE.md instructions before offering additions; never replace or silently copy\na whole file over existing project policy. Fill only facts supported by the project\nor user. Existing authorization to initialize and commit persists; ask only about\nmissing decisions or replacing existing instructions.\n\nDo not create `.claude\u002Frules`, `.claude\u002Ftodo` or Claude notification configuration\non the Codex path. Use project-owned `.claudna\u002Ftodo.md` only if a task file is needed.\nThe shared-documentation resolver still consumes the existing CLAUDE.md seam or the\ndeclared environment root: do not claim that writing an AGENTS.md section changes\nthat contract. In Step 6.5, reuse a declared root; if absent, offer the existing\nCLAUDE.md seam only within authorized scope, or leave it unprovisioned with a clear\nnext step. Never invent a second vault resolver or mutate a vault during setup.\nSteps 4–6 still create ordinary project documentation. Claude-specific template,\ncache and notification rules below apply only to the Claude Code target.\n\n## Procedure\n\nFollow these steps exactly in order.\n\n### Step 1: Assess Current State\n\nScan the project root for existing configuration:\n\n- `CLAUDE.md` — project instructions for Claude Code\n- `CHANGELOG.md` — structured change history\n- `PROJECT_MISSION.md` — project mission statement\n- `documentation\u002Fplanning\u002F` — planning structure for skills\n- CLAUDE.md `## Shared Documentation` section — the shared-docs seam (Step 6.5)\n\nAlso scan for signals about the project:\n\n- `README.md` — project description, tech stack\n- `package.json`, `Cargo.toml`, `pyproject.toml`, `*.xcodeproj`, `go.mod` — tech stack detection\n- `.git\u002F` — is this a git repo?\n- Existing source directories — understand the project structure\n\nPresent findings:\n\n```\nProject Assessment\n═══════════════════════════════════════════════════════\n  Project root:    \u002Fpath\u002Fto\u002Fproject\n  Git repo:        yes\u002Fno\n  Tech stack:      [detected from manifest files]\n\n  CLAUDE.md:            ✓ exists \u002F ✗ missing\n  CHANGELOG.md:         ✓ exists \u002F ✗ missing\n  PROJECT_MISSION.md:   ✓ exists \u002F ✗ missing\n  documentation\u002F:       ✓ exists \u002F ✗ missing\n  Shared docs seam:     ✓ declared (\u003Croot path>) \u002F ✗ not declared\n═══════════════════════════════════════════════════════\n```\n\nIf everything already exists, tell the user and ask if they want to align any of it to the clauDNA template. If none exist, proceed to Step 2. If some exist, note which will be created vs. skipped.\n\n### Step 2: Gather Project Context\n\nAsk the user these questions (skip any that are obvious from Step 1):\n\n1. **Project name and one-line description**\n2. **Key commands** — build, lint, test, dev server (whatever applies)\n3. **Any known \"gotchas\"?** — things Claude should NOT do, common mistakes, domain-specific traps\n\nKeep the interview short. If the codebase is readable, infer what you can and confirm with the user rather than asking from scratch.\n\n### Step 3: Create CLAUDE.md\n\nGenerate `CLAUDE.md` using the template at [references\u002FCLAUDE_MD_TEMPLATE.md](references\u002FCLAUDE_MD_TEMPLATE.md).\n\n**Customization rules:**\n- Fill in the Project Overview section with real project details\n- Populate the Architecture section by scanning the actual directory structure (use `ls` and `Glob`). Show the real tree, not a placeholder.\n- Fill in Development Workflow with the actual commands from Step 2\n- Fill in Commands Reference with the actual commands\n- Add any gotchas from Step 2 to \"Things Claude Should NOT Do\"\n- Keep all static sections (Workflow Orchestration, Core Principles, etc.) exactly as templated — these are universal\n- Remove placeholder comments (`\u003C!-- Customize -->`) after filling in — but leave the commented `## Shared Documentation` block alone; Step 6.5 owns it\n\n**For large projects** (200+ lines after customization): Consider creating `.claude\u002Frules\u002F` files with `paths:` frontmatter to scope domain-specific rules to matching files. Keep CLAUDE.md under 200 lines — only universal rules and safety constraints.\n\n**Cache efficiency guidelines** (these affect prompt cache hit rates across every API call). For detailed scoring criteria (PASS\u002FWARN\u002FFAIL for each check), see [cache-checks.md](cache-checks.md) in this skill directory.\n- Static sections first, dynamic sections last. Add `\u003C!-- Static sections above, project-specific sections below. Keep this order for prompt cache efficiency. -->` at the boundary.\n- Keep CLAUDE.md under 200 lines (WARN). Over 350 lines is a FAIL — significant token cost per call.\n- Don't add instructions to edit CLAUDE.md mid-session — defer edits to session boundaries (`\u002Fclaudna:session handoff`).\n- Don't add instructions to switch models or tools mid-session — both invalidate the entire prompt cache.\n- If using `.claude\u002Frules\u002F`, ensure each file has `paths:` frontmatter (not `globs:`) to scope when each rule loads.\n\n**Do NOT:**\n- Leave `[bracket placeholders]` in the output\n- Remove static sections the user didn't ask about\n- Over-fill sections with speculation — empty with a note is better than wrong\n\n### Step 4: Create CHANGELOG.md\n\nGenerate `CHANGELOG.md` using the template at [references\u002FCHANGELOG_TEMPLATE.md](references\u002FCHANGELOG_TEMPLATE.md).\n\n**Customization rules:**\n- If this is a new project, create a single `## [Unreleased]` section\n- If the project has existing git history, create version sections from tags and populate with summaries of the commits\n- Use `git log --oneline` and `git tag` to build history\n- Follow the Keep a Changelog format: `### Added`, `### Fixed`, `### Changed`, `### Removed`, `### Refactored`\n- Entry format: `- **Feature Name** — Description`\n\n### Step 5: Create PROJECT_MISSION.md\n\nIf `PROJECT_MISSION.md` doesn't exist, create it. Use the project name and description from Step 2:\n\n```markdown\n# [Project Name] — Mission\n\n[One-paragraph mission statement: what this project does, who it's for, what success looks like.]\n```\n\nIf the user provided a clear description in Step 2, write a real mission statement. If not, create the stub and note that `\u002Fclaudna:product-vision` will flesh it out. This file anchors `\u002Fclaudna:product-vision` ideation and gives all skills a shared understanding of the project's purpose.\n\n### Step 6: Scaffold documentation\u002F\n\nIf `documentation\u002Fplanning\u002F` doesn't exist, create the standard planning structure. This is the shared directory layout that planning and audit skills write to (see `..\u002F_shared\u002Fdocumentation-standard.md` for the full spec).\n\nCreate these directories with `.gitkeep` files:\n\n```\ndocumentation\u002F\n├── planning\u002F\n│   ├── phases\u002F.gitkeep\n│   ├── tech_debt\u002F.gitkeep\n│   ├── security\u002F.gitkeep\n│   ├── access-paths\u002F.gitkeep\n│   ├── product-vision\u002F.gitkeep\n│   └── investigations\u002F.gitkeep\n├── decisions\u002F.gitkeep\n├── specs\u002F.gitkeep\n├── guides\u002F.gitkeep\n└── archive\u002F.gitkeep\n```\n\nIf `documentation\u002F` already exists, scan for missing subdirectories and create only what's missing.\n\n**Directory purposes:**\n- `planning\u002F` — project-owned docs explicitly exported by a user-selected `--output docs`; the default generated reports for `\u002Fclaudna:audit`, `\u002Fclaudna:product-enhance`, and `\u002Fclaudna:product-vision` live in the owning session's artifacts. Existing project planning files are not moved by setup.\n- `decisions\u002F` — Architecture Decision Records (ADRs). Why we chose X over Y. Permanent, not archived.\n- `specs\u002F` — Technical specifications, API contracts, data schemas. Living docs.\n- `guides\u002F` — Setup guides, onboarding, runbooks. Living docs.\n- `archive\u002F` — Completed planning sessions moved here after all phases merge.\n\n### Step 6.5: Shared Knowledge Seam\n\nProvision the `## Shared Documentation` CLAUDE.md section — the root that `\u002Fclaudna:recall` and `\u002Fclaudna:index` resolve. The section format, `(claudron vault)` annotation semantics, and env-over-section precedence are contract-bound in `..\u002F_shared\u002Fdocumentation-standard.md` §10 — write exactly that format.\n\n**Idempotency first.** If CLAUDE.md already has a `## Shared Documentation` section, show it and offer to update it by re-running the detection below — never write a second section. (The CLAUDE.md template ships the section as a commented placeholder — treat that as absent, and replace the commented block with the real section when writing.)\n\n**Pre-ladder: an existing raw tree via env.** If `SHARED_DOCS_PATH` is set (`printenv SHARED_DOCS_PATH`) and no vault resolves in (a), the raw tree already exists — offer to write the unannotated section with *that* path and skip the ladder; never scaffold a new default beside an env-declared root.\n\nDetect which of three states applies, in order:\n\n**(a) Vault resolvable.** `CLAUDRON_VAULT_PATH` is set (check with `printenv CLAUDRON_VAULT_PATH`), or `claudron` is on PATH (`command -v claudron`) and `claudron status --json` reports a vault path. Write the section with the resolved path (prefer the `~`-relative form when it's under the home directory) and the `(claudron vault)` annotation:\n\n```markdown\n## Shared Documentation\n\n~\u002Fvault  (claudron vault)\nCross-project knowledge lives here — see \u002Fclaudna:recall.\n```\n\nDetection is read-only (`claudron status` is safe to run). **Print-not-execute for anything mutating:** never run `claudron init`, `claudron migrate`, or any other writing claudron command — show the command and let the user run it.\n\n**(b) claudron present, no vault.** `claudron` is on PATH but no vault resolves (no env var, and `claudron status` exits non-zero with a stderr message — it never emits JSON on the no-vault path). Emit the standard degradation notice (`..\u002F_shared\u002Fclaudron-engine.md` §3.1 — the `\u002Fclaudna:init-project` row, `present-no-vault` wording), then print the remedy — do not run it, and do **not** scaffold a raw tree (it would shadow the vault the user is about to create):\n\n```\nclaudron is installed but no vault is initialized. Run:\n\n  claudron init ~\u002Fvault --personal\n\n(the path is where your vault will live — pick your own; if the command is\nrejected, the CLI has moved — `claudron --help` shows the current form) then\nre-invoke \u002Fclaudna:init-project — Step 6.5 will detect the vault and write\nthe CLAUDE.md section.\n```\n\nOffer to re-run this step's detection once the user has initialized.\n\n**(c) No claudron.** Emit the standard degradation notice (`..\u002F_shared\u002Fclaudron-engine.md` §3.1 — the `\u002Fclaudna:init-project` row, `absent` wording) so the user knows a vault was looked for and not found, rather than inferring it from being offered a raw tree. Then offer the minimal raw-tree scaffold. Ask where the shared root should live, defaulting to the **stable absolute `~\u002Fshared`** — never a cwd-relative sibling like `..\u002Fshared`, which fragments the store per parent directory. If the user picks a path *inside this repo*, warn once before proceeding: shared docs are cross-project by doctrine (documentation-standard §10) — an in-repo root silently scopes them to this repo. On yes:\n\n1. Create `\u003Croot>\u002Fknowledge\u002F\u003Crepo-name>\u002F`, `\u003Croot>\u002Fplanning\u002Factive\u002F`, and `\u003Croot>\u002Fdecisions\u002F` (`mkdir -p`).\n2. Invoke `\u002Fclaudna:index \u003Croot> --recursive` to write the stub INDEX.md files — index is the sole INDEX.md writer; don't write them by hand.\n3. Write the section into CLAUDE.md with the path only, **no annotation** (raw trees are INDEX-discovered):\n\n```markdown\n## Shared Documentation\n\n~\u002Fshared\nCross-project knowledge lives here — see \u002Fclaudna:recall.\n```\n\nThe scaffold is the only write this skill makes outside the project, and only at the path the user chose. If the user declines, skip the seam entirely and point at SETUP_GUIDE's \"Claudron Integration\" section for setting it up later.\n\n### Step 7: Verify & Confirm\n\nShow the user what was created:\n\n```\nProject Initialized\n═══════════════════════════════════════════════════════\n  Created:\n    ✓ CLAUDE.md              (N lines — project instructions)\n    ✓ CHANGELOG.md           (N lines — change history)\n    ✓ PROJECT_MISSION.md     (N lines — mission statement)\n    ✓ documentation\u002F         (10 directories: planning, decisions, specs, guides, archive)\n    ✓ Shared docs seam       (## Shared Documentation → ~\u002Fshared; raw tree scaffolded)\n\n  Skipped:\n    - CLAUDE.md (already exists)\n═══════════════════════════════════════════════════════\n```\n\nReport the seam line as whichever Step 6.5 branch ran: the annotated vault section, the raw-tree scaffold + section, printed `claudron init` guidance (nothing written), or skipped.\n\nAsk: **\"Want me to commit these files?\"**\n\nIf yes, stage only the created\u002Fmodified files and commit with:\n```\ndocs: initialize project configuration (CLAUDE.md, CHANGELOG.md, .claude\u002F, documentation\u002F)\n```\n\nA Step 6.5 raw-tree scaffold lives outside the repo — never stage it; only the CLAUDE.md section ships with the commit.\n\n---\n\n## Rules\n\n- **Never overwrite existing files without asking.** If `CLAUDE.md` already exists, ask before replacing or merging.\n- **Infer before asking.** Read the codebase first. Ask the user to confirm\u002Fcorrect, not to describe from scratch.\n- **Keep static sections intact and ordered first.** The Workflow Orchestration, Core Principles, and Task Management sections are universal clauDNA conventions. They must appear before project-specific dynamic sections for cache efficiency.\n- **Architecture must be real.** Scan the actual directory tree. Don't write a placeholder tree structure.\n- **CHANGELOG must reflect real history.** Use `git log` and `git tag`. Don't invent entries.\n\n---\n\n## Optional: Notification Setup (macOS)\n\nDuring Step 7, if the user is on macOS, mention notification options:\n\n**iTerm2 (recommended):** Profiles → Terminal → check \"Send notification when idle\" (set idle time to ~5 seconds). iTerm2 will alert when any terminal tab is waiting for input.\n\n**Hook-based:** The clauDNA plugin ships a notification hook in `plugin-hooks\u002Fhooks.json` that fires a macOS notification when Claude needs input. It activates automatically when the plugin is enabled.\n\n**Manual trigger:** `osascript -e 'display notification \"Message\" with title \"Claude Code\"'`\n\n**iTerm2 tab management tips:**\n- Right-click tab → \"Edit Tab Title\" to name Claude sessions\n- Right-click tab → \"Tab Color\" to color-code worktrees\u002Ftasks\n- Profiles → General → Badge → `\\(session.path)` for directory badges\n\nThis is informational context — do not block initialization on notification setup.\n",{"name":5,"requires":43,"description":7,"allowed-tools":47,"user-invocable":48,"disable-model-invocation":48},[44],{"cli":45,"reason":46},"claudron","Optional — Step 6.5 vault detection only; every ladder branch degrades when absent and announces it with the standard notice in ..\u002F_shared\u002Fclaudron-engine.md §3.1 (this is a soft dependency, not a functional requirement)","Read(*), Write(*), Edit(*), Glob(*), Grep(*), Bash(git log *), Bash(git tag *), Bash(ls *), Bash(mkdir *), Bash(command -v *), Bash(claudron status *)",true,"main","525fa1341307bedb4500dcb4865351f705f470dd","skills\u002Finit-project",1,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA","https:\u002F\u002Fgithub.com\u002FClaudfather","https:\u002F\u002Fcrog.gg","Rise of the machines","2026-11-15 02:10:52",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":48},[60,63,66],{"tool":61,"command":62},"npx","npx skills add Claudfather\u002FclauDNA --skill init-project",{"tool":64,"command":65},"bunx","bunx skills add Claudfather\u002FclauDNA --skill init-project",{"tool":67,"command":68},"pnpm","pnpm dlx skills add Claudfather\u002FclauDNA --skill init-project","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002FSKILL.md",[71,77,81,85],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"cache-checks.md","REFERENCE","参考文档",5504,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002Fcache-checks.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002FAGENTS_MD_TEMPLATE.md",1058,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002Freferences\u002FAGENTS_MD_TEMPLATE.md",{"path":82,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002FCHANGELOG_TEMPLATE.md",659,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002Freferences\u002FCHANGELOG_TEMPLATE.md",{"path":86,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002FCLAUDE_MD_TEMPLATE.md",3772,"https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Finit-project\u002Freferences\u002FCLAUDE_MD_TEMPLATE.md",[90,115,125,148,172,189],{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":38},"01M71T1STJ99BE1C0JYHCQW0XN","example-review","Use when you want to review pull requests with detailed, actionable feedback on code quality, correctness, and maintainability.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvalid-package\u002FSKILL.md",[],[97,98,99,100,101,102,103,104,29,105,30,106,107,108,109,110,111,112,113,114],"review","example","example review","actionable","pull requests","with","code","correctness","you","use","gh","gh pr","diff","view","pr","code quality","feedback","pull",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":121,"publishedAt":38},"01M71T1RMCD30MAJC954JC7580","bad-skill","Too short","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Ffailing-package\u002FSKILL.md",[],[122,123,124],"bad","bad skill","short",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":38},"01M71T1NS97NJ2MQ993V7FBES7","worktree","Use when starting feature work that needs isolation from the current workspace, or when running multiple Claude sessions in parallel on different branches — creates and manages git worktrees. For fetching latest main into every existing worktree and branch across your sibling repos, use \u002Fclaudna:sync-branches instead.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fworktree\u002FSKILL.md",[],[127,132,133,134,135,136,137,138,139,140,141,142,30,143,49,144,35,145,146,147],"sync","repos","git","isolation","running","sessions","worktrees","work","across","needs","git worktrees","claude sessions","branches","parallel","for","feature",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":38},"01M71T1HNVG1CZY8P904P6RB7P","weigh-development-paths","Use when at a development junction with multiple viable approaches — architecture choices, refactoring strategies, where to put new code, or which pattern to follow. Triggers on 'which approach', 'how should I', 'Option A vs B', or any point where the next step isn't obvious and the wrong choice creates rework.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fweigh-development-paths\u002FSKILL.md",[],[155,156,157,158,159,160,161,162,163,164,165,166,167,103,30,168,31,169,170,171],"development","weigh development paths","paths","next step","path","refactoring","choice","pattern","at","how","next","strategies","architecture","auto","junction","option","which",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":38},"01M71T1ECV1T5E168GH70AY5B3","verify-completion","Use when about to claim work is complete, fixed, or passing -- requires running verification commands and confirming output before making any success claims.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fverify-completion\u002FSKILL.md",[],[179,180,181,182,136,183,184,185,139,186,187,188,30,106],"verify completion","verify","claim","complete","true","commands","about","verification","claims","output",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":200,"publishedAt":38},"01M71T1BC1HA7XQH0Q1H574FYS","vercel","Use for Vercel operations — deploy to production or preview (or roll back), view, filter, or debug deployment logs, or check project status (deployments, domains, env vars, config). Replaces \u002Fvercel-deploy, \u002Fvercel-logs, \u002Fvercel-status.","https:\u002F\u002Fgithub.com\u002FClaudfather\u002FclauDNA\u002Fblob\u002Fmain\u002Fskills\u002Fvercel\u002FSKILL.md",[195],{"categoryNo":196,"categoryName":197,"taxonomyType":198,"taxonomyTypeDesc":199},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[191,201,202,203,204,205,206,207,208,106,209,183,210,211,212,20,146,110,213,214],"inspection","check","filter","env","logs","preview","debug deployment","debug","deployments","domains","deployment","env vars","project status","back"]