close

name	close
description	Close skill — draft resolution comment, sync backends, redirect to next task

Close

Close a task: draft a resolution comment, optionally sync with each linked backend, set wiki to done, and redirect to next active task.

Arguments

$ARGUMENTS — A task ref or path. Accepts wiki path (wiki/tasks/fix-login-bug.md), an external ref the task is linked to, or a title fragment.

Behavior

Step 1 — Resolve the target

Find the task page from $ARGUMENTS. Read its frontmatter to identify:

• The wiki path
• All backend refs (gh_ref, jira_ref, asana_ref)
• Current status
• The source field (the originating backend; treated as the primary close target unless the user clearly meant a different one)

If status is already done, tell the user and stop.

Step 2 — Draft a resolution comment

Read the task page — especially the ## Activity log, body description, and any solution-shaped sections — and draft a concise closing comment:

• 2–4 sentences or short bullets
• Summarize what was done and how
• Skip implementation noise; future readers want the why and the outcome

Show the draft and ask: "Use this comment, edit it, or write your own?" The user can override; a closing comment is always posted (at minimum a one-liner) — skipping is not an option.

Step 3 — Show the close preview

Show a structured preview before any external write:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CLOSE PREVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Task:        [[<task title>]]
Wiki status: <current> → done
Wiki closed: <today>
Primary:     <backend> — transition to done + post comment

Comment:
> <first 200 chars of comment>...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Confirm? (yes / no / edit)

Nothing is written until the user says yes.

Step 4 — Close the wiki page

Run via Bash (this updates wiki status, closed date, daily page, and wiki/log.md atomically):

rubber-ducky task close <wiki-path>

Step 5 — Transition + comment in primary backend

Run /transition (or its underlying CLI) to set the external status to done — the CLI path is gated by the confirm-token flow:

TOKEN=$(rubber-ducky --no-json confirm request \
  --action <backend>.transition \
  --preview "<preview-text>")
rubber-ducky --json transition <wiki-path> \
  --backend <backend> \
  --to done \
  --confirm-token "$TOKEN"

Then post the closing comment via /comment (same confirm-token gate, with --action <backend>.comment).

If the primary transition fails before the wiki close, do not update the wiki — the user should know the external system is still open.

Step 6 — Offer to close linked backends

If the task has additional backend refs beyond the primary, ask separately for each:

This task also has a linked <backend>: <ref>
Close that too? (yes / no)

On yes:

Use the same closing comment, or draft a new one? (same / new)

• same → post the same comment, transition to done.
• new → draft a fresh comment, show it for approval, then post + transition.

If a linked-backend close fails, warn the user but don't reverse the primary close.

Step 7 — Redirect to next active task

Look for an obvious next task: other in-progress tasks on today's daily page; active_task on a current-status file if one exists; an ASAP item. If something obvious comes up, suggest it ("Ready to get back to ?"). Otherwise ask what to work on next.

Step 8 — Confirm

Report:

Closed: <task title>
Wiki:    done
<Backend>: <ref> transitioned to done, comment posted

Plus any additional linked-backend results from Step 6.

Rules

• Nothing is written externally until the user confirms.
• A closing comment is always posted (the user can edit it; skipping isn't an option).
• If the primary backend transition fails before the wiki close, do not update the wiki.
• closed: is today's date. If the user wants to backdate, they edit frontmatter directly.