Task workflow skills
Refine, Plan, Act, Consolidate
The Task workflow skills are a set of utilities that support any developer through a standard development task, from fetching the ticket to handing the finished code over to review.
They are based on the RPAC pattern: Refine, Plan, Act, Consolidate. Misunderstandings surface in a reviewable document before any code is written, and a failed attempt costs a retry from the last file, not the whole task.
Each phase runs in a fresh session and hands over a file, not chat history, so the context stays sharp.
Start from the ticket
fetch-ticket
Every task starts with a ticket. This skill downloads it from Jira, GitHub, Azure DevOps or similar into a self-contained TICKET.md, attachments and linked tickets included. No tracker? Write the file by hand and the workflow stays the same. An attachment it can't download gets flagged, so you can add it with /attach-to-ticket.
attach-to-ticket
Some attachments never make it through the fetch: a screenshot from a chat, a file behind a login. Paste it, or give its path or link, and the agent saves it next to TICKET.md and adds it to the ticket file with a short caption, so the next session sees it too. It asks before filling a missing attachment or writing a caption. It only touches your local files: your tracker stays untouched.
Agree on what to build
refine-ticket
Defines the WHAT. The agent checks the ticket against the actual codebase and interviews you, one question at a time, each with a recommended answer. No silent assumptions: you decide. The result is a validated REQUIREMENTS.md. No ticket yet? Give it a raw idea and it grills you on the goal and the scope first.
Decide how to build it
create-implementation-plan
Defines the HOW. The agent studies the code, settles the technical decisions with you and writes a self-contained PLAN.md that a fresh session can execute step by step.
harden-artifact
An optional check between a document and the phase that builds on it. Run it on a REQUIREMENTS.md or a PLAN.md in a fresh session, not the one that wrote it: a sub-agent with a clean context checks it against the ticket, the code and the related tickets, and your session tries to disprove each finding. You decide the ones that survive, one at a time, each with a recommendation: fix, dismiss or defer. When the document is ready, you get the commands that start the next phase. /refine-ticket and /create-implementation-plan both offer it when they finish.
split-plan-tasks
A plan that lands in one sweep is hard to review. Give this skill the PLAN.md and it splits the steps into small tasks, each one leaving the project building and its tests passing, grouped into PR-sized batches. The first batch gives you something to click or run as early as the plan allows. You approve the breakdown, then it appends the task list to the plan, with a done check and a suggested commit subject per task. The plan's own text stays as it was.
Build it
Run the whole plan with a plain prompt, or one task at a time when you split it.
Execute the plan
Running the whole plan needs no skill at all. Open a fresh session and ask the agent to execute the plan: everything it needs is in PLAN.md. Ask it to run your project's checks too, so it verifies its own work.
execute-plan-tasks
Split the plan into tasks? Then run this instead, one task per fresh session. It implements that task and nothing beyond it, runs the task's done check and your project's checks, ticks the task off in PLAN.md and stops, so you review and commit before the next one. A deviation from the plan it had to settle on the way goes into a DECISIONS.md next to the plan, with its why. Every run ends with the command for the next task, and tells you when a group is complete and ready to become a PR. It never commits or pushes.
Review and hand over
fresh-eyes-review
First step of Consolidate: before handing over, let a sub-agent with a clean context review the changeset. It catches what the session that wrote the code misses.
handover
Closes the task. Give it a ticket id, or nothing at all, and it finds the task's planning files, gathers the decisions made along the way, from the ticket to the session itself, matches the plan against the actual diff and writes a HANDOVER.md: a paste-ready PR description with the decisions worth knowing, where to look and what's still open, so reviewers never reconstruct intent from the diff. Your repo has a PR template? It fills that in instead, ticking only the boxes it can back up.
Extra workflow skills
Not part of the main flow, but handy when the task calls for them.
create-manual-test-instructions
Turns a ticket or its requirements into a concise MANUAL-TEST.md a non-author can follow: what changed, how to get there, before vs after, and what to verify.
review-ticket
A triage glance before anyone picks a ticket up: compares it against the codebase and reports whether it's ready, plus the questions worth asking whoever owns the requirements. Each question survived an adversarial hunt for its answer across code, tracker, designs and docs, so you're never asked what the sources could have answered. A gap that is another team's or another repo's to fix comes back as a handoff, with a message ready to send to its owner. Verdict and briefing land in a TICKET-REVIEW.md next to the ticket, and /refine-ticket picks it up later, starting from whether those questions got an answer.
verify-understanding
The other skills write files for the next agent session. This one is for you. Run it on the TICKET-REVIEW.md, right after the review or days later just before you start coding. It asks you to explain the feature in your own words: who uses it, what they see and do, why it exists, and what each ticket adds. Then it digs into one weak spot at a time and corrects you using only the review and the tickets, saying so when they don't settle something instead of making up an answer. It plays the part of that last chat with your product owner before development starts. It writes no files: the conversation is the point.
check-ticket-implementation
Answers one question: how much of this ticket is already built? It splits the ticket into individual requirements and judges each one against the code, so the verdict lands per requirement instead of on the ticket as a whole: done, partially done, not done, or not verifiable from the code, each with a short note and the file:line where it was checked.
The report goes into a TICKET-STATUS.md, headed by the tally and the requirements that need attention. Useful when you pick up a branch someone else started, or before you call a ticket finished. Give it a ticket link and it fetches the ticket first. Apart from that, the report is the only file it writes: your code and the ticket stay untouched.
grill-me
The interview that refine-ticket and create-implementation-plan run, on its own. Bring any plan, design or idea and say grill me: the agent asks one question at a time, each with its recommended answer, until every branch is settled. What the code can answer, it looks up instead of asking you. Want a REQUIREMENTS.md at the end? Use refine-ticket instead.
This skill was originally created by Matt Pocock. We made it available in this toolkit with one small edit: it words its questions with /explain-in-simple-language, so they are easy to follow.
prepare-prompt
Every phase above ends with a ready command for the next session. For anything else there's this skill: when a fresh session should continue the work, check it, or pick up what was left open, it writes the prompt to paste there. It keeps only what the next session can't find on its own, points at files instead of pasting them, and checks every path and command it prints. Asking a new session to check the work? It leaves out its own conclusions, so they can't steer the check.
plans-directory
Opt-in rule for where planning documents go: one folder per task in the project's planning
directory, with file names that say what each file is. The default is
.agents/plans/, so every planning file the demos on this page save, like
1234-users.TICKET.md or 1234-users.HANDOVER.md, lands in
.agents/plans/1234-users/. Most skills on this page already save their
files this way, and with the rule installed, /fetch-ticket no longer has
to ask you where your plans live. The agent also follows it for any other planning document
it writes, like a design note or an investigation. If your project already has a planning
directory of its own, that one wins.
./install-opinionated-rules.sh
installs it along with all the other rules, or you can pick only the ones you want.