New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets

Matt Pocock · video · 2026-07-08 source ↗ Reader 🖥️

Agent Planning Artifacts Agent Skills Code Quality Context Rot & Context Limits Human-in-the-Loop Progressive Disclosure Spec-Driven Development

Agent-assisted software work is best handled not as ad-hoc prompting but as an explicit, skill-mediated development lifecycle — interactively grill the human into a spec, split the spec into tickets each scoped to a single agent session, implement, then code-review for refactoring smells — fronted by a dedicated planning phase (Wayfinder) that externalizes large, foggy plans onto the shared issue tracker so they survive beyond any one context window, with research, prototyping and TDD as first-class supporting stages.

practical · product release walkthrough / changelog screencast — a ~14-minute narrated demo of a v1.1 bump to the author's open-source agent-skills library, part show-and-tell, part opinionated workflow argument — This is a changelog, a weak analytical-reading target: much of it is version-specific release notes (renames, install commands, bug fixes) that will be stale within weeks and whose real detail lives in the GitHub repo, not the video. The durable, transferable content is the set of workflow patterns the release demonstrates — staging agent work as an explicit spec->tickets->implement lifecycle, fronting it with a dedicated planning phase, reviewing for refactoring smells, and designing skills to be thin and AFK-usable. The extraction favours those patterns over the ephemeral specifics.

Structure

Part	Role
Intro + merge: shipping v1.1	Frames the video as a walkthrough of a version bump to a widely-used skills library, merging the release PR live
The two renames: /to-PRD -> /to-spec and /to-issues -> /to-tickets	Argues the renamed flow skills now name their artifacts correctly: a specification (broad, technical or not) is the destination; tickets (vendor-neutral vs GitHub/Linear 'issues') are the journey that enacts it
Grilling-skill fixes	Sharpens the shared grilling reference: ask one question at a time (with the why), a confirmation gate before enacting, and a facts-vs-decisions distinction so the agent stops grilling itself
The complete flow + the /implement skill	Answers the recurring 'what is the main flow?' question: grill -> spec -> tickets -> implement (one ticket per session) -> code review -> commit; the implement skill is deliberately minimal, leaning on the agent's priors and the harness
The /code-review skill + Fowler's refactoring smells	Two parallel sub-agent axes (standards conformance vs faithful spec implementation) plus a new, cheap layer that invokes Martin Fowler's named code smells to make the agent find and fix them
Wayfinder: the new pre-spec planning skill	For work too big for one agent session and 'wrapped in fog', charts the route as a shared map of typed, blocking, session-sized sub-issues on the repo's issue tracker, worked one at a time until clear, then turned into a spec
Supporting skills: /research and /prototype	Small skills Wayfinder can invoke — background-agent research writing findings to the repo's notes, and logic-or-UI prototypes to raise decision fidelity before a spec exists
TDD-skill change + migration guidance + course plug	TDD skill becomes reference-material-only (usable AFK), keeping red-before-green ordering but moving refactoring out of the loop into code review; migration via re-adding skills; a plug for an AI-coding course planned with Wayfinder

Key terms

