@anionzo/skill 1.6.0 → 1.7.0

package/skills/commit/meta.yaml

@@ -27,4 +27,3 @@ related_skills:
   - code-review
   - debug
   - extract
-  - go-pipeline

package/skills/debug/meta.yaml

@@ -36,3 +36,4 @@ related_skills:
   - commit
   - verification-before-completion
   - test-driven-development
+  - extract

package/skills/docs-writer/meta.yaml

@@ -21,6 +21,7 @@ constraints:
   - prefer section edits over full rewrites
 related_skills:
   - using-skills
-  - repo-onboarding
+  - research
   - feature-delivery
+  - extract
   - verification-before-completion

package/skills/extract/SKILL.md

@@ -6,6 +6,8 @@ Extract reusable patterns, significant decisions, and failure learnings from com
 
 This skill exists to turn individual task outcomes into organizational memory — not just code patterns, but also the decisions and mistakes that are expensive to repeat.
 
+It also covers session handoff when work is not yet complete: compress the active task state into the smallest high-signal baton pass so a new session can continue without rereading everything.
+
 ## When To Use
 
 Load this skill when:
@@ -15,16 +17,45 @@ Load this skill when:
 - a decision was made that future work should know about
 - a mistake was made that should not be repeated
 - the user says "extract learnings", "document what we learned", or "capture this pattern"
+- the user asks "what did we do so far?" or "summarize where we are"
+- work is being handed to another session or agent
+- the current session is approaching its context limit
 
-Skip this skill when work was routine with no surprises or novel patterns.
+Skip this skill when work was routine with no surprises, novel patterns, or meaningful in-progress state to carry forward.
 
 ## Workflow
 
-1. Identify the source of knowledge (completed task, code change, debugging session).
-2. Analyze across three categories: patterns, decisions, and failures.
-3. Check for existing documentation that should be updated (avoid duplicates).
-4. Create or update knowledge documentation.
-5. Promote critical learnings that would save significant time if known in advance.
+1. Identify the source of value:
+   - completed task or debugging session -> durable learning extraction
+   - unfinished task or near-full context -> session handoff
+2. If extracting durable knowledge, analyze across three categories: patterns, decisions, and failures.
+3. If preparing a handoff, compress the active task into: goal, done so far, current state, locked decisions, open risks, and next best action.
+4. Check for existing documentation that should be updated (avoid duplicates).
+5. Create or update the right artifact:
+   - durable knowledge documentation
+   - temporary handoff summary
+6. Promote critical learnings that would save significant time if known in advance.
+
+## Session Handoff Mode
+
+When the task is not complete, create a high-signal baton pass for the next session.
+
+Include:
+
+- **Goal** — what is actively being worked on
+- **Done So Far** — completed changes, validation, commits, and approved decisions
+- **Current State** — what is verified, what is still in progress, and any dirty worktree notes
+- **Locked Decisions** — decisions that should not be re-litigated unless the user reopens them
+- **Open Questions / Risks** — blockers, uncertainty, or easy-to-miss constraints
+- **Next Best Action** — the single clearest next step
+- **Handoff Payload** — a compact 5-15 line summary for copy-paste into a new session
+
+Compression rules:
+
+- include only details that save meaningful time in the next session
+- prefer concrete file paths, commands, commits, and verification state when relevant
+- do not replay the whole conversation
+- keep temporary task state separate from durable knowledge
 
 ## Three-Category Analysis
 
@@ -126,12 +157,14 @@ Present results using the Shared Output Contract:
 
 1. **Goal/Result** — what knowledge was extracted, updated, or intentionally not extracted
 2. **Key Details:**
-   - what was extracted (patterns, decisions, failures)
+   - what was extracted or handed off
+   - whether this was durable knowledge or temporary task state
    - whether docs were created or updated
    - whether critical learnings were promoted
    - where the canonical knowledge now lives
 3. **Next Action** — only when findings lead somewhere:
    - extracted from completed task → `commit` if changes pending
+   - task is not complete but should continue later → name the primary next skill
    - no clear handoff → stop after the result
 
 ## No-Op Case
@@ -141,6 +174,7 @@ If the work was too routine to generalize, say so explicitly and do not force a
 ## Red Flags
 
 - only extracting code patterns, ignoring decisions and failures
