Manage a local file-based kanban for software projects worked on with an LLM. Use this skill whenever the user wants to add a feature, work on an existing task, see project status, decide what to do next, or resume work mid-task. Also use it when the user mentions milestones, epics, tasks, "the kanban", "the board", or asks "what's next" / "where were we". Persists context across sessions through Markdown files with YAML front matter, append-only decision logs, and verifiable Definition of Done.
Use this skill whenever you are working on a Go project following the agile-team-v2 workflow — features in .features/, sprints in .sprints/, strategic ADRs in .adrs/, tactical/strategic decisions log in .decisions/, global architecture in .architecture/ (VISION.md + ARCHITECTURE.md + CONVENTIONS.md + INTEGRATIONS.md). The architect absorbs the ex-scaffolder role: scaffolds Go contracts (signatures with `panic("not implemented")` bodies), inlines `// AC: <criterion>` + `// TODO(impl-<feat>, ac-<NNN>)` markers above each scaffolded body, and decides the `mechanical: true|false` flag in FEATURE.md frontmatter. The PM has two passes: passe 1 (FEATURE.md narrative — Why/Context/User journey/Out of scope/Open questions), passe 2 (inline `// SCENARIO:` + `t.Skip("not implemented")` in business test skeletons within `pm_test_territories`, skipped if `mechanical: true`). The sprint-planner lists tasks **by code marker** in SPRINT.md (no separate TASK.md / TASK-red.md / TASK-green.md / SCAFFOLD.md / TASKS.md files — th
Use this skill whenever you need the exact format, lifecycle, or strict rules for the agile-team-v2 code markers — `// AC: <criterion>` + `// TODO(impl-<feature-slug>, ac-<NNN>)` + `panic("not implemented")` (inlined by the architect during scaffolding above each scaffolded function body that maps to an acceptance criterion) and `// SCENARIO: <narrative>` + `// TODO(impl-<feature-slug>, scenario-<NNN>)` + `t.Skip("not implemented")` (inlined by the PM in passe 2 inside business test skeletons under `pm_test_territories`). Covers the strict marker format that `check.sh` enforces (kebab-case feature-slug, three-digit zero-padded NNN, exact `ac-` or `scenario-` prefix), the `pm_test_territories` glob block declared in `.architecture/CONVENTIONS.md` (where `// SCENARIO:` markers may live), the seven-step marker lifecycle (architect scaffolds → PM passe 2 → red → green → e2e-tester → reviewer pass 2 → TODO removed when feature done while `// AC:` stays as permanent record), and the marker-based task lookup procedu
Use this skill whenever you are running as the `red` or `green` agent on an agile-team-v2 task. Covers the discipline-based spec isolation between red and green (no private TASK*.md files exist; the only handoff is committed code/tests), the in-scope vs out-of-scope rules of the red/green pattern (applies to standard and architectural complexity features only — mechanical maintenance is a mono-agent task), the mono-assistant safeguard when one Claude instance must wear both hats sequentially (commit red first, fresh session before reading green-side material — `check.sh` audits this at sprint review), and the marker-based task lookup procedure (grep for `TODO(impl-<slug>, ac-<NNN>)` to locate the scaffolded body and its sibling test file). Loaded only by `red` and `green`. Other agents (architect, PM, sprint-planner, e2e-tester, reviewer, bug-detective) operate outside the live red/green isolation flow and do not need these rules.
Use this skill whenever you create, write, modify, or statue an entry under `.decisions/` or `.adrs/`, or when you need to know the difference between a tactical DECISION and a strategic ADR, the two-zone frontmatter format of DECISION-NNN-*.md (zone author + zone review with `revisit`/`reviewed_by`/`reviewed_at`/`outcome` fields), the R2 strict rules under which green is allowed to author a tactical DECISION (scope=tactical, revisit=true at creation, necessary to unblock current task, DECISION-NNN referenced in code or commit message), or the R6 three-level defence around the `Authored-By:` commit trailer (pre-commit format, CI git-blame ↔ trailer cross-check, reviewer pass DoD sanity check). Also covers the architect's three statuing outcomes (confirm / reformulate / supersede) for tactical DECISIONS surfaced in RETRO.md `decisions_to_statue:` from the previous sprint, and the strategic ADR format. Loaded only by `architect` (writes strategic, statues tactical, both ADRs and DECISIONS), `green` (writes tact
Use this skill when classifying a feature's complexity (mechanical, standard, architectural), when deciding which pipeline shape applies to a given feature, when escalating a task to a higher complexity level during execution, or when reviewing classification accuracy at retro. Triggers on FEATURE.md DoR review, sprint planning, task escalation via dispute or blocker, and RETRO.md classification accuracy sections. The complexity classification is **distinct** from the `mechanical:` flag in FEATURE.md frontmatter — they answer different questions and live under different rules. Complexity drives **pipeline shape** (which phases run); the mechanical flag drives **whether the PM does passe 2** (skipped if true). Both can be set independently. In v2 the agent tier system was simplified — there is one `red` agent and one `green` agent, no per-tier variants — so this skill no longer routes red/green models, only pipeline shape. Consult before setting a complexity field, before deciding whether to skip PM/architect/
Use whenever you need clarifications, decisions, or preferences from the user before proceeding on a task. Instead of asking inline in chat, materialize the questions as a structured QCM markdown file in `.questions/` at the project root. The user answers by editing the file (replacing `[-]` with `[x]` or `[ ]`). Trigger on any ambiguity, missing decision, technical choice, or "should I do A or B" moment — especially during planning, triage, or before sprint kickoff. Do NOT use for trivial confirmations or for questions the project context already answers.
Use this skill whenever you are working on a Go project following this agile workflow — features in .features/, sprints in .sprints/, ADRs in .adrs/, global architecture in .architecture/, per-feature ARCHITECTURE.md written by the Architect, tasks under .features/<slug>/tasks/ with scaffolding-first plus red/green triples (TASK.md shared + TASK-red.md + TASK-green.md), spec isolation between paired teammates, dispute arbitration by the sprint-planner, complexity-based agent assignment (scaffolder, red-opus/sonnet/haiku, green-opus/sonnet/haiku, e2e-tester, reviewer), PM and Architect roles for feature definition, and retro-driven sub-sprints for private-helper test coverage. Triggers: mention of sprint planning, feature breakdown, TASK.md / TASK-red.md / TASK-green.md / SCAFFOLD.md, SPRINT.md, REVIEW.md, RETRO.md, Definition of Ready, Definition of Done, blockers, questions, ADRs with revisit flag, dispute files in .disputes/, any of the sprint-planner/product-manager/architect/scaffolder/red-*/green-*/revie