flow skills
The sequence of skills that together form the intended end-to-end development flow — grill/Wayfinder for planning, /to-spec, /to-tickets, /implement, /code-review, /commit; 'flow' means the main workflow path users should follow, not a psychological flow state. The two 'main flow skills' renamed in this release are /to-spec and /to-tickets.
/to-spec (formerly /to-PRD)
The flow skill that turns grilled understanding into a specification. Renamed off 'PRD' because what it produced was not really a product requirements document but a specification — a broader term for a description of the thing you want to build, which can be technical, non-technical or a blend; the spec 'defines the destination'.
/to-tickets (formerly /to-issues)
The flow skill that decomposes a spec into individual work items. Renamed off 'issues' because that felt biased toward GitHub/Linear; tickets are the units 'underneath the spec', 'the journey you take to enact the spec', each sized so development can be spread across multiple agent sessions.
Wayfinder
A new pre-spec planning skill for a loose idea 'too big for one agent session and wrapped in fog', where the route to the destination isn't yet visible. It charts the way as a shared map on the repo's issue tracker — a GitHub issue whose typed sub-issues (research / grilling / prototype / task) carry blocking relationships and are each scoped to one agent session — worked one at a time until the route is clear, then converted to a spec. Removes the anxiety of hand-offs and 'blowing out of the smart zone', and is collaborative because it lives in GitHub.
grilling
A central reference skill that teaches the LLM how to interrogate the human, used by grill-me and grill-with-docs (and Wayfinder's grilling tickets). It replaces plan mode: the agent asks questions one at a time, distinguishes facts (which it discovers by exploring the codebase) from decisions (which only the user can make), captures rationale in ADRs and a glossary, and gates on explicit human confirmation before enacting the plan.
refactoring smells
Martin Fowler's named code smells (mysterious name, duplicated code, feature envy, data clumps, primitive obsession, repeated switches, divergent change, speculative generality, message chains, middle man). Because Fowler's Refactoring is old and heavily cited, these are 'deep in the agent's priors', so the code-review skill only needs to name each one in a sentence to make the agent identify it, name it back, and fix it.

Propositions

explicitAgent-assisted development should be run as an explicit, staged lifecycle in which each stage is a discrete, named skill — grill/plan, then /to-spec, then /to-tickets, then /implement (one ticket per session), then /code-review, then commit — rather than ad-hoc prompting or a single 'plan mode'; this answers the recurring user question 'what is the main flow?'.conf: high
supportsAddy Osmani’s Post · p4 — Osmani's 'shift from doing to directing — scope the task, define done, calibrate trust, verify' is the principle; this lifecycle is the concrete machinery. Grilling/Wayfinder + /to-spec scope the task, tickets and the spec define 'done', the grilling confirmation gate and AFK-vs-human-decision split calibrate trust, and /code-review verifies — a worked instantiation of directing agents rather than doing the work.
explicitWorkflow artifacts should be named for what they actually are, and in vendor-neutral terms: the skills were renamed from /to-PRD to /to-spec (what they produced was a specification, not a PRD) and from /to-issues to /to-tickets ('issues' felt biased toward GitHub/Linear) — 'good friction because it names it properly'.conf: high
explicitWork should be decomposed into agent-session-sized units: a spec defines the destination, and tickets are the journey — sized so 'you can spread the development out over multiple agent sessions' and implement one ticket per fresh session — so the plan is chunked to fit the agent's effective context rather than to human sprint conventions.conf: high
explicitAn implementation skill should be deliberately thin, leaning on the agent's priors and the harness rather than encoding detailed instructions: /implement is 'very, very simple' ('implement the work described... use TDD where possible at pre-agreed seams, run type-checking and single test files regularly and the full suite once at the end, then code review, then commit') and earns its place mainly by naming and anchoring a stage in the flow, not by adding instruction volume.conf: high
explicitA skill can invoke a model's latent knowledge by naming canonical concepts rather than teaching them: because Fowler's Refactoring is old and heavily cited, its code smells are 'deep in the agent's priors', so describing each smell in one sentence (~10 lines total) is enough to make the agent identify it, repeat the name back, and fix it — 'outrageously useful' and cheap.conf: high
explicitCode review should run as independent concerns in parallel: a standards axis (does the code conform to the repo's documented coding standards) and a spec axis (does the code faithfully implement the originating spec/issue), each a separate sub-agent — and coding standards belong in a separate coding-standards file, kept out of the always-loaded AGENTS.md and pulled in at review time, where they are most useful.conf: high
explicitLarge, foggy work needs a dedicated planning phase, separate from implementation, that externalizes the evolving plan onto a shared, durable tracker: Wayfinder charts a route as a map of typed, blocking, session-sized sub-issues on the repo's issue tracker, worked one at a time until the route is clear and then turned into a spec — which removes the anxiety of managing hand-offs and 'blowing out of the smart zone', and makes the plan collaborative because it lives in GitHub.conf: high
extends11 Tips For AI Coding With Ralph Wiggum · p5 — Same author. Ralph externalizes IMPLEMENTATION state (a committed progress file plus per-feature commits) because agents 'forget everything between tasks'; Wayfinder extends the identical externalization principle to the PLANNING phase and to a shared, durable medium — a GitHub issue map of session-sized typed sub-issues — so a large, foggy plan survives beyond one context window ('blowing out of the smart zone') and becomes collaborative. Note the contrast in who decomposes: Ralph's loop lets the agent pick its own next task, whereas Wayfinder has the human-charted map define the session-sized units up front.
explicitFidelity of a planning discussion is raised most cheaply by building a rough, concrete artifact to react to, before committing to a spec: prototyping (an outline, a rough tech stub, or UI logic via the /prototype skill) should happen in the pre-spec phase — especially for anything touching front-end code — because 'how should it look / how should it behave' is answered better by a concrete artifact than by abstract discussion.conf: high
explicitdevelopedPlanning should use interactive intent elicitation rather than the human writing the plan: instead of plan mode, an agent grills the human one question at a time, explicitly separating facts (which the agent discovers by exploring the code) from decisions (which only the human can make), captures rationale in ADRs and a glossary, and gates on explicit human confirmation before implementing.conf: high
extends ←How I write software with LLMs · p7 — Both require an explicit human confirmation gate before implementation begins and treat the pre-implementation conversation as where facts/decisions get negotiated; this article shows the same discipline enforced by prompt instruction and a magic word ('approved') rather than by a dedicated harness skill.
explicitSkills should be designed to work AFK (usable by an away-from-keyboard agent without step-by-step human confirmation): the TDD skill was converted to reference-material-only, dropping its prescribed interactive steps and keeping just the ordering discipline (red before green, one slice at a time), and refactoring was moved out of the red-green loop into the code-review stage so implementation isn't overloaded.conf: high
implicitdevelopedCodifying agent workflows into reusable, installable, versioned skills is a better unit for distributing engineering practice than ad-hoc prompting — the load-bearing premise behind shipping a versioned skills library at all.conf: medium
extends ←Lessons from building Claude Code: How we use skills · p14 — Wayfinder's proposition frames codified, versioned skills as a better distribution unit for engineering practice than ad-hoc prompting; this doc adds an important caveat that same optimistic framing omits — skill-to-skill composition and dependency management is still informal and unmanaged, a real limitation on 'skills as a distribution unit.'

Arguments

Agent-assisted development should be structured as an explicit, skill-mediated lifecycle — a dedicated planning phase (Wayfinder), then grill -> spec -> tickets -> implement -> code-review-for-smells -> commit — rather than ad-hoc prompting or a single plan mode.

Explicit premises:

Users kept asking 'what is the main flow?', i.e. there was no legible end-to-end path from idea to shipped code.
Planning that is too big for one agent session 'blows out of the smart zone' or the context window, so it needs its own externalized, chunked phase.
Agents carry canonical engineering knowledge (e.g. Fowler's code smells) in their priors that a thin skill can evoke by naming.
Naming artifacts correctly (spec, tickets) and staging them as discrete skills makes the workflow legible and re-runnable.

Implicit premises:

Codifying a workflow into reusable, installable skills produces more repeatable, higher-quality outcomes than ad-hoc prompting (asserted, never measured).
Large plans genuinely need a dedicated planning phase distinct from implementation, rather than the agent planning inline as it goes.
A skill's value can come from naming and anchoring a stage even when it adds little instruction — workflow legibility is itself worth a skill.
The author's personal, weeks-long usage generalizes across other users, models and codebases.

Inferences:

If the binding constraint is a legible, context-safe path from idea to shipped code, then discrete skills that stage and externalize the work supply that path.
Therefore the flow, not any single skill, is the product — each skill earns its place by occupying a stage in the lifecycle.

A prompt/skill for a well-known domain should evoke the model's priors by naming canonical concepts, not re-teach them.