Take a vague idea all the way to a merged PR

An afternoon · 10 steps

The worked example adds CSV export to an app, but any small feature fits. Each step uses a different strength: Pocock for shaping and slicing, pstack for design and adversarial checks, Addy for the launch checklist.

Before you start

• A repo with tests you can run
• The addy, pocock and pstack plugins installed
• New to the hub? Install the plugins first.

1. 1

   Set the repo up once

   /pocock:setup-matt-pocock-skills

   Several Pocock skills publish to an issue tracker, or to local files if you have none. This records which one this repo uses, so the later steps know where to write.

   /pocock:setup-matt-pocock-skills Copy

   Done when: The agent has written down your tracker and labels. Skip this step in any repo where it has already run.

2. 2

   Get interviewed about the idea

   /pocock:grill-me

   The agent questions you until the plan holds up. Decisions you had not noticed you were making come out here, while they are still cheap to change.

   /pocock:grill-me I want users to export their data as CSV. Copy

   Done when: You can state who it is for, what is out of scope, and what happens on the awkward cases, such as very large exports.

3. 3

   Turn the conversation into a spec

   /pocock:to-spec

   No further interview: it synthesizes what you just discussed and publishes it to your tracker, so the decisions outlive this chat.

   /pocock:to-spec Copy

   Done when: The spec reads correctly to you. Fix it now if it does not.

4. 4

   Sketch the shape before any code

   /pstack:architect

   Types, signatures and module boundaries come first. Changing a signature here costs a sentence; changing it after implementation costs a rewrite.

   /pstack:architect Sketch the types and module structure for the CSV export spec. Copy

   Done when: You have read the signatures and would be happy to build against them.

5. 5

   Slice it into tickets

   /pocock:to-tickets

   Produces tracer-bullet tickets: thin vertical slices that each declare what blocks them, so the order of work is explicit.

   /pocock:to-tickets Copy

   Done when: Each ticket can be finished and checked on its own, and the blocking order makes sense.

6. 6

   Implement a ticket

   /pocock:implement

   Works test-first where it can, runs typechecks and tests as it goes, reviews its own work, and commits to the current branch. Repeat this for each ticket.

   /pocock:implement <ticket reference> Copy

   Done when: The tests pass and the commit covers only that ticket.

7. 7

   Look beyond the diff

   /pstack:blast-radius

   A review of the diff only sees what changed. This looks for what the change could break elsewhere, and proves the key safety claim by running real code.

   /pstack:blast-radius of the CSV export branch Copy

   Done when: You have the list of risks, and the fact that makes the change safe has been shown by a run.

8. 8

   Try to break it

   /pstack:interrogate

   Adversaries attack the change, and only findings proven by a run survive, so you get real problems rather than a list of maybes. Fix what it finds.

   /pstack:interrogate this branch Copy

   Done when: Every surviving finding is fixed or consciously accepted.

9. 9

   Check you are ready to release

   /addy:shipping-and-launch

   A pre-launch checklist covering monitoring, staged rollout and rollback. This is the step most easily skipped when a feature feels finished.

   /addy:shipping-and-launch for the CSV export Copy

   Done when: You know how you would notice a problem and how you would undo the release.

10. 10

    Write the PR

    /pocock:pr

    Writes the PR body. Review what it says before the PR goes out.

    /pocock:pr Copy

    Done when: A reviewer could understand the change from the description alone.

← All tutorials Next: run skills in loops →