[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HGC1H4JQFJWH613XTJC59":3,"skill-same:01M71HGC1H4JQFJWH613XTJC59":131},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71HGC1H4JQFJWH613XTJC59","spec-driven",null,"Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).","runecraftai\u002Farcanum","runecraftai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279098826?v=4","01M71HBGS1RCAJ490RAYST7M00","01M71HBGT1CB94MNS6T6SGAZKW",1,"CC-BY-4.0","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"spec","driven","spec driven","architecture","tasks","analysis","when","atomic commits","auto","self-improving","design","local","implementing","decision","project","pt","scope","task breakdown","complexity","coverage","2026-11-10 10:12:30",false,"---\nname: spec-driven\ndescription: >\n  Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute.\n  Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git\n  commits, and requirement traceability. Features an independent Verifier (author != verifier,\n  evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests,\n  plus a self-improving lessons layer that turns verification failures into reusable project-local\n  guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown),\n  implementing with verification and atomic commits, or validating\u002Fverifying an implementation\n  against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\",\n  \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\",\n  \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\",\n  \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\".\n  Do NOT use for architecture decomposition analysis (use architecture skills) or technical\n  design docs (treat as Complex scope: discuss gray areas + architecture-focused design).\nlicense: CC-BY-4.0\nmetadata:\n  version: 5.0.0\n---\n\n# spec-driven\n\nPlan and implement features with precision. Granular tasks. Clear dependencies. Right tools. Zero ceremony.\n\n```\n┌──────────┐   ┌──────────┐   ┌─────────┐   ┌─────────┐\n│ SPECIFY  │ → │  DESIGN  │ → │  TASKS  │ → │ EXECUTE │\n└──────────┘   └──────────┘   └─────────┘   └─────────┘\n   required      optional*      optional*     required\n\n* Agent auto-skips when scope doesn't need it\n```\n\n## Critical Rules (read before acting)\n\n**Loading this skill's files.** Reference files live under `references\u002F` in this skill's own directory (where this `SKILL.md` resides). Resolve them relative to the skill directory — never the workspace root — and load them through the active skill by name; never assume a fixed install path. When a step tells you to read a reference, **read it completely (to EOF)** before acting — never act on a partial\u002Ftruncated read.\n\n**Execution contract — every task, non-negotiable (holds even if you do not open the reference files):**\n\n1. Tests derive from the spec's acceptance criteria and assert spec-defined outcomes — they never mirror the implementation.\n2. The gate must pass (tests pass) before a task is done — the test runner decides, not self-assessment.\n3. One atomic commit per task. Never batch tasks; never weaken, skip, or delete tests to make them pass.\n4. After the LAST task, a fresh **Verifier always runs automatically** (author ≠ verifier) — spec-anchored outcome check + discrimination sensor. It is never optional and never prompted. See Sub-Agent Delegation.\n\n**Before Execute:** read [implement.md](references\u002Fimplement.md) completely; if a formal `tasks.md` has more than 3 phases, present the sub-agent offer first (see Sub-Agent Delegation).\n\n## Auto-Sizing: The Core Principle\n\n**The complexity determines the depth, not a fixed pipeline.** Before starting any feature, assess its scope and apply only what's needed:\n\n| Scope       | What                     | Specify                                                 | Design                                          | Tasks                         | Execute                                               |\n| ----------- | ------------------------ | ------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | ----------------------------------------------------- |\n| **Small**   | ≤3 files, one sentence   | One-liner spec (inline)                                 | Skip                                            | Skip                          | Implement + verify inline                             |\n| **Medium**  | Clear feature, \u003C10 tasks | Spec (brief)                                            | Skip — design inline                            | Skip — tasks implicit         | Implement + verify                                    |\n| **Large**   | Multi-component feature  | Full spec + requirement IDs                             | Architecture + components                       | Full breakdown + dependencies | Implement + verify per task                           |\n| **Complex** | Ambiguity, new domain    | Full spec + [discuss gray areas](references\u002Fdiscuss.md) | [Research](references\u002Fdesign.md) + architecture | Breakdown + parallel plan     | Implement + [interactive UAT](references\u002Fvalidate.md) |\n\n**Rules:**\n\n- **Specify and Execute are always required** — you always need to know WHAT and DO it\n- **Design is skipped** when the change is straightforward (no architectural decisions, no new patterns)\n- **Tasks is skipped** when there are ≤3 obvious steps (they become implicit in Execute)\n- **Discuss is triggered within Specify** when the agent detects ambiguous gray areas that need user input, or when the feature has any implicit-requirement dimension present (persistence\u002Fstate, external calls, auth, payments, concurrency, state transitions)\n- **Interactive UAT is triggered within Execute** only for user-facing features with complex behavior\n\n**Safety valve:** Even when Tasks is skipped, Execute ALWAYS starts by listing atomic steps inline (see [implement.md](references\u002Fimplement.md)). If that listing reveals >5 steps or complex dependencies, STOP and create a formal `tasks.md` — the Tasks phase was wrongly skipped.\n\n## .specs Structure\n\n```\n.specs\u002F\n├── STATE.md            # Project memory: Decisions log (AD-NNN) + Handoff snapshot\n├── LESSONS.md          # Self-improving lessons playbook (rendered by scripts\u002Flessons.py — do not hand-edit)\n├── lessons.json        # Canonical lessons state (machine-owned)\n└── features\u002F           # Feature specifications\n    └── [feature]\u002F\n        ├── spec.md         # Requirements with traceable IDs\n        ├── context.md      # User decisions for gray areas (only when discuss is triggered)\n        ├── design.md       # Architecture & components (only for Large\u002FComplex)\n        ├── tasks.md        # Atomic tasks with verification (only for Large\u002FComplex)\n        └── validation.md   # Verifier report: PASS\u002FFAIL, per-AC evidence, sensor result, diff range\n```\n\n## Workflow\n\n**New feature:**\n\n1. Specify → (Design) → (Tasks) → Execute (depth auto-sized)\n\n**Resume work:**\n\nRead `.specs\u002FSTATE.md` — Handoff section for in-flight state, Decisions section to re-confirm active constraints — then propose the next step.\n\n## Context Loading Strategy\n\n**On-demand load (only what the current task needs):**\n\n- `.specs\u002FSTATE.md` — Decisions section (read at Design, re-read on resume); Handoff section (read on resume only)\n- confirmed lessons — load at Specify and Design via `python3 scripts\u002Flessons.py list --status confirmed` ([lessons.md](references\u002Flessons.md)); confirmed only, never candidates\n- spec.md (when working on a specific feature)\n- context.md (when designing or implementing from user decisions)\n- design.md (when implementing from design)\n- tasks.md (when executing tasks)\n\n**Never load simultaneously:**\n\n- Multiple feature specs\n- Multiple architecture docs\n\n**Target:** \u003C40k tokens total context\n**Reserve:** 160k+ tokens for work, reasoning, outputs\n**Monitoring:** Display status when >40k (see [context-limits.md](references\u002Fcontext-limits.md))\n\n## Sub-Agent Delegation\n\n**Trigger:** >3 phases → offer one worker per phase (sequential); ≤3 phases → execute inline.\n\n**Offer-then-confirm** — never auto-spawn. The user must accept before any sub-agent is dispatched.\n\n**One worker per phase:** Each phase worker executes all its tasks in order (implement → gate → atomic commit), then reports a compact summary (tasks done, commit hashes, test counts, deviations). Workers never spawn further sub-agents.\n\n**Verifier (always-on, never prompted):** After the final task is committed, the orchestrator dispatches a fresh Verifier sub-agent automatically — regardless of phase count. Validation never requires a user prompt; it is the closing step of Execute. **Author ≠ verifier**: the Verifier re-derives coverage independently using evidence-or-zero; it does not inherit the author's mental model. The Verifier: (1) performs a **spec-anchored outcome check** — confirms each test's asserted value matches the spec-defined expected outcome, flags spec-precision gaps; (2) runs a **discrimination sensor** — injects behavior-level faults in scratch state, confirms tests kill them, discards mutations, surviving mutants become fix tasks; (3) writes `.specs\u002Ffeatures\u002F[feature]\u002Fvalidation.md` (PASS\u002FFAIL, per-AC evidence, sensor result, diff range); (4) returns a compact verdict + ranked gap list to the orchestrator in chat. Gaps become fix tasks; the fix→re-verify loop is bounded to 3 iterations before escalating. (5) **distills lessons** — turns each grounded failure (surviving mutant, spec-precision gap, failed AC, SPEC_DEVIATION) into a reusable project-local lesson via `scripts\u002Flessons.py`; a clean PASS records nothing (see [lessons.md](references\u002Flessons.md)).\n\n**Standalone fallback:** Without sub-agents, run `validate.md` as an independent fresh-eyes pass after the final commit — including the spec-anchored check and discrimination sensor.\n\nFull mechanics (worker payload, compact summary format, failure handling, context sizing, Verifier report format): [sub-agents.md](references\u002Fsub-agents.md).\n\n## Commands\n\n**Feature-level (auto-sized):**\n| Trigger Pattern | Reference |\n|----------------|-----------|\n| Specify feature, define requirements | [specify.md](references\u002Fspecify.md) |\n| Discuss feature, capture context, how should this work | [discuss.md](references\u002Fdiscuss.md) |\n| Design feature, architecture | [design.md](references\u002Fdesign.md) |\n| Break into tasks, create tasks | [tasks.md](references\u002Ftasks.md) |\n| Implement task, build, execute | [implement.md](references\u002Fimplement.md) |\n| Validate, verify, test, UAT, walk me through it | [validate.md](references\u002Fvalidate.md) |\n\n**Memory:**\n| Trigger Pattern | Reference |\n|----------------|-----------|\n| Record decision, this is a project-level decision | [memory.md](references\u002Fmemory.md) |\n| Pause work, end session, I need to stop | [memory.md](references\u002Fmemory.md) |\n| Resume work, continue, pick up where we left off | [memory.md](references\u002Fmemory.md) |\n| Load lessons, what have we learned, apply past lessons | [lessons.md](references\u002Flessons.md) |\n| Record lesson, distill lessons (auto-runs after validation) | [lessons.md](references\u002Flessons.md) |\n\n## Knowledge Verification Chain\n\nWhen researching, designing, or making any technical decision, follow this chain in strict order. Never skip steps.\n\n```\nStep 1: Codebase → check existing code, conventions, and patterns already in use\nStep 2: Project docs → README, docs\u002F, inline comments, `.specs\u002FSTATE.md` (Decisions)\nStep 3: Context7 MCP → resolve library ID, then query for current API\u002Fpatterns\nStep 4: Web search → official docs, reputable sources, community patterns\nStep 5: Flag as uncertain → \"I'm not certain about X — here's my reasoning, but verify\"\n```\n\n**Rules:**\n\n- Never skip to Step 5 if Steps 1-4 are available\n- Step 5 is ALWAYS flagged as uncertain — never presented as fact\n- **NEVER assume or fabricate.** If you cannot find an answer, say \"I don't know\" or \"I couldn't find documentation for this\". Inventing APIs, patterns, or behaviors causes cascading failures across design → tasks → implementation. Uncertainty is always preferable to fabrication.\n\n## Output Behavior\n\n**Model guidance:** After completing lightweight tasks (validation, feature-level checks), naturally mention once per session that such tasks work well with faster\u002Fcheaper models. For heavy tasks (complex design, large features), briefly note the reasoning requirements before starting.\n\nBe conversational, not robotic. Don't interrupt workflow—add as a natural closing note. Skip if user seems experienced or has already acknowledged the tip.\n\n## Code Analysis\n\nUse available tools with graceful degradation. See [code-analysis.md](references\u002Fcode-analysis.md).\n","# spec-driven\n\nPlan and implement features with precision. Granular tasks. Clear dependencies. Right tools. Zero ceremony.\n\n```\n┌──────────┐   ┌──────────┐   ┌─────────┐   ┌─────────┐\n│ SPECIFY  │ → │  DESIGN  │ → │  TASKS  │ → │ EXECUTE │\n└──────────┘   └──────────┘   └─────────┘   └─────────┘\n   required      optional*      optional*     required\n\n* Agent auto-skips when scope doesn't need it\n```\n\n## Critical Rules (read before acting)\n\n**Loading this skill's files.** Reference files live under `references\u002F` in this skill's own directory (where this `SKILL.md` resides). Resolve them relative to the skill directory — never the workspace root — and load them through the active skill by name; never assume a fixed install path. When a step tells you to read a reference, **read it completely (to EOF)** before acting — never act on a partial\u002Ftruncated read.\n\n**Execution contract — every task, non-negotiable (holds even if you do not open the reference files):**\n\n1. Tests derive from the spec's acceptance criteria and assert spec-defined outcomes — they never mirror the implementation.\n2. The gate must pass (tests pass) before a task is done — the test runner decides, not self-assessment.\n3. One atomic commit per task. Never batch tasks; never weaken, skip, or delete tests to make them pass.\n4. After the LAST task, a fresh **Verifier always runs automatically** (author ≠ verifier) — spec-anchored outcome check + discrimination sensor. It is never optional and never prompted. See Sub-Agent Delegation.\n\n**Before Execute:** read [implement.md](references\u002Fimplement.md) completely; if a formal `tasks.md` has more than 3 phases, present the sub-agent offer first (see Sub-Agent Delegation).\n\n## Auto-Sizing: The Core Principle\n\n**The complexity determines the depth, not a fixed pipeline.** Before starting any feature, assess its scope and apply only what's needed:\n\n| Scope       | What                     | Specify                                                 | Design                                          | Tasks                         | Execute                                               |\n| ----------- | ------------------------ | ------------------------------------------------------- | ----------------------------------------------- | ----------------------------- | ----------------------------------------------------- |\n| **Small**   | ≤3 files, one sentence   | One-liner spec (inline)                                 | Skip                                            | Skip                          | Implement + verify inline                             |\n| **Medium**  | Clear feature, \u003C10 tasks | Spec (brief)                                            | Skip — design inline                            | Skip — tasks implicit         | Implement + verify                                    |\n| **Large**   | Multi-component feature  | Full spec + requirement IDs                             | Architecture + components                       | Full breakdown + dependencies | Implement + verify per task                           |\n| **Complex** | Ambiguity, new domain    | Full spec + [discuss gray areas](references\u002Fdiscuss.md) | [Research](references\u002Fdesign.md) + architecture | Breakdown + parallel plan     | Implement + [interactive UAT](references\u002Fvalidate.md) |\n\n**Rules:**\n\n- **Specify and Execute are always required** — you always need to know WHAT and DO it\n- **Design is skipped** when the change is straightforward (no architectural decisions, no new patterns)\n- **Tasks is skipped** when there are ≤3 obvious steps (they become implicit in Execute)\n- **Discuss is triggered within Specify** when the agent detects ambiguous gray areas that need user input, or when the feature has any implicit-requirement dimension present (persistence\u002Fstate, external calls, auth, payments, concurrency, state transitions)\n- **Interactive UAT is triggered within Execute** only for user-facing features with complex behavior\n\n**Safety valve:** Even when Tasks is skipped, Execute ALWAYS starts by listing atomic steps inline (see [implement.md](references\u002Fimplement.md)). If that listing reveals >5 steps or complex dependencies, STOP and create a formal `tasks.md` — the Tasks phase was wrongly skipped.\n\n## .specs Structure\n\n```\n.specs\u002F\n├── STATE.md            # Project memory: Decisions log (AD-NNN) + Handoff snapshot\n├── LESSONS.md          # Self-improving lessons playbook (rendered by scripts\u002Flessons.py — do not hand-edit)\n├── lessons.json        # Canonical lessons state (machine-owned)\n└── features\u002F           # Feature specifications\n    └── [feature]\u002F\n        ├── spec.md         # Requirements with traceable IDs\n        ├── context.md      # User decisions for gray areas (only when discuss is triggered)\n        ├── design.md       # Architecture & components (only for Large\u002FComplex)\n        ├── tasks.md        # Atomic tasks with verification (only for Large\u002FComplex)\n        └── validation.md   # Verifier report: PASS\u002FFAIL, per-AC evidence, sensor result, diff range\n```\n\n## Workflow\n\n**New feature:**\n\n1. Specify → (Design) → (Tasks) → Execute (depth auto-sized)\n\n**Resume work:**\n\nRead `.specs\u002FSTATE.md` — Handoff section for in-flight state, Decisions section to re-confirm active constraints — then propose the next step.\n\n## Context Loading Strategy\n\n**On-demand load (only what the current task needs):**\n\n- `.specs\u002FSTATE.md` — Decisions section (read at Design, re-read on resume); Handoff section (read on resume only)\n- confirmed lessons — load at Specify and Design via `python3 scripts\u002Flessons.py list --status confirmed` ([lessons.md](references\u002Flessons.md)); confirmed only, never candidates\n- spec.md (when working on a specific feature)\n- context.md (when designing or implementing from user decisions)\n- design.md (when implementing from design)\n- tasks.md (when executing tasks)\n\n**Never load simultaneously:**\n\n- Multiple feature specs\n- Multiple architecture docs\n\n**Target:** \u003C40k tokens total context\n**Reserve:** 160k+ tokens for work, reasoning, outputs\n**Monitoring:** Display status when >40k (see [context-limits.md](references\u002Fcontext-limits.md))\n\n## Sub-Agent Delegation\n\n**Trigger:** >3 phases → offer one worker per phase (sequential); ≤3 phases → execute inline.\n\n**Offer-then-confirm** — never auto-spawn. The user must accept before any sub-agent is dispatched.\n\n**One worker per phase:** Each phase worker executes all its tasks in order (implement → gate → atomic commit), then reports a compact summary (tasks done, commit hashes, test counts, deviations). Workers never spawn further sub-agents.\n\n**Verifier (always-on, never prompted):** After the final task is committed, the orchestrator dispatches a fresh Verifier sub-agent automatically — regardless of phase count. Validation never requires a user prompt; it is the closing step of Execute. **Author ≠ verifier**: the Verifier re-derives coverage independently using evidence-or-zero; it does not inherit the author's mental model. The Verifier: (1) performs a **spec-anchored outcome check** — confirms each test's asserted value matches the spec-defined expected outcome, flags spec-precision gaps; (2) runs a **discrimination sensor** — injects behavior-level faults in scratch state, confirms tests kill them, discards mutations, surviving mutants become fix tasks; (3) writes `.specs\u002Ffeatures\u002F[feature]\u002Fvalidation.md` (PASS\u002FFAIL, per-AC evidence, sensor result, diff range); (4) returns a compact verdict + ranked gap list to the orchestrator in chat. Gaps become fix tasks; the fix→re-verify loop is bounded to 3 iterations before escalating. (5) **distills lessons** — turns each grounded failure (surviving mutant, spec-precision gap, failed AC, SPEC_DEVIATION) into a reusable project-local lesson via `scripts\u002Flessons.py`; a clean PASS records nothing (see [lessons.md](references\u002Flessons.md)).\n\n**Standalone fallback:** Without sub-agents, run `validate.md` as an independent fresh-eyes pass after the final commit — including the spec-anchored check and discrimination sensor.\n\nFull mechanics (worker payload, compact summary format, failure handling, context sizing, Verifier report format): [sub-agents.md](references\u002Fsub-agents.md).\n\n## Commands\n\n**Feature-level (auto-sized):**\n| Trigger Pattern | Reference |\n|----------------|-----------|\n| Specify feature, define requirements | [specify.md](references\u002Fspecify.md) |\n| Discuss feature, capture context, how should this work | [discuss.md](references\u002Fdiscuss.md) |\n| Design feature, architecture | [design.md](references\u002Fdesign.md) |\n| Break into tasks, create tasks | [tasks.md](references\u002Ftasks.md) |\n| Implement task, build, execute | [implement.md](references\u002Fimplement.md) |\n| Validate, verify, test, UAT, walk me through it | [validate.md](references\u002Fvalidate.md) |\n\n**Memory:**\n| Trigger Pattern | Reference |\n|----------------|-----------|\n| Record decision, this is a project-level decision | [memory.md](references\u002Fmemory.md) |\n| Pause work, end session, I need to stop | [memory.md](references\u002Fmemory.md) |\n| Resume work, continue, pick up where we left off | [memory.md](references\u002Fmemory.md) |\n| Load lessons, what have we learned, apply past lessons | [lessons.md](references\u002Flessons.md) |\n| Record lesson, distill lessons (auto-runs after validation) | [lessons.md](references\u002Flessons.md) |\n\n## Knowledge Verification Chain\n\nWhen researching, designing, or making any technical decision, follow this chain in strict order. Never skip steps.\n\n```\nStep 1: Codebase → check existing code, conventions, and patterns already in use\nStep 2: Project docs → README, docs\u002F, inline comments, `.specs\u002FSTATE.md` (Decisions)\nStep 3: Context7 MCP → resolve library ID, then query for current API\u002Fpatterns\nStep 4: Web search → official docs, reputable sources, community patterns\nStep 5: Flag as uncertain → \"I'm not certain about X — here's my reasoning, but verify\"\n```\n\n**Rules:**\n\n- Never skip to Step 5 if Steps 1-4 are available\n- Step 5 is ALWAYS flagged as uncertain — never presented as fact\n- **NEVER assume or fabricate.** If you cannot find an answer, say \"I don't know\" or \"I couldn't find documentation for this\". Inventing APIs, patterns, or behaviors causes cascading failures across design → tasks → implementation. Uncertainty is always preferable to fabrication.\n\n## Output Behavior\n\n**Model guidance:** After completing lightweight tasks (validation, feature-level checks), naturally mention once per session that such tasks work well with faster\u002Fcheaper models. For heavy tasks (complex design, large features), briefly note the reasoning requirements before starting.\n\nBe conversational, not robotic. Don't interrupt workflow—add as a natural closing note. Skip if user seems experienced or has already acknowledged the tip.\n\n## Code Analysis\n\nUse available tools with graceful degradation. See [code-analysis.md](references\u002Fcode-analysis.md).\n",{"name":5,"license":14,"metadata":43,"description":45},{"version":44},"5.0.0","Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Fspec-driven",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add runecraftai\u002Farcanum --skill spec-driven",{"tool":59,"command":60},"bunx","bunx skills add runecraftai\u002Farcanum --skill spec-driven",{"tool":62,"command":63},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill spec-driven","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",true,[67,73,77,81,85,89,93,97,101,105,109,113,117,121,125],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},".skill-meta.json","REFERENCE","参考文档",517,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002F.skill-meta.json",{"path":74,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":75,"sourceHtmlUrl":76},"README.md",14019,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FREADME.md",{"path":78,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fcode-analysis.md",2216,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fcode-analysis.md",{"path":82,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fcoding-principles.md",1791,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fcoding-principles.md",{"path":86,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fcontext-limits.md",750,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fcontext-limits.md",{"path":90,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fdesign.md",8059,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fdesign.md",{"path":94,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fdiscuss.md",6110,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fdiscuss.md",{"path":98,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fimplement.md",23683,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fimplement.md",{"path":102,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Flessons.md",6700,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Flessons.md",{"path":106,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fmemory.md",4449,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fmemory.md",{"path":110,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":111,"sourceHtmlUrl":112},"references\u002Fspecify.md",9381,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fspecify.md",{"path":114,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":115,"sourceHtmlUrl":116},"references\u002Fsub-agents.md",6690,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fsub-agents.md",{"path":118,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":119,"sourceHtmlUrl":120},"references\u002Ftasks.md",21277,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Ftasks.md",{"path":122,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":123,"sourceHtmlUrl":124},"references\u002Fvalidate.md",16467,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Freferences\u002Fvalidate.md",{"path":126,"resourceType":127,"resourceTypeDesc":128,"sizeBytes":129,"sourceHtmlUrl":130},"scripts\u002Flessons.py","SCRIPT","脚本",13543,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002Fscripts\u002Flessons.py",[132,161,185,209,233,256],{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":143,"publishedAt":38},"01M71HGTN9FRQ3WEZMVVX7C3VZ","using-agent-skills","Discovers and invokes the right @runecraft\u002Fspells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: \u002Fskill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json \u002F Claude Code plugin paths).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",[138],{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[144,145,146,33,147,148,24,149,150,151,22,152,153,154,155,156,157,158,159,160],"using agent skills","standalone","which","pick","Meta","workflow","you","code","skill discovery","route","work","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":38},"01M71HGPD6N9JH2G8EVBXJR77X","typescript-patterns","TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: \u002Ftypescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: \u002Ftypescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftypescript-patterns\u002FSKILL.md",[],[168,169,170,171,172,173,33,174,32,175,176,177,178,179,180,181,182,183,151,184],"typescript","patterns","typescript patterns","do","projects","for","runtime","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":197,"publishedAt":38},"01M71HGJAKX4TFN0PECYPJ9S38","test-driven-development","Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: \u002Ftest, write tests first, TDD, prove it, 80\u002F15\u002F5 pyramid, Beyonce Rule. PT triggers: \u002Fteste, testes primeiro, provar com teste, pirâmide 80\u002F15\u002F5. Do NOT use for: production incident triage (use \u002Fdebug), or cosmetic-only changes with no behavioral surface.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[191,194],{"categoryNo":192,"categoryName":193,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":195,"categoryName":196,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000008","测试与质量",[198,199,200,19,33,201,30,202,179,24,203,204,205,206,207,171,173,176,178,208],"test driven development","development","test","incident","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":219,"publishedAt":38},"01M71HG5CSP04F29HRAG7XVYKG","skill-forge","Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: \u002Fforge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: \u002Fforge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch\u002Fmeta skill), planning feature implementation, or designing software architecture.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fskill-forge\u002FSKILL.md",[215,218],{"categoryNo":216,"categoryName":217,"taxonomyType":141,"taxonomyTypeDesc":142},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":139,"categoryName":140,"taxonomyType":141,"taxonomyTypeDesc":142},[220,221,222,146,223,224,33,225,148,226,227,28,21,228,229,203,230,159,231,232],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":239,"publishedAt":38},"01M71HG1RAQY3GXX0Q5TMW0XD6","shipping-and-launch","Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: \u002Fship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: \u002Fshippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fshipping-and-launch\u002FSKILL.md",[],[240,241,242,33,243,244,24,245,246,247,248,154,249,250,251,252,229,253,254,255],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch",{"skillNo":257,"name":258,"nameZh":6,"description":259,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":260,"categories":261,"keywords":267,"publishedAt":38},"01M71HFXGHP092ZKFR762M9394","security-and-hardening","Hardens code against vulnerabilities using the OWASP Top 10 and a three-tier boundary system (input, processing, output). Use when handling user input, authentication, data storage, or external integrations. EN triggers: \u002Fsecurity, security audit, OWASP, three-tier boundary, least privilege, input validation. PT triggers: \u002Fsegurança, auditoria de segurança, OWASP, privilégio mínimo, validar entrada. Do NOT use for: non-security performance work (use \u002Freview's performance axis), or dependency updates that have no security exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fsecurity-and-hardening\u002FSKILL.md",[262],{"categoryNo":263,"categoryName":264,"taxonomyType":265,"taxonomyTypeDesc":266},"01JBSEEDCAT000000000000033","数据分析师","PROFESSION","适用职业",[268,269,270,33,271,251,229,272,171,273,173,274,275,178,180,276,277,278,279,280],"security","hardening","security and hardening","authentication","input","three","system","least privilege","privilege","validation","vulnerabilities","user","processing"]