+- replaying the full session instead of compressing it
 - promoting everything as critical (noise kills the learning loop)
 - writing generic learnings like "test more carefully" (worthless)
 - fabricating findings when the task was straightforward
@@ -150,6 +184,7 @@ If the work was too routine to generalize, say so explicitly and do not force a
 ## Checklist
 
 - [ ] Three categories analyzed (patterns, decisions, failures)
+- [ ] Or handoff state compressed (goal, done, current state, risks, next action)
 - [ ] Existing docs checked for duplicates
 - [ ] Knowledge is genuinely generalizable
 - [ ] Includes concrete examples (for patterns)
@@ -158,4 +193,9 @@ If the work was too routine to generalize, say so explicitly and do not force a
 
 ## Done Criteria
 
-This skill is complete when the three-category analysis is done and any findings worth preserving are documented in the appropriate location. If nothing worth extracting was found, an explicit "no-op" statement is the valid completion.
+This skill is complete when either:
+
+- the three-category analysis is done and any durable findings worth preserving are documented in the appropriate location, or
+- the in-progress task has been compressed into a clear handoff that a new session can continue from without redoing expensive analysis.
+
+If nothing worth extracting or handing off was found, an explicit "no-op" statement is the valid completion.

package/skills/extract/meta.yaml

@@ -1,25 +1,31 @@
 name: extract
-version: 0.1.0
+version: 0.2.0
 category: knowledge
-summary: Extract reusable patterns, decisions, and failure learnings from completed work to compound knowledge.
-summary_vi: "Tr\xEDch xu\u1EA5t pattern, quy\u1EBFt \u0111\u1ECBnh, v\xE0 b\xE0i h\u1ECDc t\u1EEB c\xF4ng vi\u1EC7c ho\xE0n th\xE0nh \u0111\u1EC3 t\xEDch l\u0169y ki\u1EBFn th\u1EE9c."
+summary: Extract durable learnings from completed work, or compress in-progress task state into a high-signal handoff for the next session.
+summary_vi: "Trích xuất bài học bền vững từ công việc đã xong, hoặc nén trạng thái công việc đang dở thành handoff sắc gọn cho session tiếp theo."
 triggers:
   - extract learnings from this task
   - document what we learned
   - capture this pattern
   - what did we learn
+  - what did we do so far
+  - summarize where we are
+  - prepare a handoff
+  - context is getting full
 inputs:
-  - completed task or feature
-  - code changes or debugging session
+  - completed task, unfinished task, or feature
+  - code changes, debugging session, or current task state
 outputs:
   - patterns documented
   - decisions recorded
   - failures captured
   - critical learnings promoted
+  - handoff payload for the next session
 constraints:
   - search existing docs before creating new ones
   - do not fabricate findings
-  - three-category analysis required
+  - use three-category analysis for durable knowledge
+  - compress instead of replaying the whole session for handoffs
 related_skills:
   - using-skills
   - commit

package/skills/feature-delivery/SKILL.md

@@ -28,7 +28,7 @@ Present results using the Shared Output Contract:
    - files changed
    - verification performed
    - follow-up or risk note
-3. **Next Action** — `verification-before-completion` to confirm, then `code-review` or `commit`
+3. **Next Action** — `verification-before-completion` to confirm, then `code-review` or `commit`; if pausing mid-task, use `extract` in handoff mode
 
 ## Red Flags
 
@@ -42,3 +42,5 @@ Present results using the Shared Output Contract:
 This skill is complete when the feature works as intended, the change is verified with the most relevant check available, and the outcome is summarized clearly.
 
 Before declaring done, run `verification-before-completion` to confirm the claim is backed by fresh evidence.
+
+If the task must pause before completion, use `extract` in handoff mode so the next session can resume without repeating the implementation analysis.

package/skills/feature-delivery/meta.yaml

@@ -22,10 +22,10 @@ related_skills:
   - using-skills
   - brainstorming
   - planning
-  - repo-onboarding
+  - research
   - debug
   - verification-before-completion
   - code-review
   - docs-writer
-  - go-pipeline
+  - extract
   - test-driven-development

package/skills/planning/SKILL.md

@@ -6,6 +6,8 @@ Produce an execution-ready plan before code changes begin. Each step must be con
 
 This skill exists to make planning explicit, especially for multi-file or non-trivial work.
 
+It also covers go mode when the user wants an approved spec or clear task executed end-to-end with minimal review gates.
+
 ## When To Use
 
 Load this skill when:
