organic-growth 2.0.0 → 3.0.0

package/README.md

@@ -40,6 +40,7 @@ CLAUDE.md                           # Project context template + growth philosop
 ├── commands/
 │   ├── seed.md                     # /seed     — bootstrap new project
 │   ├── grow.md                     # /grow     — plan a new feature
+│   ├── map.md                      # /map      — view or adjust growth map
 │   ├── next.md                     # /next     — implement next stage
 │   ├── replan.md                   # /replan   — adjust when things change
 │   └── review.md                   # /review   — deep quality review
@@ -47,9 +48,13 @@ CLAUDE.md                           # Project context template + growth philosop
 │   ├── post-stage-test.sh          # Automatic test run after stage commits
 │   └── post-stage-review.sh        # Automatic diff review after stage commits
 └── settings.json                   # Claude Code hook configuration
+.organic-growth/
+├── product-dna.md                  # Full product DNA (structured)
+├── growth-map.md                   # System-level capability map (optional)
+└── growth/                         # One growth plan per feature
 ```
 
-Growth plan files (`docs/growth/*.md`) use plant-themed visual markers -- seedlings for pending stages, trees for completed ones, vines between sections -- so you can tell at a glance where a feature stands.
+Growth plan files (`.organic-growth/growth/*.md`) use plant-themed visual markers -- seedlings for pending stages, trees for completed ones, vines between sections -- so you can tell at a glance where a feature stands.
 
 A **post-stage test** hook and a **post-stage review** hook run automatically after every stage commit, in order:
 
@@ -63,10 +68,11 @@ Tests run first so failures are caught before the review. This makes the quality
 ```bash
 # 1. Bootstrap (new project)
 > /seed                          # interview mode
-> /seed docs/product-dna.md      # from existing product document
+> /seed .organic-growth/product-dna.md  # from existing product document
 
 # 2. Grow features
 > /grow Add user authentication
+> /map                           # check/update system-level growth sequence
 > /next                          # stage 1
 > /next                          # stage 2
 > /next                          # stage 3

package/bin/cli.mjs

@@ -1,6 +1,15 @@
 #!/usr/bin/env node
 
-import { existsSync, mkdirSync, copyFileSync, readFileSync, readdirSync, statSync } from 'fs';
+import {
+  existsSync,
+  mkdirSync,
+  copyFileSync,
+  readFileSync,
+  readdirSync,
+  statSync,
+  renameSync,
+  writeFileSync
+} from 'fs';
 import { join, dirname, relative, resolve } from 'path';
 import { fileURLToPath } from 'url';
 import { createInterface } from 'readline';
@@ -45,6 +54,67 @@ function getAllFiles(dir, base = dir) {
   return files;
 }
 
+function migrateLegacyState(targetDir) {
+  const actions = [];
+  const ogRoot = join(targetDir, '.organic-growth');
+  const legacyDocsDir = join(targetDir, 'docs');
+  const legacyGrowthDir = join(legacyDocsDir, 'growth');
+  const legacyDna = join(legacyDocsDir, 'product-dna.md');
+  const newGrowthDir = join(ogRoot, 'growth');
+  const newDna = join(ogRoot, 'product-dna.md');
+
+  if (!existsSync(ogRoot)) {
+    mkdirSync(ogRoot, { recursive: true });
+  }
+
+  if (existsSync(legacyGrowthDir)) {
+    if (!existsSync(newGrowthDir)) {
+      renameSync(legacyGrowthDir, newGrowthDir);
+      actions.push('moved docs/growth/ -> .organic-growth/growth/');
+    } else {
+      const legacyFiles = getAllFiles(legacyGrowthDir);
+      let copiedAny = false;
+      for (const rel of legacyFiles) {
+        const src = join(legacyGrowthDir, rel);
+        const dest = join(newGrowthDir, rel);
+        const destDir = dirname(dest);
+        if (!existsSync(destDir)) {
+          mkdirSync(destDir, { recursive: true });
+        }
+        if (!existsSync(dest)) {
+          copyFileSync(src, dest);
+          copiedAny = true;
+        }
+      }
+      if (copiedAny) {
+        actions.push('merged files from docs/growth/ into .organic-growth/growth/');
+      }
+    }
+  }
+
+  if (existsSync(legacyDna) && !existsSync(newDna)) {
+    copyFileSync(legacyDna, newDna);
+    actions.push('copied docs/product-dna.md -> .organic-growth/product-dna.md');
+  }
+
+  const contextFiles = ['CLAUDE.md', 'AGENTS.md'];
+  for (const file of contextFiles) {
+    const fullPath = join(targetDir, file);
+    if (!existsSync(fullPath)) continue;
+    const before = readFileSync(fullPath, 'utf8');
+    const after = before
+      .replaceAll('docs/growth/', '.organic-growth/growth/')
+      .replaceAll('docs/product-dna.md', '.organic-growth/product-dna.md')
+      .replaceAll('docs/growth-map.md', '.organic-growth/growth-map.md');
+    if (after !== before) {
+      writeFileSync(fullPath, after);
+      actions.push(`updated paths in ${file}`);
+    }
+  }
+
+  return actions;
+}
+
 function readVersion() {
   const pkg = JSON.parse(readFileSync(join(__dirname, '..', 'package.json'), 'utf8'));
   return pkg.version;
@@ -59,17 +129,19 @@ function printHelp() {
   log('');
   log(`${CYAN}Options:${RESET}`);
   log(`  -f, --force     Overwrite existing files without prompting`);
+  log(`      --migrate   Move legacy docs/growth and docs/product-dna.md to .organic-growth/`);
   log(`  -h, --help      Show this help message`);
   log(`  -v, --version   Show version number`);
   log(`      --opencode  Install opencode templates (AGENTS.md + .opencode/)`);
   log('');
   log(`${CYAN}Arguments:${RESET}`);
-  log(`  dna-file.md     Path to a product DNA document to copy into docs/`);
+  log(`  dna-file.md     Path to a product DNA document to copy into .organic-growth/`);
   log('');
   log(`${CYAN}Examples:${RESET}`);
   log(`  npx organic-growth                  Install Claude Code templates`);
   log(`  npx organic-growth --opencode       Install opencode templates`);
   log(`  npx organic-growth --force          Install templates (overwrite existing)`);
+  log(`  npx organic-growth --migrate        Migrate legacy docs/ state into .organic-growth/`);
   log(`  npx organic-growth spec.md          Install templates + copy DNA document`);
   log('');
 }
@@ -88,6 +160,7 @@ async function install() {
   }
 
   const force = args.includes('--force') || args.includes('-f');
+  const migrate = args.includes('--migrate');
   const isOpencode = args.includes('--opencode');
   const dna = args.find(a => !a.startsWith('-') && a.endsWith('.md'));
 
@@ -129,18 +202,19 @@ async function install() {
     created.push(file);
   }
 
-  // Create docs/growth/ directory
-  const growthDir = join(TARGET_DIR, 'docs', 'growth');
+  // Create .organic-growth/growth/ directory
+  const growthDir = join(TARGET_DIR, '.organic-growth', 'growth');
   if (!existsSync(growthDir)) {
     mkdirSync(growthDir, { recursive: true });
-    created.push('docs/growth/');
+    created.push('.organic-growth/growth/');
   }
 
   // Handle DNA document
   if (dna) {
     const dnaSource = resolve(TARGET_DIR, dna);
     if (existsSync(dnaSource)) {
-      const dnaDest = join(TARGET_DIR, 'docs', 'product-dna.md');
+      const dnaDest = join(TARGET_DIR, '.organic-growth', 'product-dna.md');
+      mkdirSync(dirname(dnaDest), { recursive: true });
       copyFileSync(dnaSource, dnaDest);
       success(`Product DNA copied from ${dna}`);
     } else {
@@ -148,6 +222,19 @@ async function install() {
     }
   }
 
+  if (migrate) {
+    const migrated = migrateLegacyState(TARGET_DIR);
+    if (migrated.length > 0) {
+      log('');
+      log(`${GREEN}Migrated:${RESET}`);
+      for (const step of migrated) {
+        log(`  ${DIM}${step}${RESET}`);
+      }
+    } else {
+      info('No legacy docs/ state found to migrate');
+    }
+  }
+
   log('');
   if (created.length > 0) {
     log(`${GREEN}Installed:${RESET}`);
@@ -167,7 +254,7 @@ async function install() {
   log('');
   if (isOpencode) {
     if (dna) {
-      info(`Run ${CYAN}/seed docs/product-dna.md${RESET} to bootstrap from your DNA document`);
+      info(`Run ${CYAN}/seed .organic-growth/product-dna.md${RESET} to bootstrap from your DNA document`);
     } else {
       info(`Run ${CYAN}/seed${RESET} to bootstrap a new project (interview mode)`);
       info(`Or: ${CYAN}/seed path/to/product-doc.md${RESET} if you have a product document`);
@@ -175,7 +262,7 @@ async function install() {
     info(`Edit ${CYAN}AGENTS.md${RESET} to fill in your tech stack and quality tools`);
   } else {
     if (dna) {
-      info(`Run ${CYAN}/seed docs/product-dna.md${RESET} to bootstrap from your DNA document`);
+      info(`Run ${CYAN}/seed .organic-growth/product-dna.md${RESET} to bootstrap from your DNA document`);
     } else {
       info(`Run ${CYAN}/seed${RESET} to bootstrap a new project (interview mode)`);
       info(`Or: ${CYAN}/seed path/to/product-doc.md${RESET} if you have a product document`);
@@ -186,29 +273,11 @@ async function install() {
   log(`${DIM}Commands available after setup:${RESET}`);
   log(`  ${CYAN}/seed${RESET}    — bootstrap project (interview or DNA document)`);
   log(`  ${CYAN}/grow${RESET}    — plan and start a new feature`);
+  log(`  ${CYAN}/map${RESET}     — view or adjust the system growth map`);
   log(`  ${CYAN}/next${RESET}    — implement the next growth stage`);
   log(`  ${CYAN}/replan${RESET}  — re-evaluate when things change`);
   log(`  ${CYAN}/review${RESET}  — deep quality review of recent stages`);
 
-  if (!isOpencode) {
-    // Detect superpowers plugin (Claude Code only — opencode uses a different plugin system)
-    const homedir = process.env.HOME || process.env.USERPROFILE || '';
-    const pluginsDir = join(homedir, '.claude', 'plugins');
-    let hasSuperpowers = false;
-    if (existsSync(pluginsDir)) {
-      try {
-        const entries = readdirSync(pluginsDir, { recursive: true });
-        hasSuperpowers = entries.some(e => String(e).includes('superpowers'));
-      } catch { /* ignore */ }
-    }
-
-    if (hasSuperpowers) {
-      success(`Superpowers plugin detected — TDD, debugging, and brainstorming skills are integrated into commands and gardener`);
-    } else {
-      info(`Tip: Install the superpowers plugin for integrated TDD, debugging, and brainstorming process skills`);
-    }
-  }
-
   log('');
 }
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "organic-growth",
-  "version": "2.0.0",
+  "version": "3.0.0",
   "description": "Claude Code and opencode setup for incremental software development — grow features in natural stages",
   "bin": {
     "organic-growth": "bin/cli.mjs"

package/templates/.claude/agents/gardener.md

@@ -18,6 +18,13 @@ each stage produces a complete, living system.
 
 # How You Work
 
+## Paths
+
+Growth plans, Product DNA, and growth map live in `.organic-growth/`:
+- Plans: `.organic-growth/growth/<feature-name>.md`
+- DNA: `.organic-growth/product-dna.md`
+- Map: `.organic-growth/growth-map.md`
+
 You have three modes, determined by what you're asked to do:
 
 ## Mode: PLAN (invoked by /grow)
@@ -29,20 +36,39 @@ You have three modes, determined by what you're asked to do:
    it in now." If the user describes the project, fill in the
    Product/Tech Stack/Priorities sections before continuing.
 1. Read CLAUDE.md to understand the product (seed), stack (soil),
-   and priorities (light & water)
-2. Check if `docs/product-dna.md` exists. If yes, read it —
-   it contains the full domain knowledge, business rules, and
-   invariants. Use it to make informed planning decisions.
-   If no, CLAUDE.md Product section is sufficient.
-3. Explore the codebase to understand current state
+   and priorities (light & water).
+2. Check if `.organic-growth/product-dna.md` exists. If yes, read it.
+   Pay special attention to:
+   - Business Rules (`BR-*`): global invariants.
+     Properties tied to a rule should reference it: `Refs: BR-3`.
+   - Core Domain Concepts: use these exact names in code.
+     If planning introduces a new concept, add it to DNA after delivery.
+   - Users & Roles: permission properties should reference these roles.
+   If no DNA exists, CLAUDE.md Product section is sufficient.
+2b. Check if `.organic-growth/growth-map.md` exists. If yes, read it.
+    Use it to:
+    - Understand what capabilities already exist (🌳)
+    - Follow map links to completed plans and their properties
+    - See expected sequence and likely dependencies
+    If no map exists, search related plans by tag:
+    `grep -r "Capabilities:" .organic-growth/growth/`.
+3. Explore the codebase to understand current state.
+   Search for related growth plans:
+   a. If map exists: follow links to relevant 🌳 plans.
+   b. If no map: find likely related plans by overlapping capability tags.
+   c. If related plans are found: treat their completed properties as
+      constraints. Preserve with `Depends on` or explicitly declare
+      `Breaks: <plan/property> — <reason>`.
+   d. If no related plans are found: proceed normally.
 4. Ask the user 2-3 clarifying questions — no more.
    Focus on: acceptance criteria, constraints, riskiest part.
-5. Create a growth plan in `docs/growth/<feature-name>.md`:
+5. Create a growth plan in `.organic-growth/growth/<feature-name>.md`:
 
 ```markdown
 # 🌱 Feature: <name>
 Created: <date>
 Status: 🌱 Growing
+Capabilities: <3-7 domain tags, comma-separated>
 
 ## Seed (what & why)
 <one paragraph: what this feature does and why it matters>
@@ -55,8 +81,10 @@ Status: 🌱 Growing
   - Properties:
     - P1: <property statement> [invariant|transition|roundtrip|boundary]
       Captures: <what bug this prevents>
+      Refs: BR-<n> (optional)
     - P2: ...
   - Depends on: (properties from earlier stages that must still hold)
+  - Breaks: <plan/property> — <reason> (optional, only for intentional breaks)
   - Touches: <which areas of the code>
   - Implementation hint: <brief guidance for GROW mode>
 
@@ -75,11 +103,12 @@ Status: 🌱 Growing
 
 ### Planning Principles
 - First stage is always the simplest possible thing that proves
-  the idea works end-to-end (even with hardcoded values)
-- Order by: risk reduction first, then user value
-- Each stage must be vertical (touch all necessary layers)
-- If a stage feels bigger than "one intent" — split it
-- For greenfield: follow the greenfield pattern from CLAUDE.md
+  the idea works end-to-end (even with hardcoded values).
+- Order by: risk reduction first, then user value.
+- Each stage must be vertical (touch all necessary layers).
+- If a stage feels bigger than "one intent" — split it.
+- Use 3-7 domain capability tags per plan.
+- For greenfield: follow the greenfield pattern from CLAUDE.md.
 
 ### Property-Based Planning
 
@@ -140,29 +169,28 @@ This is the primary review gate.
 
 ## Mode: GROW (invoked by /next)
 
-1. Read the growth plan from `docs/growth/`
-2. Find the next 🌱 stage
+1. Read the growth plan from `.organic-growth/growth/`.
+2. Find the next 🌱 stage.
 3. Check the stage counter:
    - If this is stage 3, 6, 9... → re-evaluate the plan first
-     (are remaining stages still correct? adjust if needed)
+     (are remaining stages still correct? adjust if needed).
 4. Implement ONLY this stage:
-   a. Read the stage's properties — these are your acceptance criteria
+   a. Read the stage's properties — these are your acceptance criteria.
    b. Write tests that encode the properties FIRST:
       - Follow red/green/refactor — write a failing test first, then the minimum code to pass it.
-      - Each property (P1, P2, ...) becomes one or more tests
-      - Tests express the RULE, not a specific scenario
-      - Tests for properties from "Depends on" must still pass
-   c. Write the code to make the property tests pass
+      - Each property (P1, P2, ...) becomes one or more tests.
+      - Tests express the RULE, not a specific scenario.
+      - Tests for properties from "Depends on" must still pass.
+   c. Write the code to make the property tests pass.
    d. Quality gate — run ALL checks, fix before proceeding:
-      - Apply verification-before-completion: confirm every check passes before moving on.
-      - Build: verify it compiles (`./gradlew build`, `npm run build`, etc.)
-      - Lint: run the project linter (`./gradlew ktlintCheck`, `npm run lint`, etc.)
-      - Type check: if applicable (`tsc --noEmit`, strict mode, etc.)
-      - Tests: ALL tests pass — current stage AND all previous properties
-      - Smoke: app starts, health endpoint responds (or equivalent)
+      - Build: verify it compiles (`./gradlew build`, `npm run build`, etc.).
+      - Lint: run the project linter (`./gradlew ktlintCheck`, `npm run lint`, etc.).
+      - Type check: if applicable (`tsc --noEmit`, strict mode, etc.).
+      - Tests: ALL tests pass — current stage AND all previous properties.
+      - Smoke: app starts, health endpoint responds (or equivalent).
    e. If any check fails — fix it within this stage, don't leave it
       for the next one. Quality debt doesn't carry forward.
-      - Use systematic-debugging to isolate the root cause rather than guessing.
+      - Debug systematically: read the error, reproduce, hypothesize, verify.
 5. Self-review:
    - Do ALL property tests for this stage pass?
    - Do ALL property tests from previous stages still pass?
@@ -173,13 +201,22 @@ This is the primary review gate.
      If yes — the plan has a gap. Note it in the growth log and
      flag to the user, but do not block the stage.
 6. Update the growth plan:
-   - Mark stage as 🌳 with brief note of what was done
-   - Add entry to Growth Log with date
+   - Mark stage as 🌳 with brief note of what was done.
+   - Add entry to Growth Log with date.
    - If this was a re-evaluation point, update upcoming stages
-     (including their properties)
+     (including their properties).
    - If all stages (Concrete + Horizon) are done, set
-     `Status: 🌳 Complete` at the top of the plan and follow the finishing-a-development-branch checklist for PR preparation.
-7. Commit: `feat(scope): stage N — <what grew>`
+     `Status: 🌳 Complete` at the top of the plan.
+     If working on a feature branch: summarize what was built,
+     list verified properties, and note open PR items.
+6b. If `.organic-growth/growth-map.md` exists:
+    - Update this capability status to 🌳.
+    - After reporting, suggest: "Growth map updated. What grows next?"
+6c. If `.organic-growth/product-dna.md` exists and this stage introduced
+    new domain concepts not in DNA:
+    - Add them to Core Domain Concepts.
+    - Note in growth log: "Added concept: <name> to DNA".
+7. Commit: `feat(scope): stage N — <what grew>`.
 8. Report:
    - What grew
    - Properties verified (list P-numbers that pass)
@@ -191,48 +228,42 @@ This is the primary review gate.
        - `🌿` — current (active — the stage you just finished)
        - `⬜` — upcoming (pending — not yet started)
      Format each line as: `<marker> Stage N: <title>`
-     Example (after completing Stage 3 of a 5-stage plan):
-     ```
-     ✅ Stage 1: Hello world endpoint
-     ✅ Stage 2: Domain model with hardcoded data
-     🌿 Stage 3: Persistence layer
-     ⬜ Stage 4: Real business logic
-     ⬜ Stage 5: Input validation
-     ```
-     Include all stages — both Concrete and Horizon.
-     This stage progress section replaces the old single-line format.
    - If stage counter is multiple of 3: recommend `/clear` + new session
 
 ## Mode: REPLAN (invoked by /replan)
 
-1. Read the current growth plan
-2. Read the user's reason for replanning
-3. If `docs/product-dna.md` exists, consult it — the reason for
-   replanning may relate to domain rules or business invariants
-4. Assess current state: what's built, what works, what changed
+1. Read the current growth plan.
+2. Read the user's reason for replanning.
+3. If `.organic-growth/product-dna.md` exists, consult it — the reason for
+   replanning may relate to domain rules or business invariants.
+4. Assess current state: what's built, what works, what changed.
 5. Rewrite the Concrete stages (next 3-5) from current state,
-   including new properties per stage
+   including new properties per stage.
 6. Verify property accumulation: new stages must not invalidate
    properties from completed stages. If they do, flag this
    explicitly — it means a breaking change.
-7. Update the Horizon section
-8. Do NOT undo or modify completed stages
+7. Update the Horizon section.
+8. Do NOT undo or modify completed stages.
 9. Report what changed and why, including:
    - Properties added, removed, or modified
    - Properties from completed stages that may be at risk
+10. If `.organic-growth/growth-map.md` exists and this replan changes
+    scope significantly, flag it:
+    "This replan may affect the growth map. Review growth-map.md
+    after completing this feature."
 
 # Critical Rules
 
-- NEVER implement more than one stage per /next invocation
-- NEVER plan more than 5 concrete stages ahead
-- ALWAYS define properties before describing implementation
-- ALWAYS write property tests before writing implementation code
-- ALWAYS run build + tests + smoke check before committing
-- ALWAYS update the growth plan after each stage
+- NEVER implement more than one stage per /next invocation.
+- NEVER plan more than 5 concrete stages ahead.
+- ALWAYS define properties before describing implementation.
+- ALWAYS write property tests before writing implementation code.
+- ALWAYS run build + tests + smoke check before committing.
+- ALWAYS update the growth plan after each stage.
 - Properties from completed stages are PERMANENT — they must
   keep passing. If a new stage needs to break an old property,
   this is a REPLAN, not a quiet change.
-- If a stage reveals the plan is wrong, STOP and replan before continuing
-- Hardcoded values are natural in early stages — don't optimize prematurely
-- The growth plan file is the source of truth, not your memory
-- If you don't understand the domain, ASK — don't guess
+- If a stage reveals the plan is wrong, STOP and replan before continuing.
+- Hardcoded values are natural in early stages — don't optimize prematurely.
+- The growth plan file is the source of truth, not your memory.
+- If you don't understand the domain, ASK — don't guess.

package/templates/.claude/commands/grow.md

@@ -4,16 +4,23 @@ description: Plan and start growing a new feature from seed
 
 Grow a new feature using the Organic Growth approach.
 
-1. Invoke the brainstorming skill to explore the problem space for: $ARGUMENTS
-   Think broadly about approaches, risks, and edge cases before committing to a plan.
+1. Before planning, briefly explore the problem space for: $ARGUMENTS
+   - What are 2-3 possible approaches?
+   - What is the riskiest assumption?
+   - What could fail or be harder than expected?
+   Think through this internally. Do not create separate brainstorming artifacts.
 2. Use the gardener agent in PLAN mode
 3. Feature to grow: $ARGUMENTS
-4. When reviewing the plan, focus on PROPERTIES (not implementation hints) —
+4. If `.organic-growth/growth-map.md` exists:
+   - If capability exists on the map: set status to 🌱 and add plan link
+   - If missing: add it in the best-fit section and note it was unplanned
+   - If this modifies a 🌳 capability: add as a sub-entry under the parent capability
+5. When reviewing the plan, focus on PROPERTIES (not implementation hints) —
    these are the primary quality gate. Ask yourself:
    - Are the properties complete? Could someone implement this WRONG
      and still pass all properties?
    - Are properties from earlier stages preserved in later ones?
-   - Do the properties express domain rules, not implementation details?
-5. After the plan is created and approved, ask:
+   - Do properties express domain rules, not implementation details?
+6. After the plan is created and approved, ask:
    "Plan ready. Start growing stage 1?"
-6. If yes, immediately proceed with GROW mode for stage 1
+7. If yes, immediately proceed with GROW mode for stage 1

package/templates/.claude/commands/map.md

@@ -0,0 +1,23 @@
+---
+description: View or update the growth map — your system's big picture
+---
+
+Show or adjust the growth map.
+
+1. If `.organic-growth/growth-map.md` does not exist:
+   - Check if product DNA or CLAUDE.md has enough context to draft one
+   - If yes: generate a draft and present it for review
+   - If no: tell the user to run /seed first or describe the system
+
+2. If map exists and no $ARGUMENTS:
+   - Display current map with status summary:
+     `🌳 X complete | 🌱 Y growing | ⬜ Z planned | 💡 W candidates`
+   - Suggest next capability based on sequence
+
+3. If $ARGUMENTS contains a change request
+   (e.g., "move invoicing before approval"):
+   - Apply the change
+   - Verify whether the new order still makes sense
+   - Present the updated map with explanation
+
+Input: $ARGUMENTS

package/templates/.claude/commands/next.md

@@ -4,11 +4,13 @@ description: Grow the next stage from the current growth plan
 
 Continue growing: implement the next stage from the active growth plan.
 
-1. Find the active plan in docs/growth/
+1. Find the active plan in `.organic-growth/growth/`
 2. Use the gardener agent in GROW mode
 3. If no plan exists, tell the user to run /grow first
 4. If all stages are done, congratulate and suggest what might grow next
 
-Tip: If you hit a wall during implementation, invoke the systematic-debugging skill to work through the problem methodically instead of guessing.
+Tip: If you hit a wall during implementation, debug systematically:
+reproduce the issue, form a hypothesis, verify it, and fix one thing at a time.
+Don't guess.
 
 Feature filter (optional): $ARGUMENTS

package/templates/.claude/commands/replan.md

@@ -4,7 +4,7 @@ description: Re-evaluate the growth plan when reality changes
 
 Something changed. Re-evaluate the growth plan from current state.
 
-1. Find the active plan in docs/growth/
+1. Find the active plan in `.organic-growth/growth/`
 2. Use the gardener agent in REPLAN mode
 3. Reason for replanning: $ARGUMENTS
 4. If no reason given, ask: "What changed?"

package/templates/.claude/commands/review.md

@@ -23,7 +23,7 @@ the implementation session.
    **Consistency:**
    - Does new code follow the same patterns as existing code?
    - Naming conventions, error handling style, project structure
-   - If `docs/product-dna.md` exists: do domain terms match?
+   - If `.organic-growth/product-dna.md` exists: do domain terms match?
 
    **Simplicity:**
    - Is anything over-engineered for the current stage?
@@ -40,7 +40,7 @@ the implementation session.
    - Are edge cases covered?
    - Test readability — can someone understand intent from the test?
 
-4. Output a review report (use the requesting-code-review skill to structure findings):
+4. Output a review report:
 
    ```
    ## Review: <feature> — stages N-M
@@ -59,6 +59,6 @@ the implementation session.
    ### Verdict: ✅ Continue / ⚠️ Fix before next stage / 🔴 Stop and address
    ```
 
-5. If there are 🔴 Issues, use the receiving-code-review skill to process findings with technical rigor, then offer to fix them now.
+5. If there are 🔴 Issues, offer to fix them now.
 
 Scope: $ARGUMENTS

package/templates/.claude/commands/seed.md

@@ -4,18 +4,30 @@ description: Bootstrap a new project — from DNA document or interview
 
 Plant the seed for a new project.
 
-1. Check if a product DNA document was provided (as $ARGUMENTS path or attachment).
-   Also check if `docs/product-dna.md` already exists.
+0. Scan project root for existing code (`src/`, `package.json`, `build.gradle`, `README.md`, etc.).
+   If code already exists:
+   - Read README/build files to auto-fill Tech Stack
+   - Discover quality commands (build, lint, test)
+   - Adjust interview: skip "what tech stack?" and "what are you building?"
+   - Ask instead: "what change do you want to make?" and "any constraints?"
+   - Check recent git commits and ask whether to follow existing commit convention
+
+1. Check if a product DNA document was provided (as `$ARGUMENTS` path or attachment).
+   Also check if `.organic-growth/product-dna.md` already exists.
 
    **Path A — DNA exists:**
    - Read the document
    - Distill it into CLAUDE.md Product section (~10 lines: what, for whom,
      core problem, key domain concepts, current state)
-   - Copy/move the full document to `docs/product-dna.md` if not already there
+   - Map content into the structured DNA format and store in
+     `.organic-growth/product-dna.md`
+   - If Business Rules are missing, ask: "Any rules that must ALWAYS hold?"
    - Confirm with the user: "Here's what I extracted. Anything to adjust?"
 
    **Path B — No DNA:**
-   - Invoke the brainstorming skill to explore what this project could be, before narrowing down through the interview.
+   - Before the interview, briefly consider what this project could be:
+     what kind of system, likely domain risks, and which questions matter most.
+     Do not create separate brainstorming artifacts.
    - Interview the user. Ask these questions ONE AT A TIME:
      - What are you building? (one sentence)
      - Who is it for? What's their context?
@@ -23,23 +35,35 @@ Plant the seed for a new project.
      - What tech stack do you want? (or: should I suggest one?)
      - Any hard constraints? (hosting, budget, compliance, language)
      - What's the priority: speed to MVP, production quality, or learning?
-   - Fill in CLAUDE.md Product section from answers
+     - What are the main user roles? What can each do?
+     - What business rules must ALWAYS be true?
+     - What's the main process flow? (e.g. browse -> cart -> order -> approval -> invoice)
+   - Generate `.organic-growth/product-dna.md` using the structured template.
+     Leave missing sections as `<!-- to be filled -->`.
+   - Fill in CLAUDE.md Product section from answers.
 
 2. In both paths, also fill in:
-   - Tech Stack (THE SOIL): from DNA or interview + scan of existing project files
-   - Priorities (LIGHT & WATER): from DNA or interview
+   - Tech Stack (THE SOIL): from DNA/interview + scan of existing project files
+   - Priorities (LIGHT & WATER): from DNA/interview
 
 3. Check if CLAUDE.md already has a filled Product section.
    If yes, ask: "Product context already exists. Overwrite or update?"
 
-4. Generate `docs/growth/project-bootstrap.md` — the first growth plan:
+4. Generate `.organic-growth/growth/project-bootstrap.md` — the first growth plan:
    - Stage 1: Initialize project (build tool, dependencies, empty build passes)
    - Stage 2: Hello World endpoint/page (proves stack works end-to-end)
    - Stage 3: First domain concept with hardcoded data
    - Stage 4: Persistence (database, migration, first real data)
    - Stage 5: First real behavior with real data
-   Adjust these based on the specific stack and domain from DNA/interview.
+   - Include `Capabilities:` tags in the plan header
+
+5. If the project has 4+ distinct capabilities (from DNA/interview),
+   generate `.organic-growth/growth-map.md` draft:
+   - Organize sequence into Walking Skeleton and what follows
+   - Add short "Why This Order"
+   - Mark `project-bootstrap` as 🌱
+   - Present as aspirational, not a commitment
 
-5. Ask: "Seed planted. Start growing stage 1?"
+6. Ask: "Seed planted. Start growing stage 1?"
 
 Input: $ARGUMENTS

package/templates/CLAUDE.md

@@ -3,7 +3,7 @@
 ## Product (THE SEED — fill this in)
 
 <!-- Without this section, the agent grows weeds. Be brief but specific. -->
-<!-- If you have a full product document, put it in docs/product-dna.md -->
+<!-- If you have a full product document, put it in .organic-growth/product-dna.md -->
 <!-- This section is the distilled version — what the agent sees always. -->
 <!-- The DNA document is read only during planning (/grow, /replan). -->
 
@@ -12,7 +12,7 @@
 **Core problem:** [What pain does it solve?]
 **Key domain concepts:** [3-7 terms that someone new needs to understand]
 **Current state:** [Greenfield / MVP exists / Production system]
-**Full DNA:** [docs/product-dna.md if exists, otherwise "N/A"]
+**Full DNA:** [.organic-growth/product-dna.md if exists, otherwise "N/A"]
 
 ## Tech Stack (THE SOIL — auto-discovered, but document the non-obvious)
 
@@ -61,17 +61,17 @@ A seedling is a whole plant, not 10% of a tree.
    - Never plan more than 5 concrete stages ahead
    - Keep a rough outline of what comes after, but expect it to change
    - Re-evaluate the plan every 3 stages or when something unexpected happens
-   - Update `docs/growth/<feature>.md` after every stage
+   - Update `.organic-growth/growth/<feature>.md` after every stage
 
 3. **Vertical, not horizontal**
    - Each stage touches all layers needed (API + service + DB + test)
    - No "build all the backend first, then the frontend"
    - Early stages can return hardcoded values — that's natural
-   - Growth: hardcoded → configurable → dynamic → optimized
+   - Growth: hardcoded -> configurable -> dynamic -> optimized
 
 4. **Context hygiene**
    - Start a fresh session every 3 stages
-   - The growth plan in `docs/growth/` is the continuity mechanism
+   - The growth plan in `.organic-growth/growth/` is the continuity mechanism
    - After `/clear`, run `/next` — the agent reads the plan and continues
 
 5. **Quality gate after every stage**
@@ -81,7 +81,6 @@ A seedling is a whole plant, not 10% of a tree.
    - ALL tests must pass (not just new ones)
    - App must start (health check / smoke test)
    - Fix all failures within the stage — don't carry debt forward
-   - If the superpowers plugin is installed, its process skills (TDD, debugging, brainstorming) are integrated into commands and the gardener agent automatically
 
 6. **Deep review on demand**
    - Run `/review` after every 3-5 stages or before merging
@@ -108,10 +107,12 @@ For **existing** projects, first stages are:
 ```
 feat(scope): stage N — <what grew>
 
-Growth plan: docs/growth/<feature>.md
+Growth plan: .organic-growth/growth/<feature>.md
 ```
 
 ## Growth Plan Location
 
-All plans live in `docs/growth/<feature-name>.md`.
+All plans live in `.organic-growth/growth/<feature-name>.md`.
+Product DNA lives in `.organic-growth/product-dna.md`.
+Growth map lives in `.organic-growth/growth-map.md` (if exists).
 Format documented in the gardener agent.

package/templates-opencode/.opencode/agents/gardener.md

@@ -19,6 +19,13 @@ each stage produces a complete, living system.
 
 # How You Work
 
+## Paths
+
+Growth plans, Product DNA, and growth map live in `.organic-growth/`:
+- Plans: `.organic-growth/growth/<feature-name>.md`
+- DNA: `.organic-growth/product-dna.md`
+- Map: `.organic-growth/growth-map.md`
+
 You have three modes, determined by what you're asked to do:
 
 ## Mode: PLAN (invoked by /grow)
@@ -30,20 +37,39 @@ You have three modes, determined by what you're asked to do:
    it in now." If the user describes the project, fill in the
    Product/Tech Stack/Priorities sections before continuing.
 1. Read AGENTS.md to understand the product (seed), stack (soil),
-   and priorities (light & water)
-2. Check if `docs/product-dna.md` exists. If yes, read it —
-   it contains the full domain knowledge, business rules, and
-   invariants. Use it to make informed planning decisions.
-   If no, AGENTS.md Product section is sufficient.
-3. Explore the codebase to understand current state
+   and priorities (light & water).
+2. Check if `.organic-growth/product-dna.md` exists. If yes, read it.
+   Pay special attention to:
+   - Business Rules (`BR-*`): global invariants.
+     Properties tied to a rule should reference it: `Refs: BR-3`.
+   - Core Domain Concepts: use these exact names in code.
+     If planning introduces a new concept, add it to DNA after delivery.
+   - Users & Roles: permission properties should reference these roles.
+   If no DNA exists, AGENTS.md Product section is sufficient.
+2b. Check if `.organic-growth/growth-map.md` exists. If yes, read it.
+    Use it to:
+    - Understand what capabilities already exist (🌳)
+    - Follow map links to completed plans and their properties
+    - See expected sequence and likely dependencies
+    If no map exists, search related plans by tag:
+    `grep -r "Capabilities:" .organic-growth/growth/`.
+3. Explore the codebase to understand current state.
+   Search for related growth plans:
+   a. If map exists: follow links to relevant 🌳 plans.
+   b. If no map: find likely related plans by overlapping capability tags.
+   c. If related plans are found: treat their completed properties as
+      constraints. Preserve with `Depends on` or explicitly declare
+      `Breaks: <plan/property> — <reason>`.
+   d. If no related plans are found: proceed normally.
 4. Ask the user 2-3 clarifying questions — no more.
    Focus on: acceptance criteria, constraints, riskiest part.
-5. Create a growth plan in `docs/growth/<feature-name>.md`:
+5. Create a growth plan in `.organic-growth/growth/<feature-name>.md`:
 
 ```markdown
 # 🌱 Feature: <name>
 Created: <date>
 Status: 🌱 Growing
+Capabilities: <3-7 domain tags, comma-separated>
 
 ## Seed (what & why)
 <one paragraph: what this feature does and why it matters>
@@ -56,8 +82,10 @@ Status: 🌱 Growing
   - Properties:
     - P1: <property statement> [invariant|transition|roundtrip|boundary]
       Captures: <what bug this prevents>
+      Refs: BR-<n> (optional)
     - P2: ...
   - Depends on: (properties from earlier stages that must still hold)
+  - Breaks: <plan/property> — <reason> (optional, only for intentional breaks)
   - Touches: <which areas of the code>
   - Implementation hint: <brief guidance for GROW mode>
 
@@ -76,11 +104,12 @@ Status: 🌱 Growing
 
 ### Planning Principles
 - First stage is always the simplest possible thing that proves
-  the idea works end-to-end (even with hardcoded values)
-- Order by: risk reduction first, then user value
-- Each stage must be vertical (touch all necessary layers)
-- If a stage feels bigger than "one intent" — split it
-- For greenfield: follow the greenfield pattern from AGENTS.md
+  the idea works end-to-end (even with hardcoded values).
+- Order by: risk reduction first, then user value.
+- Each stage must be vertical (touch all necessary layers).
+- If a stage feels bigger than "one intent" — split it.
+- Use 3-7 domain capability tags per plan.
+- For greenfield: follow the greenfield pattern from AGENTS.md.
 
 ### Property-Based Planning
 
@@ -141,27 +170,28 @@ This is the primary review gate.
 
 ## Mode: GROW (invoked by /next)
 
-1. Read the growth plan from `docs/growth/`
-2. Find the next 🌱 stage
+1. Read the growth plan from `.organic-growth/growth/`.
+2. Find the next 🌱 stage.
 3. Check the stage counter:
    - If this is stage 3, 6, 9... → re-evaluate the plan first
-     (are remaining stages still correct? adjust if needed)
+     (are remaining stages still correct? adjust if needed).
 4. Implement ONLY this stage:
-   a. Read the stage's properties — these are your acceptance criteria
+   a. Read the stage's properties — these are your acceptance criteria.
    b. Write tests that encode the properties FIRST:
       - Follow red/green/refactor — write a failing test first, then the minimum code to pass it.
-      - Each property (P1, P2, ...) becomes one or more tests
-      - Tests express the RULE, not a specific scenario
-      - Tests for properties from "Depends on" must still pass
-   c. Write the code to make the property tests pass
+      - Each property (P1, P2, ...) becomes one or more tests.
+      - Tests express the RULE, not a specific scenario.
+      - Tests for properties from "Depends on" must still pass.
+   c. Write the code to make the property tests pass.
    d. Quality gate — run ALL checks, fix before proceeding:
-      - Build: verify it compiles (`./gradlew build`, `npm run build`, etc.)
-      - Lint: run the project linter (`./gradlew ktlintCheck`, `npm run lint`, etc.)
-      - Type check: if applicable (`tsc --noEmit`, strict mode, etc.)
-      - Tests: ALL tests pass — current stage AND all previous properties
-      - Smoke: app starts, health endpoint responds (or equivalent)
+      - Build: verify it compiles (`./gradlew build`, `npm run build`, etc.).
+      - Lint: run the project linter (`./gradlew ktlintCheck`, `npm run lint`, etc.).
+      - Type check: if applicable (`tsc --noEmit`, strict mode, etc.).
+      - Tests: ALL tests pass — current stage AND all previous properties.
+      - Smoke: app starts, health endpoint responds (or equivalent).
    e. If any check fails — fix it within this stage, don't leave it
       for the next one. Quality debt doesn't carry forward.
+      - Debug systematically: read the error, reproduce, hypothesize, verify.
 5. Self-review:
    - Do ALL property tests for this stage pass?
    - Do ALL property tests from previous stages still pass?
@@ -172,13 +202,22 @@ This is the primary review gate.
      If yes — the plan has a gap. Note it in the growth log and
      flag to the user, but do not block the stage.
 6. Update the growth plan:
-   - Mark stage as 🌳 with brief note of what was done
-   - Add entry to Growth Log with date
+   - Mark stage as 🌳 with brief note of what was done.
+   - Add entry to Growth Log with date.
    - If this was a re-evaluation point, update upcoming stages
-     (including their properties)
+     (including their properties).
    - If all stages (Concrete + Horizon) are done, set
      `Status: 🌳 Complete` at the top of the plan.
-7. Commit: `feat(scope): stage N — <what grew>`
+     If working on a feature branch: summarize what was built,
+     list verified properties, and note open PR items.
+6b. If `.organic-growth/growth-map.md` exists:
+    - Update this capability status to 🌳.
+    - After reporting, suggest: "Growth map updated. What grows next?"
+6c. If `.organic-growth/product-dna.md` exists and this stage introduced
+    new domain concepts not in DNA:
+    - Add them to Core Domain Concepts.
+    - Note in growth log: "Added concept: <name> to DNA".
+7. Commit: `feat(scope): stage N — <what grew>`.
 8. Report:
    - What grew
    - Properties verified (list P-numbers that pass)
@@ -194,34 +233,38 @@ This is the primary review gate.
 
 ## Mode: REPLAN (invoked by /replan)
 
-1. Read the current growth plan
-2. Read the user's reason for replanning
-3. If `docs/product-dna.md` exists, consult it — the reason for
-   replanning may relate to domain rules or business invariants
-4. Assess current state: what's built, what works, what changed
+1. Read the current growth plan.
+2. Read the user's reason for replanning.
+3. If `.organic-growth/product-dna.md` exists, consult it — the reason for
+   replanning may relate to domain rules or business invariants.
+4. Assess current state: what's built, what works, what changed.
 5. Rewrite the Concrete stages (next 3-5) from current state,
-   including new properties per stage
+   including new properties per stage.
 6. Verify property accumulation: new stages must not invalidate
    properties from completed stages. If they do, flag this
    explicitly — it means a breaking change.
-7. Update the Horizon section
-8. Do NOT undo or modify completed stages
+7. Update the Horizon section.
+8. Do NOT undo or modify completed stages.
 9. Report what changed and why, including:
    - Properties added, removed, or modified
    - Properties from completed stages that may be at risk
+10. If `.organic-growth/growth-map.md` exists and this replan changes
+    scope significantly, flag it:
+    "This replan may affect the growth map. Review growth-map.md
+    after completing this feature."
 
 # Critical Rules
 
-- NEVER implement more than one stage per /next invocation
-- NEVER plan more than 5 concrete stages ahead
-- ALWAYS define properties before describing implementation
-- ALWAYS write property tests before writing implementation code
-- ALWAYS run build + tests + smoke check before committing
-- ALWAYS update the growth plan after each stage
+- NEVER implement more than one stage per /next invocation.
+- NEVER plan more than 5 concrete stages ahead.
+- ALWAYS define properties before describing implementation.
+- ALWAYS write property tests before writing implementation code.
+- ALWAYS run build + tests + smoke check before committing.
+- ALWAYS update the growth plan after each stage.
 - Properties from completed stages are PERMANENT — they must
   keep passing. If a new stage needs to break an old property,
   this is a REPLAN, not a quiet change.
-- If a stage reveals the plan is wrong, STOP and replan before continuing
-- Hardcoded values are natural in early stages — don't optimize prematurely
-- The growth plan file is the source of truth, not your memory
-- If you don't understand the domain, ASK — don't guess
+- If a stage reveals the plan is wrong, STOP and replan before continuing.
+- Hardcoded values are natural in early stages — don't optimize prematurely.
+- The growth plan file is the source of truth, not your memory.
+- If you don't understand the domain, ASK — don't guess.

package/templates-opencode/.opencode/commands/grow.md

@@ -4,14 +4,23 @@ description: Plan and start growing a new feature from seed
 
 Grow a new feature using the Organic Growth approach.
 
-1. Use the @gardener agent in PLAN mode
-2. Feature to grow: $ARGUMENTS
-3. When reviewing the plan, focus on PROPERTIES (not implementation hints) —
+1. Before planning, briefly explore the problem space for: $ARGUMENTS
+   - What are 2-3 possible approaches?
+   - What is the riskiest assumption?
+   - What could fail or be harder than expected?
+   Think through this internally. Do not create separate brainstorming artifacts.
+2. Use the @gardener agent in PLAN mode
+3. Feature to grow: $ARGUMENTS
+4. If `.organic-growth/growth-map.md` exists:
+   - If capability exists on the map: set status to 🌱 and add plan link
+   - If missing: add it in the best-fit section and note it was unplanned
+   - If this modifies a 🌳 capability: add as a sub-entry under the parent capability
+5. When reviewing the plan, focus on PROPERTIES (not implementation hints) —
    these are the primary quality gate. Ask yourself:
    - Are the properties complete? Could someone implement this WRONG
      and still pass all properties?
    - Are properties from earlier stages preserved in later ones?
-   - Do the properties express domain rules, not implementation details?
-4. After the plan is created and approved, ask:
+   - Do properties express domain rules, not implementation details?
+6. After the plan is created and approved, ask:
    "Plan ready. Start growing stage 1?"
-5. If yes, immediately proceed with GROW mode for stage 1
+7. If yes, immediately proceed with GROW mode for stage 1

package/templates-opencode/.opencode/commands/map.md

@@ -0,0 +1,23 @@
+---
+description: View or update the growth map — your system's big picture
+---
+
+Show or adjust the growth map.
+
+1. If `.organic-growth/growth-map.md` does not exist:
+   - Check if product DNA or AGENTS.md has enough context to draft one
+   - If yes: generate a draft and present it for review
+   - If no: tell the user to run /seed first or describe the system
+
+2. If map exists and no $ARGUMENTS:
+   - Display current map with status summary:
+     `🌳 X complete | 🌱 Y growing | ⬜ Z planned | 💡 W candidates`
+   - Suggest next capability based on sequence
+
+3. If $ARGUMENTS contains a change request
+   (e.g., "move invoicing before approval"):
+   - Apply the change
+   - Verify whether the new order still makes sense
+   - Present the updated map with explanation
+
+Input: $ARGUMENTS

package/templates-opencode/.opencode/commands/next.md

@@ -4,9 +4,13 @@ description: Grow the next stage from the current growth plan
 
 Continue growing: implement the next stage from the active growth plan.
 
-1. Find the active plan in docs/growth/
+1. Find the active plan in `.organic-growth/growth/`
 2. Use the @gardener agent in GROW mode
 3. If no plan exists, tell the user to run /grow first
 4. If all stages are done, congratulate and suggest what might grow next
 
+Tip: If you hit a wall during implementation, debug systematically:
+reproduce the issue, form a hypothesis, verify it, and fix one thing at a time.
+Don't guess.
+
 Feature filter (optional): $ARGUMENTS

package/templates-opencode/.opencode/commands/replan.md

@@ -4,7 +4,7 @@ description: Re-evaluate the growth plan when reality changes
 
 Something changed. Re-evaluate the growth plan from current state.
 
-1. Find the active plan in docs/growth/
+1. Find the active plan in `.organic-growth/growth/`
 2. Use the @gardener agent in REPLAN mode
 3. Reason for replanning: $ARGUMENTS
 4. If no reason given, ask: "What changed?"

package/templates-opencode/.opencode/commands/review.md

@@ -23,7 +23,7 @@ the implementation session.
    **Consistency:**
    - Does new code follow the same patterns as existing code?
    - Naming conventions, error handling style, project structure
-   - If `docs/product-dna.md` exists: do domain terms match?
+   - If `.organic-growth/product-dna.md` exists: do domain terms match?
 
    **Simplicity:**
    - Is anything over-engineered for the current stage?

package/templates-opencode/.opencode/commands/seed.md

@@ -4,17 +4,30 @@ description: Bootstrap a new project — from DNA document or interview
 
 Plant the seed for a new project.
 
-1. Check if a product DNA document was provided (as $ARGUMENTS path or attachment).
-   Also check if `docs/product-dna.md` already exists.
+0. Scan project root for existing code (`src/`, `package.json`, `build.gradle`, `README.md`, etc.).
+   If code already exists:
+   - Read README/build files to auto-fill Tech Stack
+   - Discover quality commands (build, lint, test)
+   - Adjust interview: skip "what tech stack?" and "what are you building?"
+   - Ask instead: "what change do you want to make?" and "any constraints?"
+   - Check recent git commits and ask whether to follow existing commit convention
+
+1. Check if a product DNA document was provided (as `$ARGUMENTS` path or attachment).
+   Also check if `.organic-growth/product-dna.md` already exists.
 
    **Path A — DNA exists:**
    - Read the document
    - Distill it into AGENTS.md Product section (~10 lines: what, for whom,
      core problem, key domain concepts, current state)
-   - Copy/move the full document to `docs/product-dna.md` if not already there
+   - Map content into the structured DNA format and store in
+     `.organic-growth/product-dna.md`
+   - If Business Rules are missing, ask: "Any rules that must ALWAYS hold?"
    - Confirm with the user: "Here's what I extracted. Anything to adjust?"
 
    **Path B — No DNA:**
+   - Before the interview, briefly consider what this project could be:
+     what kind of system, likely domain risks, and which questions matter most.
+     Do not create separate brainstorming artifacts.
    - Interview the user. Ask these questions ONE AT A TIME:
      - What are you building? (one sentence)
      - Who is it for? What's their context?
@@ -22,23 +35,35 @@ Plant the seed for a new project.
      - What tech stack do you want? (or: should I suggest one?)
      - Any hard constraints? (hosting, budget, compliance, language)
      - What's the priority: speed to MVP, production quality, or learning?
-   - Fill in AGENTS.md Product section from answers
+     - What are the main user roles? What can each do?
+     - What business rules must ALWAYS be true?
+     - What's the main process flow? (e.g. browse -> cart -> order -> approval -> invoice)
+   - Generate `.organic-growth/product-dna.md` using the structured template.
+     Leave missing sections as `<!-- to be filled -->`.
+   - Fill in AGENTS.md Product section from answers.
 
 2. In both paths, also fill in:
-   - Tech Stack (THE SOIL): from DNA or interview + scan of existing project files
-   - Priorities (LIGHT & WATER): from DNA or interview
+   - Tech Stack (THE SOIL): from DNA/interview + scan of existing project files
+   - Priorities (LIGHT & WATER): from DNA/interview
 
 3. Check if AGENTS.md already has a filled Product section.
    If yes, ask: "Product context already exists. Overwrite or update?"
 
-4. Generate `docs/growth/project-bootstrap.md` — the first growth plan:
+4. Generate `.organic-growth/growth/project-bootstrap.md` — the first growth plan:
    - Stage 1: Initialize project (build tool, dependencies, empty build passes)
    - Stage 2: Hello World endpoint/page (proves stack works end-to-end)
    - Stage 3: First domain concept with hardcoded data
    - Stage 4: Persistence (database, migration, first real data)
    - Stage 5: First real behavior with real data
-   Adjust these based on the specific stack and domain from DNA/interview.
+   - Include `Capabilities:` tags in the plan header
+
+5. If the project has 4+ distinct capabilities (from DNA/interview),
+   generate `.organic-growth/growth-map.md` draft:
+   - Organize sequence into Walking Skeleton and what follows
+   - Add short "Why This Order"
+   - Mark `project-bootstrap` as 🌱
+   - Present as aspirational, not a commitment
 
-5. Ask: "Seed planted. Start growing stage 1?"
+6. Ask: "Seed planted. Start growing stage 1?"
 
 Input: $ARGUMENTS

package/templates-opencode/AGENTS.md

@@ -3,7 +3,7 @@
 ## Product (THE SEED — fill this in)
 
 <!-- Without this section, the agent grows weeds. Be brief but specific. -->
-<!-- If you have a full product document, put it in docs/product-dna.md -->
+<!-- If you have a full product document, put it in .organic-growth/product-dna.md -->
 <!-- This section is the distilled version — what the agent sees always. -->
 <!-- The DNA document is read only during planning (/grow, /replan). -->
 
@@ -12,7 +12,7 @@
 **Core problem:** [What pain does it solve?]
 **Key domain concepts:** [3-7 terms that someone new needs to understand]
 **Current state:** [Greenfield / MVP exists / Production system]
-**Full DNA:** [docs/product-dna.md if exists, otherwise "N/A"]
+**Full DNA:** [.organic-growth/product-dna.md if exists, otherwise "N/A"]
 
 ## Tech Stack (THE SOIL — auto-discovered, but document the non-obvious)
 
@@ -61,17 +61,17 @@ A seedling is a whole plant, not 10% of a tree.
    - Never plan more than 5 concrete stages ahead
    - Keep a rough outline of what comes after, but expect it to change
    - Re-evaluate the plan every 3 stages or when something unexpected happens
-   - Update `docs/growth/<feature>.md` after every stage
+   - Update `.organic-growth/growth/<feature>.md` after every stage
 
 3. **Vertical, not horizontal**
    - Each stage touches all layers needed (API + service + DB + test)
    - No "build all the backend first, then the frontend"
    - Early stages can return hardcoded values — that's natural
-   - Growth: hardcoded → configurable → dynamic → optimized
+   - Growth: hardcoded -> configurable -> dynamic -> optimized
 
 4. **Context hygiene**
    - Start a fresh session every 3 stages
-   - The growth plan in `docs/growth/` is the continuity mechanism
+   - The growth plan in `.organic-growth/growth/` is the continuity mechanism
    - After `/clear`, run `/next` — the agent reads the plan and continues
 
 5. **Quality gate after every stage**
@@ -107,10 +107,12 @@ For **existing** projects, first stages are:
 ```
 feat(scope): stage N — <what grew>
 
-Growth plan: docs/growth/<feature>.md
+Growth plan: .organic-growth/growth/<feature>.md
 ```
 
 ## Growth Plan Location
 
-All plans live in `docs/growth/<feature-name>.md`.
+All plans live in `.organic-growth/growth/<feature-name>.md`.
+Product DNA lives in `.organic-growth/product-dna.md`.
+Growth map lives in `.organic-growth/growth-map.md` (if exists).
 Format documented in the gardener agent.