improve-feature

Improve Feature

Use this workflow when the target is a Switchboard feature (a container of subtask plans), not a single plan. Its job is to make the subtask set coherent: improve every subtask, detect inconsistencies between them, and then restructure — merge overlapping plans, delete superseded ones, rewrite contradictory ones, split oversized ones.

Detect a feature when the target file is under .switchboard/features/, or contains an auto-generated <!-- BEGIN SUBTASKS ... --> / <!-- END SUBTASKS --> block. If the target is a single plan, use improve-plan instead.

Why this is a separate skill

improve-plan is deliberately non-destructive ("never delete content; only update the plan document") because for a single plan that is correct. For a feature it is the opposite of the job — the highest-value action is exactly the thing improve-plan forbids: recognising that two plans are one, that a plan is obsolete, or that a contradiction means one plan gets rewritten. This skill is authorised to cut. Invoking it is the sign-off to restructure the subtask set; there is no per-run confirmation gate.

Guardrails (different from improve-plan, not fewer)

Restructuring is expected — but bounded:

• Preserve information, not files. Every requirement, edge case, and root-cause note from a plan you delete or merge MUST survive in its target plan. The unit of preservation is the union of intent across the set, never each individual .md.
• Git is the undo. Commit before any destructive op (delete/merge) so it is trivially reversible. Deletion of a plan file on a branch is cheap — it is a working document, not shipped user data. Do not treat it with production-data caution.
• Never hand-edit the auto-generated subtasks block (<!-- BEGIN/END SUBTASKS -->) — Switchboard regenerates it from the DB.
• Route set changes through the real mechanisms, not the block:
  • Remote (no extension): git rm the removed subtask .md files (the plan watcher hard-deletes their rows on the next local pull), create any new consolidated plan file (do NOT write a **Plan ID:** line — it is never read; the importer assigns the ID and keys by file path), and add a **Feature:** <feature-plan-id> line to the new plan file's frontmatter (the feature's UUID, taken from its feature-<uuid>.md filename; applied on import with apply-if-empty semantics). For column moves, you MUST move newly created cards to PLAN REVIEWED using the session-appropriate mechanism:
    • Local (extension or standalone host running): Use the kanban_operations skill (move-card.js) or CLI (switchboard api POST /kanban/move) to move the card to PLAN REVIEWED.
    • Remote (no extension): Use the Notion/Linear provider or MCP to move the card to PLAN REVIEWED. In-place rewrites keep their existing column.
  • Local (extension running): use assign-to-feature.js / the feature's create path for card-set changes.
• Report the restructure — what merged into what, what was deleted, what survived — so the diff is legible. End with the reconciled subtask list.