@@ -15,6 +17,7 @@ Load this skill when:
 - the change touches APIs, data flow, persistence, or architecture boundaries
 - the user explicitly asks for a plan
 - implementation risk is high enough that code should not start immediately
+- the user says "run all", "go mode", "execute everything", or wants one continuous plan-to-commit flow
 
 ## Workflow
 
@@ -30,6 +33,20 @@ Load this skill when:
 10. Present for approval.
 11. End with the next implementation skill to invoke.
 
+## Go Mode
+
+When the user wants an approved spec or clear task executed with minimal review gates, planning enters go mode:
+
+1. Validate that requirements are clear enough to implement.
+2. Break the work into ordered implementation tasks.
+3. Map each task to acceptance criteria or explicit outcomes.
+4. Plan and execute each task in dependency order.
+5. Verify after each task.
+6. Run full verification at the end.
+7. Prepare a single commit proposal and ask the user before committing.
+
+If the scope is too large for one context window, checkpoint progress and resume later rather than continuing blindly.
+
 ## Bite-Sized Task Granularity
 
 Each step should be one action, completable in 2-5 minutes:
@@ -122,6 +139,7 @@ Present results using the Shared Output Contract:
    - `feature-delivery` for implementation
    - `test-driven-development` if TDD approach preferred
    - `brainstorming` if requirements need more definition first
+   - if the user wants one continuous execution run: continue in go mode under `planning`
 
 ## Planning Rules
 
@@ -169,4 +187,4 @@ Present results using the Shared Output Contract:
 
 ## Done Criteria
 
-This skill is complete when the implementation path, risks, and verification steps are clear enough to hand off to `feature-delivery`, `refactor-safe`, or `test-driven-development`. The pre-execution check and self-review must have been run with all findings addressed or explicitly surfaced.
+This skill is complete when the implementation path, risks, and verification steps are clear enough to hand off to `feature-delivery`, `refactor-safe`, or `test-driven-development` — or, in go mode, when the work has been planned, executed, verified, and brought to a commit gate. The pre-execution check and self-review must have been run with all findings addressed or explicitly surfaced.

package/skills/planning/meta.yaml

@@ -1,16 +1,20 @@
 name: planning
-version: 0.3.0
+version: 0.4.0
 category: planning
-summary: Execution-ready plans with bite-sized steps, no placeholders, self-review, and pre-execution validation.
-summary_vi: "Plan sẵn sàng thực thi với bước nhỏ gọn, không placeholder, tự review, và kiểm tra trước thực thi."
+summary: Execution-ready plans with bite-sized steps, no placeholders, self-review, pre-execution validation, and optional go-mode execution.
+summary_vi: "Plan sẵn sàng thực thi với bước nhỏ gọn, không placeholder, tự review, kiểm tra trước thực thi, và có thể chạy theo go mode."
 triggers:
   - make a plan
   - think through the implementation first
   - prepare before coding
+  - run all
+  - go mode
+  - execute everything
 inputs:
   - user request
   - relevant repo context
   - existing patterns and constraints
+  - optional approved spec or explicit requirements
 outputs:
   - scope (in/out)
   - approach
@@ -18,6 +22,7 @@ outputs:
   - pre-execution check results
   - self-review results
   - verification plan
+  - optional go-mode task execution and commit proposal
 constraints:
   - keep the plan concrete and bounded
   - separate planning from implementation
@@ -27,12 +32,10 @@ constraints:
 related_skills:
   - using-skills
   - brainstorming
-  - repo-onboarding
   - research
   - debug
   - feature-delivery
   - refactor-safe
   - code-review
   - test-driven-development
-  - go-pipeline
   - verification-before-completion

package/skills/research/SKILL.md

@@ -2,19 +2,23 @@
 
 ## Purpose
 
-Understand existing code, patterns, and decisions before writing new code.
+Understand existing code, patterns, decisions, and repository structure before writing new code.
 
 This skill exists to prevent implementing from scratch what already exists, and to surface constraints that would otherwise be discovered mid-implementation.
 
+It also covers repo onboarding: mapping a repository quickly enough to act safely when the task starts from little context.
+
 ## When To Use
 
 Load this skill when:
 
 - exploring a codebase before starting a task
+- entering a repo for the first time
 - looking for existing patterns, utilities, or conventions to follow
 - trying to understand how a feature or subsystem works
 - the implementation approach depends on what already exists
 - the user says "research this", "look into", or "what do we have for X"
