How do I install the Submit Review skill?

Run npx skillmds@latest add tmj-90/submit-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Submit Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Submit Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Submit Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Submit Review?

tmj-90 (@tmj-90) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Submit Review by tmj-90 — Agent Skill

Name: Submit Review
Author: tmj-90

Submit Review

Reference for how a finished ticket reaches human review in the Gaffer factory. Submission is RUNNER-OWNED — the agent commits its work and evidences the ACs, then stops; the runner records the delivery, pushes, opens the PR, and submits for review. Invoke when you think your work is ready to hand off, to confirm what you must do (commit + evidence) and what the runner does for you (push, PR, submit).

tmj-90 895dfb0 3.0 KB Updated Sep 17, 2026

File contents

Handing a ticket to review (runner-owned)

You do not submit your own work. In the Gaffer factory the runner — not the agent — owns delivery bookkeeping: after your agent run it runs the gates (tests/lint/hygiene/minimalism), records the delivery, pushes the branch and opens the PR when a remote exists, and moves the ticket to in_review. This makes submission deterministic and token-free, and guarantees a ticket is only ever submitted once its gates are green.

What YOU do (then stop)

Confirm every AC is evidenced. Call get_ticket (Dispatch MCP) and check each AC has true evidence. If any is missing, record it via the record-evidence skill.
Confirm the gates are green in this session: tests (run-tests), lint (run-lint), and any coverage threshold the ticket requires. Fix anything red.
Commit on the feature branch with a clear conventional message referencing the ticket (git add -A && git commit -m "deliver #<n>: <summary>"). An uncommitted edit is NOT a delivery — the branch must carry your commit. If you forget, the runner auto-commits your uncommitted changes as a safety net, but commit yourself.
Stop. Do not push, do not open a PR, do not call submit_ticket_for_review. The runner does all of that. If you cannot finish (open question, missing dependency, failing environment), call mark_ticket_blocked with a clear reason instead of leaving half-done work.

What the RUNNER does (not you)

Runs the Definition-of-Done and hygiene/minimalism gates on your committed diff.
Records the delivery (branch + diff summary + per-repo delivery rows).
Pushes the branch and opens the PR (gh pr create) when the repo has a remote.
Submits the ticket for review (moves it to in_review).

Rules

Never self-approve done or merge — only a human does, after review.
Never push, open a PR, or submit_ticket_for_review yourself — that is the runner's job.
Don't consider yourself done until every AC has real evidence and the gates are green — the runner's gates will bounce a delivery that isn't.

Capture lore

This skill is one of the places durable, reusable knowledge naturally surfaces: A delivery-time gotcha — a non-obvious build/test/landing step or environment quirk that the next agent on this repo will hit. That kind of fact is lore. Capture it via the lore-capture protocol in your brief (CLAUDE.factory.md, step 11 "Memory contribution"): call the Memory MCP suggest_lore once at the close of your work — reusable conventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

---name: submit-reviewdescription: Reference for how a finished ticket reaches human review in the Gaffer factory. Submission is RUNNER-OWNED — the agent commits its work and evidences the ACs, then stops; the runner records the delivery, pushes, opens the PR, and submits for review. Invoke when you think your work is ready to hand off, to confirm what you must do (commit + evidence) and what the runner does for you (push, PR, submit).---# Handing a ticket to review (runner-owned)You do **not** submit your own work. In the Gaffer factory the **runner** — not theagent — owns delivery bookkeeping: after your agent run it runs the gates(tests/lint/hygiene/minimalism), records the delivery, pushes the branch and opens thePR when a remote exists, and moves the ticket to `in_review`. This makes submissiondeterministic and token-free, and guarantees a ticket is only ever submitted once itsgates are green.## What YOU do (then stop)1. **Confirm every AC is evidenced.** Call `get_ticket` (Dispatch MCP) and check each AC has true evidence. If any is missing, record it via the `record-evidence` skill.2. **Confirm the gates are green** in this session: tests (`run-tests`), lint (`run-lint`), and any coverage threshold the ticket requires. Fix anything red.3. **Commit on the feature branch** with a clear conventional message referencing the ticket (`git add -A && git commit -m "deliver #<n>: <summary>"`). An uncommitted edit is NOT a delivery — the branch must carry your commit. If you forget, the runner auto-commits your uncommitted changes as a safety net, but commit yourself.4. **Stop.** Do **not** push, do **not** open a PR, do **not** call `submit_ticket_for_review`. The runner does all of that. If you cannot finish (open question, missing dependency, failing environment), call `mark_ticket_blocked` with a clear reason instead of leaving half-done work.## What the RUNNER does (not you)- Runs the Definition-of-Done and hygiene/minimalism gates on your committed diff.- Records the delivery (branch + diff summary + per-repo delivery rows).- Pushes the branch and opens the PR (`gh pr create`) when the repo has a remote.- Submits the ticket for review (moves it to `in_review`).## Rules- Never self-approve `done` or merge — only a human does, after review.- Never push, open a PR, or `submit_ticket_for_review` yourself — that is the runner's job.- Don't consider yourself done until every AC has real evidence and the gates are green — the runner's gates will bounce a delivery that isn't.## Capture loreThis skill is one of the places durable, reusable knowledge naturally surfaces:**A delivery-time gotcha — a non-obvious build/test/landing step or environment quirk that the next agent on this repo will hit.** That kind of fact is *lore*. Capture it via the **lore-captureprotocol in your brief** (`CLAUDE.factory.md`, step 11 "Memory contribution"):call the Memory MCP `suggest_lore` once at the close of your work — reusableconventions, gotchas, decisions, and boundaries only, never per-ticket trivia.

Frequently asked questions