retro

Files (13)

• .gitignore
• .npmrc
• .vally.yaml
• LICENSE
• README.md
• SKILL.md
• README.md · evals/
• eval.yaml · evals/retro/
• package-lock.json
• package.json
• closeout-safety.md · references/
• skill.test.mjs · test/
• thumbnail.png

SKILL.md (first lines)

# Retro

Turn "I think we're done" into a verified closeout. Reconstruct the user's
requests, finish authorized gaps, learn from corrections, and retire only
session-owned Git work that is demonstrably no longer needed.

Audit by default; use fix mode for active closeout. Do not mistake the user's
belief that work is finished for evidence that it is finished.

## Modes

- `/retro`: inspect and report; no project or skill edits, task
  status writes, Git mutations, review requests, or remote writes.
- `/retro fix`: audit, complete outstanding authorized work, improve used skills,
  and perform proved-safe cleanup only after separate approval.

An explicit current natural-language request to fix outstanding work or update used
skills also selects fix mode. A question about whether the session is done
selects audit mode. Ask only when the intended action is materially ambiguous.

In audit mode, follow the evidence-gathering and reporting steps below, but
only propose the remediation, validation, skill edits, and cleanup in steps
3-5. Do not run commands that write generated artifacts or invoke a sibling
workflow's mutating phases. Report outstanding actions without performing them.

Default to the current session and its explicitly associated repositories,
PRs, agents, branches, and worktrees. A named prior session is allowed only
when the user explicitly selects it. Never audit unrelated sessions or tidy
an entire machine as a side effect.

For a synthetic or scenario-only request, use the supplied facts as scenario
assumptions, not permission to inspect or change live state. Read the skill and
its references as needed, but do not query real repositories, session trackers,
agents, or network services unless the current user explicitly requests live
verification. Describe scenario actions without claiming they were executed.

## Workflow

### 1. Recover the evidence and declare coverage

Use the current conversation, actual tool results, task tracker, and known
agent results first. If earlier turns are compacted or unavailable, use the
host's session-history tool scoped to the exact session ID. Retrieve user
turns, corrections, and relevant results, not merely an assistant summary.
Follow explicit parent/child session links only for work delegated here.

Record which sources were available and whether they were complete. Paginate
within the selected session rather than treating a limited result as full
history. If the session cannot be identified, ask the user which one. If
history access is missing, ask for the missing transcript or task list and
report a partial audit; never claim every request was checked.

Inspect the current repository state and the specific artifacts named by
requests. An old successful check, a task marked done, or an agent's completion
message is a lead to verify, not completion evidence by itself.

### 2. Reconcile every request and correction

Build a compact obligation ledger in host task/session storage in fix mode,
or in working context when storage is unavailable. In audit mode, keep the
ledger in working context without persisting it. Do not print the full ledger
unless the user requests detail. Do not add a tracking file to the user's
repository unless requested. Use these columns internally:

| Request / correction | Source | Acceptance evidence | Status | Next action |
| --- | --- | --- | --- | --- |
| One independently verifiable obligation | Turn, task, or comment identifier | Current artifact and relevant result, or missing evidence | See statuses below | Exact remaining work or none |

Include the initial request, follow-up tasks, negative constraints, wording
and UX corrections, comments the user asked to address, deferred work,
delegated tasks, and promises made by the assistant. Split compound requests
so one completed subtask cannot hide another. Read all pages of associated
PR feedback, including outdated review threads, when PR work is in scope.

Use only these statuses:

- **verified**: the current deliverable meets the request with cited evidence.
- **open**: known remaining work, failed acceptance, or incomplete validation.
- **blocked**: evidence, access, authorization, a decision, or an external
  result is missing; name the blocker and owner.
- **deferred**: the user explicitly chose not to finish it now; cite that choice.
- **superseded**: a later user instruction explicitly replaced or canceled it;
  cite both instructions.

Do not silently drop a correction because code already exists. Do not mark
contradictory requests verified: use the latest clear user instruction or ask
for clarification. Only explicit user direction can defer or cancel work.

### 3. Close authorized gaps and verify the current result

In fix mode, finish open work already authorized by the session request.
Respect newer constraints and existing approval boundaries; a retro does not
authorize new features, deployments, paid calls, commits, pushes, or merges.
Ask before a material scope change or an action needing separate approval.
Do not merely recommend a fix that you can safely make within the scope.

Separate authorization evidence from completion evidence. A missing successful
result means the authorized work is unfinished, not that permission is missing.
In fix mode, name and carry out the concrete edit and focused regression check
when authorized and unblocked; do not invent a new approval blocker. In a
scenario-only request, describe those same concrete actions without performing
them. Keep independently blocked tasks visible and the verdict Incomplete.

Use the original task's established workflow. For PR work, continue the
standard `/pr` workflow; Devy supplements it and never replaces it. Read and
apply [the closeout safety rules](references/closeout-safety.md) before any PR
or cleanup action or assessment: default policy is
`{"copilot":true,"expectedReviewers":[]}`; **only for verified PRIVATE
repositories owned by `jongio`** do not request or wait for Copilot review
(even if a Copilot request is already pending), while posted Copilot feedback,
every other expected reviewer on the current head, required approvals (a
completed `COMMENTED` review counts as review completion, not approval),
passing CI, repository merge rules, merge authorization, and head-pinned merge
(`gh pr merge NUMBER -R OWNER/REPO --match-head-commit FULL_SHA` with one
explicit `--merge`, `--squash`, or `--rebase` method; never raw REST/admin
bypasses) remain mandatory gates.

Run focused acceptance checks against the final edited state. A subsequent
edit invalidates checks covering changed behavior; rerun those checks. Link

From jongio/skills, MIT.

More from jongio/skills