opencodekit 0.21.10 → 0.23.0

package/dist/template/.opencode/skill/grill-me/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: grill-me
+description: Adversarial interrogation of ideas before implementation — pushes on ambiguity, hidden assumptions, missing constraints, and hand-waving. Use when you have a rough idea, ADR, PRD, or spec that needs to survive scrutiny before code is written.
+version: 1.0.0
+tags: [planning, review, decision]
+dependencies: [brainstorming, spec-driven-development]
+agent_types: [planner, worker, reviewer]
+tools: []
+---
+
+# Grill Me — Adversarial Idea Interrogation
+
+> **Replaces** skipping straight from idea to implementation without pressure-testing the plan.
+> **Sits between** `brainstorming` (collaborative refinement) and `spec-driven-development` (formal spec/ADR creation).
+
+## When to Use
+
+- You have a rough idea that needs to be tested before implementation
+- You just finished brainstorming and need to find the flaws
+- You have an existing ADR, PRD, or spec that needs to be stress-tested
+- The agent (me) seems unclear about what to build and you want to surface that confusion
+
+## When NOT to Use
+
+- Requirements are already well-understood and the task is mechanical
+- You are already in implementation with a validated plan
+- The task is trivial (< 1 file, no decisions needed)
+- You need creative exploration (use `brainstorming` instead)
+
+## How This Is Different From Brainstorming
+
+| Brainstorming | Grill Me |
+|---|---|
+| Collaborative exploration | Adversarial interrogation |
+| "What do we need to build?" | "Why is this idea wrong or incomplete?" |
+| Generates options and approaches | Destroys weak options |
+| Asks clarifying questions | Asks challenging, uncomfortable questions |
+| Refines the idea | Tests if the idea survives scrutiny |
+| Output: a better design | Output: resolved uncertainties, killed bad ideas, hardened decisions |
+
+## Process
+
+### Phase 1: Surface the Idea
+
+Read the available context — the user's prompt, any existing docs, the repo structure, relevant code. Identify exactly what is being proposed. Restate it clearly so the human can correct any misunderstanding.
+
+### Phase 2: Interrogate
+
+Go after the idea systematically. Do not be polite. Do not assume the idea is sound. Push on:
+
+**Ambiguity**
+- Which terms in this description could mean different things to different people?
+- What's the actual scope boundary — what's explicitly in, what's explicitly out?
+- Can you point to a concrete example of the expected behavior?
+
+**Hidden assumptions**
+- What does this idea assume about the existing system?
+- What does it assume about user behavior, data quality, or failure modes?
+- What does it assume about team capacity, deployment timeline, or external dependencies?
+- What does it assume the human reviewer will accept without question?
+
+**Missing constraints**
+- What constraints are implicit but never stated?
+- Performance? Security? Backward compatibility? Error handling? Observability?
+- What existing patterns in the codebase constrain this design?
+- What deadlines or external commitments constrain the approach?
+
+**Hand-waving**
+- Where does the idea say "we'll figure that out later"?
+- Where are the "obviously" or "simply" or "just" statements? Those are hiding complexity.
+- What's the hardest part of this idea, and how does the current plan address it?
+- What would have to go wrong for this idea to fail, and how would we know?
+
+**Integration & blast radius**
+- What existing code would this touch?
+- What would break if this change were deployed?
+- What tests would need to change?
+- What documentation would become outdated?
+
+### Phase 3: Resolve
+
+For each question raised in Phase 2:
+
+1. Present the question to the human with a concrete example
+2. Let the human answer or make a decision
+3. Record the resolution
+4. Update any existing documents (ADR, PRD, spec) with the new information
+
+If the human cannot answer a question, flag it as a blocker — do not proceed to implementation until it's resolved.
+
+### Phase 4: Assess
+
+After all questions have been addressed:
+
+- **Is the idea clearly defined enough to proceed?** YES → recommend writing it up as an ADR or spec via `documentation-and-adrs` or `spec-driven-development`.
+- **Is the idea fundamentally flawed?** YES → say so directly. Explain why and suggest alternatives.
+- **Are there too many unresolved questions?** YES → recommend another brainstorming round or more research before committing to implementation.
+
+### Phase 5 (optional): Grill-with-Docs
+
+If you're working with an existing ADR, PRD, or spec document:
+
+1. Read the document(s) thoroughly
+2. Apply the same interrogation against the document content
+3. For each gap found, propose edits to the document
+4. Present the proposed edits to the human for approval
+5. Apply approved edits
+
+## Success Criteria
+
+The grilling is complete when:
+- Questions start repeating (you've exhausted the line of inquiry)
+- Added precision stops changing the plan (diminishing returns)
+- Every ambiguity, assumption, constraint gap, and hand-wave has been surfaced and either resolved or flagged as a blocker
+- You can state clearly: "this idea is ready for an ADR/spec" or "this idea should be killed/reworked"
+
+## Output
+
+Leave behind a clear summary of:
+- What was challenged and resolved
+- What decisions were made
+- What remains blocked or unresolved
+- Recommended next step (ADR, spec, more research, kill the idea)
+
+This summary becomes the input for the next phase (ADR writing or spec-driven-development).
+
+## Anti-Patterns
+
+- **Being too nice.** This is not a collaborative exploration — this is an adversarial review. If you're not making the human think hard, you're doing it wrong.
+- **Grilling during implementation.** Do this BEFORE any code is written. Once files change, the cost of finding a flaw is much higher.
+- **Grilling trivial tasks.** A one-line bugfix doesn't need this. Use judgment.
+- **Accepting "we'll fix it later."** If something is identified as risky, it needs a decision now or a clear blocker flag.
+- **Grilling without context.** Read the repo, understand the existing patterns, and ground your questions in actual code.
+
+## See Also
+
+- `brainstorming` — collaborative exploration (use before grilling)
+- `spec-driven-development` — formal spec writing (use after grilling)
+- `documentation-and-adrs` — recording decisions in ADR format
+- `development-lifecycle` — full phased workflow

package/dist/template/.opencode/skill/memory-system/SKILL.md

@@ -31,21 +31,20 @@ dependencies: []
    - Run `memory-search` with task keywords before implementation.
    - Check recent handoffs when resuming interrupted work.
 2. **Calibrate (progressive disclosure)**
-   - Use search results as index.
-   - Fetch full entries only for relevant IDs (`memory-get`).
-   - Pull timeline context only when sequencing matters (`memory-timeline`).
+   - Use search results as index; `memory-search({ file: "..." })` for file access.
+   - Retrieve full observation details from search output.
 3. **Record (high-signal only)**
    - Create `observation` for decisions, bugfixes, patterns, warnings, or durable learnings.
    - Include searchable concepts and concrete file references.
 4. **Handoff (if session boundary)**
-   - Write a concise status note with completed work, blockers, and next steps using `memory-update` under `handoffs/`.
+   - Write a concise status note with completed work, blockers, and next steps using `observation`.
 
 ## What Goes Where
 
 | Store | Put Here | Avoid Here |
 | --- | --- | --- |
-| `observation` (SQLite) | Events: decisions, bugfixes, reusable patterns, warnings | Temporary notes, speculative ideas without evidence |
-| `memory-update` files | Durable docs: handoffs, research, project notes | Every minor runtime detail from a single debug run |
+| `observation` (SQLite) | Events: decisions, bugfixes, reusable patterns, warnings, handoffs | Temporary notes, speculative ideas without evidence |
+| `memory-search` by file | Durable docs: handoffs, research, project notes | Every minor runtime detail from a single debug run |
 | Auto pipeline | Captured messages + distillations (automatic) | Manual copying of full transcripts |
 
 ## Observation Quality Bar
@@ -66,7 +65,7 @@ If most answers are "no", skip creating the observation.
 | Storing transient debugging info as permanent observations | Pollutes search results with low-value noise | Keep transient info in session context; record only durable findings |
 | Creating observations for every small finding (signal-to-noise) | Important items get buried and retrieval quality drops | Batch minor notes; publish one distilled observation per meaningful outcome |
 | Not searching memory before creating duplicate observations | Produces conflicting/duplicated records | Run `memory-search` first; update/supersede existing records when appropriate |
-| Using `memory-update` for data that should be an observation | Durable events become hard to discover and rank | Use `observation` for events; reserve `memory-update` for document-style files |
+| Using `observation` with `file` param for document-style content | Document-style content should use `memory-search({ file: "..." })` for file access | Use `observation` for events; write to memory files when structured document storage is needed |
 
 ## Verification
 
@@ -114,9 +113,9 @@ memory-admin({ operation: "log" })
 
 ### Reading Compiled Artifacts
 ```
-memory-read({ file: "index" })             // Full observation catalog
-memory-read({ file: "compiled/auth" })      // Compiled article for "auth" concept
-memory-read({ file: "log" })                // Operation audit trail
+memory-search({ file: "index" })             // Full observation catalog
+memory-search({ file: "compiled/auth" })      // Compiled article for "auth" concept
+memory-search({ file: "log" })                // Operation audit trail
 ```
 
 ## Validation Gate

package/dist/template/.opencode/skill/opensrc/references/example-workflow.md

@@ -39,7 +39,7 @@ read({
 
 // 6. Document findings
 write({
-  filePath: ".beads/artifacts/br-xxx/research.md",
+  filePath: ".opencode/artifacts/<slug>/research.md",
   content: `# Zod Async Refinements
 
 **Finding:** Async refinements use \`parseAsync()\` not \`parse()\`

package/dist/template/.opencode/skill/planning-and-task-breakdown/SKILL.md

@@ -0,0 +1,116 @@
+---
+name: planning-and-task-breakdown
+description: Decomposes a spec into small verifiable tasks with dependencies and acceptance checks. Use when a feature/change has a spec or clear goal and needs an executable implementation plan.
+version: 1.0.0
+tags: [workflow, planning, agent-coordination]
+dependencies: [spec-driven-development]
+agent_types: [planner]
+tools: [TaskCreate, TaskUpdate, memory, srcwalk_search]
+---
+
+# Planning & Task Breakdown
+
+## Overview
+
+A good plan creates leverage for builders. It says what must become true, where to work, what not to touch, and how to prove success.
+
+Core principle: plan backward from observable truths into artifacts, wiring, tasks, dependencies, and verification.
+
+## When to Use
+
+- A spec or clear goal exists and implementation is non-trivial.
+- Work spans multiple files, phases, or agents.
+- Tasks need dependency ordering or parallelization decisions.
+- You need a handoff artifact for worker agents.
+
+## When NOT to Use
+
+- Single-file fixes that can be implemented directly.
+- Requirements are still unclear; use `spec-driven-development` first.
+- You are debugging an active failure; use `debugging-and-error-recovery`.
+
+## Workflow
+
+1. Restate the goal and constraints.
+2. Convert observable truths into required artifacts.
+3. Identify required wiring between artifacts.
+4. Mark key links most likely to break.
+5. Decompose into vertical slices, not horizontal layers.
+6. Limit each task to a small scope with exact files when known.
+7. Add acceptance checks and verification commands to every task.
+8. Build a dependency graph and execution order.
+9. Create tracked tasks or write a plan artifact.
+
+## Task Packet Template
+
+```markdown
+## Task N: [Name]
+
+Goal: [one sentence]
+Files in scope:
+- [path]
+Acceptance checks:
+- [behavior] -> verify with [command/check]
+Non-goals:
+- [explicit exclusion]
+Dependencies:
+- [task id/name or none]
+Review depth: targeted|standard|full
+```
+
+## Slicing Rules
+
+- Prefer vertical slices that produce end-to-end behavior.
+- Put risky unknowns first.
+- Do not mix refactors with feature behavior unless the refactor is required.
+- If one task touches more than five files, split it.
+- If a task needs architectural judgment, route to `planner`, not `worker`.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "I'll make tasks as I go" | Hidden dependencies appear too late. Plan the graph first. |
+| "Layer-by-layer is cleaner" | Horizontal layers delay integration and hide broken wiring. |
+| "Acceptance criteria are obvious" | Workers need objective checks, not intent. |
+| "One big task is simpler" | Big tasks are hard to review, rollback, and verify. |
+
+## Red Flags
+
+- Tasks named after vague activities like "update backend".
+- No verification command/check per task.
+- UI, API, and data work split so nothing works until the end.
+- Multiple agents assigned to overlapping files without sequencing.
+- Plan omits non-goals or rollback considerations.
+
+## Verification
+
+- Every task has goal, scope, acceptance checks, non-goals, dependencies.
+- Execution order respects dependencies.
+- Key links are identified for reviewer verification.
+- The first task can be implemented without further planning.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>planning-and-task-breakdown</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Plan/task packets include scope, dependencies, and verification</evidence>
+  <artifacts>Task ids or plan file path</artifacts>
+  <risks>Large tasks, unresolved dependencies, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Planning Workflow
+
+This is the canonical active planning skill. It absorbs PRD-to-plan and writing-plans responsibilities. Use spec-driven-development first when requirements are still unclear.
+
+Plans should include:
+- scope and non-goals;
+- ordered tasks with dependencies;
+- exact files or search targets when known;
+- acceptance checks per task;
+- review and verification gates;
+- handoff details for subagents with zero assumed context.

package/dist/template/.opencode/skill/shipping-and-launch/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: shipping-and-launch
+description: Guides final readiness checks, rollback planning, documentation, and release handoff. Use when preparing to merge, deploy, release, or declare a development branch complete.
+version: 1.0.0
+tags: [shipping, workflow, release]
+dependencies: [verification-before-completion, documentation-and-adrs]
+agent_types: [planner, reviewer]
+tools: [bash, ask_user_question, memory]
+---
+
+# Shipping & Launch
+
+## Overview
+
+Shipping should be boring because risk was removed earlier. The ship phase verifies readiness, documents what changed, and makes rollback possible.
+
+Core principle: do not ship work that cannot be verified, explained, or rolled back.
+
+## When to Use
+
+- User says ship, merge, deploy, release, or finish.
+- Before closing tracked work as complete.
+- Before creating a PR or release notes.
+- After build/review/QA phases pass.
+
+## When NOT to Use
+
+- Work is still being implemented.
+- Critical review findings are open.
+- Verification cannot run and no user-approved exception exists.
+
+## Workflow
+
+1. Check worktree state and identify intended changes.
+2. Confirm spec/plan acceptance criteria are met.
+3. Run required verification or use a fresh valid verification stamp.
+4. Run phantom completion checks for stubs, placeholders, and disconnected wiring.
+5. Review security/secrets/configuration risk in the diff.
+6. Confirm docs/ADRs/changelog updates are sufficient.
+7. Define rollback path: revert commit, feature flag, migration rollback, or manual procedure.
+8. Present ship options when action is irreversible: PR, merge, deploy, hold.
+9. Record handoff/memory when useful.
+
+## Pre-Ship Checklist
+
+- Tests relevant to changed behavior pass.
+- Build/typecheck/lint pass or exceptions are documented.
+- No high-severity review findings remain.
+- No secrets or local-only paths in diff.
+- User-facing/API behavior is documented.
+- Rollback path is clear.
+- User approval exists for irreversible actions.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "Tests passed earlier" | Fresh changes require fresh evidence or a valid unchanged-state stamp. |
+| "Rollback is just git revert" | Migrations, flags, queues, and external state may need more. |
+| "Docs can wait" | Shipped behavior without docs becomes support debt. |
+| "Small release, no checklist" | Small releases still leak secrets and break config. |
+
+## Red Flags
+
+- Completion claim without verification evidence.
+- Unresolved P0/P1 findings.
+- No rollback plan for data or API changes.
+- Changelog omits user-visible behavior changes.
+- Deployment/merge attempted without explicit user approval.
+- Placeholder/stub patterns remain in modified code.
+
+## Verification
+
+- Verification commands and outputs are recorded.
+- Acceptance criteria are checked line-by-line.
+- Phantom completion scan is clean or exceptions are explained.
+- Rollback plan is documented.
+- Final action is approved when irreversible.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>shipping-and-launch</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Verification commands, acceptance audit, review status, rollback plan</evidence>
+  <artifacts>Changelog, PR, release notes, handoff, or none</artifacts>
+  <risks>Open findings, skipped checks, deployment risk, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Branch Completion
+
+`finishing-a-development-branch` was removed as a separate optional skill. Keep merge/PR/cleanup choices, release handoff, rollback planning, and completion evidence in this canonical shipping workflow.

package/dist/template/.opencode/skill/source-driven-development/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: source-driven-development
+description: Grounds implementation decisions in official docs, source code, and cited references. Use when using unfamiliar libraries, external APIs, framework behavior, or current ecosystem guidance.
+version: 1.0.0
+tags: [research, implementation, verification]
+dependencies: []
+agent_types: [scout, planner, worker]
+tools: [context7, websearch, web_fetch, webclaw_scrape, grepsearch, codesearch]
+---
+
+# Source-Driven Development
+
+## Overview
+
+Framework guesses become bugs. Source-driven work verifies behavior against authoritative references before implementation.
+
+Core principle: cite the source for non-trivial external API decisions, or mark the decision as unverified.
+
+## When to Use
+
+- New or unfamiliar library/framework/API.
+- Version-specific behavior matters.
+- Choosing between packages or integration patterns.
+- Error suggests external API misuse.
+- User asks to research current best practice.
+
+## When NOT to Use
+
+- Pure local codebase questions; use code search/explore.
+- Stable project conventions already cover the behavior.
+- Trivial syntax you can verify from existing code.
+
+## Source Hierarchy
+
+1. Official docs, specs, release notes.
+2. Maintained source code and examples.
+3. Maintainer-authored articles.
+4. Community posts only when higher sources are absent.
+
+Higher-ranked sources win on conflicts.
+
+## Workflow
+
+1. State the question precisely.
+2. Check memory/local docs for prior decisions.
+3. Retrieve authoritative sources.
+4. Verify version compatibility with the project.
+5. Compare sources if guidance conflicts.
+6. Extract only the implementation-relevant facts.
+7. Cite URLs or source refs in the recommendation.
+8. Mark unresolved uncertainty explicitly.
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "I know this API" | APIs change; verify version-specific behavior. |
+| "A blog said so" | Blogs lose to official docs/source. |
+| "The package name is obvious" | Similar packages differ in security and maintenance. |
+| "Citations slow us down" | A bad integration costs more than a source check. |
+
+## Red Flags
+
+- Unfamiliar API used without citation or local precedent.
+- Community answer conflicts with official docs.
+- Version in docs differs from package version.
+- Agent invents options, flags, or imports.
+- Research dump has no recommendation.
+
+## Verification
+
+- Key claims cite authoritative sources.
+- Project/library versions are considered.
+- Implementation recommendation is specific.
+- Unverified assumptions are labeled.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>source-driven-development</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Sources consulted and version checks</evidence>
+  <artifacts>Research notes, citations, implementation recommendation</artifacts>
+  <risks>Unverified claims, stale docs, conflicting sources, or none</risks>
+</skill_result>
+```
+
+
+## Consolidated Research Workflow
+
+This is the canonical active source-grounding skill. It absorbs deep-research and source-code-research for normal work. Use opensrc, webclaw, context7, grepsearch, or gemini-large-context as tool-specific companions only when the source demands them.
+
+Evidence hierarchy:
+1. local code and tests;
+2. official docs and source;
+3. maintained examples from reputable repos;
+4. blog posts or issues with dates and caveats.
+
+
+## Removed Optional Companion
+
+`v1-run` was removed as an optional package-health skill. Use source-grounded package evaluation, official advisories, lockfile inspection, and package-manager audit commands instead.

package/dist/template/.opencode/skill/spec-driven-development/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: spec-driven-development
+description: Guides agents from vague request to concrete specification before implementation. Use when starting a new feature, significant change, product idea, or when requirements are ambiguous.
+version: 1.0.0
+tags: [workflow, planning, product]
+dependencies: []
+agent_types: [planner, scout]
+tools: [ask_user_question, TaskCreate, memory]
+---
+
+# Spec-Driven Development
+
+## Overview
+
+A spec converts intent into testable truth. Code written before the target is clear becomes rework.
+
+Core principle: define observable outcomes, constraints, non-goals, and verification before planning implementation.
+
+**Define the vocabulary first.** Every concept in the spec should have one name — that name must match what the code will call it. This is Evans' "ubiquitous language": a shared vocabulary between developers, domain experts, code, and AI context files. Ambiguous language in the spec causes the "AI does the wrong thing" failure mode: the LLM implements what the words say, not what you meant.
+
+After writing the spec, extract a glossary of terms. Every capitalized concept in the spec should correspond to exactly one code symbol (type, class, module, function, file). If two terms mean the same thing, pick one. If one term means two things, split it.
+
+## When to Use
+
+- User asks for a new feature or significant behavior change.
+- Requirements are vague, conflicting, or missing edge cases.
+- Multiple files/systems will be affected.
+- The work needs acceptance criteria or user-visible behavior.
+
+## When NOT to Use
+
+- Tiny mechanical edits with obvious expected behavior.
+- Emergency bug fixes where reproduction is already clear; use `debugging-and-error-recovery`.
+- Pure research with no implementation decision; use `source-driven-development`.
+
+## Workflow
+
+1. State the goal as an outcome, not a task.
+2. **Establish vocabulary**: define the key terms and map them to code concepts.
+3. Derive 3-7 observable truths from the user's perspective.
+4. Identify constraints: technical, UX, security, performance, compatibility.
+5. Define non-goals to prevent scope creep.
+6. List affected surfaces: files, APIs, commands, UI screens, data models.
+7. Define acceptance criteria with verification methods.
+8. **Check vocabulary consistency**: does every spec term map to exactly one code symbol? Are any terms overloaded?
+9. Ask at most 1-4 focused questions only if missing information changes the design.
+10. Hand off to `planning-and-task-breakdown` when the spec is stable.
+
+## Spec Template
+
+```markdown
+# Spec: [Name]
+
+## Goal
+[Outcome in one sentence]
+
+## Vocabulary
+| Term | Definition | Code symbol |
+|------|------------|-------------|
+| ...  | ...        | ...         |
+
+Every concept should have one name. If two terms mean the same thing, consolidate. If one term means two things, split it.
+
+## Observable Truths
+- [User/system can observe X]
+
+## Constraints
+- [Hard constraint]
+
+## Non-Goals
+- [Explicitly out of scope]
+
+## Affected Surfaces
+- [File/API/UI/data area]
+
+## Acceptance Criteria
+- [Criterion] -> verify with [command/check/manual observation]
+
+## Open Questions
+- [Question or none]
+```
+
+## Common Rationalizations
+
+| Rationalization | Rebuttal |
+| --- | --- |
+| "The user already explained it" | Explanation is not acceptance criteria. Write the target down. |
+| "I'll discover requirements while coding" | Discovery during coding causes churn and hidden scope expansion. |
+| "This is obvious" | Obvious to you is not a contract for the next agent or reviewer. |
+| "The AI will figure out what I mean" | The AI will implement exactly what the spec says. Ambiguous language = wrong implementation. |
+| "Questions slow us down" | One precise question is cheaper than implementing the wrong behavior. |
+
+## Red Flags
+
+- No explicit non-goals for a broad feature.
+- Acceptance criteria are phrased as implementation tasks.
+- Edge cases are deferred without user agreement.
+- The plan starts before observable truths are defined.
+- User-visible behavior has no verification method.
+- **No vocabulary section** — missing ubiquitous language means AI will guess term meanings.
+- **Same term used for different concepts** — e.g. "Order" means creation flow in one place and fulfillment in another.
+- **Different terms for the same concept** — e.g. "User" vs "Account" vs "Profile" used interchangeably.
+
+## Verification
+
+- Goal is outcome-shaped.
+- Observable truths are human-verifiable.
+- Acceptance criteria include commands/checks where possible.
+- Ambiguities that affect implementation are resolved or marked as assumptions.
+
+## Skill Result Contract
+
+```xml
+<skill_result>
+  <skill>spec-driven-development</skill>
+  <status>success|partial|blocked|failure</status>
+  <evidence>Spec sections completed and questions/assumptions recorded</evidence>
+  <artifacts>Spec path or inline spec summary</artifacts>
+  <risks>Unresolved assumptions or none</risks>
+</skill_result>
+```