[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HV5MSM0Y4JBVMHDG81K2Y":3,"skill-same:01M71HV5MSM0Y4JBVMHDG81K2Y":72},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":54,"ownerHtmlUrl":55,"ownerBlogUrl":56,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M71HV5MSM0Y4JBVMHDG81K2Y","migrate-spec",null,"Detect GSD, spec-kit, or BMAD spec artifacts and transform them into bigpowers YAML layout (state.yaml, release-plan.yaml, epics\u002F, requirements\u002F, plans\u002F, ADRs). Use when migrating foreign spec docs.","danielvm-git\u002Fbigpowers","danielvm-git","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1020864?v=4","01M71H1N1CTQ529S0KN7KETVG6","Daniel V M","01M71H1N218Y3S8WHCJ58NPRSW",292,"MIT","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Fmigrate-spec\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"migrate","spec","migrate spec","requirements","artifacts","plans","transform","layout","when","yaml","detect","spec-kit","state","bmad","use","bmad spec","sonnet","release","plan","kit","2026-11-10 10:12:30",false,"---\nname: migrate-spec\nmodel: sonnet\ndescription: \"Detect GSD, spec-kit, or BMAD spec artifacts and transform them into bigpowers YAML layout (state.yaml, release-plan.yaml, epics\u002F, requirements\u002F, plans\u002F, ADRs). Use when migrating foreign spec docs.\"\n---\n\n\u003C!-- story: e25s01 -->\n\u003C!-- story: e25s02 -->\n\u003C!-- story: e25s03 -->\n\u003C!-- story: e25s04 -->\n\u003C!-- story: e25s05 -->\n\u003C!-- story: e25s06 -->\n\n# Migrate Spec\n\nTransform existing GSD, spec-kit, or BMAD planning artifacts into the bigpowers `specs\u002F` model. No code is written — the output is a set of bigpowers-format spec files the user can use immediately.\n\n## Quick start\n\n1. Run this skill from the root of the project being migrated (not the bigpowers repo itself).\n2. The skill auto-detects the source framework and presents its findings before transforming anything.\n3. All output goes to `specs\u002F` at the project root.\n\n---\n\n## Red flags — stop and ask\n\nBefore proceeding, check for these rationalization traps:\n\n- **Partial artifact set** — only one fingerprint file found (e.g. just `spec.md` with no `plan.md`). Don't assume it's a complete project. Ask: \"I found only X — is this the full set of your spec artifacts?\"\n- **Wrong trigger** — user said \"migrate my code\" or \"migrate the database\", not \"migrate my specs\". Confirm before running.\n- **Stale source** — source artifacts have commit dates older than 6 months with no recent activity. Flag: \"These specs appear inactive since \u003Cdate>. Are they still the source of truth?\"\n- **Active divergence** — source `state.yaml` or `sprint-status.yaml` shows in-progress work. Flag: \"There is active work in flight. Migrating now may lose in-progress context. Proceed?\"\n\nIf any red flag fires: surface it, wait for explicit user confirmation before continuing.\n\n---\n\n## Process\n\n### Step 1 — Detect the source framework\n\nScan for the fingerprints below. Stop at first match; if multiple match, list them and ask the user which is primary.\n\n| Framework | Fingerprints (any one is sufficient) |\n|-----------|--------------------------------------|\n| **GSD** | `.planning\u002F` directory; `.planning\u002FROADMAP.md`; `.planning\u002FREQUIREMENTS.md` with `REQ-` IDs |\n| **spec-kit** | `.specify\u002F` directory; `spec.md` + `plan.md` at root; `.github\u002Fskills\u002Fspeckit-*\u002FSKILL.md` |\n| **BMAD** | `_bmad\u002F` directory; `_bmad-output\u002F` directory; `prd.md` with `FR-` IDs; `epic-*.md` or `story-*.md` |\n\nIf none found: ask the user which framework before proceeding.\n\n→ verify: `test -d specs && test -f specs\u002Fstate.yaml`\n\n### Step 2 — Inventory the source artifacts\n\nList every artifact found matching the detected framework. Present the list to the user:\n\nSee [REFERENCE.md](REFERENCE.md) — `Detected: GSD...`\n\n→ verify: `test -d specs && test -w specs`\n\n### Step 3 — Transform (one artifact at a time, show diffs)\n\nApply the mapping from [REFERENCE.md](.\u002FREFERENCE.md) and [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md). For each target file:\n\n1. Show what will be created or appended (title + first 20 lines).\n2. Ask: \"Create this? [yes \u002F edit \u002F skip]\"\n3. On yes: write to `specs\u002F`.\n\n#### ID Tracking (REQ-XX, FR-XX, UJ-XX)\n\nWhen source artifacts contain IDs (REQ-XX, FR-XX, UJ-XX), emit them as **first-class YAML fields** in `in_scope` entries, not YAML comments:\n\nSee [REFERENCE.md](REFERENCE.md) — `# CORRECT — first-class id: field...`\n\n**When source has no IDs:** Prompt the user: \"No IDs found. Assign auto-generated IDs? [yes \u002F no]\". If yes, emit `REQ-{NNN}` with `# auto-generated` annotation.\n\n**When source has MIXED IDs:** Items with IDs get `id:` fields; items without IDs receive auto-generated `REQ-NNN` entries. Document which were auto-generated in a comment block at the top of `in_scope`.\n\nSee [REFERENCE.md — in_scope format with ID tracking](.\u002FREFERENCE.md#in_scope-format-with-id-tracking) for examples.\n\n#### Traceability Output (FR-XX, UJ-XX)\n\nWhen source has FR-XX or UJ-XX IDs, emit `specs\u002Fproduct\u002FREQUIREMENTS_TRACE.yaml` for end-to-end requirement traceability:\n\nSee [REFERENCE.md](REFERENCE.md) — `trace:...`\n\n**Existing trace file:** If `REQUIREMENTS_TRACE.yaml` already exists, prompt: \"REQUIREMENTS_TRACE.yaml exists. [overwrite \u002F merge \u002F skip]\"\n\n**No FR-XX\u002FUJ-XX found:** Skip trace file; add note to state.yaml handoff: \"No FR-XX\u002FUJ-XX IDs found — traceability file skipped\".\n\nSee [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](.\u002FREFERENCE.md#requirements_traceyaml-format) for the complete schema.\n\n> **HARD GATE** — Never overwrite an existing `specs\u002F` file without explicit user confirmation. Merge into it if it exists; don't clobber.\n>\n> → verify: `git rev-parse --git-dir >\u002Fdev\u002Fnull 2>&1 && test -d specs`\n\n→ verify: `test -d specs && [ \"$(ls specs\u002F*.md specs\u002F*.yaml 2>\u002Fdev\u002Fnull | wc -l | tr -d \" \")\" -gt 0 ]`\n\n### Step 4 — Generate state.yaml\n\nAlways regenerate `specs\u002Fstate.yaml` from scratch in bigpowers YAML format (see REFERENCE.md for template). The **handoff block is mandatory** and must include all four fields:\n\nSee [REFERENCE.md](REFERENCE.md) — `active_flow: null...`\n\nIf no open decisions were found during migration, the `open_decisions` list may be empty with an explanatory comment:\n\nSee [REFERENCE.md](REFERENCE.md) — `handoff:...`\n\n→ verify: `grep -q handoff: specs\u002Fstate.yaml`\n\n---\n\n# migrate-spec Reference — GSD\n\nFull artifact transformation rules for migrating GSD projects to bigpowers YAML layout.\n\nSee [REFERENCE.md](.\u002FREFERENCE.md) for spec-kit, BMAD, learnings, and ADR\u002FDECISION-LOG formats.\n\n---\n\n## Artifact Locations\n\nGSD stores everything under `.planning\u002F` at the project root.\n\n```\n.planning\u002F\n├── ROADMAP.md\n├── STATE.md\n├── REQUIREMENTS.md\n├── METHODOLOGY.md\n├── HANDOFF.json\n├── .continue-here.md\n└── phases\u002F\n    └── XX-name\u002F\n        ├── XX-CONTEXT.md\n        ├── XX-YY-PLAN.md\n        ├── XX-YY-SUMMARY.md\n        └── XX-DISCUSSION-LOG.md\n    spikes\u002F\n        └── SPIKE-NNN\u002FREADME.md\n```\n\n---\n\n## Transformation Rules\n\n### `.planning\u002FROADMAP.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml`\n\nGSD ROADMAP has: milestone name, phases, success criteria per phase, plan count.\n\nTransform:\n- Each GSD phase → one epic entry in `release-plan.yaml` (`id`, `title`, `wsjf`, `file`)\n- Phase detail → matching `specs\u002Fepics\u002FeNN-slug.yaml` (stories, tasks, `verify`)\n- Completed phases → `done` in `execution-status.yaml`; active → `in_progress`\n\n---\n\n### `.planning\u002FREQUIREMENTS.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml`\n\nGSD REQUIREMENTS has: REQ-XX IDs, Validated\u002FActive\u002FOut-of-Scope categories, traceability.\n\nTransform:\n- Preserve REQ-XX IDs as **first-class `id:` fields** in `in_scope` entries (see [REFERENCE.md — ID tracking format](.\u002FREFERENCE.md#in_scope-format-with-id-tracking))\n- Validated requirements → `in_scope` entries with `id:`, `description:`, `source:` fields\n- Out-of-Scope → `out_of_scope` entries (preserve IDs if present)\n- Active (in-progress) → `in_scope` with status note\n\n---\n\n### `.planning\u002Fphases\u002FXX-name\u002FXX-CONTEXT.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F`\n\nGSD CONTEXT.md has 6 sections: domain, decisions, canonical_refs, code_context, specifics, deferred.\n\nTransform:\n- `domain` → `plans\u002FTECH_STACK_LATEST.md` Domain section\n- `decisions` → scan each: if hard-to-reverse + surprising → `specs\u002Fadr\u002FNNNN-{slug}.md`; if lightweight → `specs\u002FDECISION-LOG_LATEST.md`\n- `canonical_refs` → Reference links in TECH_STACK\n- `code_context` → Architecture section\n- `deferred` → `SCOPE_LATEST.yaml` `out_of_scope` (with \"(deferred from GSD)\" note)\n\n---\n\n### `.planning\u002Fphases\u002FXX-name\u002FXX-YY-PLAN.md` → `specs\u002Fepics\u002FeNN-*.yaml` tasks\n\nGSD PLAN has: frontmatter (depends-on, verify), objective, typed tasks, success criteria, output spec.\n\nTransform:\n- Preserve task structure as `tasks[]` in epic shard\n- Keep `verify: \u003Ccommand>` lines\n- Map GSD `depends-on` to task `depends-on` notes\n- SUMMARY.md (execution record) → skip or append to `specs\u002Farchive\u002F`\n\n---\n\n### `.planning\u002FMETHODOLOGY.md` → `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`\n\nGSD METHODOLOGY.md is a standing reference for analytical lenses (Bayesian updating, STRIDE, cost-of-delay).\n\nTransform:\n- Copy each lens as a section in `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`\n- Note: \"These lenses should inform `plan-work` and `audit-code` sessions.\"\n\n---\n\n### `.planning\u002FHANDOFF.json` + `.continue-here.md` → `specs\u002Fstate.yaml` `handoff`\n\nGSD HANDOFF has: current phase, last plan, blocking reason, required reading list.\n\nTransform — populate `handoff` in `state.yaml`:\n\n```yaml\nhandoff:\n  last_step_completed: \"\u003Cphase\u002Fplan from HANDOFF>\"\n  open_decisions:\n    - \"\u003Cblocking reason if any>\"\n  required_reading:\n    - \"\u003Crequired_reading list>\"\n  next_skill: survey-context\n```\n\n---\n\n### `.planning\u002Fspikes\u002FSPIKE-NNN\u002FREADME.md` → `specs\u002Farchive\u002Fspikes\u002FSPIKE-{name}.md`\n\nGSD spike README has: YAML frontmatter (verdict, validates, related), methodology, findings, recommendation.\n\nTransform:\n- Flatten directory into `specs\u002Farchive\u002Fspikes\u002FSPIKE-{name}.md`\n- Preserve frontmatter as YAML block at top\n- Keep verdict prominently: `**Verdict:** ADOPTED \u002F REJECTED \u002F DEFERRED`\n\n---\n\n## Skip List\n\nThese GSD artifacts are not migrated — they are execution records, not planning inputs:\n\n| Artifact | Reason |\n|----------|--------|\n| `.planning\u002Fphases\u002FXX\u002FXX-YY-SUMMARY.md` | Execution log; no bigpowers equivalent |\n| `.planning\u002Fphases\u002FXX\u002FXX-DISCUSSION-LOG.md` | Audit trail only; not consumed by agents |\n| `.planning\u002FUSER-PROFILE.md` | User calibration; bigpowers has no profile system |\n| `.planning\u002Fsketches\u002F` | Visual exploration; not spec artifacts |\n\n---\n\n# Migrate Spec — Reference\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 3–68 | Navigation |\n| 69–70 | spec-kit → bigpowers Mapping |\n| 71–84 | Artifact Locations |\n| 85–94 | `spec.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` |\n| 95–105 | `plan.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F` |\n| 106–114 | `tasks.md` → `specs\u002Fepics\u002F` (via slice-tasks) |\n| 115–120 | `.specify\u002F` state |\n| 121–122 | BMAD → bigpowers Mapping |\n| 123–141 | Artifact Locations |\n| 142–148 | `product-brief.md` \u002F `prfaq-{project}.md` → `specs\u002Fproduct\u002FVISION_LATEST.yaml` |\n| 149–160 | `prd.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `GLOSSARY_LATEST.yaml` |\n| 161–167 | `addendum.md` + `decision-log.md` → `specs\u002Fadr\u002F` + `specs\u002FDECISION-LOG_LATEST.md` |\n| 168–174 | `architecture.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F` |\n| 175–178 | `epic-*.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml` |\n| 179–182 | `story-*.md` → `specs\u002Fepics\u002F` stories |\n| 183–188 | `project-context.md` → `CLAUDE.md` |\n| 189–192 | Learnings to Adopt |\n| 193–198 | From GSD |\n| 199–204 | From spec-kit |\n| 205–212 | From BMAD |\n| 213–214 | Output Formats |\n| 215–224 | ADR format (bigpowers) |\n| 225–227 | Context |\n| 228–230 | Decision |\n| 231–234 | Consequences |\n| 235–246 | DECISION-LOG.md format |\n| 247–257 | MIGRATION-AUDIT.md format |\n| 258–264 | Summary |\n| 265–274 | High Priority Findings |\n| 275–278 | Information |\n| 279–285 | Next Steps |\n| 286–306 | in_scope format with ID tracking |\n| 307–341 | REQUIREMENTS_TRACE.yaml format |\n| 342–397 | `specs\u002Fstate.yaml` template format |\n| 398–416 | Reference block 1 |\n| 417–432 | Reference block 2 |\n| 433–451 | Reference block 3 |\n| 452–474 | Reference block 4 |\n| 475–482 | Reference block 5 |\n| 483–484 | Findings |\n| 485–489 | High Priority |\n| 490–495 | Information |\n| 496–509 | Reference block 6 |\n| 510–542 | Step 7 — Post-migration: Optional two-pass spec writing gate |\n| 543–574 | Step 8 — Post-migration: Optional methodology doc template |\n| 575–600 | Artifact Mapping Summary |\n| 601–610 | Rules |\n| 611–621 | Step 5 — Surface learnings (optional) |\n| 622–644 | Step 6 — Adversarial review (optional) |\n| 645–646 | Findings |\n| 647–651 | High Priority |\n| 652–660 | Information |\n\n# migrate-spec Reference — spec-kit, BMAD, Learnings\n\nTransformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.\n\nSee [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md) for full GSD → bigpowers YAML mapping.\n\n---\n\n## spec-kit → bigpowers Mapping\n\n### Artifact Locations\n\n```\nproject-root\u002F\n├── spec.md         ← user journeys, success criteria, scope\n├── plan.md         ← technology, architecture, constraints\n├── tasks.md        ← atomic task list\n└── .specify\u002F\n    ├── workflow-catalogs.yml\n    └── workflows\u002Fruns\u002F\u003Cid>\u002F\n        ├── state.json\n        └── log.jsonl\n```\n\n### `spec.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md`\n\nspec-kit `spec.md` focuses on: who uses it, user journeys, success criteria, what's in\u002Fout of scope.\n\nTransform:\n- User journeys → `SCOPE_LATEST.yaml` success criteria \u002F `in_scope` entries\n- In\u002Fout of scope → `in_scope` \u002F `out_of_scope` sections\n- Domain terms \u002F glossary → `requirements\u002FGLOSSARY_LATEST.yaml`\n- Problem statement \u002F vision → `requirements\u002FVISION_LATEST.yaml`\n\n### `plan.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F`\n\nspec-kit `plan.md` covers: technology stack, architectural patterns, implementation constraints.\n\nTransform:\n- Technology decisions → `plans\u002FTECH_STACK_LATEST.md` Technology section\n- Architecture patterns → Architecture section\n- Hard decisions with trade-offs → `specs\u002Fadr\u002FNNNN-{slug}.md`\n- Phased approach \u002F milestones → `release-plan.yaml` epic entries\n- Implementation steps → `epics\u002FeNN-*.yaml` task list with `verify:`\n\n### `tasks.md` → `specs\u002Fepics\u002F` (via slice-tasks)\n\nspec-kit tasks are atomic, verifiable in isolation — same principle as bigpowers `verify:` mandate.\n\nTransform:\n- Copy tasks into epic shard `tasks[]`; preserve task numbers\n- Add `verify:` line if spec-kit task has an acceptance criterion\n- Group into epics matching `release-plan.yaml` entries\n\n### `.specify\u002F` state\n\nDiscard — workflow engine state; not meaningful in the bigpowers skill model.\n\n---\n\n## BMAD → bigpowers Mapping\n\n### Artifact Locations\n\n```\nproject-root\u002F\n├── _bmad\u002Fbmm\u002Fconfig.yaml\n├── _bmad-output\u002F\n│   ├── product-brief.md\n│   ├── prfaq-{project}.md\n│   ├── prd.md\n│   ├── addendum.md\n│   ├── decision-log.md\n│   ├── ux-spec.md\n│   └── architecture.md\n├── project-context.md\n└── docs\u002F\n    ├── epic-{slug}.md\n    └── story-{slug}.md\n```\n\n### `product-brief.md` \u002F `prfaq-{project}.md` → `specs\u002Fproduct\u002FVISION_LATEST.yaml`\n\nTransform:\n- Vision + core value → `VISION_LATEST.yaml` north_star \u002F success_criteria\n- Target users → notes in VISION or SCOPE\n- prfaq customer FAQ → can inform success criteria in SCOPE\n\n### `prd.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `GLOSSARY_LATEST.yaml`\n\nBMAD `prd.md` has: Glossary, FR-XX functional requirements, UJ-XX user journeys, NFRs, assumptions.\n\nTransform:\n- Glossary → `GLOSSARY_LATEST.yaml`\n- FR-XX items → `in_scope` with IDs preserved\n- UJ-XX user journeys → success criteria\n- NFRs → `constraints` section\n- `[ASSUMPTION: ...]` inline tags → collected in scope YAML\n- Out-of-scope features → `out_of_scope`\n\n### `addendum.md` + `decision-log.md` → `specs\u002Fadr\u002F` + `specs\u002FDECISION-LOG_LATEST.md`\n\nTransform:\n- Hard, irreversible, surprising decisions → individual `specs\u002Fadr\u002FNNNN-{slug}.md`\n- Lightweight decisions → `specs\u002FDECISION-LOG_LATEST.md` (date | decision | rationale)\n- `addendum.md` change signals → note in `SCOPE_LATEST.yaml` metadata\n\n### `architecture.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F`\n\nTransform:\n- ADR sections → individual `specs\u002Fadr\u002FNNNN-{slug}.md` files\n- System overview \u002F data models → TECH_STACK Architecture section\n- API contracts → keep at `docs\u002Fapi.md` or similar; link from TECH_STACK\n\n### `epic-*.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml`\n\nEach epic → one release-plan entry + one epic shard. Acceptance criteria → story tasks with `verify:`.\n\n### `story-*.md` → `specs\u002Fepics\u002F` stories\n\nEach story → one story entry in epic shard. Acceptance criteria → `verify:` lines.\n\n### `project-context.md` → `CLAUDE.md`\n\nAdd a \"## Project Context\" section to `CLAUDE.md`. Copy tech stack, coding rules, preferences verbatim.\n\n---\n\n## Learnings to Adopt\n\nOptional enhancements to offer the user after migration. Present as checkboxes.\n\n### From GSD\n\n- [x] **`specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`** — Standing analytical lenses. Agents read before planning. (adopted: optional Step 8 template scaffold)\n- [x] **`handoff` block in state.yaml** — Last skill, last step, required reading for next session. (adopted: mandatory in Step 4 output)\n- [x] **ID tracking in SCOPE_LATEST.yaml** — FR\u002FUJ IDs for spec → plan → verification traceability. (adopted in Step 3 transform)\n\n### From spec-kit\n\n- [x] **Two-pass spec writing** — User-journey pass first, then technical-decisions pass. (adopted: optional post-migration gate)\n- [ ] **Explicit inter-phase gate** — \"Approve to proceed?\" at end of `elaborate-spec`.\n- [ ] **Epic task isolation** — Each task completable in isolation; `depends-on` explicit in epic YAML.\n\n### From BMAD\n\n- [x] **FR-XX + UJ-XX in SCOPE_LATEST.yaml** — Rigorous traceability. (adopted: REQUIREMENTS_TRACE.yaml emitted on migration)\n- [ ] **`specs\u002FDECISION-LOG_LATEST.md`** — Lightweight decisions below ADR threshold.\n- [x] **Adversarial review pass** — Critique epic shard before `develop-tdd`. (adopted: optional Step 6 in migration)\n\n---\n\n## Output Formats\n\n### ADR format (bigpowers)\n\nUse `model-domain\u002FADR-FORMAT.md`. Only create when all three apply: hard to reverse, surprising without context, result of a real trade-off.\n\n```markdown\n# ADR-NNNN: {Title}\n\n**Status:** Accepted\n**Date:** YYYY-MM-DD\n\n## Context\n[What situation forced this decision?]\n\n## Decision\n[What was decided?]\n\n## Consequences\n[What becomes easier or harder?]\n```\n\n### DECISION-LOG.md format\n\nFor lightweight decisions that don't warrant a full ADR:\n\n```markdown\n# Decision Log\n\n| Date | Decision | Rationale | Alternatives |\n|------|----------|-----------|--------------|\n| 2026-05-19 | Use Postgres | Existing ops expertise | SQLite (limited), DynamoDB (no local dev) |\n```\n\n### MIGRATION-AUDIT.md format\n\nPost-migration adversarial review report. Written to `specs\u002Farchive\u002FMIGRATION-AUDIT.md` when Step 6 runs:\n\n```markdown\n# Migration Audit — \u003Cproject-name>\n\n**Source Framework:** \u003CGSD|spec-kit|BMAD>  \n**Date:** \u003CISO 8601>  \n**Status:** \u003CPass|Findings|Critical>\n\n## Summary\n\n- TODO markers: N\n- FIXME markers: N\n- MISSING markers: N\n- Epics without verify: N\n\n## High Priority Findings\n\n- **Artifact:** specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  **Issue:** Story e02s01 has no verify: commands in tasks\n  **Recommendation:** Add runnable verify command before develop-tdd\n\n- **Artifact:** specs\u002Fstate.yaml\n  **Issue:** open_decisions list empty without comment explanation\n  **Recommendation:** Add # comment if all decisions were resolved during migration\n\n## Information\n\n- Artifact specs\u002Fepics\u002Fe01-auth\u002Fepic.yaml contains TODO: \"Define Neon Auth client URL injection\" (normal for fresh migration)\n\n## Next Steps\n\n1. Address high-priority findings before plan-work\n2. Run bash scripts\u002Faudit-compliance.sh to enforce code quality gates\n3. Begin develop-tdd on highest-WSJF epic\n```\n\n### in_scope format with ID tracking\n\nSource IDs (REQ-XX, FR-XX, UJ-XX) are emitted as first-class YAML fields:\n\n```yaml\nin_scope:\n  - id: REQ-001\n    description: \"User can register with email and password\"\n    source: \"REQUIREMENTS.md\"\n  - id: FR-015\n    description: \"Auth service must support OAuth2 token flow\"\n    source: \"prd.md\"\n  - id: REQ-AUTO-002  # auto-generated when source had no ID\n    description: \"Dashboard displays user profile\"\n    # auto-generated: true  (optional comment for tracking)\n```\n\n**When source has no IDs:** If the user opts in, auto-generated IDs follow the `REQ-{NNN}` format with an optional `# auto-generated` comment.\n\n**When source has mixed IDs:** Entries with source IDs get `id:` fields; entries without IDs receive auto-generated IDs. A comment block at the top of `in_scope` documents which IDs were auto-generated.\n\n### REQUIREMENTS_TRACE.yaml format\n\nEmitted when source has FR-XX (functional requirement) or UJ-XX (user journey) IDs. Maps source requirements to bigpowers epic\u002Fstory structure and verification commands:\n\n```yaml\ntrace:\n  # Functional Requirements\n  - id: FR-001\n    type: functional_requirement\n    description: \"User can register with email\u002Fpassword\"\n    source_artifact: \"prd.md\"\n    epic: \"e02-auth-ui\"\n    story: \"e02s01\"\n    verify: \"grep -q 'FR-001' specs\u002Fproduct\u002FSCOPE_LATEST.yaml && echo OK\"\n\n  # User Journeys\n  - id: UJ-001\n    type: user_journey\n    description: \"New user completes registration flow\"\n    source_artifact: \"epic-auth-ui.md\"\n    epic: \"e02-auth-ui\"\n    story: \"e02s01\"\n    verify: \"grep -q 'UJ-001' specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml && echo OK\"\n\nmetadata:\n  source_framework: \"BMAD\"\n  migrated_at: \"2026-06-26T12:00:00Z\"\n  total_requirements: 2\n  coverage: \"All FR-XX and UJ-XX IDs from source mapped\"\n```\n\n**When source has no FR-XX\u002FUJ-XX:** Skip REQUIREMENTS_TRACE.yaml. Add note to `state.yaml` handoff: \"No FR-XX\u002FUJ-XX IDs found — traceability file skipped\".\n\n**Existing trace file:** If REQUIREMENTS_TRACE.yaml exists, prompt user: \"Overwrite? [yes \u002F merge \u002F skip]\". Merge appends new entries; skip leaves existing file intact.\n\n### `specs\u002Fstate.yaml` template format\n\nGenerated during Step 4 of migration. Regenerate from scratch in bigpowers YAML format. The **handoff block is mandatory**:\n\n```yaml\nactive_flow: null\nactive_epic_id: null\nactive_story_id: null\ncompleted_epic: false\n\nepic_cycle:\n  current_step: null\n  next_skill: null\n  story_bcps: null\n  completed_steps: []\n  audit_result: null\n\nbug_cycle:\n  current_step: null\n  completed_steps: []\n\nrelease:\n  target_version: null\n  last_tag: null\n  last_publish: null\n  ci_verified: false\n\nmetrics:\n  story_start: null\n  story_end: null\n  cycle_minutes: null\n  bcp_per_hour: null\n\ngit:\n  branch: \u003Ccurrent branch>\n  hash: \u003Cgit rev-parse HEAD>\n  pushed: false\n\nhandoff:\n  last_step_completed: \"Migrated from \u003Cframework> on \u003Cdate>\"\n  open_decisions: []  # Empty if all decisions resolved during migration\n  required_reading:\n    - specs\u002Fproduct\u002FVISION_LATEST.yaml\n    - specs\u002Fproduct\u002FSCOPE_LATEST.yaml\n    - specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md\n    - specs\u002Frelease-plan.yaml\n  next_skill: survey-context\n\ntwo_pass_spec:  # Optional: only if user activates two-pass spec writing gate\n  journey_pass: pending\n  technical_pass: pending\n  approved_at: null\n```\n\n---\n\n## Reference block 1\n\n```\nDetected: GSD\nFound:\n  ✓ .planning\u002FROADMAP.md\n  ✓ .planning\u002FREQUIREMENTS.md  (12 REQ-XX items)\n  ✓ .planning\u002Fstate.yaml\n  ✓ .planning\u002Fphases\u002F01-auth\u002F01-CONTEXT.md\n  ✗ .planning\u002FMETHODOLOGY.md  (not present)\n\nSkipping:\n  .planning\u002Fphases\u002F01-auth\u002F01-01-SUMMARY.md  (execution record; archived only)\n\nProceed with migration? [yes \u002F skip \u003Cartifact> \u002F abort]\n```\n\n---\n\n## Reference block 2\n\n```yaml\n# CORRECT — first-class id: field\nin_scope:\n  - id: REQ-001\n    description: \"User can register with email\u002Fpassword\"\n    source: \"REQUIREMENTS.md\"\n\n# DEPRECATED — comment-only\nin_scope:\n  - \"User can register with email\u002Fpassword\"  # REQ-001\n```\n\n---\n\n## Reference block 3\n\n```yaml\ntrace:\n  - id: FR-001\n    type: functional_requirement\n    description: \"User can register with email\u002Fpassword\"\n    epic: e02-auth-ui\n    story: e02s01\n    verify: \"grep -q 'FR-001' specs\u002Fproduct\u002FSCOPE_LATEST.yaml && echo OK\"\n  - id: UJ-001\n    type: user_journey\n    description: \"New user completes registration flow\"\n    epic: e02-auth-ui\n    story: e02s01\n```\n\n---\n\n## Reference block 4\n\n```yaml\nactive_flow: null\nactive_epic_id: null\nactive_story_id: null\n\n# ... other state fields ...\n\nhandoff:\n  last_step_completed: \"Migrated from \u003Cframework> on \u003Cdate>\"\n  open_decisions:\n    - \"decision text here\"\n  required_reading:\n    - specs\u002Fproduct\u002FVISION_LATEST.yaml\n    - specs\u002Fproduct\u002FSCOPE_LATEST.yaml\n    - specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md\n    - specs\u002Frelease-plan.yaml\n  next_skill: survey-context\n```\n\n---\n\n## Reference block 5\n\n```markdown\n# Migration Audit — \u003Cproject-name> from \u003Cframework>\n\n**Date:** \u003CISO 8601 timestamp>\n**Status:** Pass \u002F Fail with findings\n\n## Findings\n\n### High Priority\n- Artifact: specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  Finding: No verify: commands in story tasks\n  Recommendation: Add `verify:` to each task before develop-tdd\n\n### Information\n- Count of TODO markers: 3 (normal for fresh migration)\n```\n\n---\n\n## Reference block 6\n\n```\nWhich lenses to include in specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md?\n\n[x] Cost of Delay (CD3)           — Priority & trade-off assessment\n[ ] STRIDE                        — Security threat modeling\n[ ] F.I.R.S.T                     — Test quality principles\n[ ] Bayesian Updating            — Probabilistic decision-making\n[ ] OWASP Top 10                 — Web security framework\n```\n\n---\n\n### Step 7 — Post-migration: Optional two-pass spec writing gate\n\nAfter Steps 1–6, offer the user an optional two-pass spec writing workflow (spec-kit learning):\n\nPrompt: \"Use two-pass spec writing (user journeys first, then technical)? [yes \u002F no]\"\n\nIf **yes**, initialize the gate in `specs\u002Fstate.yaml`:\n\n```yaml\ntwo_pass_spec:\n  journey_pass: pending\n  technical_pass: pending\n  approved_at: null\n```\n\nThe journey pass must be marked \"complete\" by the user (after stakeholder approval of user-journey specs) before the technical pass begins:\n\n```yaml\ntwo_pass_spec:\n  journey_pass: complete\n  approved_at: \"2026-06-26T12:00:00Z\"\n  technical_pass: pending\n```\n\nInform the user: \"Journey pass is pending. Run `elaborate-spec` for user journeys, get stakeholder approval, then update `two_pass_spec.journey_pass: complete` in state.yaml before proceeding to technical specs.\"\n\nIf **no**, skip the two-pass gate. Proceed directly to plan-work.\n\n→ verify: `grep -q 'two_pass_spec:' specs\u002Fstate.yaml && echo \"two-pass gate initialized\" || echo \"two-pass gate not activated\"`\n\n\n---\n\n### Step 8 — Post-migration: Optional methodology doc template\n\nAfter Steps 1–7, offer the user an optional analytical framework scaffold (GSD learning):\n\nPrompt: \"Create a methodology doc? [yes \u002F no]\"\n\nIf **yes**, present a checklist of analytical lenses:\n\n```\nWhich lenses to include in specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md?\n\n[x] Cost of Delay (CD3)           — Priority & trade-off assessment\n[ ] STRIDE                        — Security threat modeling\n[ ] F.I.R.S.T                     — Test quality principles\n[ ] Bayesian Updating            — Probabilistic decision-making\n[ ] OWASP Top 10                 — Web security framework\n```\n\nCopy the template from `migrate-spec\u002Ftemplates\u002FMETHODOLOGY_LATEST.md` to `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`.\n- Active lenses remain uncommented\n- Unselected lenses are left commented out\n- Populate `{{project_name}}` with the migrated project's name\n\nIf **no**, skip. Add note to handoff: \"Methodology doc: skipped — can be added later via `cp migrate-spec\u002Ftemplates\u002FMETHODOLOGY_LATEST.md specs\u002Ftech-architecture\u002F`\"\n\n→ verify: `test -f specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md && echo \"methodology doc created\" || echo \"methodology doc skipped\"`\n\n---\n\n\n---\n\n## Artifact Mapping Summary\n\nFull mapping tables: [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md) (GSD) · [REFERENCE.md](.\u002FREFERENCE.md) (spec-kit, BMAD, learnings).\n\n| Source | Target |\n|--------|--------|\n| GSD `ROADMAP.md` | `specs\u002Frelease-plan.yaml + epic shards` |\n| GSD `REQUIREMENTS.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` |\n| GSD `CONTEXT.md` (phases) | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Fadr\u002F` |\n| GSD `PLAN.md` | `specs\u002Fepics\u002FeNN-slug\u002Fepic.yaml` (tasks with verify in `-tasks.yaml`) |\n| GSD `METHODOLOGY.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` |\n| spec-kit `spec.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002Ftech-stack.md` |\n| spec-kit `plan.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F` |\n| spec-kit `tasks.md` | `specs\u002Fepics\u002F (see slice-tasks)` |\n| BMAD `prd.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` |\n| BMAD `architecture.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Fadr\u002F` |\n| BMAD `epic-*.md` | `specs\u002Frelease-plan.yaml + epic shards` |\n| BMAD `story-*.md` | `specs\u002Fepics\u002F (see slice-tasks)` |\n| BMAD `project-context.md` | `CLAUDE.md` (append project-specific section) |\n| BMAD `decision-log.md` | `specs\u002Fadr\u002F` (one ADR per logged decision) |\n\n---\n\n\n---\n\n## Rules\n\n- **Preserve source IDs** — REQ-XX, FR-XX, UJ-XX are emitted as first-class `id:` fields in bigpowers YAML targets (e.g., `in_scope` entries). Never silently renumber. See Step 3 ID Tracking subsection for details.\n- **Never merge contradictory docs** — if source has both `CONTEXT.md` and `architecture.md`, create sections in bigpowers `CONTEXT.md`; don't collapse them.\n- **ADRs are opt-in** — only create an ADR when: hard to reverse, surprising without context, result of a real trade-off. Lightweight decisions go to `specs\u002FDECISION-LOG_LATEST.md`.\n- **state.yaml is always regenerated** — never migrate source STATE verbatim; bigpowers state.yaml needs its own format.\n- **specs\u002F is the only output location** — no files are created outside `specs\u002F` and `CLAUDE.md`.\n\n---\n\n### Step 5 — Surface learnings (optional)\n\nAfter migration, offer the user a brief analysis of what the source framework did that bigpowers doesn't have yet.\n\nUse the learnings table from [REFERENCE.md](.\u002FREFERENCE.md#learnings-to-adopt). Present as checkboxes so the user can decide which to adopt.\n\n→ verify: `grep -c \"\\- \\[ \\]\" specs\u002Fstate.yaml 2>\u002Fdev\u002Fnull && echo \"pending items recorded\" || echo \"no pending items in state.yaml\"`\n\n\n---\n\n### Step 6 — Adversarial review (optional)\n\nBefore the user runs `plan-work`, offer an optional lightweight audit of the migrated artifacts. This catches common migration errors early — incomplete specs, missing verification commands, unresolved decisions.\n\nPrompt: \"Run adversarial review of migrated artifacts? [yes \u002F skip]\"\n\nIf yes, perform these checks:\n\n1. **Scan for incomplete markers** — Find TODO, FIXME, MISSING in specs\u002F\n2. **Verify every epic has `verify:` commands** — Parse all `eNN-*\u002Fepic.yaml` files\n3. **Check state.yaml handoff** — Ensure `open_decisions` is documented (even if empty)\n\nCollect findings and write to `specs\u002Farchive\u002FMIGRATION-AUDIT.md`:\n\n```markdown\n# Migration Audit — \u003Cproject-name> from \u003Cframework>\n\n**Date:** \u003CISO 8601 timestamp>\n**Status:** Pass \u002F Fail with findings\n\n\n---\n\n## Findings\n\n### High Priority\n- Artifact: specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  Finding: No verify: commands in story tasks\n  Recommendation: Add `verify:` to each task before develop-tdd\n\n### Information\n- Count of TODO markers: 3 (normal for fresh migration)\n```\n\nIf findings exist, the handoff block should note: \"Adversarial review: N findings — see `specs\u002Farchive\u002FMIGRATION-AUDIT.md`\"\n\nIf skip is chosen, add to handoff: \"Adversarial review: skipped — review manually before plan-work\"\n\n→ verify: `test -f specs\u002Farchive\u002FMIGRATION-AUDIT.md && echo \"audit completed\" || echo \"audit skipped or not performed\"`\n","\u003C!-- story: e25s01 -->\n\u003C!-- story: e25s02 -->\n\u003C!-- story: e25s03 -->\n\u003C!-- story: e25s04 -->\n\u003C!-- story: e25s05 -->\n\u003C!-- story: e25s06 -->\n\n# Migrate Spec\n\nTransform existing GSD, spec-kit, or BMAD planning artifacts into the bigpowers `specs\u002F` model. No code is written — the output is a set of bigpowers-format spec files the user can use immediately.\n\n## Quick start\n\n1. Run this skill from the root of the project being migrated (not the bigpowers repo itself).\n2. The skill auto-detects the source framework and presents its findings before transforming anything.\n3. All output goes to `specs\u002F` at the project root.\n\n---\n\n## Red flags — stop and ask\n\nBefore proceeding, check for these rationalization traps:\n\n- **Partial artifact set** — only one fingerprint file found (e.g. just `spec.md` with no `plan.md`). Don't assume it's a complete project. Ask: \"I found only X — is this the full set of your spec artifacts?\"\n- **Wrong trigger** — user said \"migrate my code\" or \"migrate the database\", not \"migrate my specs\". Confirm before running.\n- **Stale source** — source artifacts have commit dates older than 6 months with no recent activity. Flag: \"These specs appear inactive since \u003Cdate>. Are they still the source of truth?\"\n- **Active divergence** — source `state.yaml` or `sprint-status.yaml` shows in-progress work. Flag: \"There is active work in flight. Migrating now may lose in-progress context. Proceed?\"\n\nIf any red flag fires: surface it, wait for explicit user confirmation before continuing.\n\n---\n\n## Process\n\n### Step 1 — Detect the source framework\n\nScan for the fingerprints below. Stop at first match; if multiple match, list them and ask the user which is primary.\n\n| Framework | Fingerprints (any one is sufficient) |\n|-----------|--------------------------------------|\n| **GSD** | `.planning\u002F` directory; `.planning\u002FROADMAP.md`; `.planning\u002FREQUIREMENTS.md` with `REQ-` IDs |\n| **spec-kit** | `.specify\u002F` directory; `spec.md` + `plan.md` at root; `.github\u002Fskills\u002Fspeckit-*\u002FSKILL.md` |\n| **BMAD** | `_bmad\u002F` directory; `_bmad-output\u002F` directory; `prd.md` with `FR-` IDs; `epic-*.md` or `story-*.md` |\n\nIf none found: ask the user which framework before proceeding.\n\n→ verify: `test -d specs && test -f specs\u002Fstate.yaml`\n\n### Step 2 — Inventory the source artifacts\n\nList every artifact found matching the detected framework. Present the list to the user:\n\nSee [REFERENCE.md](REFERENCE.md) — `Detected: GSD...`\n\n→ verify: `test -d specs && test -w specs`\n\n### Step 3 — Transform (one artifact at a time, show diffs)\n\nApply the mapping from [REFERENCE.md](.\u002FREFERENCE.md) and [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md). For each target file:\n\n1. Show what will be created or appended (title + first 20 lines).\n2. Ask: \"Create this? [yes \u002F edit \u002F skip]\"\n3. On yes: write to `specs\u002F`.\n\n#### ID Tracking (REQ-XX, FR-XX, UJ-XX)\n\nWhen source artifacts contain IDs (REQ-XX, FR-XX, UJ-XX), emit them as **first-class YAML fields** in `in_scope` entries, not YAML comments:\n\nSee [REFERENCE.md](REFERENCE.md) — `# CORRECT — first-class id: field...`\n\n**When source has no IDs:** Prompt the user: \"No IDs found. Assign auto-generated IDs? [yes \u002F no]\". If yes, emit `REQ-{NNN}` with `# auto-generated` annotation.\n\n**When source has MIXED IDs:** Items with IDs get `id:` fields; items without IDs receive auto-generated `REQ-NNN` entries. Document which were auto-generated in a comment block at the top of `in_scope`.\n\nSee [REFERENCE.md — in_scope format with ID tracking](.\u002FREFERENCE.md#in_scope-format-with-id-tracking) for examples.\n\n#### Traceability Output (FR-XX, UJ-XX)\n\nWhen source has FR-XX or UJ-XX IDs, emit `specs\u002Fproduct\u002FREQUIREMENTS_TRACE.yaml` for end-to-end requirement traceability:\n\nSee [REFERENCE.md](REFERENCE.md) — `trace:...`\n\n**Existing trace file:** If `REQUIREMENTS_TRACE.yaml` already exists, prompt: \"REQUIREMENTS_TRACE.yaml exists. [overwrite \u002F merge \u002F skip]\"\n\n**No FR-XX\u002FUJ-XX found:** Skip trace file; add note to state.yaml handoff: \"No FR-XX\u002FUJ-XX IDs found — traceability file skipped\".\n\nSee [REFERENCE.md — REQUIREMENTS_TRACE.yaml format](.\u002FREFERENCE.md#requirements_traceyaml-format) for the complete schema.\n\n> **HARD GATE** — Never overwrite an existing `specs\u002F` file without explicit user confirmation. Merge into it if it exists; don't clobber.\n>\n> → verify: `git rev-parse --git-dir >\u002Fdev\u002Fnull 2>&1 && test -d specs`\n\n→ verify: `test -d specs && [ \"$(ls specs\u002F*.md specs\u002F*.yaml 2>\u002Fdev\u002Fnull | wc -l | tr -d \" \")\" -gt 0 ]`\n\n### Step 4 — Generate state.yaml\n\nAlways regenerate `specs\u002Fstate.yaml` from scratch in bigpowers YAML format (see REFERENCE.md for template). The **handoff block is mandatory** and must include all four fields:\n\nSee [REFERENCE.md](REFERENCE.md) — `active_flow: null...`\n\nIf no open decisions were found during migration, the `open_decisions` list may be empty with an explanatory comment:\n\nSee [REFERENCE.md](REFERENCE.md) — `handoff:...`\n\n→ verify: `grep -q handoff: specs\u002Fstate.yaml`\n\n---\n\n# migrate-spec Reference — GSD\n\nFull artifact transformation rules for migrating GSD projects to bigpowers YAML layout.\n\nSee [REFERENCE.md](.\u002FREFERENCE.md) for spec-kit, BMAD, learnings, and ADR\u002FDECISION-LOG formats.\n\n---\n\n## Artifact Locations\n\nGSD stores everything under `.planning\u002F` at the project root.\n\n```\n.planning\u002F\n├── ROADMAP.md\n├── STATE.md\n├── REQUIREMENTS.md\n├── METHODOLOGY.md\n├── HANDOFF.json\n├── .continue-here.md\n└── phases\u002F\n    └── XX-name\u002F\n        ├── XX-CONTEXT.md\n        ├── XX-YY-PLAN.md\n        ├── XX-YY-SUMMARY.md\n        └── XX-DISCUSSION-LOG.md\n    spikes\u002F\n        └── SPIKE-NNN\u002FREADME.md\n```\n\n---\n\n## Transformation Rules\n\n### `.planning\u002FROADMAP.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml`\n\nGSD ROADMAP has: milestone name, phases, success criteria per phase, plan count.\n\nTransform:\n- Each GSD phase → one epic entry in `release-plan.yaml` (`id`, `title`, `wsjf`, `file`)\n- Phase detail → matching `specs\u002Fepics\u002FeNN-slug.yaml` (stories, tasks, `verify`)\n- Completed phases → `done` in `execution-status.yaml`; active → `in_progress`\n\n---\n\n### `.planning\u002FREQUIREMENTS.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml`\n\nGSD REQUIREMENTS has: REQ-XX IDs, Validated\u002FActive\u002FOut-of-Scope categories, traceability.\n\nTransform:\n- Preserve REQ-XX IDs as **first-class `id:` fields** in `in_scope` entries (see [REFERENCE.md — ID tracking format](.\u002FREFERENCE.md#in_scope-format-with-id-tracking))\n- Validated requirements → `in_scope` entries with `id:`, `description:`, `source:` fields\n- Out-of-Scope → `out_of_scope` entries (preserve IDs if present)\n- Active (in-progress) → `in_scope` with status note\n\n---\n\n### `.planning\u002Fphases\u002FXX-name\u002FXX-CONTEXT.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F`\n\nGSD CONTEXT.md has 6 sections: domain, decisions, canonical_refs, code_context, specifics, deferred.\n\nTransform:\n- `domain` → `plans\u002FTECH_STACK_LATEST.md` Domain section\n- `decisions` → scan each: if hard-to-reverse + surprising → `specs\u002Fadr\u002FNNNN-{slug}.md`; if lightweight → `specs\u002FDECISION-LOG_LATEST.md`\n- `canonical_refs` → Reference links in TECH_STACK\n- `code_context` → Architecture section\n- `deferred` → `SCOPE_LATEST.yaml` `out_of_scope` (with \"(deferred from GSD)\" note)\n\n---\n\n### `.planning\u002Fphases\u002FXX-name\u002FXX-YY-PLAN.md` → `specs\u002Fepics\u002FeNN-*.yaml` tasks\n\nGSD PLAN has: frontmatter (depends-on, verify), objective, typed tasks, success criteria, output spec.\n\nTransform:\n- Preserve task structure as `tasks[]` in epic shard\n- Keep `verify: \u003Ccommand>` lines\n- Map GSD `depends-on` to task `depends-on` notes\n- SUMMARY.md (execution record) → skip or append to `specs\u002Farchive\u002F`\n\n---\n\n### `.planning\u002FMETHODOLOGY.md` → `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`\n\nGSD METHODOLOGY.md is a standing reference for analytical lenses (Bayesian updating, STRIDE, cost-of-delay).\n\nTransform:\n- Copy each lens as a section in `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`\n- Note: \"These lenses should inform `plan-work` and `audit-code` sessions.\"\n\n---\n\n### `.planning\u002FHANDOFF.json` + `.continue-here.md` → `specs\u002Fstate.yaml` `handoff`\n\nGSD HANDOFF has: current phase, last plan, blocking reason, required reading list.\n\nTransform — populate `handoff` in `state.yaml`:\n\n```yaml\nhandoff:\n  last_step_completed: \"\u003Cphase\u002Fplan from HANDOFF>\"\n  open_decisions:\n    - \"\u003Cblocking reason if any>\"\n  required_reading:\n    - \"\u003Crequired_reading list>\"\n  next_skill: survey-context\n```\n\n---\n\n### `.planning\u002Fspikes\u002FSPIKE-NNN\u002FREADME.md` → `specs\u002Farchive\u002Fspikes\u002FSPIKE-{name}.md`\n\nGSD spike README has: YAML frontmatter (verdict, validates, related), methodology, findings, recommendation.\n\nTransform:\n- Flatten directory into `specs\u002Farchive\u002Fspikes\u002FSPIKE-{name}.md`\n- Preserve frontmatter as YAML block at top\n- Keep verdict prominently: `**Verdict:** ADOPTED \u002F REJECTED \u002F DEFERRED`\n\n---\n\n## Skip List\n\nThese GSD artifacts are not migrated — they are execution records, not planning inputs:\n\n| Artifact | Reason |\n|----------|--------|\n| `.planning\u002Fphases\u002FXX\u002FXX-YY-SUMMARY.md` | Execution log; no bigpowers equivalent |\n| `.planning\u002Fphases\u002FXX\u002FXX-DISCUSSION-LOG.md` | Audit trail only; not consumed by agents |\n| `.planning\u002FUSER-PROFILE.md` | User calibration; bigpowers has no profile system |\n| `.planning\u002Fsketches\u002F` | Visual exploration; not spec artifacts |\n\n---\n\n# Migrate Spec — Reference\n\n## Navigation\n\n| Lines | Section |\n|-------|---------|\n| 1 | Title |\n| 3–68 | Navigation |\n| 69–70 | spec-kit → bigpowers Mapping |\n| 71–84 | Artifact Locations |\n| 85–94 | `spec.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` |\n| 95–105 | `plan.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F` |\n| 106–114 | `tasks.md` → `specs\u002Fepics\u002F` (via slice-tasks) |\n| 115–120 | `.specify\u002F` state |\n| 121–122 | BMAD → bigpowers Mapping |\n| 123–141 | Artifact Locations |\n| 142–148 | `product-brief.md` \u002F `prfaq-{project}.md` → `specs\u002Fproduct\u002FVISION_LATEST.yaml` |\n| 149–160 | `prd.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `GLOSSARY_LATEST.yaml` |\n| 161–167 | `addendum.md` + `decision-log.md` → `specs\u002Fadr\u002F` + `specs\u002FDECISION-LOG_LATEST.md` |\n| 168–174 | `architecture.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F` |\n| 175–178 | `epic-*.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml` |\n| 179–182 | `story-*.md` → `specs\u002Fepics\u002F` stories |\n| 183–188 | `project-context.md` → `CLAUDE.md` |\n| 189–192 | Learnings to Adopt |\n| 193–198 | From GSD |\n| 199–204 | From spec-kit |\n| 205–212 | From BMAD |\n| 213–214 | Output Formats |\n| 215–224 | ADR format (bigpowers) |\n| 225–227 | Context |\n| 228–230 | Decision |\n| 231–234 | Consequences |\n| 235–246 | DECISION-LOG.md format |\n| 247–257 | MIGRATION-AUDIT.md format |\n| 258–264 | Summary |\n| 265–274 | High Priority Findings |\n| 275–278 | Information |\n| 279–285 | Next Steps |\n| 286–306 | in_scope format with ID tracking |\n| 307–341 | REQUIREMENTS_TRACE.yaml format |\n| 342–397 | `specs\u002Fstate.yaml` template format |\n| 398–416 | Reference block 1 |\n| 417–432 | Reference block 2 |\n| 433–451 | Reference block 3 |\n| 452–474 | Reference block 4 |\n| 475–482 | Reference block 5 |\n| 483–484 | Findings |\n| 485–489 | High Priority |\n| 490–495 | Information |\n| 496–509 | Reference block 6 |\n| 510–542 | Step 7 — Post-migration: Optional two-pass spec writing gate |\n| 543–574 | Step 8 — Post-migration: Optional methodology doc template |\n| 575–600 | Artifact Mapping Summary |\n| 601–610 | Rules |\n| 611–621 | Step 5 — Surface learnings (optional) |\n| 622–644 | Step 6 — Adversarial review (optional) |\n| 645–646 | Findings |\n| 647–651 | High Priority |\n| 652–660 | Information |\n\n# migrate-spec Reference — spec-kit, BMAD, Learnings\n\nTransformation rules for spec-kit and BMAD projects, plus learnings to adopt and output formats.\n\nSee [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md) for full GSD → bigpowers YAML mapping.\n\n---\n\n## spec-kit → bigpowers Mapping\n\n### Artifact Locations\n\n```\nproject-root\u002F\n├── spec.md         ← user journeys, success criteria, scope\n├── plan.md         ← technology, architecture, constraints\n├── tasks.md        ← atomic task list\n└── .specify\u002F\n    ├── workflow-catalogs.yml\n    └── workflows\u002Fruns\u002F\u003Cid>\u002F\n        ├── state.json\n        └── log.jsonl\n```\n\n### `spec.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md`\n\nspec-kit `spec.md` focuses on: who uses it, user journeys, success criteria, what's in\u002Fout of scope.\n\nTransform:\n- User journeys → `SCOPE_LATEST.yaml` success criteria \u002F `in_scope` entries\n- In\u002Fout of scope → `in_scope` \u002F `out_of_scope` sections\n- Domain terms \u002F glossary → `requirements\u002FGLOSSARY_LATEST.yaml`\n- Problem statement \u002F vision → `requirements\u002FVISION_LATEST.yaml`\n\n### `plan.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F`\n\nspec-kit `plan.md` covers: technology stack, architectural patterns, implementation constraints.\n\nTransform:\n- Technology decisions → `plans\u002FTECH_STACK_LATEST.md` Technology section\n- Architecture patterns → Architecture section\n- Hard decisions with trade-offs → `specs\u002Fadr\u002FNNNN-{slug}.md`\n- Phased approach \u002F milestones → `release-plan.yaml` epic entries\n- Implementation steps → `epics\u002FeNN-*.yaml` task list with `verify:`\n\n### `tasks.md` → `specs\u002Fepics\u002F` (via slice-tasks)\n\nspec-kit tasks are atomic, verifiable in isolation — same principle as bigpowers `verify:` mandate.\n\nTransform:\n- Copy tasks into epic shard `tasks[]`; preserve task numbers\n- Add `verify:` line if spec-kit task has an acceptance criterion\n- Group into epics matching `release-plan.yaml` entries\n\n### `.specify\u002F` state\n\nDiscard — workflow engine state; not meaningful in the bigpowers skill model.\n\n---\n\n## BMAD → bigpowers Mapping\n\n### Artifact Locations\n\n```\nproject-root\u002F\n├── _bmad\u002Fbmm\u002Fconfig.yaml\n├── _bmad-output\u002F\n│   ├── product-brief.md\n│   ├── prfaq-{project}.md\n│   ├── prd.md\n│   ├── addendum.md\n│   ├── decision-log.md\n│   ├── ux-spec.md\n│   └── architecture.md\n├── project-context.md\n└── docs\u002F\n    ├── epic-{slug}.md\n    └── story-{slug}.md\n```\n\n### `product-brief.md` \u002F `prfaq-{project}.md` → `specs\u002Fproduct\u002FVISION_LATEST.yaml`\n\nTransform:\n- Vision + core value → `VISION_LATEST.yaml` north_star \u002F success_criteria\n- Target users → notes in VISION or SCOPE\n- prfaq customer FAQ → can inform success criteria in SCOPE\n\n### `prd.md` → `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `GLOSSARY_LATEST.yaml`\n\nBMAD `prd.md` has: Glossary, FR-XX functional requirements, UJ-XX user journeys, NFRs, assumptions.\n\nTransform:\n- Glossary → `GLOSSARY_LATEST.yaml`\n- FR-XX items → `in_scope` with IDs preserved\n- UJ-XX user journeys → success criteria\n- NFRs → `constraints` section\n- `[ASSUMPTION: ...]` inline tags → collected in scope YAML\n- Out-of-scope features → `out_of_scope`\n\n### `addendum.md` + `decision-log.md` → `specs\u002Fadr\u002F` + `specs\u002FDECISION-LOG_LATEST.md`\n\nTransform:\n- Hard, irreversible, surprising decisions → individual `specs\u002Fadr\u002FNNNN-{slug}.md`\n- Lightweight decisions → `specs\u002FDECISION-LOG_LATEST.md` (date | decision | rationale)\n- `addendum.md` change signals → note in `SCOPE_LATEST.yaml` metadata\n\n### `architecture.md` → `specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md` + `specs\u002Fadr\u002F`\n\nTransform:\n- ADR sections → individual `specs\u002Fadr\u002FNNNN-{slug}.md` files\n- System overview \u002F data models → TECH_STACK Architecture section\n- API contracts → keep at `docs\u002Fapi.md` or similar; link from TECH_STACK\n\n### `epic-*.md` → `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002FeNN-*.yaml`\n\nEach epic → one release-plan entry + one epic shard. Acceptance criteria → story tasks with `verify:`.\n\n### `story-*.md` → `specs\u002Fepics\u002F` stories\n\nEach story → one story entry in epic shard. Acceptance criteria → `verify:` lines.\n\n### `project-context.md` → `CLAUDE.md`\n\nAdd a \"## Project Context\" section to `CLAUDE.md`. Copy tech stack, coding rules, preferences verbatim.\n\n---\n\n## Learnings to Adopt\n\nOptional enhancements to offer the user after migration. Present as checkboxes.\n\n### From GSD\n\n- [x] **`specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`** — Standing analytical lenses. Agents read before planning. (adopted: optional Step 8 template scaffold)\n- [x] **`handoff` block in state.yaml** — Last skill, last step, required reading for next session. (adopted: mandatory in Step 4 output)\n- [x] **ID tracking in SCOPE_LATEST.yaml** — FR\u002FUJ IDs for spec → plan → verification traceability. (adopted in Step 3 transform)\n\n### From spec-kit\n\n- [x] **Two-pass spec writing** — User-journey pass first, then technical-decisions pass. (adopted: optional post-migration gate)\n- [ ] **Explicit inter-phase gate** — \"Approve to proceed?\" at end of `elaborate-spec`.\n- [ ] **Epic task isolation** — Each task completable in isolation; `depends-on` explicit in epic YAML.\n\n### From BMAD\n\n- [x] **FR-XX + UJ-XX in SCOPE_LATEST.yaml** — Rigorous traceability. (adopted: REQUIREMENTS_TRACE.yaml emitted on migration)\n- [ ] **`specs\u002FDECISION-LOG_LATEST.md`** — Lightweight decisions below ADR threshold.\n- [x] **Adversarial review pass** — Critique epic shard before `develop-tdd`. (adopted: optional Step 6 in migration)\n\n---\n\n## Output Formats\n\n### ADR format (bigpowers)\n\nUse `model-domain\u002FADR-FORMAT.md`. Only create when all three apply: hard to reverse, surprising without context, result of a real trade-off.\n\n```markdown\n# ADR-NNNN: {Title}\n\n**Status:** Accepted\n**Date:** YYYY-MM-DD\n\n## Context\n[What situation forced this decision?]\n\n## Decision\n[What was decided?]\n\n## Consequences\n[What becomes easier or harder?]\n```\n\n### DECISION-LOG.md format\n\nFor lightweight decisions that don't warrant a full ADR:\n\n```markdown\n# Decision Log\n\n| Date | Decision | Rationale | Alternatives |\n|------|----------|-----------|--------------|\n| 2026-05-19 | Use Postgres | Existing ops expertise | SQLite (limited), DynamoDB (no local dev) |\n```\n\n### MIGRATION-AUDIT.md format\n\nPost-migration adversarial review report. Written to `specs\u002Farchive\u002FMIGRATION-AUDIT.md` when Step 6 runs:\n\n```markdown\n# Migration Audit — \u003Cproject-name>\n\n**Source Framework:** \u003CGSD|spec-kit|BMAD>  \n**Date:** \u003CISO 8601>  \n**Status:** \u003CPass|Findings|Critical>\n\n## Summary\n\n- TODO markers: N\n- FIXME markers: N\n- MISSING markers: N\n- Epics without verify: N\n\n## High Priority Findings\n\n- **Artifact:** specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  **Issue:** Story e02s01 has no verify: commands in tasks\n  **Recommendation:** Add runnable verify command before develop-tdd\n\n- **Artifact:** specs\u002Fstate.yaml\n  **Issue:** open_decisions list empty without comment explanation\n  **Recommendation:** Add # comment if all decisions were resolved during migration\n\n## Information\n\n- Artifact specs\u002Fepics\u002Fe01-auth\u002Fepic.yaml contains TODO: \"Define Neon Auth client URL injection\" (normal for fresh migration)\n\n## Next Steps\n\n1. Address high-priority findings before plan-work\n2. Run bash scripts\u002Faudit-compliance.sh to enforce code quality gates\n3. Begin develop-tdd on highest-WSJF epic\n```\n\n### in_scope format with ID tracking\n\nSource IDs (REQ-XX, FR-XX, UJ-XX) are emitted as first-class YAML fields:\n\n```yaml\nin_scope:\n  - id: REQ-001\n    description: \"User can register with email and password\"\n    source: \"REQUIREMENTS.md\"\n  - id: FR-015\n    description: \"Auth service must support OAuth2 token flow\"\n    source: \"prd.md\"\n  - id: REQ-AUTO-002  # auto-generated when source had no ID\n    description: \"Dashboard displays user profile\"\n    # auto-generated: true  (optional comment for tracking)\n```\n\n**When source has no IDs:** If the user opts in, auto-generated IDs follow the `REQ-{NNN}` format with an optional `# auto-generated` comment.\n\n**When source has mixed IDs:** Entries with source IDs get `id:` fields; entries without IDs receive auto-generated IDs. A comment block at the top of `in_scope` documents which IDs were auto-generated.\n\n### REQUIREMENTS_TRACE.yaml format\n\nEmitted when source has FR-XX (functional requirement) or UJ-XX (user journey) IDs. Maps source requirements to bigpowers epic\u002Fstory structure and verification commands:\n\n```yaml\ntrace:\n  # Functional Requirements\n  - id: FR-001\n    type: functional_requirement\n    description: \"User can register with email\u002Fpassword\"\n    source_artifact: \"prd.md\"\n    epic: \"e02-auth-ui\"\n    story: \"e02s01\"\n    verify: \"grep -q 'FR-001' specs\u002Fproduct\u002FSCOPE_LATEST.yaml && echo OK\"\n\n  # User Journeys\n  - id: UJ-001\n    type: user_journey\n    description: \"New user completes registration flow\"\n    source_artifact: \"epic-auth-ui.md\"\n    epic: \"e02-auth-ui\"\n    story: \"e02s01\"\n    verify: \"grep -q 'UJ-001' specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml && echo OK\"\n\nmetadata:\n  source_framework: \"BMAD\"\n  migrated_at: \"2026-06-26T12:00:00Z\"\n  total_requirements: 2\n  coverage: \"All FR-XX and UJ-XX IDs from source mapped\"\n```\n\n**When source has no FR-XX\u002FUJ-XX:** Skip REQUIREMENTS_TRACE.yaml. Add note to `state.yaml` handoff: \"No FR-XX\u002FUJ-XX IDs found — traceability file skipped\".\n\n**Existing trace file:** If REQUIREMENTS_TRACE.yaml exists, prompt user: \"Overwrite? [yes \u002F merge \u002F skip]\". Merge appends new entries; skip leaves existing file intact.\n\n### `specs\u002Fstate.yaml` template format\n\nGenerated during Step 4 of migration. Regenerate from scratch in bigpowers YAML format. The **handoff block is mandatory**:\n\n```yaml\nactive_flow: null\nactive_epic_id: null\nactive_story_id: null\ncompleted_epic: false\n\nepic_cycle:\n  current_step: null\n  next_skill: null\n  story_bcps: null\n  completed_steps: []\n  audit_result: null\n\nbug_cycle:\n  current_step: null\n  completed_steps: []\n\nrelease:\n  target_version: null\n  last_tag: null\n  last_publish: null\n  ci_verified: false\n\nmetrics:\n  story_start: null\n  story_end: null\n  cycle_minutes: null\n  bcp_per_hour: null\n\ngit:\n  branch: \u003Ccurrent branch>\n  hash: \u003Cgit rev-parse HEAD>\n  pushed: false\n\nhandoff:\n  last_step_completed: \"Migrated from \u003Cframework> on \u003Cdate>\"\n  open_decisions: []  # Empty if all decisions resolved during migration\n  required_reading:\n    - specs\u002Fproduct\u002FVISION_LATEST.yaml\n    - specs\u002Fproduct\u002FSCOPE_LATEST.yaml\n    - specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md\n    - specs\u002Frelease-plan.yaml\n  next_skill: survey-context\n\ntwo_pass_spec:  # Optional: only if user activates two-pass spec writing gate\n  journey_pass: pending\n  technical_pass: pending\n  approved_at: null\n```\n\n---\n\n## Reference block 1\n\n```\nDetected: GSD\nFound:\n  ✓ .planning\u002FROADMAP.md\n  ✓ .planning\u002FREQUIREMENTS.md  (12 REQ-XX items)\n  ✓ .planning\u002Fstate.yaml\n  ✓ .planning\u002Fphases\u002F01-auth\u002F01-CONTEXT.md\n  ✗ .planning\u002FMETHODOLOGY.md  (not present)\n\nSkipping:\n  .planning\u002Fphases\u002F01-auth\u002F01-01-SUMMARY.md  (execution record; archived only)\n\nProceed with migration? [yes \u002F skip \u003Cartifact> \u002F abort]\n```\n\n---\n\n## Reference block 2\n\n```yaml\n# CORRECT — first-class id: field\nin_scope:\n  - id: REQ-001\n    description: \"User can register with email\u002Fpassword\"\n    source: \"REQUIREMENTS.md\"\n\n# DEPRECATED — comment-only\nin_scope:\n  - \"User can register with email\u002Fpassword\"  # REQ-001\n```\n\n---\n\n## Reference block 3\n\n```yaml\ntrace:\n  - id: FR-001\n    type: functional_requirement\n    description: \"User can register with email\u002Fpassword\"\n    epic: e02-auth-ui\n    story: e02s01\n    verify: \"grep -q 'FR-001' specs\u002Fproduct\u002FSCOPE_LATEST.yaml && echo OK\"\n  - id: UJ-001\n    type: user_journey\n    description: \"New user completes registration flow\"\n    epic: e02-auth-ui\n    story: e02s01\n```\n\n---\n\n## Reference block 4\n\n```yaml\nactive_flow: null\nactive_epic_id: null\nactive_story_id: null\n\n# ... other state fields ...\n\nhandoff:\n  last_step_completed: \"Migrated from \u003Cframework> on \u003Cdate>\"\n  open_decisions:\n    - \"decision text here\"\n  required_reading:\n    - specs\u002Fproduct\u002FVISION_LATEST.yaml\n    - specs\u002Fproduct\u002FSCOPE_LATEST.yaml\n    - specs\u002Ftech-architecture\u002FTECH_STACK_LATEST.md\n    - specs\u002Frelease-plan.yaml\n  next_skill: survey-context\n```\n\n---\n\n## Reference block 5\n\n```markdown\n# Migration Audit — \u003Cproject-name> from \u003Cframework>\n\n**Date:** \u003CISO 8601 timestamp>\n**Status:** Pass \u002F Fail with findings\n\n## Findings\n\n### High Priority\n- Artifact: specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  Finding: No verify: commands in story tasks\n  Recommendation: Add `verify:` to each task before develop-tdd\n\n### Information\n- Count of TODO markers: 3 (normal for fresh migration)\n```\n\n---\n\n## Reference block 6\n\n```\nWhich lenses to include in specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md?\n\n[x] Cost of Delay (CD3)           — Priority & trade-off assessment\n[ ] STRIDE                        — Security threat modeling\n[ ] F.I.R.S.T                     — Test quality principles\n[ ] Bayesian Updating            — Probabilistic decision-making\n[ ] OWASP Top 10                 — Web security framework\n```\n\n---\n\n### Step 7 — Post-migration: Optional two-pass spec writing gate\n\nAfter Steps 1–6, offer the user an optional two-pass spec writing workflow (spec-kit learning):\n\nPrompt: \"Use two-pass spec writing (user journeys first, then technical)? [yes \u002F no]\"\n\nIf **yes**, initialize the gate in `specs\u002Fstate.yaml`:\n\n```yaml\ntwo_pass_spec:\n  journey_pass: pending\n  technical_pass: pending\n  approved_at: null\n```\n\nThe journey pass must be marked \"complete\" by the user (after stakeholder approval of user-journey specs) before the technical pass begins:\n\n```yaml\ntwo_pass_spec:\n  journey_pass: complete\n  approved_at: \"2026-06-26T12:00:00Z\"\n  technical_pass: pending\n```\n\nInform the user: \"Journey pass is pending. Run `elaborate-spec` for user journeys, get stakeholder approval, then update `two_pass_spec.journey_pass: complete` in state.yaml before proceeding to technical specs.\"\n\nIf **no**, skip the two-pass gate. Proceed directly to plan-work.\n\n→ verify: `grep -q 'two_pass_spec:' specs\u002Fstate.yaml && echo \"two-pass gate initialized\" || echo \"two-pass gate not activated\"`\n\n\n---\n\n### Step 8 — Post-migration: Optional methodology doc template\n\nAfter Steps 1–7, offer the user an optional analytical framework scaffold (GSD learning):\n\nPrompt: \"Create a methodology doc? [yes \u002F no]\"\n\nIf **yes**, present a checklist of analytical lenses:\n\n```\nWhich lenses to include in specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md?\n\n[x] Cost of Delay (CD3)           — Priority & trade-off assessment\n[ ] STRIDE                        — Security threat modeling\n[ ] F.I.R.S.T                     — Test quality principles\n[ ] Bayesian Updating            — Probabilistic decision-making\n[ ] OWASP Top 10                 — Web security framework\n```\n\nCopy the template from `migrate-spec\u002Ftemplates\u002FMETHODOLOGY_LATEST.md` to `specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md`.\n- Active lenses remain uncommented\n- Unselected lenses are left commented out\n- Populate `{{project_name}}` with the migrated project's name\n\nIf **no**, skip. Add note to handoff: \"Methodology doc: skipped — can be added later via `cp migrate-spec\u002Ftemplates\u002FMETHODOLOGY_LATEST.md specs\u002Ftech-architecture\u002F`\"\n\n→ verify: `test -f specs\u002Ftech-architecture\u002FMETHODOLOGY_LATEST.md && echo \"methodology doc created\" || echo \"methodology doc skipped\"`\n\n---\n\n\n---\n\n## Artifact Mapping Summary\n\nFull mapping tables: [REFERENCE-GSD.md](.\u002FREFERENCE-GSD.md) (GSD) · [REFERENCE.md](.\u002FREFERENCE.md) (spec-kit, BMAD, learnings).\n\n| Source | Target |\n|--------|--------|\n| GSD `ROADMAP.md` | `specs\u002Frelease-plan.yaml + epic shards` |\n| GSD `REQUIREMENTS.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` |\n| GSD `CONTEXT.md` (phases) | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Fadr\u002F` |\n| GSD `PLAN.md` | `specs\u002Fepics\u002FeNN-slug\u002Fepic.yaml` (tasks with verify in `-tasks.yaml`) |\n| GSD `METHODOLOGY.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` |\n| spec-kit `spec.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` + `specs\u002Ftech-architecture\u002Ftech-stack.md` |\n| spec-kit `plan.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Frelease-plan.yaml` + `specs\u002Fepics\u002F` |\n| spec-kit `tasks.md` | `specs\u002Fepics\u002F (see slice-tasks)` |\n| BMAD `prd.md` | `specs\u002Fproduct\u002FSCOPE_LATEST.yaml` |\n| BMAD `architecture.md` | `specs\u002Ftech-architecture\u002Ftech-stack.md` + `specs\u002Fadr\u002F` |\n| BMAD `epic-*.md` | `specs\u002Frelease-plan.yaml + epic shards` |\n| BMAD `story-*.md` | `specs\u002Fepics\u002F (see slice-tasks)` |\n| BMAD `project-context.md` | `CLAUDE.md` (append project-specific section) |\n| BMAD `decision-log.md` | `specs\u002Fadr\u002F` (one ADR per logged decision) |\n\n---\n\n\n---\n\n## Rules\n\n- **Preserve source IDs** — REQ-XX, FR-XX, UJ-XX are emitted as first-class `id:` fields in bigpowers YAML targets (e.g., `in_scope` entries). Never silently renumber. See Step 3 ID Tracking subsection for details.\n- **Never merge contradictory docs** — if source has both `CONTEXT.md` and `architecture.md`, create sections in bigpowers `CONTEXT.md`; don't collapse them.\n- **ADRs are opt-in** — only create an ADR when: hard to reverse, surprising without context, result of a real trade-off. Lightweight decisions go to `specs\u002FDECISION-LOG_LATEST.md`.\n- **state.yaml is always regenerated** — never migrate source STATE verbatim; bigpowers state.yaml needs its own format.\n- **specs\u002F is the only output location** — no files are created outside `specs\u002F` and `CLAUDE.md`.\n\n---\n\n### Step 5 — Surface learnings (optional)\n\nAfter migration, offer the user a brief analysis of what the source framework did that bigpowers doesn't have yet.\n\nUse the learnings table from [REFERENCE.md](.\u002FREFERENCE.md#learnings-to-adopt). Present as checkboxes so the user can decide which to adopt.\n\n→ verify: `grep -c \"\\- \\[ \\]\" specs\u002Fstate.yaml 2>\u002Fdev\u002Fnull && echo \"pending items recorded\" || echo \"no pending items in state.yaml\"`\n\n\n---\n\n### Step 6 — Adversarial review (optional)\n\nBefore the user runs `plan-work`, offer an optional lightweight audit of the migrated artifacts. This catches common migration errors early — incomplete specs, missing verification commands, unresolved decisions.\n\nPrompt: \"Run adversarial review of migrated artifacts? [yes \u002F skip]\"\n\nIf yes, perform these checks:\n\n1. **Scan for incomplete markers** — Find TODO, FIXME, MISSING in specs\u002F\n2. **Verify every epic has `verify:` commands** — Parse all `eNN-*\u002Fepic.yaml` files\n3. **Check state.yaml handoff** — Ensure `open_decisions` is documented (even if empty)\n\nCollect findings and write to `specs\u002Farchive\u002FMIGRATION-AUDIT.md`:\n\n```markdown\n# Migration Audit — \u003Cproject-name> from \u003Cframework>\n\n**Date:** \u003CISO 8601 timestamp>\n**Status:** Pass \u002F Fail with findings\n\n\n---\n\n## Findings\n\n### High Priority\n- Artifact: specs\u002Fepics\u002Fe02-auth-ui\u002Fepic.yaml\n  Finding: No verify: commands in story tasks\n  Recommendation: Add `verify:` to each task before develop-tdd\n\n### Information\n- Count of TODO markers: 3 (normal for fresh migration)\n```\n\nIf findings exist, the handoff block should note: \"Adversarial review: N findings — see `specs\u002Farchive\u002FMIGRATION-AUDIT.md`\"\n\nIf skip is chosen, add to handoff: \"Adversarial review: skipped — review manually before plan-work\"\n\n→ verify: `test -f specs\u002Farchive\u002FMIGRATION-AUDIT.md && echo \"audit completed\" || echo \"audit skipped or not performed\"`\n",{"name":5,"model":40,"description":7},"main","72f5e4c8b43f60cf86b37078ad8cd7e22daf67aa",".copilot\u002Fskills\u002Fmigrate-spec",23,"https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers","https:\u002F\u002Fdanielvm-git.github.io\u002Fbigpowers\u002F","https:\u002F\u002Fgithub.com\u002Fdanielvm-git","danielvm.net","2026-11-10 01:18:54",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add danielvm-git\u002Fbigpowers --skill migrate-spec",{"tool":64,"command":65},"bunx","bunx skills add danielvm-git\u002Fbigpowers --skill migrate-spec",{"tool":67,"command":68},"pnpm","pnpm dlx skills add danielvm-git\u002Fbigpowers --skill migrate-spec","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002F.copilot\u002Fskills\u002Fmigrate-spec\u002FSKILL.md",true,[],[73,94,101,127,150,171],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":44},"01M71KBG9F8X644MJB16H4V8M7","skill-verify-fail-open-fixture","Negative-path fixture for run-skill-verify.sh — must never PASS.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fskill-verify-fail-open\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[85,86,87,88,89,90,91,92,93],"fixture","open","verify","skill verify fail open fixture","skill verify","path","run","for","never",{"skillNo":95,"name":96,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":44},"01M71KBE3BKEMKNE0C5DGVDWZH","negative-path","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fspecs\u002Fverifications\u002Ffixtures\u002Fnegative-path\u002FSKILL.md",[],[100,90],"negative path",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":110,"publishedAt":44},"01M71KBBGF7Y4EB4AMHBZ8CJFC","write-document","Write, organize, and sync high-integrity technical documents using the BMAD methodology. Ensures every document is Bold, Minimal, Actionable, and Durable. Use when creating architectural docs, technical guides, or organizing the specs\u002F directory.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-document\u002FSKILL.md",[107],{"categoryNo":108,"categoryName":109,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000002","文档处理",[111,112,113,114,115,116,117,118,37,119,38,32,120,121,40,122,123,124,125,126],"write","write document","document","documents","actionable","technical","methodology","high","standard","minimal","bold","integrity","organize","sync","directory","guides",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":44},"01M71KB8TM089JJD5AY5KAFSDM","wire-observability","Add structured JSON logging, observability commands, and idempotent setup scripts to a project. Use when a project needs production-readiness instrumentation, when user wants structured logging, or as a production-readiness gate at any phase of development.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-observability\u002FSKILL.md",[],[134,135,136,119,137,38,138,139,140,141,40,142,143,144,145,146,147,32,148,149],"observability","wire observability","readiness","commands","development","as","logging","add","instrumentation","at","structured logging","production-readiness","idempotent","phase","project","scripts",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":44},"01M71KB6CNRANP449DQA3NJZ96","wire-ci","CI pipeline setup with bundled, forge-neutral templates and local validation. Detects the forge from the git remote, generates workflows for supported forges, and skips honestly for the rest. The CI equivalent of wire-observability.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fwire-ci\u002FSKILL.md",[],[157,158,159,160,161,162,163,164,165,166,167,119,168,92,134,40,169,170],"wire ci","ci","remote","local","pipeline","forge","validation","setup","templates","REST","with","ci pipeline setup","git","workflows",{"skillNo":172,"name":173,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":186,"publishedAt":44},"01M71KB2ZV98P03X88QR8MT9F1","visual-dashboard","Start a browser-based dashboard that visualizes architecture, implementation plans, and project status. Persists artifacts in .bigpowers\u002Fdashboard\u002F. Reads specs\u002Fstate.yaml, release-plan.yaml, epics, and planning-status via HTTP API or opencode panel.","https:\u002F\u002Fgithub.com\u002Fdanielvm-git\u002Fbigpowers\u002Fblob\u002Fmain\u002Fskills\u002Fvisual-dashboard\u002FSKILL.md",[177,180,183],{"categoryNo":178,"categoryName":179,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000013","分析与可视化",{"categoryNo":181,"categoryName":182,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":184,"categoryName":185,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000033","数据分析师",[187,188,189,190,28,191,29,192,193,40,194,41,195,42,196,197,198,148,199,200],"dashboard","visual","visual dashboard","status","http","planning","panel","start","opencode","browser","api","architecture","project status","http api"]