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.

2026-06-032

knowledge-capture

choral-io/choral-skills

Use when the user has approved a specific shared-knowledge write, promotion, reorganization, or update.

2026-06-032

name	kanban-maintenance
description	Use when the user has approved adding, moving, or updating cards on the repository Kanban board.

Kanban Maintenance

Runtime Context

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 apply approved changes to <knowledge_dir>/planning/KANBAN.md.

Preconditions

A maintainer has explicitly approved the Kanban change.
The proposed card links to project knowledge or a task item.
The card is not a duplicate of an active card.

Workflow

Read <knowledge_dir>/.workflow/rules/delivery.md.
Open <knowledge_dir>/planning/KANBAN.md.
Resolve card wikilinks to task items by task id or file basename.
Check the requested transition against the Move Matrix in references/cards.md.
Apply only the approved board changes.
Keep cards thin and linked.
Preserve the column order.
For Reviewing -> Done, report whether dependency follow-up was approved, deferred, or not applicable.
For new accepted tasks with planned dependencies, place cards in Backlog unless the approved dry run explicitly selects Ready.
Report exact cards moved, added, changed, or removed.

Guardrails

Do not edit unrelated cards.
Do not use localized files as card sources.
Do not duplicate acceptance criteria or long discussion in the board.
Stop and report ambiguity if a card link can match multiple canonical files.
When moving a card to Blocked, keep the board card thin and ensure blocker details live in the linked task item.
Do not move a new dependent task to Blocked only because it has blocked_by; use Backlog plus task readiness metadata until the work was expected to proceed.
Move out of Blocked only to the approved next state: Ready when no one is actively handling it, Doing when the current handler is continuing it, or Backlog when it still needs refinement.
Do not move Reviewing -> Done while known dependency follow-up is unresolved unless the maintainer explicitly defers it.
Stop if the requested change conflicts with the Kanban workflow.

References

For card and column examples, read references/cards.md.