[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHW63B3VE05RNX0184R0E4":3,"skill-same:01M6CHW63B3VE05RNX0184R0E4":91},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":30,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":75,"ownerHtmlUrl":76,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":77,"install":78,"resources":90},"01M6CHW63B3VE05RNX0184R0E4","init",null,"[ADD v0.11.0] Initialize Agent Driven Development — PRD interview + project setup","MountainUnicorn\u002Fadd","MountainUnicorn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199411549?v=4","01M6CHRAWFWD275ANP1S2A0HXC","01M6CHRB0QE1678D913B438SAR",11,"MIT","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Finit\u002FSKILL.md",[17,22,27],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":28,"categoryName":29,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000038","人力资源",[5,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"Rules","agent driven development","project setup","v0","interview","initialize","edit","write","read","grep","Bash","templates","prd","examples","registry","development","setup","telemetry","sync","2026-11-10 10:12:30",false,"---\ndescription: \"[ADD v0.11.0] Initialize Agent Driven Development — PRD interview + project setup\"\nargument-hint: \"[--reconfigure] [--quick] [--defaults] [--sync-registry]\"\nallowed-tools: [Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion]\nreferences: [\"maturity-matrix.md\", \"skill-epilogue.md\", \"rules\u002Ftelemetry.md\", \"templates\u002Finit-interview.md\", \"templates\u002Finit-output-examples.md\"]\ndisable-model-invocation: true\n---\n\n# ADD Init Command v0.11.0\n\nInitialize Agent Driven Development for this project. This command conducts a structured interview to understand the project, then scaffolds the full ADD framework.\n\n## Modes\n\n| Flag | Purpose | Questions | Target user |\n|---|---|---|---|\n| (none) | Full interview — detects adoption vs greenfield, runs Phases 0-5 | ~12 | New projects with non-trivial scope or existing codebases |\n| `--quick` | Greenfield fast path — 5 essential questions, sensible defaults elsewhere | 5 | Prototypes, solo projects, time-constrained onboarding |\n| `--defaults` | True non-interactive init — every value derived or defaulted, zero questions | 0 | Headless sessions (`claude -p`, `codex exec`), CI pipelines |\n| `--reconfigure` | Re-run interview preserving existing answers as defaults | ~12 | Updating an already-initialized project |\n| `--sync-registry` | Read-only: reconcile `~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json` with ground truth | 0 | Fixing drift detected by the registry-sync rule |\n\n## Quick Mode (`--quick`)\n\nGreenfield fast path. Skips adoption detection, skips profile-derived questions, and defaults anything that isn't one of the 5 essential answers. Use when you want ADD initialized in ~2 minutes.\n\n### The 5 questions\n\n1. **Name** — \"Project name? (defaults to directory basename: `{current_dir_name}`)\"\n2. **Languages \u002F frameworks** — \"What's the primary stack? (e.g., 'python+fastapi', 'typescript+react', 'go', 'rust+axum')\"\n3. **Environment tier** — \"Deployment scope: 1 (local only), 2 (local + prod), or 3 (local + dev + staging + prod)? (default: 2)\"\n4. **Maturity** — \"Project maturity: poc, alpha, beta, or ga? (default: alpha)\"\n5. **Autonomy** — \"Agent autonomy level: guided (ask often), balanced (default), or autonomous (trust)? (default: balanced)\"\n\n### Defaults applied\n\nEverything else that the full interview asks is defaulted:\n\n| Area | Quick-mode default |\n|------|-------------------|\n| PRD depth | 1-pager generated from (name, stack, scope-paragraph prompt) |\n| Quality mode | `strict` for beta\u002Fga, `standard` for alpha, `spike` for poc |\n| CI\u002FCD provider | Inferred from `.github\u002F` if present, otherwise `none` |\n| Commit convention | Conventional commits |\n| Protected branches | `[main]` |\n| Coverage threshold | 80% at beta\u002Fga, 50% at alpha, 0 at poc |\n| Branding palette | Default ADD raspberry (`#b00149`) until `\u002Fadd:brand` is run |\n| Image generation | `enabled: false, nudged: false` |\n\n### What `--quick` skips\n\n- Adoption mode detection (Phase 0) — not relevant for greenfield\n- Cross-spec consistency check — no specs yet\n- Profile-integration confirmation prompts — profile defaults applied silently\n- PRD interview (Phase 1 Sections 3-7) — replaced by \"scope paragraph\" prompt at the end\n- Swarm\u002Fworktree config questions — set by maturity default\n\n### What `--quick` still does\n\n- Writes `.add\u002Fconfig.json`, `.add\u002Flearnings.json` (empty), `docs\u002Fprd.md` (1-pager), `specs\u002F` (dir), `docs\u002Fplans\u002F` (dir)\n- Bumps project registry (`~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json`)\n- Validates that maturity + tier combination is sensible (e.g., warns if `maturity=ga` + `tier=1`)\n- Runs Phase 4 Cross-Project Persistence (same as full interview)\n\n### Upgrade path\n\nAfter quick init, the user can always run `\u002Fadd:init --reconfigure` for the full interview, or run `\u002Fadd:spec` to start formalizing features. Specs created under a quick-init project are no different from specs created under full init.\n\n## Defaults Mode (`--defaults`)\n\nTrue non-interactive init. Asks **zero** questions — no AskUserQuestion calls, no interview turns, no confirmation prompts. Every value is derived from the project or defaulted. Designed for headless one-shot sessions (`claude -p \"\u002Fadd:init --defaults\"`, `codex exec \"\u002Fadd-init --defaults\"`) and CI pipelines, where there is no second turn to answer a question in.\n\n### Existing-config guard\n\nBefore doing anything else, check for `.add\u002Fconfig.json`. If it exists, print a notice and stop — touch nothing:\n\n```\n.add\u002Fconfig.json already exists — \u002Fadd:init --defaults never overwrites an\ninitialized project. Run \u002Fadd:init --reconfigure to refresh the configuration.\n```\n\n### Values derived\n\n| Field | Defaults-mode value |\n|------|-------------------|\n| Project name | Basename of the current working directory |\n| Language | Auto-detected from manifest files: `package.json` → typescript (if `tsconfig.json` or TS deps) else javascript, `pyproject.toml`\u002F`setup.py` → python, `go.mod` → go, `Cargo.toml` → rust, `Gemfile`\u002F`*.gemspec` → ruby; fallback `unknown` |\n| Environments | `[\"local\"]`, no autoPromote |\n| Maturity | `poc` (greenfield) or the evidence-based detected level (adoption path) — no confirmation question either way |\n| Operating mode | `autonomous` |\n| Scope paragraph | Omitted — PRD stub notes \"run \u002Fadd:spec to define scope\" |\n| Quality mode, coverage, branding, etc. | Same defaults table as `--quick` |\n\n### What `--defaults` skips\n\n- The entire interview (Phases 0-1 questions) — adoption vs greenfield is still auto-detected, but the findings\u002Fassessment panels are informational only, never confirmation prompts\n- The maturity confirmation — the detected (or `poc`) level is applied directly\n- The scope-paragraph prompt that `--quick` asks at the end\n- All profile-integration, rule-overlap, and CLAUDE.md-overwrite questions — apply the non-destructive default silently (append, never overwrite)\n\n### What `--defaults` still does\n\n- Writes `.add\u002Fconfig.json`, `.add\u002Flearnings.json` (empty), `docs\u002Fprd.md` (stub noting \"run \u002Fadd:spec to define scope\"), `specs\u002F` (dir), `docs\u002Fplans\u002F` (dir)\n- Bumps the project registry (`~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json`)\n- Runs Phase 4 Cross-Project Persistence promptlessly — reads an existing profile if present, never creates or modifies one (profile creation requires the interview)\n- Composes with `--sync-registry` unchanged\n\n### Upgrade path\n\nSame as `--quick`: run `\u002Fadd:init --reconfigure` any time for the full interview, or `\u002Fadd:spec` to start formalizing features.\n\n## Sync Registry Mode (`--sync-registry`)\n\nReconciles `~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json` against the project's ground truth. Triggered automatically by the `registry-sync.md` rule when drift is detected at session start, or manually by the user.\n\nRead-only in the project; writes only to the cross-project registry file. Shows a diff before writing:\n\n```\nREGISTRY RECONCILIATION for {project}:\n  learnings_count: 5 → 55\n  last_retro: null → {date}\n  maturity: alpha → beta\n\nApply? [yes\u002Fno]\n```\n\nDoes not run the interview. Does not touch `.add\u002Fconfig.json`.\n\n## Pre-Flight Check\n\n1. Check if `.add\u002Fconfig.json` already exists\n2. If exists AND no `--reconfigure` flag, display current config summary and ask if reconfiguration is wanted\n3. If exists AND `--reconfigure` flag, proceed with interview (preserving existing answers as defaults)\n4. If exists AND `--defaults` flag, print the existing-config notice (see Defaults Mode) and exit without touching anything\n\n### User Profile Detection\n\nCheck if `~\u002F.claude\u002Fadd\u002Fprofile.md` exists. This file carries preferences across projects.\n\nAlso check `~\u002F.claude\u002Fadd\u002Flibrary.md` for cross-project learnings and\n`~\u002F.claude\u002Fadd\u002Fprojects\u002F` for previous project history.\n\n**If profile exists:**\nRead it and use preferences as defaults throughout the interview. Also read\n`~\u002F.claude\u002Fadd\u002Flibrary.md` for cross-project knowledge. Announce this:\n```\nI found your ADD profile with preferences from previous projects.\nI'll use these as defaults — you can override anything during the interview.\n\nYour profile preferences:\n  Stack: {languages, frameworks from profile}\n  Cloud: {provider from profile}\n  Process: {autonomy, quality mode from profile}\n\nPrevious ADD projects: {list from ~\u002F.claude\u002Fadd\u002Fprojects\u002F}\n```\nThis can dramatically shorten the interview — if the profile matches, Section 2 might only be 2-3 confirmation questions instead of 6-8.\n\n**If no profile exists:**\nThis is a first-time ADD user. After the interview, offer to create one:\n```\nThis is your first ADD project. After setup, I can create a user\nprofile (~\u002F.claude\u002Fadd\u002Fprofile.md) so future projects inherit your\npreferences and the interview gets shorter. Want me to create it?\n```\n\n## Phase 0: Discovery (Adoption Mode — Automatic Detection)\n\nIf `.add\u002Fconfig.json` does NOT exist AND the project contains existing project files (CLAUDE.md, .claude\u002F, specs\u002F, tests\u002F, CI\u002FCD, docker-compose.yml, git history, etc.), automatically enter **adoption mode**. This is non-destructive — ADD absorbs and complements existing methodology.\n\n### Automatic Detection Checklist\n\nSilently scan the project for existing methodology without asking the user:\n\n```\n□ CLAUDE.md — read it, extract project description and existing commands\n□ .claude\u002Frules\u002F — list existing rules, note coverage areas\n□ .claude\u002Fskills\u002F — list existing skills, note what ADD would add\n□ .claude\u002Fsettings.json — read permissions\n□ specs\u002F or .add\u002Fspecs\u002F — list existing feature specifications\n□ docs\u002F or docs\u002Fplans\u002F — list existing implementation plans\n□ tests\u002F — identify test framework, coverage, directory structure\n□ .github\u002Fworkflows\u002F — identify CI\u002FCD pipelines\n□ .gitlab-ci.yml \u002F Jenkinsfile — alternative CI\u002FCD\n□ docker-compose.yml — identify containerization strategy\n□ Dockerfile — identify containerization\n□ package.json \u002F pyproject.toml \u002F Cargo.toml \u002F go.mod — identify stack\n□ .git\u002Fconfig — identify git remote host and repository\n□ .pre-commit-config.yaml — identify existing git hooks\n□ .env.example — identify environment variables and secrets strategy\n□ PROJECT_STATUS.md or similar — identify session tracking \u002F status history\n```\n\n### Present Adoption Findings to User\n\nAfter silent detection (and the maturity assessment below), show the user a structured summary of what exists vs. what ADD adds: existing methodology, existing infrastructure, what ADD would add (non-destructive), what ADD would preserve untouched — then ask \"Proceed with adoption?\". Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Adoption Findings Panel).\n\n### Maturity Level Detection\n\nAssess project maturity using evidence-based scoring. This assessment is BINDING — maturity is determined by what the project actually demonstrates, not by aspiration.\n\n#### Evidence Scoring\n\nScore each of these 12 evidence categories as present or absent (git timestamps, configs, and CI files are the detection sources): specs, tests, coverage threshold (20% = alpha signal, 50% = beta, 80% = ga), CI\u002FCD pipeline, PR-based branching, conventional commits (sample last 20 commits), environment separation, release tags, protected branches, TDD evidence (tests predate\u002Faccompany implementation), spec-driven evidence (specs predate implementation), and quality gates (pre-commit hooks, CI checks, linting).\n\nScoring: **POC** 0–2 items · **Alpha** 3–5 · **Beta** 6–8 · **GA** 9+.\n\nFor the full maturity cascade matrix and promotion process, see `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fmaturity-matrix.md`.\n\n#### Assessment Output\n\nPresent the assessment authoritatively — do NOT ask the user to confirm or override the level. Compact example:\n\n```\nMATURITY ASSESSMENT (evidence-based):\n  Your project operates at: ALPHA\n  Evidence: ✓ tests (47% coverage) ✓ CI\u002FCD ✓ conventional commits · ✗ 9 other items\n  Score: 3\u002F12 evidence items → ALPHA\n  Gap to Beta: specs (\u002Fadd:spec), coverage >50%, PR workflow, 2+ environments, TDD evidence\n```\n\nRender the full panel (per-item ✓\u002F✗ list, gap checklist, promotion note) per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Maturity Assessment Panel).\n\nIf the user disagrees with the assessment, explain that ADD maturity is evidence-based and that promotion happens through `\u002Fadd:retro` when criteria are met. The user can start at the detected level and promote quickly if the project genuinely meets higher criteria.\n\n### Adoption-Mode Interview (Shorter and Smarter)\n\nAdoption mode runs a SHORTER interview because many answers are detected:\n\n**Section 1 (Product):**\nIf CLAUDE.md exists with a project description, skip most questions. Just confirm:\n```\nFrom your CLAUDE.md, I understand this project:\n{Extracted description from CLAUDE.md}\n\nIs that still accurate? Anything to add or clarify?\n```\n\nOtherwise, run standard Section 1 questions (4 questions, ~3 min).\n\n**Section 2 (Architecture):**\nNearly all answers are detected from project files. Just run confirmations:\n```\nI detected your tech stack from your project files:\n  Language: {detected}\n  Backend: {detected}\n  Frontend: {detected}\n  Database: {detected}\n  Containers: {detected}\n  Git: {detected}\n  CI\u002FCD: {detected}\n\nDoes this match your current setup? Anything to add or correct?\n```\n\nThen ask the 3 process questions from Section 3 (autonomy, quality mode, team size).\n\n**Total adoption interview: ~5-8 questions, ~5 minutes** (vs. 14-16 questions in greenfield mode).\n\n### Handling Existing Rules\n\nADD's rules are NOT copied into the project — they are injected each session by the plugin's SessionStart hook (`load-rules.sh`), maturity-gated, and update automatically with the plugin. `\u002Fadd:init` never writes to `.claude\u002Frules\u002F`.\n\nFor each existing rule in the project's `.claude\u002Frules\u002F`, check for overlap with ADD's rule set:\n\n- **If an existing project rule covers similar ground as an ADD rule:** Ask the user:\n  ```\n  You have an existing rule: {existing_rule.md}\n  This covers similar ground as ADD's {add_rule} (injected automatically each session).\n\n  Options:\n    a) Keep your rule as-is — it takes precedence where they conflict\n    b) Trim your rule to only the parts ADD doesn't cover\n    c) Remove your rule — rely on ADD's injected version\n  ```\n\n- **If a stale ADD rule copy exists** (same name as a plugin rule, or `add-` prefixed — left behind by an ADD version before v0.9.11 that copied rules): recommend removal, since the hook now injects the current version and the copy will drift:\n  ```\n  .claude\u002Frules\u002F{name}.md matches an ADD plugin rule. ADD now injects rules\n  at session start — this copy is redundant and will go stale. Remove it?\n  ```\n\n### Handling Existing Skills\n\nFor each ADD skill (e.g., `\u002Fadd:spec`, `\u002Fadd:plan`, `\u002Fadd:away`, `\u002Fadd:back`, `\u002Fadd:retro`):\n\n- **If project has equivalent skill:** Ask:\n  ```\n  You have an existing skill: {existing_skill}\n  ADD provides {add_skill} which extends this.\n\n  Keep yours, use ADD's, or should I merge them?\n  ```\n\n- **If project doesn't have it:** Add the ADD skill to `.claude\u002Fskills\u002F`.\n\n- **Priority:** Project's existing skills are preferred unless the user wants ADD's version or a merge.\n\n### Non-Destructive CLAUDE.md\n\n**NEVER overwrite an existing CLAUDE.md.**\n\nInstead, append an ADD methodology section at the end:\n\n```markdown\n## ADD Methodology\n\nThis project follows Agent Driven Development (ADD) for structured code generation and knowledge persistence.\n\n**Configuration:** `.add\u002Fconfig.json`\n**Knowledge Base:** `.add\u002Flearnings.md` (auto-populated during development)\n**Quality Gates:** Enforced via `\u002Fadd:verify` command\n**Workflow:** `\u002Fadd:spec` → `\u002Fadd:plan` → `\u002Fadd:tdd-cycle` → `\u002Fadd:retro`\n\nSee `.add\u002Fconfig.json` for detailed settings.\n```\n\n### Retroactive Specs Import\n\nIf the project already has specs in a custom location (e.g., `specs\u002Fspike\u002F`, `doc\u002Fspecs\u002F`, or other):\n\n- **DON'T move or rename them.**\n- **DO** create `.add\u002Fconfig.json` pointing to the existing specs directory:\n  ```json\n  \"specs_directory\": \"specs\u002Fspike\u002F\",\n  \"specs_format\": \"markdown\"\n  ```\n\n- Ask the user:\n  ```\n  Your feature specs are currently in {location}.\n  Should I continue using that directory for ADD specs,\n  or create a fresh specs\u002F directory for ADD-formatted specs?\n  ```\n\n### Retroactive Learnings Seeding\n\nFor mature projects, seed `.add\u002Flearnings.md` with initial knowledge instead of a blank template:\n\n1. **Read CLAUDE.md** for documented patterns, architectural decisions, and conventions.\n2. **Scan git log** (last 30 commits) for common issues, bugs, and fixes.\n3. **Read PROJECT_STATUS.md** (if exists) for session history and lessons learned.\n4. **Extract patterns:** Identify recurring problems, solutions, and anti-patterns.\n\nPresent the seed entries to the user for confirmation:\n\n```\nI've extracted initial learnings from your project history:\n\nPATTERNS & CONVENTIONS:\n  - {pattern 1 from CLAUDE.md}\n  - {pattern 2 from git history}\n\nCOMMON ISSUES & SOLUTIONS:\n  - {issue 1} → {solution from git log}\n  - {issue 2} → {solution from recent commits}\n\nThese will populate .add\u002Flearnings.md as the starting knowledge base.\nAny additions or corrections before I finalize?\n```\n\n### Catch-Up Spike Generation\n\nAfter confirming maturity level and completing the adoption interview, generate a gap analysis comparing current project state against the confirmed maturity level requirements (per the cascade matrix in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fmaturity-matrix.md`):\n\n```\nCATCH-UP ANALYSIS: Bringing {project} to {MATURITY} compliance\n\nREQUIRED FOR {MATURITY}:                    STATUS:\n  PRD document                               {✓ exists | ✗ missing}\n  Feature specs                              {✓ N specs found | ✗ missing for N features}\n  Implementation plans                       {✓ N plans found | ✗ missing}\n  Quality gates configured                   {✓ N gates active | ✗ not configured}\n  TDD coverage at threshold                  {✓ N% meets threshold | ✗ N% below threshold}\n  CI\u002FCD pipeline                             {✓ active | ✗ not found | ○ not required at this level}\n  Milestone structure                        {✓ found | ✗ missing | ○ not required at this level}\n  Source control workflow                    {✓ matches | ⚠ partial | ✗ missing}\n\nSCORE: {N}\u002F{TOTAL} requirements met\n\nCATCH-UP ITEMS (if score \u003C 100%):\n  1. {item — e.g., \"Generate docs\u002Fprd.md from existing CLAUDE.md + brief interview\"}\n  2. {item — e.g., \"Create retroactive specs for auth, billing features\"}\n  3. {item — e.g., \"Configure 3-gate quality pipeline\"}\n```\n\nIf catch-up items exist, ask:\n```\nI can generate a catch-up cycle to bring your project to {MATURITY} compliance.\nThis would take approximately {estimate} of autonomous work.\n\nOptions:\n  a) Run catch-up spike now (I'll work autonomously)\n  b) Save as first cycle plan (you review first)\n  c) Skip — I'll adopt ADD alongside your existing workflow\n```\n\nIf option (a) or (b):\n- Create `.add\u002Fcycles\u002Fcycle-0-catchup.md` with the gap items as work items\n- For (a): execute immediately, report back when done\n- For (b): save plan, wait for human review\n\n### Adoption Summary\n\nDisplay what was newly created, what was enhanced, what was preserved exactly as-is, the resulting configuration (stack, tier, quality, autonomy), and next steps. Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Adoption Summary Panel).\n\n## Phase 1: The Interview\n\nConduct a structured 1-by-1 interview following the human-collaboration rule. Always estimate total questions upfront.\n\n### Greeting\n\n```\nWelcome to Agent Driven Development (ADD).\n\nI'll interview you across 4 sections to understand your project:\n  Section 1: Product (4 questions, ~3 min)\n  Section 2: Architecture & Tech Stack (6-8 questions, adaptive, ~5 min)\n  Section 2.5: Branding (1-2 questions, ~1 min)\n  Section 3: Process & Collaboration (5 questions, ~4 min)\n\nTotal: approximately 16-19 questions, ~12 minutes.\nSome questions are adaptive — I'll skip what I can detect automatically.\n\nYour answers will generate:\n  - docs\u002Fprd.md (Product Requirements Document)\n  - .add\u002Fconfig.json (project configuration)\n  - .claude\u002Fsettings.json (Claude Code settings)\n  - specs\u002F directory (for feature specifications)\n  - docs\u002Fplans\u002F directory (for implementation plans)\n\nLet's begin.\n```\n\n### Question Bank\n\nLoad the question bank — verbatim Q1–Q18 prompts plus AskUserQuestion options — from `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-interview.md`. Ask questions ONE AT A TIME, building on previous answers. Phase structure and branching logic:\n\n**Section 1: Product (Q1–Q4, ~4 questions)**\nProblem\u002Fvalue proposition (Q1), primary users (Q2), success metrics (Q3), MVP scope in\u002Fout (Q4).\n\n**Section 2: Architecture & Tech Stack (Q5–Q13, ~6-8 questions, adaptive)**\n\nBefore asking tech questions, run the silent detection step (do not show to user): check for package.json, pyproject.toml\u002Frequirements.txt, Cargo.toml, go.mod, pom.xml\u002Fbuild.gradle, docker-compose.yml, Dockerfile, .github\u002Fworkflows\u002F, .gitlab-ci.yml, Jenkinsfile, .git\u002Fconfig, terraform\u002F.tf files, Makefile\u002Fjustfile. If project files are detected, summarize what you found before asking Q5.\n\n- **Q5 (The Branch Question)** determines whether Q6–Q8 are prescriptive (human tells) or advisory (Claude suggests). Three branches:\n  - \"Detect from project files\" → present the detected stack for confirmation, skip Q6–Q7.\n  - \"Suggest a stack\" → propose per the heuristics in the question bank based on Section 1 answers; human approves\u002Fmodifies.\n  - \"I have a stack in mind\" → ask Q6 (languages + versions) and Q7 (frameworks). If answers are vague (\"Python\" with no version), probe for the version.\n- **Q8 (all paths converge): source control & hosting** — confirm if a `.git\u002Fconfig` remote is detected, otherwise ask.\n- **Q9: environment tier** (Tier 1 local \u002F Tier 2 local+prod \u002F Tier 3 full pipeline), then **Q10: tier-dependent deployment details** (Tier 1: run command; Tier 2: cloud provider + production URL; Tier 3: per-environment infrastructure walkthrough).\n- **Q11: CI\u002FCD** — confirm if detected; \"None yet — set it up for me\" means scaffold a basic pipeline during Phase 2.\n- **Q12: containerization** — confirm if detected, otherwise ask.\n- **Q13: additional technical constraints** (auth, compliance, performance, integrations).\n\n**Section 2.5: Branding (Q13.5, ~1 min)**\n\"Yes — let me share it\" → parse hex color, fonts, tone, logo path, and style-guide source into `branding.*`, generating the palette per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fpresets.json`. \"No — use ADD defaults\" → raspberry preset (#b00149) from presets.json, optionally offering the preset picker (Raspberry \u002F AI Purple \u002F Ocean \u002F custom hex). Branding can always be updated later with `\u002Fadd:brand-update`.\n\n**Section 3: Process & Collaboration (Q14–Q18, ~4 min)**\n\n- **Q14: maturity level** — branching:\n  - **Adoption mode** (Phase 0 detected existing project): SKIP Q14 entirely; use the evidence-based level from Phase 0, and note \"Maturity level was determined by evidence analysis in Phase 0. Skipping maturity question.\"\n  - **Greenfield mode:** cap at Alpha maximum — a brand new project has zero evidence for Beta or GA (promote via `\u002Fadd:retro` when criteria are met). If POC is selected, explain the relaxed process per the question bank.\n- **Q15: autonomy** (guided \u002F balanced \u002F autonomous), **Q16: quality standard** (spike \u002F standard \u002F strict — sets coverage threshold), **Q17: team size** (sets branching + PR strategy), **Q18: existing patterns\u002Fconventions** (default: ADD defaults).\n\n### Interview Complete\n\n```\nThanks for the thorough answers. I have everything I need to set up ADD.\n\nGenerating:\n  1. docs\u002Fprd.md — your Product Requirements Document\n  2. .add\u002Fconfig.json — project configuration\n  3. Project directories and scaffolding\n```\n\n## Phase 2: Scaffold Project Structure\n\nThe standard ADD layout. See `${CLAUDE_PLUGIN_ROOT}\u002Frules\u002Fproject-structure.md` for the full specification.\n\n### Step 2.1: Create Project Directories\n\n```bash\n# ADD methodology directories (committed to git)\nmkdir -p .add .add\u002Fretros .add\u002Faway-logs\n\n# Specification and planning directories\nmkdir -p specs docs\u002Fplans\n\n# Milestone and cycle tracking\nmkdir -p docs\u002Fmilestones .add\u002Fcycles\n\n# Test artifact directories\nmkdir -p tests\u002Fscreenshots tests\u002Fscreenshots\u002Ferrors tests\u002Fe2e tests\u002Funit tests\u002Fintegration\n\n# Claude Code config\nmkdir -p .claude\n```\n\n### Step 2.1.1: Scaffold CHANGELOG.md\n\nIf `CHANGELOG.md` does not already exist in the project root, create it from the changelog template:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fchangelog.md.template`\n2. Write it to `CHANGELOG.md` in the project root\n\nThis gives the project a Keep a Changelog-formatted changelog from day one. The `\u002Fadd:changelog` command and the push hook will populate it automatically as development proceeds.\n\n### Step 2.2: Create Cross-Project Directories (machine-local)\n\n```bash\n# ADD user-level persistence (outside any project)\nmkdir -p ~\u002F.claude\u002Fadd ~\u002F.claude\u002Fadd\u002Fprojects\n```\n\n### Step 2.3: Update .gitignore\n\nAppend ADD-specific entries if not already present:\n\n```gitignore\n# ADD — ephemeral artifacts (don't commit)\n.add\u002Faway-logs\u002F\ntests\u002Fscreenshots\u002Ferrors\u002F\n\n# ADD — these SHOULD be committed (don't ignore)\n# .add\u002Fconfig.json\n# .add\u002Flearnings.md\n# .add\u002Fretros\u002F\n# specs\u002F\n# docs\u002Fplans\u002F\n# tests\u002Fscreenshots\u002F{feature}\u002F\n```\n\n## Phase 2.5: Verify Rule Loading (no copying)\n\nADD rules are NOT copied into the project. The plugin's SessionStart hook (`load-rules.sh`) injects the active rule set every session, gated by the project's maturity level — rules stay current with the plugin and never drift. (Versions before v0.9.11 copied 10 rules into `.claude\u002Frules\u002F`; that mechanism is retired because copies went stale and, after v0.9.9, duplicated the hook injection.)\n\nThis phase only checks for leftovers:\n\n1. If `.claude\u002Frules\u002F` exists, list its files and compare basenames against `${CLAUDE_PLUGIN_ROOT}\u002Frules\u002F` (also match `add-` prefixed variants).\n2. For each match — a stale ADD copy from an older init — ask the user once (batch, not per-file):\n   ```\n   Found {N} ADD rule copies in .claude\u002Frules\u002F from an earlier ADD version:\n   {list}\n   ADD now injects current rules at session start, so these are redundant\n   and will go stale. Remove them? (user-authored rules are untouched)\n   ```\n3. Track for the Phase 5 summary: **Removed** \u002F **Kept** (user declined).\n\n## Phase 3: Generate Configuration Files\n\n### Step 3.1: Generate .add\u002Fconfig.json\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fconfig.json.template and fill in all placeholders with interview answers. Use the Write tool.\n\nEnsure the generated config includes the `maturity` field:\n```json\n{\n  \"maturity\": {\n    \"level\": \"{poc|alpha|beta|ga}\",\n    \"promoted_from\": null,\n    \"promoted_date\": null,\n    \"next_promotion_criteria\": \"{what's needed for the next level}\"\n  }\n}\n```\n\n### Step 3.2: Generate docs\u002Fprd.md\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fprd.md.template and fill in all placeholders with interview answers. Write a real PRD — don't leave template placeholders. Every section should have substantive content based on the interview answers.\n\n### Step 3.3: Generate .claude\u002Fsettings.json (if it doesn't exist)\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fsettings.json.template. Customize permissions based on the tech stack detected.\n\nThe template includes a `statusLine` configuration that displays `\u002FADD:enabled` in the Claude Code status bar (with \"ADD\" in raspberry #b00149). This provides an at-a-glance indicator that the project is ADD-managed. If the user already has a custom `statusLine` in their settings, ask before overwriting it.\n\n### Step 3.4: Generate CLAUDE.md (if it doesn't exist)\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002FCLAUDE.md.template. Fill in project-specific information:\n- Project name and description (from Q1)\n- Tech stack (from Section 2)\n- Key commands (run, test, lint, deploy per stack)\n- Environment info (tier, URLs, deploy triggers)\n- Quality gates (mode, thresholds)\n- Standard directory layout\n- Link to docs\u002Fprd.md\n\nIf CLAUDE.md already exists, ask before overwriting. Offer to append ADD-specific sections instead.\n\n### Step 3.5: Generate .add\u002Flearnings.md\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Flearnings.md.template and fill in the project name. This is the knowledge base that agents build over time through automatic checkpoints. Committed to git so it transfers between devices.\n\n### Step 3.6: Generate AGENTS.md\n\nInvoke `\u002Fadd:agents-md` to generate a portable `AGENTS.md` at project root. This is the cross-tool open standard — any agent (Cursor, Codex CLI, Copilot, Windsurf, etc.) reading the repo will pick it up. Generation is maturity-aware: POC projects get a minimal bullet summary, Alpha+ projects get a sectioned doc. If an `AGENTS.md` already exists without the ADD marker block, skip this step and recommend the user run `\u002Fadd:agents-md --merge` after init completes.\n\n## Phase 4: Cross-Project Persistence\n\n### Step 4.1: User Profile\n\nIf `~\u002F.claude\u002Fadd\u002Fprofile.md` does NOT exist and the user agreed to create one:\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fprofile.md.template, fill in preferences from the interview, and write to `~\u002F.claude\u002Fadd\u002Fprofile.md`.\n\nIf profile already exists, do NOT modify it — profile updates only happen during `\u002Fadd:retro`.\n\n### Step 4.2: Project Index Entry\n\nWrite a snapshot to `~\u002F.claude\u002Fadd\u002Fprojects\u002F{project-name}.json`:\n\n```json\n{\n  \"name\": \"{PROJECT_NAME}\",\n  \"path\": \"{ABSOLUTE_PROJECT_PATH}\",\n  \"initialized\": \"{DATE}\",\n  \"last_retro\": null,\n  \"stack\": [\"{lang-version}\", \"{framework}\", ...],\n  \"tier\": {N},\n  \"cloud\": \"{provider}\",\n  \"key_learnings\": []\n}\n```\n\nThis lets future `\u002Fadd:init` calls on new projects reference your history:\n\"I see you worked on {project} with {stack}. Similar setup here?\"\n\n### Step 4.3: Cross-Project Library\n\nIf `~\u002F.claude\u002Fadd\u002Flibrary.md` does NOT exist, create it from ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Flibrary.md.template.\nIf it exists, leave it alone — it's updated during `\u002Fadd:retro`.\n\n## Phase 5: Summary\n\nDisplay an \"ADD initialized successfully\" panel covering: project structure created (per-file ✓ list), rules installed \u002F skipped \u002F prefixed (from Phase 2.5 tracking), cross-project files, the 3-tier knowledge cascade (plugin-global `knowledge\u002Fglobal.md` → user-local `~\u002F.claude\u002Fadd\u002Flibrary.md` → project `.add\u002Flearnings.md`), the resolved configuration (stack, infrastructure, tier, maturity, quality + coverage threshold, autonomy, branching), and what's committed vs machine-local (with the `\u002Fadd:init --import` note). Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Phase 5 Init Summary Panel).\n\n### Persona-Aware Next Steps\n\nDisplay exactly ONE next-steps block based on maturity level and config — do NOT show all three. Block text is in `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Persona-Aware Next Steps Blocks):\n\n- **maturity = poc** → lightweight prototype-mode block (\u002Fadd:tdd-cycle → \u002Fadd:verify fast path; \u002Fadd:spec and \u002Fadd:retro optional).\n- **maturity = alpha or beta** → standard workflow block (\u002Fadd:spec → \u002Fadd:plan → \u002Fadd:tdd-cycle → \u002Fadd:verify, plus \u002Fadd:away, \u002Fadd:retro, \u002Fadd:cycle).\n- **PM \u002F non-engineer** (detected by: `collaboration.team_size` > 1, OR user said \"PM\" or \"product manager\" during the interview, OR autonomy = \"guided\") → product-person block (\u002Fadd:spec and \u002Fadd:verify only).\n\nEnd-of-skill epilogue: follow ${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md (observation + learning checkpoint + progress tracking).\n","# ADD Init Command v0.11.0\n\nInitialize Agent Driven Development for this project. This command conducts a structured interview to understand the project, then scaffolds the full ADD framework.\n\n## Modes\n\n| Flag | Purpose | Questions | Target user |\n|---|---|---|---|\n| (none) | Full interview — detects adoption vs greenfield, runs Phases 0-5 | ~12 | New projects with non-trivial scope or existing codebases |\n| `--quick` | Greenfield fast path — 5 essential questions, sensible defaults elsewhere | 5 | Prototypes, solo projects, time-constrained onboarding |\n| `--defaults` | True non-interactive init — every value derived or defaulted, zero questions | 0 | Headless sessions (`claude -p`, `codex exec`), CI pipelines |\n| `--reconfigure` | Re-run interview preserving existing answers as defaults | ~12 | Updating an already-initialized project |\n| `--sync-registry` | Read-only: reconcile `~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json` with ground truth | 0 | Fixing drift detected by the registry-sync rule |\n\n## Quick Mode (`--quick`)\n\nGreenfield fast path. Skips adoption detection, skips profile-derived questions, and defaults anything that isn't one of the 5 essential answers. Use when you want ADD initialized in ~2 minutes.\n\n### The 5 questions\n\n1. **Name** — \"Project name? (defaults to directory basename: `{current_dir_name}`)\"\n2. **Languages \u002F frameworks** — \"What's the primary stack? (e.g., 'python+fastapi', 'typescript+react', 'go', 'rust+axum')\"\n3. **Environment tier** — \"Deployment scope: 1 (local only), 2 (local + prod), or 3 (local + dev + staging + prod)? (default: 2)\"\n4. **Maturity** — \"Project maturity: poc, alpha, beta, or ga? (default: alpha)\"\n5. **Autonomy** — \"Agent autonomy level: guided (ask often), balanced (default), or autonomous (trust)? (default: balanced)\"\n\n### Defaults applied\n\nEverything else that the full interview asks is defaulted:\n\n| Area | Quick-mode default |\n|------|-------------------|\n| PRD depth | 1-pager generated from (name, stack, scope-paragraph prompt) |\n| Quality mode | `strict` for beta\u002Fga, `standard` for alpha, `spike` for poc |\n| CI\u002FCD provider | Inferred from `.github\u002F` if present, otherwise `none` |\n| Commit convention | Conventional commits |\n| Protected branches | `[main]` |\n| Coverage threshold | 80% at beta\u002Fga, 50% at alpha, 0 at poc |\n| Branding palette | Default ADD raspberry (`#b00149`) until `\u002Fadd:brand` is run |\n| Image generation | `enabled: false, nudged: false` |\n\n### What `--quick` skips\n\n- Adoption mode detection (Phase 0) — not relevant for greenfield\n- Cross-spec consistency check — no specs yet\n- Profile-integration confirmation prompts — profile defaults applied silently\n- PRD interview (Phase 1 Sections 3-7) — replaced by \"scope paragraph\" prompt at the end\n- Swarm\u002Fworktree config questions — set by maturity default\n\n### What `--quick` still does\n\n- Writes `.add\u002Fconfig.json`, `.add\u002Flearnings.json` (empty), `docs\u002Fprd.md` (1-pager), `specs\u002F` (dir), `docs\u002Fplans\u002F` (dir)\n- Bumps project registry (`~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json`)\n- Validates that maturity + tier combination is sensible (e.g., warns if `maturity=ga` + `tier=1`)\n- Runs Phase 4 Cross-Project Persistence (same as full interview)\n\n### Upgrade path\n\nAfter quick init, the user can always run `\u002Fadd:init --reconfigure` for the full interview, or run `\u002Fadd:spec` to start formalizing features. Specs created under a quick-init project are no different from specs created under full init.\n\n## Defaults Mode (`--defaults`)\n\nTrue non-interactive init. Asks **zero** questions — no AskUserQuestion calls, no interview turns, no confirmation prompts. Every value is derived from the project or defaulted. Designed for headless one-shot sessions (`claude -p \"\u002Fadd:init --defaults\"`, `codex exec \"\u002Fadd-init --defaults\"`) and CI pipelines, where there is no second turn to answer a question in.\n\n### Existing-config guard\n\nBefore doing anything else, check for `.add\u002Fconfig.json`. If it exists, print a notice and stop — touch nothing:\n\n```\n.add\u002Fconfig.json already exists — \u002Fadd:init --defaults never overwrites an\ninitialized project. Run \u002Fadd:init --reconfigure to refresh the configuration.\n```\n\n### Values derived\n\n| Field | Defaults-mode value |\n|------|-------------------|\n| Project name | Basename of the current working directory |\n| Language | Auto-detected from manifest files: `package.json` → typescript (if `tsconfig.json` or TS deps) else javascript, `pyproject.toml`\u002F`setup.py` → python, `go.mod` → go, `Cargo.toml` → rust, `Gemfile`\u002F`*.gemspec` → ruby; fallback `unknown` |\n| Environments | `[\"local\"]`, no autoPromote |\n| Maturity | `poc` (greenfield) or the evidence-based detected level (adoption path) — no confirmation question either way |\n| Operating mode | `autonomous` |\n| Scope paragraph | Omitted — PRD stub notes \"run \u002Fadd:spec to define scope\" |\n| Quality mode, coverage, branding, etc. | Same defaults table as `--quick` |\n\n### What `--defaults` skips\n\n- The entire interview (Phases 0-1 questions) — adoption vs greenfield is still auto-detected, but the findings\u002Fassessment panels are informational only, never confirmation prompts\n- The maturity confirmation — the detected (or `poc`) level is applied directly\n- The scope-paragraph prompt that `--quick` asks at the end\n- All profile-integration, rule-overlap, and CLAUDE.md-overwrite questions — apply the non-destructive default silently (append, never overwrite)\n\n### What `--defaults` still does\n\n- Writes `.add\u002Fconfig.json`, `.add\u002Flearnings.json` (empty), `docs\u002Fprd.md` (stub noting \"run \u002Fadd:spec to define scope\"), `specs\u002F` (dir), `docs\u002Fplans\u002F` (dir)\n- Bumps the project registry (`~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json`)\n- Runs Phase 4 Cross-Project Persistence promptlessly — reads an existing profile if present, never creates or modifies one (profile creation requires the interview)\n- Composes with `--sync-registry` unchanged\n\n### Upgrade path\n\nSame as `--quick`: run `\u002Fadd:init --reconfigure` any time for the full interview, or `\u002Fadd:spec` to start formalizing features.\n\n## Sync Registry Mode (`--sync-registry`)\n\nReconciles `~\u002F.claude\u002Fadd\u002Fprojects\u002F{name}.json` against the project's ground truth. Triggered automatically by the `registry-sync.md` rule when drift is detected at session start, or manually by the user.\n\nRead-only in the project; writes only to the cross-project registry file. Shows a diff before writing:\n\n```\nREGISTRY RECONCILIATION for {project}:\n  learnings_count: 5 → 55\n  last_retro: null → {date}\n  maturity: alpha → beta\n\nApply? [yes\u002Fno]\n```\n\nDoes not run the interview. Does not touch `.add\u002Fconfig.json`.\n\n## Pre-Flight Check\n\n1. Check if `.add\u002Fconfig.json` already exists\n2. If exists AND no `--reconfigure` flag, display current config summary and ask if reconfiguration is wanted\n3. If exists AND `--reconfigure` flag, proceed with interview (preserving existing answers as defaults)\n4. If exists AND `--defaults` flag, print the existing-config notice (see Defaults Mode) and exit without touching anything\n\n### User Profile Detection\n\nCheck if `~\u002F.claude\u002Fadd\u002Fprofile.md` exists. This file carries preferences across projects.\n\nAlso check `~\u002F.claude\u002Fadd\u002Flibrary.md` for cross-project learnings and\n`~\u002F.claude\u002Fadd\u002Fprojects\u002F` for previous project history.\n\n**If profile exists:**\nRead it and use preferences as defaults throughout the interview. Also read\n`~\u002F.claude\u002Fadd\u002Flibrary.md` for cross-project knowledge. Announce this:\n```\nI found your ADD profile with preferences from previous projects.\nI'll use these as defaults — you can override anything during the interview.\n\nYour profile preferences:\n  Stack: {languages, frameworks from profile}\n  Cloud: {provider from profile}\n  Process: {autonomy, quality mode from profile}\n\nPrevious ADD projects: {list from ~\u002F.claude\u002Fadd\u002Fprojects\u002F}\n```\nThis can dramatically shorten the interview — if the profile matches, Section 2 might only be 2-3 confirmation questions instead of 6-8.\n\n**If no profile exists:**\nThis is a first-time ADD user. After the interview, offer to create one:\n```\nThis is your first ADD project. After setup, I can create a user\nprofile (~\u002F.claude\u002Fadd\u002Fprofile.md) so future projects inherit your\npreferences and the interview gets shorter. Want me to create it?\n```\n\n## Phase 0: Discovery (Adoption Mode — Automatic Detection)\n\nIf `.add\u002Fconfig.json` does NOT exist AND the project contains existing project files (CLAUDE.md, .claude\u002F, specs\u002F, tests\u002F, CI\u002FCD, docker-compose.yml, git history, etc.), automatically enter **adoption mode**. This is non-destructive — ADD absorbs and complements existing methodology.\n\n### Automatic Detection Checklist\n\nSilently scan the project for existing methodology without asking the user:\n\n```\n□ CLAUDE.md — read it, extract project description and existing commands\n□ .claude\u002Frules\u002F — list existing rules, note coverage areas\n□ .claude\u002Fskills\u002F — list existing skills, note what ADD would add\n□ .claude\u002Fsettings.json — read permissions\n□ specs\u002F or .add\u002Fspecs\u002F — list existing feature specifications\n□ docs\u002F or docs\u002Fplans\u002F — list existing implementation plans\n□ tests\u002F — identify test framework, coverage, directory structure\n□ .github\u002Fworkflows\u002F — identify CI\u002FCD pipelines\n□ .gitlab-ci.yml \u002F Jenkinsfile — alternative CI\u002FCD\n□ docker-compose.yml — identify containerization strategy\n□ Dockerfile — identify containerization\n□ package.json \u002F pyproject.toml \u002F Cargo.toml \u002F go.mod — identify stack\n□ .git\u002Fconfig — identify git remote host and repository\n□ .pre-commit-config.yaml — identify existing git hooks\n□ .env.example — identify environment variables and secrets strategy\n□ PROJECT_STATUS.md or similar — identify session tracking \u002F status history\n```\n\n### Present Adoption Findings to User\n\nAfter silent detection (and the maturity assessment below), show the user a structured summary of what exists vs. what ADD adds: existing methodology, existing infrastructure, what ADD would add (non-destructive), what ADD would preserve untouched — then ask \"Proceed with adoption?\". Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Adoption Findings Panel).\n\n### Maturity Level Detection\n\nAssess project maturity using evidence-based scoring. This assessment is BINDING — maturity is determined by what the project actually demonstrates, not by aspiration.\n\n#### Evidence Scoring\n\nScore each of these 12 evidence categories as present or absent (git timestamps, configs, and CI files are the detection sources): specs, tests, coverage threshold (20% = alpha signal, 50% = beta, 80% = ga), CI\u002FCD pipeline, PR-based branching, conventional commits (sample last 20 commits), environment separation, release tags, protected branches, TDD evidence (tests predate\u002Faccompany implementation), spec-driven evidence (specs predate implementation), and quality gates (pre-commit hooks, CI checks, linting).\n\nScoring: **POC** 0–2 items · **Alpha** 3–5 · **Beta** 6–8 · **GA** 9+.\n\nFor the full maturity cascade matrix and promotion process, see `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fmaturity-matrix.md`.\n\n#### Assessment Output\n\nPresent the assessment authoritatively — do NOT ask the user to confirm or override the level. Compact example:\n\n```\nMATURITY ASSESSMENT (evidence-based):\n  Your project operates at: ALPHA\n  Evidence: ✓ tests (47% coverage) ✓ CI\u002FCD ✓ conventional commits · ✗ 9 other items\n  Score: 3\u002F12 evidence items → ALPHA\n  Gap to Beta: specs (\u002Fadd:spec), coverage >50%, PR workflow, 2+ environments, TDD evidence\n```\n\nRender the full panel (per-item ✓\u002F✗ list, gap checklist, promotion note) per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Maturity Assessment Panel).\n\nIf the user disagrees with the assessment, explain that ADD maturity is evidence-based and that promotion happens through `\u002Fadd:retro` when criteria are met. The user can start at the detected level and promote quickly if the project genuinely meets higher criteria.\n\n### Adoption-Mode Interview (Shorter and Smarter)\n\nAdoption mode runs a SHORTER interview because many answers are detected:\n\n**Section 1 (Product):**\nIf CLAUDE.md exists with a project description, skip most questions. Just confirm:\n```\nFrom your CLAUDE.md, I understand this project:\n{Extracted description from CLAUDE.md}\n\nIs that still accurate? Anything to add or clarify?\n```\n\nOtherwise, run standard Section 1 questions (4 questions, ~3 min).\n\n**Section 2 (Architecture):**\nNearly all answers are detected from project files. Just run confirmations:\n```\nI detected your tech stack from your project files:\n  Language: {detected}\n  Backend: {detected}\n  Frontend: {detected}\n  Database: {detected}\n  Containers: {detected}\n  Git: {detected}\n  CI\u002FCD: {detected}\n\nDoes this match your current setup? Anything to add or correct?\n```\n\nThen ask the 3 process questions from Section 3 (autonomy, quality mode, team size).\n\n**Total adoption interview: ~5-8 questions, ~5 minutes** (vs. 14-16 questions in greenfield mode).\n\n### Handling Existing Rules\n\nADD's rules are NOT copied into the project — they are injected each session by the plugin's SessionStart hook (`load-rules.sh`), maturity-gated, and update automatically with the plugin. `\u002Fadd:init` never writes to `.claude\u002Frules\u002F`.\n\nFor each existing rule in the project's `.claude\u002Frules\u002F`, check for overlap with ADD's rule set:\n\n- **If an existing project rule covers similar ground as an ADD rule:** Ask the user:\n  ```\n  You have an existing rule: {existing_rule.md}\n  This covers similar ground as ADD's {add_rule} (injected automatically each session).\n\n  Options:\n    a) Keep your rule as-is — it takes precedence where they conflict\n    b) Trim your rule to only the parts ADD doesn't cover\n    c) Remove your rule — rely on ADD's injected version\n  ```\n\n- **If a stale ADD rule copy exists** (same name as a plugin rule, or `add-` prefixed — left behind by an ADD version before v0.9.11 that copied rules): recommend removal, since the hook now injects the current version and the copy will drift:\n  ```\n  .claude\u002Frules\u002F{name}.md matches an ADD plugin rule. ADD now injects rules\n  at session start — this copy is redundant and will go stale. Remove it?\n  ```\n\n### Handling Existing Skills\n\nFor each ADD skill (e.g., `\u002Fadd:spec`, `\u002Fadd:plan`, `\u002Fadd:away`, `\u002Fadd:back`, `\u002Fadd:retro`):\n\n- **If project has equivalent skill:** Ask:\n  ```\n  You have an existing skill: {existing_skill}\n  ADD provides {add_skill} which extends this.\n\n  Keep yours, use ADD's, or should I merge them?\n  ```\n\n- **If project doesn't have it:** Add the ADD skill to `.claude\u002Fskills\u002F`.\n\n- **Priority:** Project's existing skills are preferred unless the user wants ADD's version or a merge.\n\n### Non-Destructive CLAUDE.md\n\n**NEVER overwrite an existing CLAUDE.md.**\n\nInstead, append an ADD methodology section at the end:\n\n```markdown\n## ADD Methodology\n\nThis project follows Agent Driven Development (ADD) for structured code generation and knowledge persistence.\n\n**Configuration:** `.add\u002Fconfig.json`\n**Knowledge Base:** `.add\u002Flearnings.md` (auto-populated during development)\n**Quality Gates:** Enforced via `\u002Fadd:verify` command\n**Workflow:** `\u002Fadd:spec` → `\u002Fadd:plan` → `\u002Fadd:tdd-cycle` → `\u002Fadd:retro`\n\nSee `.add\u002Fconfig.json` for detailed settings.\n```\n\n### Retroactive Specs Import\n\nIf the project already has specs in a custom location (e.g., `specs\u002Fspike\u002F`, `doc\u002Fspecs\u002F`, or other):\n\n- **DON'T move or rename them.**\n- **DO** create `.add\u002Fconfig.json` pointing to the existing specs directory:\n  ```json\n  \"specs_directory\": \"specs\u002Fspike\u002F\",\n  \"specs_format\": \"markdown\"\n  ```\n\n- Ask the user:\n  ```\n  Your feature specs are currently in {location}.\n  Should I continue using that directory for ADD specs,\n  or create a fresh specs\u002F directory for ADD-formatted specs?\n  ```\n\n### Retroactive Learnings Seeding\n\nFor mature projects, seed `.add\u002Flearnings.md` with initial knowledge instead of a blank template:\n\n1. **Read CLAUDE.md** for documented patterns, architectural decisions, and conventions.\n2. **Scan git log** (last 30 commits) for common issues, bugs, and fixes.\n3. **Read PROJECT_STATUS.md** (if exists) for session history and lessons learned.\n4. **Extract patterns:** Identify recurring problems, solutions, and anti-patterns.\n\nPresent the seed entries to the user for confirmation:\n\n```\nI've extracted initial learnings from your project history:\n\nPATTERNS & CONVENTIONS:\n  - {pattern 1 from CLAUDE.md}\n  - {pattern 2 from git history}\n\nCOMMON ISSUES & SOLUTIONS:\n  - {issue 1} → {solution from git log}\n  - {issue 2} → {solution from recent commits}\n\nThese will populate .add\u002Flearnings.md as the starting knowledge base.\nAny additions or corrections before I finalize?\n```\n\n### Catch-Up Spike Generation\n\nAfter confirming maturity level and completing the adoption interview, generate a gap analysis comparing current project state against the confirmed maturity level requirements (per the cascade matrix in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fmaturity-matrix.md`):\n\n```\nCATCH-UP ANALYSIS: Bringing {project} to {MATURITY} compliance\n\nREQUIRED FOR {MATURITY}:                    STATUS:\n  PRD document                               {✓ exists | ✗ missing}\n  Feature specs                              {✓ N specs found | ✗ missing for N features}\n  Implementation plans                       {✓ N plans found | ✗ missing}\n  Quality gates configured                   {✓ N gates active | ✗ not configured}\n  TDD coverage at threshold                  {✓ N% meets threshold | ✗ N% below threshold}\n  CI\u002FCD pipeline                             {✓ active | ✗ not found | ○ not required at this level}\n  Milestone structure                        {✓ found | ✗ missing | ○ not required at this level}\n  Source control workflow                    {✓ matches | ⚠ partial | ✗ missing}\n\nSCORE: {N}\u002F{TOTAL} requirements met\n\nCATCH-UP ITEMS (if score \u003C 100%):\n  1. {item — e.g., \"Generate docs\u002Fprd.md from existing CLAUDE.md + brief interview\"}\n  2. {item — e.g., \"Create retroactive specs for auth, billing features\"}\n  3. {item — e.g., \"Configure 3-gate quality pipeline\"}\n```\n\nIf catch-up items exist, ask:\n```\nI can generate a catch-up cycle to bring your project to {MATURITY} compliance.\nThis would take approximately {estimate} of autonomous work.\n\nOptions:\n  a) Run catch-up spike now (I'll work autonomously)\n  b) Save as first cycle plan (you review first)\n  c) Skip — I'll adopt ADD alongside your existing workflow\n```\n\nIf option (a) or (b):\n- Create `.add\u002Fcycles\u002Fcycle-0-catchup.md` with the gap items as work items\n- For (a): execute immediately, report back when done\n- For (b): save plan, wait for human review\n\n### Adoption Summary\n\nDisplay what was newly created, what was enhanced, what was preserved exactly as-is, the resulting configuration (stack, tier, quality, autonomy), and next steps. Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Adoption Summary Panel).\n\n## Phase 1: The Interview\n\nConduct a structured 1-by-1 interview following the human-collaboration rule. Always estimate total questions upfront.\n\n### Greeting\n\n```\nWelcome to Agent Driven Development (ADD).\n\nI'll interview you across 4 sections to understand your project:\n  Section 1: Product (4 questions, ~3 min)\n  Section 2: Architecture & Tech Stack (6-8 questions, adaptive, ~5 min)\n  Section 2.5: Branding (1-2 questions, ~1 min)\n  Section 3: Process & Collaboration (5 questions, ~4 min)\n\nTotal: approximately 16-19 questions, ~12 minutes.\nSome questions are adaptive — I'll skip what I can detect automatically.\n\nYour answers will generate:\n  - docs\u002Fprd.md (Product Requirements Document)\n  - .add\u002Fconfig.json (project configuration)\n  - .claude\u002Fsettings.json (Claude Code settings)\n  - specs\u002F directory (for feature specifications)\n  - docs\u002Fplans\u002F directory (for implementation plans)\n\nLet's begin.\n```\n\n### Question Bank\n\nLoad the question bank — verbatim Q1–Q18 prompts plus AskUserQuestion options — from `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-interview.md`. Ask questions ONE AT A TIME, building on previous answers. Phase structure and branching logic:\n\n**Section 1: Product (Q1–Q4, ~4 questions)**\nProblem\u002Fvalue proposition (Q1), primary users (Q2), success metrics (Q3), MVP scope in\u002Fout (Q4).\n\n**Section 2: Architecture & Tech Stack (Q5–Q13, ~6-8 questions, adaptive)**\n\nBefore asking tech questions, run the silent detection step (do not show to user): check for package.json, pyproject.toml\u002Frequirements.txt, Cargo.toml, go.mod, pom.xml\u002Fbuild.gradle, docker-compose.yml, Dockerfile, .github\u002Fworkflows\u002F, .gitlab-ci.yml, Jenkinsfile, .git\u002Fconfig, terraform\u002F.tf files, Makefile\u002Fjustfile. If project files are detected, summarize what you found before asking Q5.\n\n- **Q5 (The Branch Question)** determines whether Q6–Q8 are prescriptive (human tells) or advisory (Claude suggests). Three branches:\n  - \"Detect from project files\" → present the detected stack for confirmation, skip Q6–Q7.\n  - \"Suggest a stack\" → propose per the heuristics in the question bank based on Section 1 answers; human approves\u002Fmodifies.\n  - \"I have a stack in mind\" → ask Q6 (languages + versions) and Q7 (frameworks). If answers are vague (\"Python\" with no version), probe for the version.\n- **Q8 (all paths converge): source control & hosting** — confirm if a `.git\u002Fconfig` remote is detected, otherwise ask.\n- **Q9: environment tier** (Tier 1 local \u002F Tier 2 local+prod \u002F Tier 3 full pipeline), then **Q10: tier-dependent deployment details** (Tier 1: run command; Tier 2: cloud provider + production URL; Tier 3: per-environment infrastructure walkthrough).\n- **Q11: CI\u002FCD** — confirm if detected; \"None yet — set it up for me\" means scaffold a basic pipeline during Phase 2.\n- **Q12: containerization** — confirm if detected, otherwise ask.\n- **Q13: additional technical constraints** (auth, compliance, performance, integrations).\n\n**Section 2.5: Branding (Q13.5, ~1 min)**\n\"Yes — let me share it\" → parse hex color, fonts, tone, logo path, and style-guide source into `branding.*`, generating the palette per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fpresets.json`. \"No — use ADD defaults\" → raspberry preset (#b00149) from presets.json, optionally offering the preset picker (Raspberry \u002F AI Purple \u002F Ocean \u002F custom hex). Branding can always be updated later with `\u002Fadd:brand-update`.\n\n**Section 3: Process & Collaboration (Q14–Q18, ~4 min)**\n\n- **Q14: maturity level** — branching:\n  - **Adoption mode** (Phase 0 detected existing project): SKIP Q14 entirely; use the evidence-based level from Phase 0, and note \"Maturity level was determined by evidence analysis in Phase 0. Skipping maturity question.\"\n  - **Greenfield mode:** cap at Alpha maximum — a brand new project has zero evidence for Beta or GA (promote via `\u002Fadd:retro` when criteria are met). If POC is selected, explain the relaxed process per the question bank.\n- **Q15: autonomy** (guided \u002F balanced \u002F autonomous), **Q16: quality standard** (spike \u002F standard \u002F strict — sets coverage threshold), **Q17: team size** (sets branching + PR strategy), **Q18: existing patterns\u002Fconventions** (default: ADD defaults).\n\n### Interview Complete\n\n```\nThanks for the thorough answers. I have everything I need to set up ADD.\n\nGenerating:\n  1. docs\u002Fprd.md — your Product Requirements Document\n  2. .add\u002Fconfig.json — project configuration\n  3. Project directories and scaffolding\n```\n\n## Phase 2: Scaffold Project Structure\n\nThe standard ADD layout. See `${CLAUDE_PLUGIN_ROOT}\u002Frules\u002Fproject-structure.md` for the full specification.\n\n### Step 2.1: Create Project Directories\n\n```bash\n# ADD methodology directories (committed to git)\nmkdir -p .add .add\u002Fretros .add\u002Faway-logs\n\n# Specification and planning directories\nmkdir -p specs docs\u002Fplans\n\n# Milestone and cycle tracking\nmkdir -p docs\u002Fmilestones .add\u002Fcycles\n\n# Test artifact directories\nmkdir -p tests\u002Fscreenshots tests\u002Fscreenshots\u002Ferrors tests\u002Fe2e tests\u002Funit tests\u002Fintegration\n\n# Claude Code config\nmkdir -p .claude\n```\n\n### Step 2.1.1: Scaffold CHANGELOG.md\n\nIf `CHANGELOG.md` does not already exist in the project root, create it from the changelog template:\n\n1. Read `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fchangelog.md.template`\n2. Write it to `CHANGELOG.md` in the project root\n\nThis gives the project a Keep a Changelog-formatted changelog from day one. The `\u002Fadd:changelog` command and the push hook will populate it automatically as development proceeds.\n\n### Step 2.2: Create Cross-Project Directories (machine-local)\n\n```bash\n# ADD user-level persistence (outside any project)\nmkdir -p ~\u002F.claude\u002Fadd ~\u002F.claude\u002Fadd\u002Fprojects\n```\n\n### Step 2.3: Update .gitignore\n\nAppend ADD-specific entries if not already present:\n\n```gitignore\n# ADD — ephemeral artifacts (don't commit)\n.add\u002Faway-logs\u002F\ntests\u002Fscreenshots\u002Ferrors\u002F\n\n# ADD — these SHOULD be committed (don't ignore)\n# .add\u002Fconfig.json\n# .add\u002Flearnings.md\n# .add\u002Fretros\u002F\n# specs\u002F\n# docs\u002Fplans\u002F\n# tests\u002Fscreenshots\u002F{feature}\u002F\n```\n\n## Phase 2.5: Verify Rule Loading (no copying)\n\nADD rules are NOT copied into the project. The plugin's SessionStart hook (`load-rules.sh`) injects the active rule set every session, gated by the project's maturity level — rules stay current with the plugin and never drift. (Versions before v0.9.11 copied 10 rules into `.claude\u002Frules\u002F`; that mechanism is retired because copies went stale and, after v0.9.9, duplicated the hook injection.)\n\nThis phase only checks for leftovers:\n\n1. If `.claude\u002Frules\u002F` exists, list its files and compare basenames against `${CLAUDE_PLUGIN_ROOT}\u002Frules\u002F` (also match `add-` prefixed variants).\n2. For each match — a stale ADD copy from an older init — ask the user once (batch, not per-file):\n   ```\n   Found {N} ADD rule copies in .claude\u002Frules\u002F from an earlier ADD version:\n   {list}\n   ADD now injects current rules at session start, so these are redundant\n   and will go stale. Remove them? (user-authored rules are untouched)\n   ```\n3. Track for the Phase 5 summary: **Removed** \u002F **Kept** (user declined).\n\n## Phase 3: Generate Configuration Files\n\n### Step 3.1: Generate .add\u002Fconfig.json\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fconfig.json.template and fill in all placeholders with interview answers. Use the Write tool.\n\nEnsure the generated config includes the `maturity` field:\n```json\n{\n  \"maturity\": {\n    \"level\": \"{poc|alpha|beta|ga}\",\n    \"promoted_from\": null,\n    \"promoted_date\": null,\n    \"next_promotion_criteria\": \"{what's needed for the next level}\"\n  }\n}\n```\n\n### Step 3.2: Generate docs\u002Fprd.md\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fprd.md.template and fill in all placeholders with interview answers. Write a real PRD — don't leave template placeholders. Every section should have substantive content based on the interview answers.\n\n### Step 3.3: Generate .claude\u002Fsettings.json (if it doesn't exist)\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fsettings.json.template. Customize permissions based on the tech stack detected.\n\nThe template includes a `statusLine` configuration that displays `\u002FADD:enabled` in the Claude Code status bar (with \"ADD\" in raspberry #b00149). This provides an at-a-glance indicator that the project is ADD-managed. If the user already has a custom `statusLine` in their settings, ask before overwriting it.\n\n### Step 3.4: Generate CLAUDE.md (if it doesn't exist)\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002FCLAUDE.md.template. Fill in project-specific information:\n- Project name and description (from Q1)\n- Tech stack (from Section 2)\n- Key commands (run, test, lint, deploy per stack)\n- Environment info (tier, URLs, deploy triggers)\n- Quality gates (mode, thresholds)\n- Standard directory layout\n- Link to docs\u002Fprd.md\n\nIf CLAUDE.md already exists, ask before overwriting. Offer to append ADD-specific sections instead.\n\n### Step 3.5: Generate .add\u002Flearnings.md\n\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Flearnings.md.template and fill in the project name. This is the knowledge base that agents build over time through automatic checkpoints. Committed to git so it transfers between devices.\n\n### Step 3.6: Generate AGENTS.md\n\nInvoke `\u002Fadd:agents-md` to generate a portable `AGENTS.md` at project root. This is the cross-tool open standard — any agent (Cursor, Codex CLI, Copilot, Windsurf, etc.) reading the repo will pick it up. Generation is maturity-aware: POC projects get a minimal bullet summary, Alpha+ projects get a sectioned doc. If an `AGENTS.md` already exists without the ADD marker block, skip this step and recommend the user run `\u002Fadd:agents-md --merge` after init completes.\n\n## Phase 4: Cross-Project Persistence\n\n### Step 4.1: User Profile\n\nIf `~\u002F.claude\u002Fadd\u002Fprofile.md` does NOT exist and the user agreed to create one:\nRead ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Fprofile.md.template, fill in preferences from the interview, and write to `~\u002F.claude\u002Fadd\u002Fprofile.md`.\n\nIf profile already exists, do NOT modify it — profile updates only happen during `\u002Fadd:retro`.\n\n### Step 4.2: Project Index Entry\n\nWrite a snapshot to `~\u002F.claude\u002Fadd\u002Fprojects\u002F{project-name}.json`:\n\n```json\n{\n  \"name\": \"{PROJECT_NAME}\",\n  \"path\": \"{ABSOLUTE_PROJECT_PATH}\",\n  \"initialized\": \"{DATE}\",\n  \"last_retro\": null,\n  \"stack\": [\"{lang-version}\", \"{framework}\", ...],\n  \"tier\": {N},\n  \"cloud\": \"{provider}\",\n  \"key_learnings\": []\n}\n```\n\nThis lets future `\u002Fadd:init` calls on new projects reference your history:\n\"I see you worked on {project} with {stack}. Similar setup here?\"\n\n### Step 4.3: Cross-Project Library\n\nIf `~\u002F.claude\u002Fadd\u002Flibrary.md` does NOT exist, create it from ${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Flibrary.md.template.\nIf it exists, leave it alone — it's updated during `\u002Fadd:retro`.\n\n## Phase 5: Summary\n\nDisplay an \"ADD initialized successfully\" panel covering: project structure created (per-file ✓ list), rules installed \u002F skipped \u002F prefixed (from Phase 2.5 tracking), cross-project files, the 3-tier knowledge cascade (plugin-global `knowledge\u002Fglobal.md` → user-local `~\u002F.claude\u002Fadd\u002Flibrary.md` → project `.add\u002Flearnings.md`), the resolved configuration (stack, infrastructure, tier, maturity, quality + coverage threshold, autonomy, branching), and what's committed vs machine-local (with the `\u002Fadd:init --import` note). Render per `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Phase 5 Init Summary Panel).\n\n### Persona-Aware Next Steps\n\nDisplay exactly ONE next-steps block based on maturity level and config — do NOT show all three. Block text is in `${CLAUDE_PLUGIN_ROOT}\u002Ftemplates\u002Finit-output-examples.md` (Persona-Aware Next Steps Blocks):\n\n- **maturity = poc** → lightweight prototype-mode block (\u002Fadd:tdd-cycle → \u002Fadd:verify fast path; \u002Fadd:spec and \u002Fadd:retro optional).\n- **maturity = alpha or beta** → standard workflow block (\u002Fadd:spec → \u002Fadd:plan → \u002Fadd:tdd-cycle → \u002Fadd:verify, plus \u002Fadd:away, \u002Fadd:retro, \u002Fadd:cycle).\n- **PM \u002F non-engineer** (detected by: `collaboration.team_size` > 1, OR user said \"PM\" or \"product manager\" during the interview, OR autonomy = \"guided\") → product-person block (\u002Fadd:spec and \u002Fadd:verify only).\n\nEnd-of-skill epilogue: follow ${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md (observation + learning checkpoint + progress tracking).\n",{"references":55,"description":7,"allowed-tools":61,"argument-hint":68,"disable-model-invocation":69},[56,57,58,59,60],"maturity-matrix.md","skill-epilogue.md","rules\u002Ftelemetry.md","templates\u002Finit-interview.md","templates\u002Finit-output-examples.md",[62,63,64,65,66,41,67],"Read","Write","Edit","Glob","Grep","AskUserQuestion","[--reconfigure] [--quick] [--defaults] [--sync-registry]",true,"main","e335248c85d50f73919320bc138766eb413c5ee3","plugins\u002Fadd\u002Fskills\u002Finit",6,"https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd","https:\u002F\u002Fgetadd.dev","https:\u002F\u002Fgithub.com\u002FMountainUnicorn","2026-10-31 22:03:50",{"source":8,"skillName":5,"commands":79,"prompt":89,"zipAvailable":69},[80,83,86],{"tool":81,"command":82},"npx","npx skills add MountainUnicorn\u002Fadd --skill init",{"tool":84,"command":85},"bunx","bunx skills add MountainUnicorn\u002Fadd --skill init",{"tool":87,"command":88},"pnpm","pnpm dlx skills add MountainUnicorn\u002Fadd --skill init","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Finit\u002FSKILL.md",[],[92,100,105,110,120,146],{"skillNo":93,"name":94,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":50},"01M6CHXN68ZCGNXE9Q0K2T2RKX","add-verify","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-modified\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[98,99],"add verify","verify",{"skillNo":101,"name":94,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":50},"01M6CHXJY4ZXKTNP0235A9KTNH","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-missing\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[98,99],{"skillNo":106,"name":94,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":109,"publishedAt":50},"01M6CHXG6NV1DBMWT2N6XE5555","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fhealthy\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[98,99],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":116,"publishedAt":50},"01M6CHXDZFPEFBZ79GHP48S1BB","version","[ADD v0.11.0] Show installed version, project version, and upgrade status","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fversion\u002FSKILL.md",[],[112,40,117,48,41,31,118,39,34,119],"status","check","show",{"skillNo":121,"name":99,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":132,"publishedAt":50},"01M6CHXB5XG415PP88E0GACHP8","[ADD v0.11.0] Run quality gates — lint, types, tests, coverage, spec compliance","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fverify\u002FSKILL.md",[125,128,129],{"categoryNo":126,"categoryName":127,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":130,"categoryName":131,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000037","律师与法务",[99,40,39,133,134,34,135,136,31,48,137,138,139,140,141,142,143,41,144,145],"coverage","fix","smoke","gate","spec","quality gates","run","lint","ci","compliance","secrets","learning","quality",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":159,"publishedAt":50},"01M6CHX8JF3M3J8BKTBW604D37","ux","[ADD v0.11.0] Iterate on UI\u002FUX design before implementation — wireframes, flow validation, and design sign-off","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fux\u002FSKILL.md",[152,155,156],{"categoryNo":153,"categoryName":154,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":157,"categoryName":158,"taxonomyType":25,"taxonomyTypeDesc":26},"01JBSEEDCAT000000000000032","设计师",[148,160,161,162,163,48,137,41,164,31,40,39,38,37,34,165,166,167,168],"ui","file","figma","validation","system","design-system","implementation","flow","design"]