+- the user asks "explain this repo" or "understand this codebase before we change it"
 
 Skip this skill when you already have clear context and the task is straightforward.
 
@@ -31,7 +35,32 @@ Skip this skill when you already have clear context and the task is straightforw
    - whether it is reusable, needs adaptation, or is irrelevant
    - any conventions or constraints it reveals
 4. Identify gaps — what does NOT exist that the task needs.
-5. Summarize findings with concrete recommendations.
+5. If this is repo onboarding, also identify:
+   - project purpose
+   - major components and responsibilities
+   - runtime model and key integrations
+   - important development commands
+   - notable conventions and open questions
+6. Summarize findings with concrete recommendations.
+
+## Repo Onboarding Mode
+
+When the user is entering an unfamiliar repo, use research in repo-map mode:
+
+1. Read the top-level operating docs first, especially `AGENTS.md` and `README.md` when present.
+2. Inspect the most informative files next:
+   - package manifests or build files
+   - app entrypoints and framework bootstraps
+   - core config files
+   - representative tests
+3. Summarize:
+   - project purpose
+   - architecture summary
+   - major components
+   - important commands
+   - notable conventions or constraints
+   - open questions
+4. Recommend the next files or directories to inspect for the user's likely goal.
 
 ## Search Techniques
 
@@ -66,6 +95,7 @@ Present findings using the Shared Output Contract:
 3. **Next Action** — recommend a follow-up only when findings clearly lead somewhere:
    - research for an active task → `planning`
    - research revealed a gap → `brainstorming`
+   - research produced enough repo context → `planning`, `docs-writer`, or direct execution
    - no clear handoff → stop after findings
 
 ## Research Rules
@@ -97,4 +127,4 @@ Present findings using the Shared Output Contract:
 
 ## Done Criteria
 
-This skill is complete when the findings are concrete enough to inform the next step — whether that is planning, implementation, or a decision that more information is needed. Every finding should include a file path or explicit "not found" statement.
+This skill is complete when the findings are concrete enough to inform the next step — whether that is planning, implementation, docs work, or a decision that more information is needed. Every finding should include a file path or explicit "not found" statement.

package/skills/research/meta.yaml

@@ -1,21 +1,25 @@
 name: research
-version: 0.1.0
+version: 0.2.0
 category: discovery
-summary: Understand existing code, patterns, and decisions before writing new code to avoid reinventing what exists.
-summary_vi: "T\xECm hi\u1EC3u code, pattern, v\xE0 quy\u1EBFt \u0111\u1ECBnh hi\u1EC7n c\xF3 tr\u01B0\u1EDBc khi vi\u1EBFt code m\u1EDBi \u0111\u1EC3 tr\xE1nh l\xE0m l\u1EA1i nh\u1EEFng g\xEC \u0111\xE3 c\xF3."
+summary: Understand repository structure, existing code, patterns, and decisions before acting so new work follows what already exists.
+summary_vi: "Tìm hiểu cấu trúc repo, code, pattern, và quyết định hiện có trước khi hành động để công việc mới đi đúng theo cái đã có."
 triggers:
   - research this codebase
   - what do we already have for X
   - look into how this works
   - explore before implementing
+  - explain this repo
+  - onboard into a codebase
+  - understand architecture before changing code
 inputs:
-  - topic or feature to research
+  - topic, feature, or repository area to research
   - optional file paths or package names
 outputs:
   - existing implementations found
   - patterns and conventions discovered
   - gaps identified
   - actionable recommendations
+  - repo map and important commands when onboarding
 constraints:
   - search before assuming nothing exists
   - read actual code not just filenames
@@ -24,4 +28,4 @@ related_skills:
   - planning
   - brainstorming
   - extract
-  - repo-onboarding
+  - docs-writer

package/skills/using-skills/SKILL.md

@@ -34,7 +34,6 @@ If the user types `an:<skill-name>` (for example `an:planning` or `an:debug`), s
 **Available skills:**
 
 - `an:brainstorming` — explore ideas, lock decisions, optionally write a spec
-- `an:repo-onboarding` — understand an unfamiliar codebase
 - `an:research` — explore existing code and patterns before implementing
 - `an:planning` — create an execution-ready plan with bite-sized steps
 - `an:feature-delivery` — implement a feature
