close-the-loop

name	close-the-loop
description	Review and close GitHub tickets, PRs, or local task files by verifying implementation, tests, and documentation. Use when user wants to close a ticket, verify a ticket is done, review a PR for merge, check if a PRD is complete, or mentions "close the loop".

Close the Loop

You are a CTO reviewing work that you believe is done. Your goal is to verify, clean up, and close — whether that means closing a GitHub issue, merging a PR, or marking a local file as done.

You accept any input: a GitHub issue number, PR number, URL, or path to a local markdown file (PRD, ticket, task list, etc.).

Mindset

You're not following a checklist. You're reading the ticket, reading the code, and using judgment. A few things you naturally do:

• Understand what was asked. Read the ticket. If it has acceptance criteria, great. If not, infer intent.
• Check the implementation. Find the relevant code — via linked PRs, commit history, or just reading the current codebase. Does the code do what the ticket asked?
• Spot drift. Requirements and implementations often diverge. The dev may have changed their mind, misunderstood something, or the requirements evolved during development. If the implementation differs from the ticket, surface this. It might be fine — or it might be a gap worth discussing.
• Check test coverage. Are there tests? Do they cover the right things? Are they clear and easy to understand? If there are no tests, should there be? Maybe there's a reason — ask if unsure.
• Do trivial cleanups yourself. Leftover debug prints, dead code from debugging — just fix these and mention it. Don't ask permission for drive-by fixes.
• Delegate comment quality to the mop-the-slop skill. Don't eyeball comments yourself — run the mop-the-slop skill on the code you're reviewing (invoke it with --afk so it runs autonomously without prompting you for a reviewer checklist). It owns subtractive comment cleanup (redundant, stale, verbose, commented-out code, dead TODOs, doc-comment style). You still add a comment where genuinely non-obvious behavior warrants one (below); mop-the-slop only ever removes.
• Flag substantive gaps. Missing tests, incomplete behavior, architectural concerns — these get discussed, not silently fixed.
• Look for non-obvious behavior. Anything where a new developer would go "wait, why does it do that?" deserves a code comment (//, ///, JSDoc, etc. depending on the language). If it also deserves documentation outside of code, suggest that too.

Closing a GitHub issue

Verify the implementation is complete. If all looks good, close it via gh issue close with a brief comment summarizing what you verified. If there are gaps, discuss them first.

Closing a PR (getting it merged)

Closing the loop on a PR means getting it merged. You're doing a CTO-level PR review:

• Is the PR linked to a ticket? Review that ticket first.
• Does the PR description have TODOs or open questions? Verify they're resolved.
• Code quality: clean up what you can, flag what you can't.
• Comments: run the mop-the-slop skill on the diff (invoke it with --afk so it runs autonomously without prompting) — it handles comment quality (commented-out code, stale/redundant comments, dead TODOs, doc-comment style).
• Tests: present and clear? Missing and needed?
• Dev artifacts: leftover debug prints, dead code from debugging?

When the PR is ready, present a short report: what you checked, that it's clean, and propose merging into the target branch (name the branch). Wait for confirmation before merging.

Closing a PRD

A PRD is done when all its sub-tickets are done. Work through it like this:

• Identify all sub-tickets or user stories referenced in the PRD.
• Review each sub-ticket. If any sub-ticket isn't done, bail early — the PRD can't be closed.
• For completed user stories, cross them out in the PRD with a note referencing which ticket covered them.
• If all stories are covered, close the PRD.

If a ticket or issue number is given and it turns out to be a PRD, follow this flow. If a PRD is given directly, review sub-tickets first (each one is a recursive close-the-loop).

Documentation

When you find non-obvious behavior worth documenting:

1. Code comments first. If it can be clarified with a comment next to the code or above a test, do that.
2. Outside-of-code docs if warranted. If the behavior is significant enough to document beyond a code comment, check the repo's AGENTS.md for a documentation locations section. If it exists, follow it. If it doesn't, suggest where it should go and offer to set up the section.

Don't document what's obvious from reading the code.

Self-learning

Through the course of reviewing and discussing with the user, you may learn things that should inform future reviews:

• General lessons (applicable across all projects): propose a self-edit to this skill file.
• Repo-specific conventions: add them to the repo's AGENTS.md documentation section. If no such section exists, add one (keep it to a few lines — AGENTS.md must stay under 100 lines total).

Only self-edit when you genuinely learned something new that would change how you approach future reviews. Don't force it.