Menu
Use when the user asks to implement an approved Kanban task or linked project change with clear acceptance criteria.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when a maintainer explicitly asks for Knowledge Workflow setup, checks, upgrade migration, manifest work, or approved configuration updates.
Use when delivery work needs a proposal before editing task candidates, Kanban cards, backlog shape, or board changes.
Use when delivery work needs review, a PR or local diff needs validation, or Done readiness is in question.
Use when a user asks how to use Knowledge Workflow in a repository, where content belongs, which skill applies, what project rules mean, how to recover safely, or how to record local workflow feedback.
Use when the user has approved a specific shared-knowledge write, promotion, reorganization, or update.
Use when an idea, requirement, feedback, research note, decision, or fact may become shared knowledge but the target is not yet approved.
| name | delivery-implementation |
| description | Use when the user asks to implement an approved Kanban task or linked project change with clear acceptance criteria. |
Before acting, resolve <knowledge_dir> using the runtime bootstrap rules, then read <knowledge_dir>/.workflow/runtime.md and <knowledge_dir>/.workflow/manifest.yml; do not assume non-default workflow paths or default ids.
Use this skill to implement a selected Kanban card and keep code, tests, and knowledge aligned.
<knowledge_dir>/planning/KANBAN.md.<knowledge_dir>/.workflow/runtime.md; read local workspace instructions if they exist; read relevant sections from <knowledge_dir>/members/<member-id>.md only when assignment, ownership, review, or handoff context is needed.workspace-worklist:intake-task to create or update the local WORKLIST item before implementation.<knowledge_dir>/.workflow/rules/knowledge.md, <knowledge_dir>/.workflow/schemas/common.md, and relevant area schemas under <knowledge_dir>/.workflow/schemas/ before updating knowledge.references/checklist.md.references/checklist.md.references/checklist.md.When Superpowers skills are available, use them as execution-method guidance only:
| Situation | Optional Superpowers skill |
|---|---|
| Requirements or approach need shaping before implementation | brainstorming |
| Work needs a multi-step implementation plan | writing-plans |
| Code behavior changes, bugfixes, or refactors | test-driven-development |
| Failure cause is unclear | systematic-debugging |
| Completion, commit, PR, or review-readiness claim | verification-before-completion |
Superpowers usage does not replace task acceptance criteria, project checks, canonical knowledge updates, delivery review, or Kanban approval gates.
Before invoking Superpowers brainstorming or writing-plans, resolve and state the output directory and commit behavior using knowledge-assistant/references/superpowers.md: user-specified path first, then <knowledge_dir>/workspace/<member-id>/local/superpowers/specs/ or plans/ with SCM exclusion verified and no commit, and only then the Superpowers default when repair is not the next step and the user explicitly confirms using that default path.
Before invoking Superpowers subagent-driven-development, require an accepted plan with independent tasks and keep the main Agent responsible for integration, review checkpoints, approvals, shared knowledge writes, commits, and Kanban state. Worker subagents must route approval or elevated-execution needs back to the main Agent and must not commit local-only output.
Before invoking Superpowers using-git-worktrees, resolve <worktrees_dir> from Knowledge Workflow runtime and manifest; do not use an unrelated Superpowers default location. Before invoking Superpowers verification-before-completion, run the relevant project checks and treat the result as review-readiness evidence, not as a replacement for Knowledge Workflow delivery review or Done approval.
Default implementation handoffs are not separate files. Put ordinary review handoff context in the final response, local work log, task item update, or review request.
Use this structure when handing implementation to review or reporting blocked work:
This compact chat summary uses the core sections of <knowledge_dir>/.workflow/templates/handoff.md. When creating a formal shared handoff file, use the full template instead.
## Purpose
## Source Context
## Actions Taken
## Decisions Made
## Missing Information
## Risks
## Next Action
## Review Request
Create a formal shared handoff under <knowledge_dir>/workspace/<member-id>/handoffs/ only when the handoff is cross-member, long-lived, complex enough to survive the chat, or explicitly requested. Use <knowledge_dir>/.workflow/templates/handoff.md as a reference template. Do not write into another member's workspace.
<knowledge_dir>/product/ when user-facing behavior changes.<knowledge_dir>/user-stories/ when implementation changes accepted user stories, use cases, scenarios, journeys, or acceptance intent.<knowledge_dir>/design/ when UI design, component behavior, layout, interaction states, or visual rules change.<knowledge_dir>/architecture/ when module boundaries, APIs, data flow, integration behavior, configuration, or operational constraints change.<knowledge_dir>/decisions/ when a lasting product or technical tradeoff is made.<knowledge_dir>/test-cases/ when reusable validation intent, manual checks, acceptance cases, regression cases, or exploratory test cases change.<knowledge_dir>/metrics/ when metric definitions, targets, thresholds, sources, or interpretation rules change.<knowledge_dir>/experiments/ when hypotheses, rollout probes, guardrails, experiment results, or follow-up experiment decisions change.<knowledge_dir>/releases/ when release scope, validation evidence, rollout, rollback, release notes, or post-release follow-up changes.<knowledge_dir>/guidelines/ when cross-area writing, terminology, language, documentation, or process guidance changes.references/checklist.md.