@@ -46,7 +45,6 @@ If the user types `an:<skill-name>` (for example `an:planning` or `an:debug`), s
 - `an:commit` — create a conventional commit with verification
 - `an:docs-writer` — update documentation
 - `an:extract` — extract patterns, decisions, and learnings from completed work
-- `an:go-pipeline` — execute a full spec-to-commit pipeline in one run
 
 ## Workflow
 
@@ -69,20 +67,20 @@ If the user types `an:<skill-name>` (for example `an:planning` or `an:debug`), s
 
 - `an:<skill-name>` (direct trigger) -> load the named skill immediately
 - vague feature idea, unclear goal, tradeoff exploration -> `brainstorming`, then `planning`
-- unfamiliar repo or missing context -> `repo-onboarding`
+- unfamiliar repo or missing context -> `research`
 - need to understand existing code before implementing -> `research`
 - complex feature needing requirements definition -> `brainstorming` (includes spec writing)
-- docs work in an unfamiliar repo -> `repo-onboarding` first, then `docs-writer`
+- docs work in an unfamiliar repo -> `research` first, then `docs-writer`
 - bug report, error trace, failing test, regression -> `debug`
 - implement or change behavior -> `planning`, then `feature-delivery`
 - implement with TDD approach -> `planning`, then `test-driven-development`
+- execute an approved spec or clear task end-to-end with minimal gates -> `planning` in go mode
 - refactor, restructure, extract, or migrate without behavior change -> `planning`, then `refactor-safe`
 - review diff, PR, or changed files -> `code-review`
 - respond to review feedback -> `code-review` (receiving mode)
 - ready to commit -> `commit`
 - update README, runbook, onboarding docs, API notes in a known repo -> `docs-writer`
-- extract learnings from completed work -> `extract`
-- execute an approved spec end-to-end -> `go-pipeline`
+- extract learnings from completed work, or summarize active work for the next session -> `extract`
 
 ## Planning Rule
 

package/skills/using-skills/examples.md

@@ -41,7 +41,7 @@ Help me understand this repo before we add a new API endpoint.
 Expected routing:
 
 - task type: repo understanding
-- chosen skill: `repo-onboarding`
+- chosen skill: `research`
 - planning required: not yet
 - next step: read repo docs and inspect core entrypoints
 
@@ -60,7 +60,22 @@ Expected routing:
 - planning required: yes
 - next step: refine the exact SSO scope and constraints before writing the implementation plan
 
-## Example 5 — Sample completed output
+## Example 5
+
+User request:
+
+```text
+What did we do so far? Prepare the next session to continue this task.
+```
+
+Expected routing:
+
+- task type: extraction / handoff
+- chosen skill: `extract`
+- planning required: no
+- next step: summarize the active task, completed work, locked decisions, risks, and next action
+
+## Example 6 — Sample completed output
 
 User request:
 

package/skills/using-skills/meta.yaml

@@ -1,5 +1,5 @@
 name: using-skills
-version: 0.3.0
+version: 0.4.0
 category: routing
 summary: Route a user request to the right primary skill and working mode before deeper work begins.
 summary_vi: "Phân loại request và chọn đúng skill chính trước khi bắt đầu công việc sâu hơn."
@@ -19,7 +19,6 @@ constraints:
   - prefer one primary skill at a time
 related_skills:
   - brainstorming
-  - repo-onboarding
   - research
   - planning
   - test-driven-development
@@ -31,4 +30,3 @@ related_skills:
   - verification-before-completion
   - docs-writer
   - extract
-  - go-pipeline

package/skills/verification-before-completion/meta.yaml

@@ -30,7 +30,6 @@ related_skills:
   - docs-writer
   - feature-delivery
   - debug
-  - go-pipeline
   - planning
   - refactor-safe
   - test-driven-development

package/skills/go-pipeline/SKILL.md

