Agile Close Task

Table of Contents

When to use this skill

As soon as implementation is complete and locally verified (build + tests green) — before raising the PR and before requesting review. The task is done as far as the developer is concerned; review is a post-done validation activity, not a step that bookkeeping waits on. Never close bookkeeping after review approves, and never in a follow-up PR/commit once CI has already gone green — either wastes a full CI cycle for a change with no code content.

If a review round turns up a real functional gap that reopens the work, that's an exception to "done" (the implementation genuinely wasn't finished) — fix it as part of that round's own commit and amend * Result=/=* Decisions in the same commit, rather than treating routine review feedback as reopening the task by default.

How to use this skill

  1. Flip the state — task DONE, story table row synced, journal stamped:

    ./projects/ores.compass/compass.sh task done <task-slug>
    
  1. Write the * Result by hand: what shipped, what acceptance was met.
  2. Distill the * Plan into the parent story's * Decisions if it holds durable choices.
  3. Cascade if last task: when no open tasks remain, set the story DONE in story.org and its row in sprint.org — both files in the same commit.
  4. Commit per commit conventions: [agile] Close <task>. This commit is part of what pr-raise pushes when it opens the PR — not a follow-up. Once the PR is open, CI and review run against a branch that already reflects the task as done; when CI goes green post-approval, merge immediately with pr-merge, no further commits.

Recipes

Reference

Emacs 29.3 (Org mode 9.6.15)