Reusable agent skills distilled from production software-engineering work. The skills are small, focused, and designed to work across different projects and coding agents.
Turn the dependency graph written by to-tickets into an implementation run. The
skill reads every ticket and its blockers, calculates which tickets are ready, and
launches one fresh subagent for each ready ticket. Each subagent receives a
self-contained mandate — claim the ticket, work test-first, typecheck and test as it
goes, review its own diff, commit, and record the outcome on the ticket — so the run
depends on no skill it might be unable to invoke.
Independent tickets run concurrently in isolated Git worktrees, up to the parallelism limit defined by the user, repository, and host agent. Tickets with unresolved blockers wait. When a subagent finishes, the skill collects its verified commit, integrates successful commits serially, verifies their combined state, and only then releases the next group of tickets.
For example, given this graph:
A ──┬──> B ──┐
└──> C ──┴──> D
the skill runs the tickets in three rounds:
- Implement A in one subagent.
- After A integrates and passes verification, implement B and C in parallel subagents.
- After both B and C integrate and pass verification, implement D.
Each ticket has exactly one writer: the subagent that implements it claims it, records its acceptance criteria, and marks its outcome. The orchestrator only reads the ticket system and introduces no status convention of its own. After each round it rereads the tracker and recomputes the executable frontier instead of assuming that the graph is unchanged. Merge or verification failures keep downstream work blocked.
Use implement-ticket-graph when an implementation effort contains multiple tickets
with blocking relationships and the project already defines its ticket-tracker
workflow.
npx skills@latest add asterixcapri/skills --skill implement-ticket-graphMatt Pocock skills:
setup-matt-pocock-skillswrites thedocs/agents/issue-tracker.mdanddocs/agents/triage-labels.mdthis skill reads the tracker through.to-ticketsproduces the dependency graph consumed by this skill.tddandcode-revieware named in each subagent's mandate. Neither is required: the mandate states the same work in plain terms for a subagent that cannot invoke them.
Turn decisions made during implementation, review, or design work into durable project guidance. The skill separates project-wide rules from local fixes, already-documented guidance, and patterns that are not mature enough to adopt. It proposes documentation changes first and applies them only after explicit approval.
Use to-docs when recent work has surfaced decisions that may deserve a place
in project documentation, especially:
- after implementing or reviewing a feature that introduced a reusable pattern;
- after a design discussion resolved conventions, boundaries, or exceptions;
- before adding lessons from a specific bug or route to
AGENTS.md, coding standards, architectural guidance, or other project-wide documentation; - when existing guidance may need refinement rather than another overlapping rule.
Applied repeatedly, to-docs improves the repository-level coding-agent
harness: the instructions and documentation that steer the agent's behavior. It
strengthens context engineering by turning decisions from real work into
consistent, discoverable guidance, keeping the agent aligned with project
conventions while preventing contradictory or overly specific rules from
accumulating.
The skill is most valuable when the difficult question is not how to write the documentation, but whether a decision is durable and general enough to document at all.
npx skills@latest add asterixcapri/skills --skill to-docsMatt Pocock skill:
writing-for-agentswrites the approved documentation changes.
The counterpart of to-docs for the skills themselves. Where to-docs asks
whether a decision deserves a place in this project's documentation,
to-skills asks whether a behaviour observed during a session should change
the skills that steer the agent in every project. The two split the same
material along ownership: a rule that holds because of this repository's
conventions is documentation, a procedure that holds in a repository you have
never seen is a skill.
The skill works from observed failure rather than from good intentions. A change earns its place when the agent ran under a given skill and the work still went wrong, or when the skill never entered the run at all. It then locates which of three surfaces failed:
- invocation — the description fired on work the skill does not handle, or stayed silent on work it does;
- execution — the agent read the skill, followed it, and still chose wrong;
- absence — no skill owned the procedure, and the agent reinvented it.
Skills installed as dependencies are never edited in place, because the next install overwrites them: the outcome for those is an upstream patch or an owned skill that covers the gap. Proposals prefer sharpening or replacing text over appending it, since every line added to a skill is paid on every invocation, in every project that installs it.
Use to-skills after a session where a skill misfired, failed to fire, or was
followed to a wrong result, and when a procedure that keeps recurring across
projects has no skill to own it.
npx skills@latest add asterixcapri/skills --skill to-skillsMatt Pocock skill:
writing-for-agentswrites the approved skill changes.
This repository's to-docs receives the decisions to-skills rejects as
project-specific.
List the skills published by this repository without installing them:
npx skills@latest add asterixcapri/skills --list