@@ -1,156 +0,0 @@
-# Go Pipeline
-
-## Purpose
-
-Execute a full development pipeline from an approved spec: break into tasks, plan each, implement each, verify all, and commit — in one continuous run with minimal review gates.
-
-This skill exists for when the spec is approved and the user wants execution, not incremental review at each step.
-
-## When To Use
-
-Load this skill when:
-
-- the user has an approved spec and wants to execute everything in one shot
-- the user says "run all", "go mode", "execute everything", or "just build it"
-- all requirements are clear and decisions are locked
-
-## When NOT To Use
-
-- Spec is still a draft — redirect to `brainstorming` first.
-- User wants to review each task individually — use `planning` + `feature-delivery` per task.
-- Spec has unresolved open questions — resolve them first.
-- The scope is too large for one context window — use `planning` + `feature-delivery` incrementally.
-
-## Workflow
-
-### Phase 1: Validate Spec
-
-Before starting, verify the spec is ready:
-
-- [ ] Spec exists and is approved
-- [ ] Has acceptance criteria defined
-- [ ] No unresolved blocking questions
-- [ ] Requirements are specific enough to implement
-
-If any check fails, STOP and redirect:
-> "Spec not ready. [specific issue]. Run `brainstorming` first."
-
-### Phase 2: Generate Tasks
-
-Parse the spec and break it into ordered implementation tasks:
-
-- Group related requirements into logical tasks
-- Order by dependency (foundational first, dependent last)
-- Each task should be completable in a single implementation session
-- Map each task to the spec acceptance criteria it fulfills
-
-**Report:** "Created X tasks from spec. Starting implementation..."
-
-### Phase 3: Plan + Implement Each Task
-
-Loop through all tasks in dependency order:
-
-For each task:
-1. **Research context** — check related code, patterns, docs
-2. **Draft plan** — concrete steps, files to change, tests to add
-3. **Implement** — work through plan steps
-4. **Verify** — run tests/lint/build after each task
-5. **Mark complete** — note what was done
-
-**Progress report between tasks:**
-> "Task X/Y done: [title]. Continuing..."
-
-### Phase 4: Full Verification
-
-After all tasks complete:
-
-1. Run the full test suite
-2. Run the build
-3. Run linting
-4. Check acceptance criteria coverage:
-
-```
-Coverage Report
-===============
-Spec: [name]
-Tasks: X/X complete (100%)
-ACs: Y/Z verified
-```
-
-If coverage < 100%, identify and address gaps.
-
-### Phase 5: Commit
-
-Stage all changes and prepare a single conventional commit:
-
-```
-feat(<scope>): implement <spec-name>
-
-- Task 1: <title>
-- Task 2: <title>
-- All ACs verified
-```
-
-**This is the ONE gate in go-pipeline — ask user before committing:**
-
-> Pipeline complete. X tasks done, all verified.
-> Ready to commit. Proceed? (yes / no / edit)
-
-## Context Budget Management
-
-If context exceeds approximately 60% during implementation:
-
-1. Finish the current task
-2. Commit completed work so far
-3. Report progress and remaining tasks
-4. Suggest: "Run `go-pipeline` again to continue remaining tasks."
-
-The skill should detect already-completed tasks and skip them on re-run.
-
-## Error Handling
-
-- **Build/test fails during a task:** Fix the error, re-run tests. If unfixable, mark task as blocked, note why, continue to next task.
-- **Spec has conflicting requirements:** STOP and ask user to clarify.
-- **Task depends on blocked task:** Skip and report at the end.
-
-## Output Format
-
-Present results using the Shared Output Contract:
-
-1. **Goal/Result** — what was completed across the full pipeline run
-2. **Key Details:**
-   - total tasks created and completed
-   - any blocked or skipped tasks
-   - acceptance criteria coverage percentage
-   - build/test/lint status
-   - commit proposal
-3. **Next Action:**
-   - if complete → commit confirmation
-   - if interrupted → how to resume
-   - if blocked → what to resolve
-
-## Red Flags
-
-- running on a draft or unapproved spec
-- skipping verification between tasks
-- not checking acceptance criteria before marking tasks done
-- committing without user approval
-- ignoring build/test failures
-- not reporting progress between tasks
-- continuing past context budget limit without checkpointing
-- treating this as a shortcut to skip proper spec work
-
-## Checklist
-
-- [ ] Spec is approved
-- [ ] Spec validated (requirements clear, ACs defined)
-- [ ] Tasks generated with AC mapping
-- [ ] Each task: planned, implemented, verified, completed
-- [ ] Full verification passed (tests, build, lint)
-- [ ] AC coverage reported
-- [ ] User approved commit
-- [ ] Commit created
-
-## Done Criteria
-
-This skill is complete when all tasks from the spec are implemented, verified, and committed with user approval — or when progress is checkpointed and the user is informed how to resume.