mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-06-27 13:01:50 +00:00
* Add /vertical-slice skill, prototype overhaul, and workflow integration - Add /vertical-slice skill for pre-production validation (Phase 4 gate) - Overhaul /prototype skill with two-mode design: concept prototype (Phase 1) vs vertical slice (Phase 4), with clearer differentiation and higher standards for VS - Update prototyper agent to own both prototype and vertical-slice workflows - Add prototype-report.md and vertical-slice-report.md output templates - Update WORKFLOW-GUIDE, quick-start, skills-reference, agent-coordination-map, and skill-flow-diagrams to fully integrate both skills into the 7-phase pipeline - Remove orphaned empty quick-prototype/ directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * sync v1 counts + polish Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * Add entity inventory flow, relax vertical-slice gate, improve UX authoring prompts - /asset-spec: new Phase 0b entity & screen inventory when no argument and no existing inventory — reads GDDs/art-bible, proposes categorized list, writes design/assets/entity-inventory.md collaboratively - /asset-spec: entity/character target falls back to inline user description when no source doc exists, rather than failing - /gate-check: vertical slice changed from blocking to CONCERNS-only when absent; built-but-broken slice still fails; adds entity inventory as gate artifact - /ux-design: convert inline approval prompts to AskUserQuestion for structured option capture at key authoring decision points - workflow-catalog.yaml: entity-inventory step added to pre-production; UX spec min_count raised to 3; vertical-slice and prototype marked required: false with updated descriptions - .gitignore: exclude marrow/ eval tooling directory Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Add missing AskUserQuestion widgets to 7 skills Audit found 11 decision points across 7 skills where structured option prompts were missing — using plain text, auto-selection, or no gate at all. Skills patched: - create-epics: per-epic approval + producer CONCERNS verdict - sprint-plan: producer CONCERNS verdict with scope/timeline options - milestone-review: AT RISK / OFF TRACK producer verdicts require acknowledgement - retrospective: existing-retro handling converted from plain text [A]/[B] - quick-design: classification confirmation + draft approve/revise/redirect - tech-debt add mode: category (6 options) + effort (S/M/L/XL) structured capture - regression-suite: no-arg mode selection instead of silent auto-detect - hotfix: severity confirmation gate before workflow begins Also added AskUserQuestion to allowed-tools headers for retrospective, quick-design, tech-debt, regression-suite, and hotfix. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * Prep v1 stable: fix WORKFLOW-GUIDE counts, stale agent names, and skill model fields - WORKFLOW-GUIDE.md: correct agent count (48→49), skill count (66/68→73), add 6 missing skills to Appendix B, fix Creative category count (2→4), replace 3 non-existent agent names with correct ue-*/unity-* specialists, add missing godot-csharp/gdextension specialists to hierarchy, fix production/stories/ paths → production/epics/ - coordination-rules.md: replace "not yet used" with opt-in env var note - quick-start.md: rename duplicate "Validate the concept" label → "Prototype the mechanic" - skill-flow-diagrams.md: remove duplicate legacy UX pipeline section - All 62 skills missing model: field now have explicit model: sonnet Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: comprehensive skill audit — consistency, UX, and flow gaps Two-pass audit fixing ~35 bugs across 41 files. Pre-production flow: - Brainstorm next-steps split into Path A (design-first) and Path B (prototype-first) — eliminates "prototype after architecture" confusion - /architecture-review added to pre-production flow in brainstorm and create-architecture handoffs - gate-check traceability check corrected to requirements-traceability.md - dev-story TR registry error now points to /architecture-review (not /create-epics) - start now writes production/stage.txt on first onboarding AskUserQuestion gaps filled: - balance-check, code-review, hotfix, day-one-patch, consistency-check all gain closing widgets and/or missing allowed-tools declarations - hotfix git branch creation now requires user confirmation - sprint-plan review-mode setup moved to Phase 0 (before gates run) - team-combat gains architecture→implementation approval gate - design-review APPROVED path consolidated from 3 widgets to 1 multiSelect All 9 team-* skills: - Phase 0 review-mode resolution added (solo/lean/full now respected) - team-audio output path fixed (design/gdd/ → design/audio/) - team-level final doc compilation delegated to level-designer subagent - team-narrative localization-lead added to composition list - team-qa sprint path fixed (flat files, not directories) - team-release NO-GO override captures written justification - team-live-ops Cancel verdict now explicitly BLOCKED Other fixes: - Art bible path standardized to design/art/art-bible.md (3 wrong refs) - AD-PHASE-GATE added to lean-mode skip list in director-gates.md - design-system duplicate 5d heading fixed; skeleton decline path added; mandatory agent spawns now respect review mode - story-readiness acceptance criteria thresholds now type-aware - create-stories gains multi-ADR and no-ADR handling guidance - consistency-check creates docs/consistency-failures.md on first run - retrospective frontmatter bash injection replaced with explicit Bash call - smoke-check ls -t gains PowerShell fallback - Conventional Commits format documented in coding-standards.md - gate-check: ADR acceptance gate, QA plan check, chain-of-verification tool-action requirement all added Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix: expose --review flag in argument-hints for all team-* skills All 9 team-* skills already implement Phase 0 review-mode resolution internally (full/lean/solo), but none advertised [--review full|lean|solo] in their argument-hint. Users had no way to discover the per-run override. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add SECURITY.md with coordinated disclosure policy Defines scope, reporting process (GitHub private vulnerability reporting), contributor security guidelines for hooks/skills/agents, and 90-day coordinated disclosure timeline. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add CONTRIBUTING.md with framework contribution guidelines Covers what PRs are welcome, skill/hook/agent technical requirements, the collaborative principle, testing expectations, commit format, and platform compatibility requirements. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * docs: add v1.0.0-beta → v1.0 upgrade section to UPGRADING.md Documents the 17 commits since the beta tag: new /vertical-slice gate, entity inventory flow in /map-systems, AskUserQuestion widgets across 7 skills, --review flag exposure on team-* skills, bug fixes (#21, #36, #42, #43, #45), and the new CONTRIBUTING.md and SECURITY.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
444 lines
18 KiB
Markdown
444 lines
18 KiB
Markdown
---
|
||
name: adopt
|
||
description: "Brownfield onboarding — audits existing project artifacts for template format compliance (not just existence), classifies gaps by impact, and produces a numbered migration plan. Run this when joining an in-progress project or upgrading from an older template version. Distinct from /project-stage-detect (which checks what exists) — this checks whether what exists will actually work with the template's skills."
|
||
argument-hint: "[focus: full | gdds | adrs | stories | infra]"
|
||
user-invocable: true
|
||
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
|
||
model: sonnet
|
||
agent: technical-director
|
||
---
|
||
|
||
# Adopt — Brownfield Template Adoption
|
||
|
||
This skill audits an existing project's artifacts for **format compliance** with
|
||
the template's skill pipeline, then produces a prioritised migration plan.
|
||
|
||
**This is not `/project-stage-detect`.**
|
||
`/project-stage-detect` answers: *what exists?*
|
||
`/adopt` answers: *will what exists actually work with the template's skills?*
|
||
|
||
A project can have GDDs, ADRs, and stories — and every format-sensitive skill
|
||
will still fail silently or produce wrong results if those artifacts are in the
|
||
wrong internal format.
|
||
|
||
**Output:** `docs/adoption-plan-[date].md` — a persistent, checkable migration plan.
|
||
|
||
**Argument modes:**
|
||
|
||
**Audit mode:** `$ARGUMENTS[0]` (blank = `full`)
|
||
|
||
- **No argument / `full`**: Complete audit — all artifact types
|
||
- **`gdds`**: GDD format compliance only
|
||
- **`adrs`**: ADR format compliance only
|
||
- **`stories`**: Story format compliance only
|
||
- **`infra`**: Infrastructure artifact gaps only (registry, manifest, sprint-status, stage.txt)
|
||
|
||
---
|
||
|
||
## Phase 1: Detect Project State
|
||
|
||
Emit one line before reading: `"Scanning project artifacts..."` — this confirms the
|
||
skill is running during the silent read phase.
|
||
|
||
Then read silently before presenting anything else.
|
||
|
||
### Existence check
|
||
- `production/stage.txt` — if present, read it (authoritative phase)
|
||
- `design/gdd/game-concept.md` — concept exists?
|
||
- `design/gdd/systems-index.md` — systems index exists?
|
||
- Count GDD files: `design/gdd/*.md` (excluding game-concept.md and systems-index.md)
|
||
- Count ADR files: `docs/architecture/adr-*.md`
|
||
- Count story files: `production/epics/**/*.md` (excluding EPIC.md)
|
||
- `.claude/docs/technical-preferences.md` — engine configured?
|
||
- `docs/engine-reference/` — engine reference docs present?
|
||
- Glob `docs/adoption-plan-*.md` — note the filename of the most recent prior plan if any exist
|
||
|
||
### Infer phase (if no stage.txt)
|
||
Use the same heuristic as `/project-stage-detect`:
|
||
- 10+ source files in `src/` → Production
|
||
- Stories in `production/epics/` → Pre-Production
|
||
- ADRs exist → Technical Setup
|
||
- systems-index.md exists → Systems Design
|
||
- game-concept.md exists → Concept
|
||
- Nothing → Fresh (not a brownfield project — suggest `/start`)
|
||
|
||
If the project appears fresh (no artifacts at all), use `AskUserQuestion`:
|
||
- "This looks like a fresh project — no existing artifacts found. `/adopt` is for
|
||
projects with work to migrate. What would you like to do?"
|
||
- "Run `/start` — begin guided first-time onboarding"
|
||
- "My artifacts are in a non-standard location — help me find them"
|
||
- "Cancel"
|
||
|
||
Then stop — do not proceed with the audit regardless of which option the user picks
|
||
(each option leads to a different skill or manual investigation).
|
||
|
||
Report: "Detected phase: [phase]. Found: [N] GDDs, [M] ADRs, [P] stories."
|
||
|
||
---
|
||
|
||
## Phase 2: Format Audit
|
||
|
||
For each artifact type in scope (based on argument mode), check not just that
|
||
the file exists but that it contains the internal structure the template requires.
|
||
|
||
### 2a: GDD Format Audit
|
||
|
||
For each GDD file found, check for the 8 required sections by scanning headings:
|
||
|
||
| Required Section | Heading pattern to look for |
|
||
|---|---|
|
||
| Overview | `## Overview` |
|
||
| Player Fantasy | `## Player Fantasy` |
|
||
| Detailed Rules / Design | `## Detailed` or `## Core Rules` or `## Detailed Design` |
|
||
| Formulas | `## Formulas` or `## Formula` |
|
||
| Edge Cases | `## Edge Cases` |
|
||
| Dependencies | `## Dependencies` or `## Depends` |
|
||
| Tuning Knobs | `## Tuning` |
|
||
| Acceptance Criteria | `## Acceptance` |
|
||
|
||
For each GDD, record:
|
||
- Which sections are present
|
||
- Which sections are missing
|
||
- Whether it has any content in present sections or just placeholder text
|
||
(`[To be designed]` or equivalent)
|
||
|
||
Also check: does each GDD have a `**Status**:` field in its header block?
|
||
Valid values: `In Design`, `Designed`, `In Review`, `Approved`, `Needs Revision`.
|
||
|
||
### 2b: ADR Format Audit
|
||
|
||
For each ADR file found, check for these critical sections:
|
||
|
||
| Section | Impact if missing |
|
||
|---|---|
|
||
| `## Status` | **BLOCKING** — `/story-readiness` ADR status check silently passes everything |
|
||
| `## ADR Dependencies` | HIGH — dependency ordering in `/architecture-review` breaks |
|
||
| `## Engine Compatibility` | HIGH — post-cutoff API risk is unknown |
|
||
| `## GDD Requirements Addressed` | MEDIUM — traceability matrix loses coverage |
|
||
| `## Performance Implications` | LOW — not pipeline-critical |
|
||
|
||
For each ADR, record: which sections present, which missing, current Status value
|
||
if the Status section exists.
|
||
|
||
### 2c: systems-index.md Format Audit
|
||
|
||
If `design/gdd/systems-index.md` exists:
|
||
|
||
1. **Parenthetical status values** — Grep for any Status cell containing
|
||
parentheses: `"Needs Revision ("`, `"In Progress ("`, etc.
|
||
These break exact-string matching in `/gate-check`, `/create-stories`,
|
||
and `/architecture-review`. **BLOCKING.**
|
||
|
||
2. **Valid status values** — check that Status column values are only from:
|
||
`Not Started`, `In Progress`, `In Review`, `Designed`, `Approved`, `Needs Revision`
|
||
Flag any unrecognised values.
|
||
|
||
3. **Column structure** — check that the table has at minimum: System name,
|
||
Layer, Priority, Status columns. Missing columns degrade skill functionality.
|
||
|
||
### 2d: Story Format Audit
|
||
|
||
For each story file found:
|
||
|
||
- **`Manifest Version:` field** — present in story header? (LOW — auto-passes if absent)
|
||
- **TR-ID reference** — does story contain `TR-[a-z]+-[0-9]+` pattern? (MEDIUM — no staleness tracking)
|
||
- **ADR reference** — does story reference at least one ADR? (check for `ADR-` pattern)
|
||
- **Status field** — present and readable?
|
||
- **Acceptance criteria** — does the story have a checkbox list (`- [ ]`)?
|
||
|
||
### 2e: Infrastructure Audit
|
||
|
||
| Artifact | Path | Impact if missing |
|
||
|---|---|---|
|
||
| TR registry | `docs/architecture/tr-registry.yaml` | HIGH — no stable requirement IDs |
|
||
| Control manifest | `docs/architecture/control-manifest.md` | HIGH — no layer rules for stories |
|
||
| Manifest version stamp | In manifest header: `Manifest Version:` | MEDIUM — staleness checks blind |
|
||
| Sprint status | `production/sprint-status.yaml` | MEDIUM — `/sprint-status` falls back to markdown |
|
||
| Stage file | `production/stage.txt` | MEDIUM — phase auto-detect unreliable |
|
||
| Engine reference | `docs/engine-reference/[engine]/VERSION.md` | HIGH — ADR engine checks blind |
|
||
| Architecture traceability | `docs/architecture/architecture-traceability.md` | MEDIUM — no persistent matrix |
|
||
|
||
### 2f: Technical Preferences Audit
|
||
|
||
Read `.claude/docs/technical-preferences.md`. Check each field for `[TO BE CONFIGURED]`:
|
||
- Engine, Language, Rendering, Physics → HIGH if unconfigured (ADR skills fail)
|
||
- Naming conventions → MEDIUM
|
||
- Performance budgets → MEDIUM
|
||
- Forbidden Patterns, Allowed Libraries → LOW (starts empty by design)
|
||
|
||
---
|
||
|
||
## Phase 3: Classify and Prioritise Gaps
|
||
|
||
Organise every gap found across all audits into four severity tiers:
|
||
|
||
**BLOCKING** — Will cause template skills to silently produce wrong results *right now*.
|
||
Examples: ADR missing Status field, systems-index parenthetical status values,
|
||
engine not configured when ADRs exist.
|
||
|
||
**HIGH** — Will cause stories to be generated with missing safety checks, or
|
||
infrastructure bootstrapping will fail.
|
||
Examples: ADRs missing Engine Compatibility, GDDs missing Acceptance Criteria
|
||
(stories can't be generated from them), tr-registry.yaml missing.
|
||
|
||
**MEDIUM** — Degrades quality and pipeline tracking but does not break functionality.
|
||
Examples: GDDs missing Tuning Knobs or Formulas sections, stories missing TR-IDs,
|
||
sprint-status.yaml missing.
|
||
|
||
**LOW** — Retroactive improvements that are nice-to-have but not urgent.
|
||
Examples: Stories missing Manifest Version stamps, GDDs missing Open Questions section.
|
||
|
||
Count totals per tier. If zero BLOCKING and zero HIGH gaps: report that the project
|
||
is template-compatible and only advisory improvements remain.
|
||
|
||
---
|
||
|
||
## Phase 4: Build the Migration Plan
|
||
|
||
Compose a numbered, ordered action plan. Ordering rules:
|
||
1. BLOCKING gaps first (must fix before any pipeline skill runs reliably)
|
||
2. HIGH gaps next, infrastructure before GDD/ADR content (bootstrapping needs correct formats)
|
||
3. MEDIUM gaps ordered: GDD gaps before ADR gaps before story gaps (stories depend on GDDs and ADRs)
|
||
4. LOW gaps last
|
||
|
||
For each gap, produce a plan entry with:
|
||
- A clear problem statement (one sentence, no jargon)
|
||
- The exact command to fix it, if a skill handles it
|
||
- Manual steps if it requires direct editing
|
||
- A time estimate (rough: 5 min / 30 min / 1 session)
|
||
- A checkbox `- [ ]` for tracking
|
||
|
||
**Special case — systems-index parenthetical status values:**
|
||
This is always the first item if present. Show the exact values that need changing
|
||
and the exact replacement text. Offer to fix this immediately before writing the plan.
|
||
|
||
**Special case — ADRs missing Status field:**
|
||
For each affected ADR, the fix is:
|
||
`/architecture-decision retrofit docs/architecture/adr-[NNNN]-[slug].md`
|
||
List each ADR as a separate checkable item.
|
||
|
||
**Special case — GDDs missing sections:**
|
||
For each affected GDD, list which sections are missing and the fix:
|
||
`/design-system retrofit design/gdd/[filename].md`
|
||
|
||
**Infrastructure bootstrap ordering** — always present in this sequence:
|
||
1. Fix ADR formats first (registry depends on reading ADR Status fields)
|
||
2. Run `/architecture-review` → bootstraps `tr-registry.yaml`
|
||
3. Run `/create-control-manifest` → creates manifest with version stamp
|
||
4. Run `/sprint-plan update` → creates `sprint-status.yaml`
|
||
5. Run `/gate-check [phase]` → writes `stage.txt` authoritatively
|
||
|
||
**Existing stories** — note explicitly:
|
||
> "Existing stories continue to work with all template skills — all new format
|
||
> checks auto-pass when the fields are absent. They won't benefit from TR-ID
|
||
> staleness tracking or manifest version checks until they're regenerated. This
|
||
> is intentional: do not regenerate stories that are already in progress."
|
||
|
||
---
|
||
|
||
## Phase 5: Present Summary and Ask to Write
|
||
|
||
Present a compact summary before writing:
|
||
|
||
```
|
||
## Adoption Audit Summary
|
||
Phase detected: [phase]
|
||
Engine: [configured / NOT CONFIGURED]
|
||
GDDs audited: [N] ([X] fully compliant, [Y] with gaps)
|
||
ADRs audited: [N] ([X] fully compliant, [Y] with gaps)
|
||
Stories audited: [N]
|
||
|
||
Gap counts:
|
||
BLOCKING: [N] — template skills will malfunction without these fixes
|
||
HIGH: [N] — unsafe to run /create-stories or /story-readiness
|
||
MEDIUM: [N] — quality degradation
|
||
LOW: [N] — optional improvements
|
||
|
||
Estimated remediation: [X blocking items × ~Y min each = roughly Z hours]
|
||
```
|
||
|
||
Before asking to write, show a **Gap Preview**:
|
||
- List every BLOCKING gap as a one-line bullet describing the actual problem
|
||
(e.g. `systems-index.md: 3 rows have parenthetical status values`,
|
||
`adr-0002.md: missing ## Status section`). No counts — show the actual items.
|
||
- Show HIGH / MEDIUM / LOW as counts only (e.g. `HIGH: 4, MEDIUM: 2, LOW: 1`).
|
||
|
||
This gives the user enough context to judge scope before committing to writing the file.
|
||
|
||
If a prior adoption plan was detected in Phase 1, add a note:
|
||
> "A previous plan exists at `docs/adoption-plan-[prior-date].md`. The new plan will
|
||
> reflect current project state — it does not diff against the prior run."
|
||
|
||
Use `AskUserQuestion`:
|
||
- "Ready to write the migration plan?"
|
||
- "Yes — write `docs/adoption-plan-[date].md`"
|
||
- "Show me the full plan preview first (don't write yet)"
|
||
- "Cancel — I'll handle migration manually"
|
||
|
||
If the user picks "Show me the full plan preview", output the complete plan as a
|
||
fenced markdown block. Then ask again with the same three options.
|
||
|
||
---
|
||
|
||
## Phase 6: Write the Adoption Plan
|
||
|
||
If approved, write `docs/adoption-plan-[date].md` with this structure:
|
||
|
||
```markdown
|
||
# Adoption Plan
|
||
|
||
> **Generated**: [date]
|
||
> **Project phase**: [phase]
|
||
> **Engine**: [name + version, or "Not configured"]
|
||
> **Template version**: v1.0+
|
||
|
||
Work through these steps in order. Check off each item as you complete it.
|
||
Re-run `/adopt` anytime to check remaining gaps.
|
||
|
||
---
|
||
|
||
## Step 1: Fix Blocking Gaps
|
||
|
||
[One sub-section per blocking gap with problem, fix command, time estimate, checkbox]
|
||
|
||
---
|
||
|
||
## Step 2: Fix High-Priority Gaps
|
||
|
||
[One sub-section per high gap]
|
||
|
||
---
|
||
|
||
## Step 3: Bootstrap Infrastructure
|
||
|
||
### 3a. Register existing requirements (creates tr-registry.yaml)
|
||
Run `/architecture-review` — even if ADRs already exist, this run bootstraps
|
||
the TR registry from your existing GDDs and ADRs.
|
||
**Time**: 1 session (review can be long for large codebases)
|
||
- [ ] tr-registry.yaml created
|
||
|
||
### 3b. Create control manifest
|
||
Run `/create-control-manifest`
|
||
**Time**: 30 min
|
||
- [ ] docs/architecture/control-manifest.md created
|
||
|
||
### 3c. Create sprint tracking file
|
||
Run `/sprint-plan update`
|
||
**Time**: 5 min (if sprint plan already exists as markdown)
|
||
- [ ] production/sprint-status.yaml created
|
||
|
||
### 3d. Set authoritative project stage
|
||
Run `/gate-check [current-phase]`
|
||
**Time**: 5 min
|
||
- [ ] production/stage.txt written
|
||
|
||
---
|
||
|
||
## Step 4: Medium-Priority Gaps
|
||
|
||
[One sub-section per medium gap]
|
||
|
||
---
|
||
|
||
## Step 5: Optional Improvements
|
||
|
||
[One sub-section per low gap]
|
||
|
||
---
|
||
|
||
## What to Expect from Existing Stories
|
||
|
||
Existing stories continue to work with all template skills. New format checks
|
||
(TR-ID validation, manifest version staleness) auto-pass when the fields are
|
||
absent — so nothing breaks. They won't benefit from staleness tracking until
|
||
regenerated. Do not regenerate stories that are in progress or done.
|
||
|
||
---
|
||
|
||
## Re-run
|
||
|
||
Run `/adopt` again after completing Step 3 to verify all blocking and high gaps
|
||
are resolved. The new run will reflect the current state of the project.
|
||
```
|
||
|
||
---
|
||
|
||
## Phase 6b: Set Review Mode
|
||
|
||
After writing the adoption plan (or if the user cancels writing), check whether
|
||
`production/review-mode.txt` exists.
|
||
|
||
**If it exists**: Read it and note the current mode — "Review mode is already set to `[current]`." — skip the prompt.
|
||
|
||
**If it does not exist**: Use `AskUserQuestion`:
|
||
|
||
- **Prompt**: "One more setup step: how much design review would you like as you work through the workflow?"
|
||
- **Options**:
|
||
- `Full` — Director specialists review at each key workflow step. Best for teams, learning the workflow, or when you want thorough feedback on every decision.
|
||
- `Lean (recommended)` — Directors only at phase gate transitions (/gate-check). Skips per-skill reviews. Balanced for solo devs and small teams.
|
||
- `Solo` — No director reviews at all. Maximum speed. Best for game jams, prototypes, or if reviews feel like overhead.
|
||
|
||
Write the choice to `production/review-mode.txt` immediately after selection — no separate "May I write?" needed:
|
||
- `Full` → write `full`
|
||
- `Lean (recommended)` → write `lean`
|
||
- `Solo` → write `solo`
|
||
|
||
Create the `production/` directory if it does not exist.
|
||
|
||
---
|
||
|
||
## Phase 7: Offer First Action
|
||
|
||
After writing the plan, don't stop there. Pick the single highest-priority gap
|
||
and offer to handle it immediately using `AskUserQuestion`. Choose the first
|
||
branch that applies:
|
||
|
||
**If there are parenthetical status values in systems-index.md:**
|
||
Use `AskUserQuestion`:
|
||
- "The most urgent fix is `systems-index.md` — [N] rows have parenthetical status
|
||
values (e.g. `Needs Revision (see notes)`) that break /gate-check,
|
||
/create-stories, and /architecture-review right now. I can fix these in-place."
|
||
- "Fix it now — edit systems-index.md"
|
||
- "I'll fix it myself"
|
||
- "Done — leave me with the plan"
|
||
|
||
**If ADRs are missing `## Status` (and no parenthetical issue):**
|
||
Use `AskUserQuestion`:
|
||
- "The most urgent fix is adding `## Status` to [N] ADR(s): [list filenames].
|
||
Without it, /story-readiness silently passes all ADR checks. Start with
|
||
[first affected filename]?"
|
||
- "Yes — retrofit [first affected filename] now"
|
||
- "Retrofit all [N] ADRs one by one"
|
||
- "I'll handle ADRs myself"
|
||
|
||
**If GDDs are missing Acceptance Criteria (and no blocking issues above):**
|
||
Use `AskUserQuestion`:
|
||
- "The most urgent gap is missing Acceptance Criteria in [N] GDD(s):
|
||
[list filenames]. Without them, /create-stories can't generate stories.
|
||
Start with [highest-priority GDD filename]?"
|
||
- "Yes — add Acceptance Criteria to [GDD filename] now"
|
||
- "Do all [N] GDDs one by one"
|
||
- "I'll handle GDDs myself"
|
||
|
||
**If no BLOCKING or HIGH gaps exist:**
|
||
Use `AskUserQuestion`:
|
||
- "No blocking gaps — this project is template-compatible. What next?"
|
||
- "Walk me through the medium-priority improvements"
|
||
- "Run /project-stage-detect for a broader health check"
|
||
- "Done — I'll work through the plan at my own pace"
|
||
|
||
> **Adoption plan saved to `docs/adoption-plan-[date].md`.** Re-run `/adopt` at any time to re-check remaining gaps as you complete them.
|
||
|
||
---
|
||
|
||
## Collaborative Protocol
|
||
|
||
1. **Read silently** — complete the full audit before presenting anything
|
||
2. **Show the summary first** — let the user see scope before asking to write
|
||
3. **Ask before writing** — always confirm before creating the adoption plan file
|
||
4. **Offer, don't force** — the plan is advisory; the user decides what to fix and when
|
||
5. **One action at a time** — after handing off the plan, offer one specific next step,
|
||
not a list of six things to do simultaneously
|
||
6. **Never regenerate existing artifacts** — only fill gaps in what exists;
|
||
do not rewrite GDDs, ADRs, or stories that already have content
|