Implement One Agreed Ticket

What it does

The source deliberately keeps this workflow short: retrieve the requested issue, identify its title and resolve ambiguity before editing. Implementation then follows test-driven development at previously agreed seams. Type checking and single-file tests provide feedback during the change; the full suite runs at the end. A code review closes the loop before committing on the current branch. The value lies in finishing a bounded ticket against an existing agreement rather than inventing a new planning framework.

When to use it

• Implement a ready ticket with explicit acceptance behavior.
• Finish one dependency-unblocked slice from a larger specification.
• Apply an agreed fix while keeping the public test boundary stable.

Step-by-step workflow

1. Resolve the ticket reference and state the title to confirm the intended task.
2. Read acceptance criteria, project standards and the agreed test seams.
3. Build one observable behavior at a time with the collection’s TDD workflow.
4. Run relevant type checks and focused tests during work, then the full suite.
5. Review the final diff against standards and the ticket before the authorized commit.

Example request

Use implement for the ticket titled Reject duplicate invoice imports. Confirm the issue before editing. Preserve the agreed importer API test seam: importing the same invoice twice must create one invoice and return the existing identifier. Cover malformed input and storage failure without calling the live payment service. Run focused checks during development, then the complete project checks. Review the diff; commit only within the repository’s established authorization.

Worked example

For duplicate invoice imports, the first test can exercise the public import operation twice with the same input. The implementation should make the second result observable through that operation, avoiding tests tied to private helper names. If the ticket does not define whether a corrected invoice counts as a duplicate, that ambiguity must be resolved before choosing behavior. The final review compares the diff with the issue and confirms unrelated payment changes did not enter the patch.

What you get

A tested, reviewed ticket implementation and, where authorized, a commit on the current branch.

How to evaluate the result

• Confirm the retrieved title matches the requested ticket.
• Check acceptance behavior and failure cases through agreed seams.
• Record the full-suite outcome and review any remaining failures.

What you need

A specific ticket, agreed acceptance behavior and test seams, working project checks, plus access to companion TDD and review skills.

Setup and activation

The publisher documents plugin setup for Claude Code, Codex and Copilot, and manual Agent Skills setup for Gemini CLI and other clients. Choose one distribution method per client to avoid duplicate skills. The engineering collection expects project-specific tracker, triage-label and document-location settings from setup-matt-pocock-skills. Keep referenced companion skills and files available. This catalogue review does not install or run them; scan the exact source before any later installation. Client tools, permissions and subagent support still need separate validation.

Limits and considerations

This is not a substitute for unresolved requirements or a multi-ticket orchestrator. The upstream flow includes a commit, so branch state and write authorization must be understood. Passing a focused test alone does not establish full-suite success.

Related workflows

• Use to-tickets to prepare bounded work.
• Use pr to describe the resulting change for reviewers.

License and reuse

MIT at repository level (Copyright 2026 Matt Pocock). Preserve the copyright and permission notice when redistributing substantial source material; inspect any separately licensed dependencies or assets.

Further reading

• Reviewed SKILL.md (immutable commit)
• Publisher README: setup and compatibility
• Reviewed MIT license