alexion/ai-artifacts
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add artifact vault contents

Browse Source
This commit is contained in:
alexion
2026-08-01 14:05:09 -04:00
parent 361bde2621
commit 3230f9395b
78 changed files with 6156 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

50
projects/skills/031-slice-skill-map.md Normal file
View File

@@ -0,0 +1,50 @@
---
status: complete
tags:
- wayfinder/map
---
# Slice skill
## Destination
Implement a packaged `slice` skill in the skills repository.
The skill turns a settled plan, spec, conversation, or artifact into Wayfinder task tickets for tracer-bullet implementation slices.
## Notes
The skill name is `slice`.
The repository source lives under `skills/slice/`.
Runtime enablement in dotfiles or another consumer repository is out of scope.
The skill should produce Wayfinder-compatible `ticket/task/afk` and `ticket/task/human` artifacts in the resolved AI-artifacts project destination, using that destination's naming and wikilink conventions.
The user's invocation is sufficient permission to slice the provided source material.
Implementation slices are destination work, not Wayfinder decision tickets.
The skill should not create `.claude/tasks/` files.
Task-ticket bodies should include implementation-oriented sections such as `## What to build`, `## Acceptance criteria`, and `## Implementation Notes` when useful.
`## Implementation Notes` may contain concise handoff guidance from slicing and later execution notes from the implementing agent.
## Frontier
None.
## Decisions so far
Preserve the old `to-tasks` source-intake, optional codebase exploration, tracer-bullet slicing, prefactoring-first bias, review loop, blockers, acceptance criteria, and anti-stale-detail guidance, but replace `.claude/tasks` output, feature-slug metadata, four-digit numbering, filename-stem blockers, and legacy completion semantics with Wayfinder artifacts.
Preserve Matt Pocock's explicit invocation, broad source intake, tracer-bullet discipline, blocker and frontier model, review loop, useful issue-body semantics, and wide-refactor expand-contract exception, adapt sizing toward coherent single-commit slices rather than fresh-context limits, and replace tracker, `.scratch`, label, native-link, and parent-issue mechanics with Wayfinder task-ticket artifacts.
Create open, unclaimed Wayfinder task tickets in the resolved artifact destination, use destination naming, identifier, wikilink, parent, blocker, status, claim, and Frontier rules, keep implementation detail in task artifacts rather than maps, and treat research, prototype, and grill tickets as planning work rather than implementation slices.
The implementation-ready `slice` specification defines explicit invocation, broad source handling, destination and parent resolution, coherent single-commit tracer-bullet slicing, the wide-refactor exception to strict vertical slicing, Wayfinder blocker and Frontier semantics, AFK versus human task classification, task body structure, review-before-write behavior, and verification expectations.
The packaged skill source lives at `skills/slice/SKILL.md`, is explicitly invoked, writes Wayfinder task artifacts rather than legacy `.claude/tasks`, and was tightened through `/design-skill` structural review.
`nix flake check "path:$PWD"` passes and verifies that the repository discovers and packages the new `slice` skill.
## Result
The packaged `slice` skill is implemented at `skills/slice/SKILL.md` and repository verification passes.
## Not yet specified
None.
## Out of scope
Enabling the skill in dotfiles or another consumer repository is outside this map.
Writing legacy `.claude/tasks/` files is outside this map.

61
projects/skills/032-slice-skill-old-to-tasks-research.md Normal file
View File

@@ -0,0 +1,61 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
blocked-by: []
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T22:57:30-04:00"
tags:
- ticket/research
---
# Slice skill old to-tasks research
## Question
What behavior should `slice` preserve, adapt, or reject from the old local `to-tasks` skill?
## Findings
The old skill accepts source material from the current conversation or an explicit argument such as a spec path, and only derives a feature slug when a `.claude/spec/<feature-slug>.md` source exists.
`slice` should preserve the source-material flexibility but reject the `.claude/spec`-specific slug contract because Wayfinder artifact provenance and parent links replace that field.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`.
The old skill treats codebase exploration as optional when the agent has not already explored the area.
It says task titles and descriptions should use the project's domain glossary vocabulary and respect ADRs, and it explicitly looks for prefactoring that makes the implementation easier before slicing.
`slice` should preserve this behavior, but resolve glossary and ADR context through the active project and artifact destination rather than Claude-specific paths.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`.
The core slicing rule is durable: each slice is a tracer bullet that delivers a narrow complete path through every layer the change requires, is demoable or verifiable on its own, and puts any prefactoring first.
`slice` should preserve this as a central contract.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`.
The old skill requires a user review loop before writing task files.
It presents the proposed breakdown with file stem, blockers, and covered user stories when available, then asks whether granularity, dependency relationships, and merge or split choices are correct.
`slice` should preserve review-before-write by default, while allowing an explicitly noninteractive caller mode only if the new skill chooses to support one.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`.
The old global numbering sequence is a legacy `.claude/tasks` mechanic.
It scans for the highest four-digit prefix under `.claude/tasks/` and never restarts per feature.
`slice` should reject that mechanism because Wayfinder artifacts use the AI-artifacts destination's naming and identifier allocation rules instead.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`.
The old `blocked-by` field is a durable dependency concept but not a reusable representation.
It stores permanent dependencies by full task filename stem and treats a slice as pickable when every blocker has all acceptance criteria resolved.
`slice` should preserve permanent blocking edges and frontier pickability, but adapt them to Wayfinder `blocked-by` wikilinks and ticket statuses.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/TASK-FORMAT.md`.
The old body format is worth carrying forward in adapted form.
It uses `## What to build` for a concise end-to-end behavior description and `## Acceptance criteria` for checklist completion.
It also says not to include brittle file paths or code snippets unless a prototype snippet encodes a settled decision more precisely than prose can.
`slice` should preserve these body sections and the anti-staleness rule inside Wayfinder task tickets.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/TASK-FORMAT.md`.
The old completion model is acceptance-criteria-centered.
A task is done when every criterion is checked as satisfied or deliberately dropped, with dropped work recorded in Implementation Notes by the implementation flow.
`slice` should preserve acceptance criteria as execution checklist content, but final lifecycle state must be the Wayfinder ticket `status` rather than a separate `.claude/tasks` convention.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/TASK-FORMAT.md`.
## Conclusion
`slice` should preserve the old skill's flexible source intake, optional codebase exploration, tracer-bullet vertical slicing, prefactoring-first bias, default user review loop, permanent blocker semantics, end-to-end task body, acceptance criteria, and anti-stale-detail guidance.
It should reject `.claude/tasks` output, `.claude/spec` feature-slug metadata, four-digit task numbering, filename-stem blockers, and `.claude/tasks` completion semantics in favor of Wayfinder artifacts.

175
projects/skills/033-slice-skill-implementation-spec-task.md Normal file
View File

@@ -0,0 +1,175 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T23:19:15-04:00"
blocked-by:
- "[[032-slice-skill-old-to-tasks-research]]"
- "[[036-slice-skill-matt-to-tickets-research]]"
- "[[037-slice-skill-wayfinder-contract-research]]"
tags:
- ticket/task/afk
---
# Slice skill implementation spec
## Question
Produce an implementation-ready specification for the `slice` skill.
## What to build
Write the skill specification that a later implementation step can translate directly into `skills/slice/SKILL.md` and any support files.
The spec should define invocation inputs, source-material handling, Wayfinder parent resolution, task-ticket artifact creation, blocking-edge rules, AFK versus human task classification, user review before writes, and verification expectations.
## Specification
### Purpose
`slice` turns settled source material into implementation-ready Wayfinder task tickets.
The source material may be a plan, spec, current conversation, issue text, existing artifact, or other explicit reference supplied by the caller.
The output is a set of open, unclaimed Wayfinder `ticket/task/afk` and `ticket/task/human` artifacts that represent tracer-bullet implementation slices.
### Invocation boundary
`slice` is explicitly invoked.
It should not be implicitly selected by the model because it writes multiple durable handoff artifacts and shapes future implementation work.
The caller's invocation is sufficient permission to slice the provided source material.
The skill does not require the source map to be complete, and it does not second-guess the user's decision to slice.
If the source material clearly contains unresolved planning questions rather than settled implementation input, `slice` should surface that as a problem in the proposed breakdown rather than inventing implementation work.
### Source handling
The skill works from conversation context first.
If the caller passes paths, artifact links, issue references, or URLs, the agent reads the referenced body and relevant comments or surrounding artifact context before slicing.
When source material names a Wayfinder artifact, that artifact should be the default provenance parent.
When no source artifact exists, use the active map if one is clear from context.
When neither exists, create or select the minimal Wayfinder parent required by the artifact contract rather than writing orphaned task tickets.
The agent may explore the codebase when the current implementation state is not already understood.
Titles and descriptions should use the project's established vocabulary and respect relevant ADRs or context artifacts.
The agent should look for prefactoring that makes the change easier before slicing implementation behavior.
### Artifact destination and naming
Resolve the artifact destination before naming files.
Use an explicitly supplied destination directory exactly.
Otherwise use Wayfinder's default destination resolution.
Read the destination's `AGENTS.md` before any artifact write.
Follow the destination's naming, identifier allocation, slug, and wikilink conventions.
For the AI-artifacts vault, project artifacts are flat files named `<NNN>-<scope-slug>[-<subject-slug>]-<artifact-type>.md`.
Task slice artifacts use the `task` artifact-type suffix because Wayfinder forbids `ticket` as a ticket filename suffix.
Allocate identifiers by incrementing the vault root `.counter` before artifact creation when the destination convention requires identifiers.
Preserve identifiers and update wikilinks if any file is renamed.
### Slicing discipline
Each normal slice is a tracer bullet.
It must deliver a narrow complete path through every layer the change requires, not a horizontal layer-only chunk.
A completed slice must be demoable or verifiable on its own.
A slice should make sense as one coherent commit.
Prefactoring that makes the implementation easy should appear before dependent behavior slices.
Wide mechanical refactors are the exception to strict vertical slicing.
When one mechanical change has a blast radius that prevents any vertical slice from landing green, use expand-contract sequencing instead of forcing artificial vertical slices.
Create an expand task that adds the new form beside the old one, migration batch tasks sized by blast radius, and a contract task blocked by all migrations.
If migration batches cannot stay green alone, preserve the sequence but identify the integration-branch constraint and add a final integrate-and-verify task.
### Blocking edges and Frontier
Every slice declares its blockers.
Use Wayfinder `blocked-by` wikilinks, not filename stems, issue IDs, or prose-only references.
Use `parent` only for provenance.
Use `blocked-by` for prerequisites that must resolve before the slice is actionable.
A slice with no blockers can be worked immediately.
After writing task artifacts, re-read the map and recompute its Frontier from ticket metadata.
Open, unclaimed, unblocked task tickets belong on the Frontier.
### AFK versus human tasks
Use `ticket/task/afk` when an agent can complete and verify the slice without live human input.
Use `ticket/task/human` when execution or validation depends on the user, such as subjective UI judgment, physical device checks, credentials the agent cannot access, or behavior only the human can confirm.
Do not mark a task human merely because it is important.
Make the required human involvement precise in the task body.
### Task artifact shape
Each created slice task starts with Wayfinder frontmatter:
```markdown
---
status: open
parent: "[[<source-artifact-or-map>]]"
blocked-by: []
tags:
- ticket/task/afk
---
```
Use `ticket/task/human` for human-dependent slices.
The body contains:
```markdown
# <task name>
## Question
<one precise implementation action sized to one agent session>
## What to build
<concise end-to-end behavior or implementation result, not a layer-by-layer checklist>
## Acceptance criteria
- [ ] <observable criterion>
## Implementation Notes
<concise handoff guidance when useful>
```
`## Implementation Notes` may be empty when no guidance is useful.
Later implementing agents may append execution notes, verification results, and reasons for deliberately dropped criteria.
Avoid brittle file paths and code snippets unless a prototype or prior decision snippet encodes the decision more precisely than prose can.
### Review loop
Before writing artifacts, present the proposed breakdown and wait for approval unless the caller explicitly asks for noninteractive output.
For each proposed slice show the title, task type, blockers, what it delivers, and relevant user stories or source requirements.
Ask the user to validate granularity, blocking edges, and whether any slices should be merged or split.
Iterate until the breakdown is approved.
In explicitly noninteractive mode, write the best breakdown and record any assumptions in `## Implementation Notes`.
### Relationship to other Wayfinder tickets
`slice` creates implementation task tickets.
It does not create research, prototype, or grill tickets as part of normal slicing.
If slicing reveals a precise unresolved planning question, report it and either stop or create the appropriate Wayfinder ticket only when the caller asks for that planning work.
Implementation detail belongs in task artifacts, not in the map's Decisions so far.
The map records only concise route decisions and keeps the Frontier as its only ticket-link section.
### Verification expectations
The implemented skill should be packaged as `skills/slice/SKILL.md` in this repository.
It should not write `.claude/tasks/` as an output target.
It may mention the legacy format only to say it is intentionally replaced.
Repository verification should include `nix flake check "path:$PWD"` while the new skill files are untracked.
## Acceptance criteria
- [x] The spec states that `slice` creates Wayfinder `ticket/task/afk` and `ticket/task/human` artifacts rather than legacy `.claude/tasks/` files.
- [x] The spec explains how `slice` resolves the artifact destination and chooses the parent artifact or map according to Wayfinder artifact rules.
- [x] The spec preserves tracer-bullet vertical slicing and the wide-refactor expand-contract exception.
- [x] The spec defines task body sections for `## What to build`, `## Acceptance criteria`, and `## Implementation Notes`.
- [x] The spec requires a review loop before writing artifacts unless the caller explicitly asks for noninteractive output.
- [x] The spec distinguishes implementation task tickets from Wayfinder research, prototype, and grill decision tickets.
## Implementation Notes
The specification uses the old `to-tasks`, Matt `to-tickets`, and Wayfinder contract research as its evidence base.
Sizing is specified around coherent single commits rather than fresh context windows.
The wide-refactor exception is framed as an exception to strict vertical slicing.
Keep the implementation focused on skill behavior rather than adding repository-specific execution helpers.

39
projects/skills/034-slice-skill-source-task.md Normal file
View File

@@ -0,0 +1,39 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T23:27:00-04:00"
blocked-by:
- "[[033-slice-skill-implementation-spec-task]]"
tags:
- ticket/task/afk
---
# Slice skill source
## Question
Implement the packaged `slice` skill source from the approved implementation-ready specification.
## What to build
Use `/design-skill` to add the `slice` skill under the repository's packaged skill source tree.
The skill should guide agents through slicing source material into Wayfinder task tickets, including artifact destination handling, review-before-write behavior, blocking-edge recording, and implementation-oriented task bodies.
## Acceptance criteria
- [x] `/design-skill` has been applied to draft and verify the skill structure.
- [x] `skills/slice/SKILL.md` exists and follows the approved specification.
- [x] Any companion reference files needed by the skill live under `skills/slice/`.
- [x] The skill description is concise and accurately describes when to use `slice`.
- [x] The skill does not instruct agents to write `.claude/tasks/` files.
- [x] The skill uses Wayfinder artifact terminology consistently with `ARTIFACTS.md`.
## Implementation Notes
Created `skills/slice/SKILL.md` with `disable-model-invocation: true`.
No companion reference files were needed.
The skill source embeds the minimum Wayfinder ticket contract and tells agents to follow destination artifact conventions.
Applied `/design-skill` structurally by checking invocation mode, information hierarchy, completion criteria, duplication, sediment, sprawl, no-op behavior, and leading-word fit against `skills/design-skill/GLOSSARY.md`.
A headless Pi smoke-test with `--skill skills/slice` did not reliably exercise the user-invoked skill and produced horizontal slices, so I tightened the skill text to reject layer-only slices and to give an exact review shape.
The smoke-test evidence is under `/tmp/slice-smoke/`.

33
projects/skills/035-slice-skill-package-verification-task.md Normal file
View File

@@ -0,0 +1,33 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T23:33:26-04:00"
blocked-by:
- "[[034-slice-skill-source-task]]"
tags:
- ticket/task/afk
---
# Slice skill package verification
## Question
Verify that the new `slice` skill is correctly packaged by the skills repository.
## What to build
Run the repository validation required for a newly added untracked skill source and fix any packaging or formatting issues that appear.
## Acceptance criteria
- [x] `nix flake check "path:$PWD"` passes.
- [x] The new `slice` skill is included by the repository's skill discovery.
- [x] No generated skill links are edited as source.
## Implementation Notes
Ran `nix flake check "path:$PWD"` from `/home/alexion/wrk/skills`.
The check passed and evaluated `packages.x86_64-linux.slice` plus `checks.x86_64-linux.slice`.
The command warned that incompatible systems `aarch64-darwin` and `aarch64-linux` were omitted.
`git status --short` shows only the new untracked `skills/slice/` source directory inside this repository.

69
projects/skills/036-slice-skill-matt-to-tickets-research.md Normal file
View File

@@ -0,0 +1,69 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
blocked-by: []
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T22:58:13-04:00"
tags:
- ticket/research
---
# Slice skill Matt to-tickets research
## Question
What behavior should `slice` preserve, adapt, or reject from Matt Pocock's `to-tickets` skill?
## Findings
Matt Pocock's skill is explicitly non-implicit.
Its frontmatter disables model invocation, and its OpenAI agent policy sets `allow_implicit_invocation: false`.
`slice` should likely preserve explicit invocation as a safety boundary because it writes multiple handoff artifacts and can shape future implementation work.
Sources: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Downloads/skills/skills/engineering/to-tickets/agents/openai.yaml`.
The input model is broader than a spec file.
`to-tickets` can break down a plan, spec, current conversation, issue number, or URL, and it fetches full issue bodies and comments for issue references.
`slice` should preserve broad source intake and avoid spec-only naming or behavior.
Sources: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Downloads/skills/docs/engineering/to-tickets.md`.
The central output concept is a set of tracer-bullet vertical slices with blocking edges.
Each slice cuts through all relevant integration layers, avoids horizontal layer-only work, is demoable or verifiable on its own, and puts prefactoring first.
Matt's source skill sizes each slice for a single fresh context window, but `slice` should adapt sizing toward a coherent single commit instead of making context-window size the main boundary.
Source: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`.
Blocking edges are the main handoff contract.
Every ticket declares the tickets that block it, tickets with no blockers can start immediately, and the frontier is the set whose blockers are all done.
`slice` should preserve this model, but represent edges as Wayfinder `blocked-by` wikilinks and use Wayfinder ticket status to determine the frontier.
Sources: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Downloads/skills/docs/engineering/to-tickets.md`.
The review loop is part of the source skill's safety model.
It presents title, blockers, and delivered behavior for each proposed ticket, then asks about granularity, blocking edges, and merge or split choices before publishing.
`slice` should preserve review-before-write by default because artifact creation fixes names, identifiers, and dependency structure.
Source: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`.
The local-file versus real-tracker split is source-specific.
Matt's skill publishes either `.scratch/<feature>/issues/<NN>-<slug>.md` local files or real tracker issues with native blocking links and `ready-for-agent` labels.
`slice` should reject that publishing abstraction and target Wayfinder artifacts only, because this skill's destination is the AI-artifacts project destination rather than an issue tracker.
Sources: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Downloads/skills/docs/engineering/to-tickets.md`.
The issue templates overlap with Wayfinder metadata but still supply useful execution-body semantics.
Matt's template includes parent reference, end-to-end `What to build`, acceptance criteria, and `Blocked by`.
Wayfinder already owns parent and blocker representation through frontmatter, while `slice` should preserve `What to build` and `Acceptance criteria` as task body sections and optionally add `Implementation Notes` for handoff and execution details.
Source: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`.
The wide-refactor exception is important enough to preserve.
A wide mechanical refactor should not be forced into vertical slices when no slice can land green.
It should be sequenced as expand, migration batches, and contract, with an integration-branch and final integrate-and-verify step only when batches cannot stay green alone.
`slice` should include this exception so agents do not cargo-cult vertical slicing into unsuitable refactors.
Sources: `/home/alexion/Downloads/skills/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Downloads/skills/docs/engineering/to-tickets.md`.
The documentation frames `to-tickets` as a step after an agreed plan or written spec, not as the planning skill itself.
It says to produce a spec first if the change has not been written up.
`slice` should preserve that boundary in Wayfinder terms: it should slice source material the caller treats as settled enough to implement, not resolve unresolved design fog.
Source: `/home/alexion/Downloads/skills/docs/engineering/to-tickets.md`.
## Conclusion
`slice` should preserve Matt Pocock's explicit invocation, broad source intake, tracer-bullet discipline, blocker/frontier model, review loop, useful issue-body semantics, and wide-refactor expand-contract exception.
It should adapt sizing toward coherent single-commit slices rather than emphasizing fresh-context-window limits.
It should reject the configured-tracker prerequisite, `.scratch` local-file output, real issue tracker publishing, `ready-for-agent` labels, platform-native blocker links, and tracker-specific parent issue behavior in favor of Wayfinder task-ticket artifacts.

76
projects/skills/037-slice-skill-wayfinder-contract-research.md Normal file
View File

@@ -0,0 +1,76 @@
---
status: resolved
parent: "[[031-slice-skill-map]]"
blocked-by: []
claimed-by: "019fbb2a-dbcd-79d2-ae72-c5bcdd1d714e"
claimed-at: "2026-07-31T22:58:59-04:00"
tags:
- ticket/research
---
# Slice skill Wayfinder contract research
## Question
What Wayfinder artifact rules must `slice` follow when creating implementation task tickets?
## Findings
Wayfinder normally plans rather than implements.
It creates a durable map of questions whose resolutions are decisions, findings, prototypes, or completed prerequisites, and says implementing the destination usually marks the edge of the map and the handoff point.
`slice` therefore needs an explicit contract that it creates implementation handoff tickets only when invoked, rather than silently turning unresolved planning fog into destination work.
Source: `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`.
The user-facing reference rule is human-readable artifact titles through the destination's link style, not bare identifiers or slugs.
`slice` should present proposed and written artifacts by wikilink title such as `[[034-slice-skill-source-task]]`, not by an unlinked filename stem or numeric identifier alone.
Source: `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`.
Artifact destinations are resolved before naming files.
When a caller provides a destination directory, it must be used exactly.
Otherwise the default is `$(xdg-user-dir DOCUMENTS)/ai-artifacts/projects/<project>` when the AI-artifacts vault exists, falling back to `./docs` in the current project.
`slice` must read the destination's `AGENTS.md` before writing artifacts.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
This vault's project artifact convention is flat and identifier-bearing.
Project Markdown artifacts are named `<NNN>-<scope-slug>[-<subject-slug>]-<artifact-type>.md`, with identifiers allocated by incrementing the vault root `.counter` before artifact creation.
The creating skill chooses the artifact-type slug, but Wayfinder ticket filenames use `research`, `prototype`, `grill`, or `task`, and maps should use the normal `map` artifact-type suffix.
Sources: `/home/alexion/Documents/ai-artifacts/AGENTS.md`, `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Wayfinder maps are route summaries, not stores for detailed ticket results.
Only the Frontier links to tickets or other artifacts, Decisions so far contains concise plain-language decisions without links, and map status is open while live tickets or fog remain.
`slice` should not store implementation slice bodies in the map.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Wayfinder tickets are self-resolving artifacts with authoritative metadata.
A new ticket has `status: open`, a singular `parent` wikilink, `blocked-by: []`, and one ticket tag.
Task tickets use `ticket/task/afk` or `ticket/task/human`.
`slice` should create one implementation slice per Wayfinder task ticket and choose AFK when an agent can complete it without live human input, or human when the task's execution or validation requires the user.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
`parent` and `blocked-by` mean different things.
`parent` records provenance, while `blocked-by` records upstream artifacts that must resolve before the ticket becomes actionable.
A ticket is on the Frontier when it is open, every blocker is satisfied, and it has no claim.
`slice` should put the source artifact or map in `parent`, and put prerequisite slices or unresolved prerequisite artifacts in `blocked-by`.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Claims are part of the execution protocol and should not be pre-created by `slice`.
A ticket is claimed only when an agent is about to work it, by setting `status: claimed`, `claimed-by`, and `claimed-at` before doing work.
`slice` should create open unclaimed task tickets, then recompute the map Frontier.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Research and prototype tickets have called-skill completion contracts, while task tickets perform prerequisite work where possible or give the human a checklist.
Because `slice` output is implementation work, it should not create research, prototype, or grill tickets unless slicing reveals a precise unresolved planning question instead of an implementation slice.
Source: `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`.
The existing full map in the dotfiles project shows the artifact style in practice: a map artifact `[[002-pi-subagents-map]]`, decision summaries in the map, task tickets such as `[[026-pi-subagents-dotfiles-deployment-task]]` and `[[027-pi-subagents-implementation-spec-task]]`, and detailed task results living in those task artifacts rather than in the map.
Some completed historical tickets use `status: done`, but the current Wayfinder artifact contract lists `resolved` as the resolved ticket status, so `slice` should follow the current contract rather than copying that older status spelling.
Sources: `/home/alexion/Documents/ai-artifacts/projects/dotfiles/002-pi-subagents-map.md`, `/home/alexion/Documents/ai-artifacts/projects/dotfiles/026-pi-subagents-dotfiles-deployment-task.md`, `/home/alexion/Documents/ai-artifacts/projects/dotfiles/027-pi-subagents-implementation-spec-task.md`, `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Concurrent writes require re-reading shared artifacts immediately before editing them and reconciling duplicate identifiers or filenames after parallel creation.
`slice` should allocate artifact identifiers sequentially, create approved task artifacts, then re-read and repair the map Frontier after the files exist.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
## Conclusion
`slice` must write open, unclaimed Wayfinder task tickets in the resolved artifact destination, using destination naming, identifier, wikilink, parent, blocker, status, claim, and Frontier rules.
It should keep implementation slice detail in each task artifact, not the map, and it should treat research, prototype, and grill tickets as planning work rather than implementation slices.

62
projects/skills/038-implement-skill-map.md Normal file
View File

@@ -0,0 +1,62 @@
---
status: complete
tags:
- wayfinder/map
---
# Implement workflow
## Destination
Create an implementation-ready plan for migrating the packaged implementation workflow to Wayfinder-aware skills in this skills repository.
The route ends when the `implement`, `test-driven-development`, and review skill contracts, dependencies, artifact lifecycle, git and PR handling, and migration scope are decided enough to hand off implementation.
## Notes
The workflow includes packaged `implement`, `test-driven-development`, and review skills.
The review skill is named `review`.
The old Claude Code skill sources live under `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/`, and `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/review-uncommitted/`.
The new packaged skill sources, if implemented later, would live under `skills/implement/`, `skills/test-driven-development/`, and `skills/review/` in this repository.
Runtime enablement in dotfiles or another consumer repository is out of scope unless a later decision explicitly broadens the destination.
Wayfinder-aware implementation should work with Wayfinder task tickets and preserve useful execution, review, commit, and PR mechanics from the old workflow only where they still fit the artifact contract.
Research comes before HITL decisions.
## Frontier
None.
## Decisions so far
The migration scope includes the complete implementation workflow: packaged `implement`, packaged `test-driven-development`, and packaged `review`.
Preserve explicit task selection, blocker safety, conservative git branching from `main`, no automatic stashing or destructive resets, TDD where appropriate, regular verification, specific staging, pre-commit review, deviation notes, one commit per task, and useful PR reporting, but adapt task identity, blocker readiness, branch naming, spec source, task closeout, PR references, and lifecycle state from legacy `.claude/tasks` conventions to Wayfinder task-ticket artifacts.
Execute exactly one actionable implementation task ticket per session at a time, claim it in metadata before code changes, respect `blocked-by` and existing claims, record implementation results in the same ticket artifact, transition it to `resolved`, and repair the owning map's Frontier without storing implementation detail in the map.
HITL task tickets can be implemented until they reach the point requiring human input, where the skill must pause and surface the precise human checkpoint.
Create dedicated follow-up research for Matt Pocock's `implement`, `to-tickets`, `tdd`, `code-review`, and `wayfinder` skills, but not for handoff skills unless the destination expands to session handoff automation.
Use Matt Pocock's `implement` as a simplicity reference, but keep stricter local handling for Wayfinder claiming, branch setup, artifact closeout, and PR or handoff reporting.
Preserve Matt Pocock's tracer-bullet, blocker, frontier, and wide-refactor concepts from `to-tickets`, but reject tracker labels and issue-specific publication mechanics in favor of Wayfinder task metadata.
Preserve public-seam, anti-tautology, one-test-at-a-time TDD discipline, while leaving the timing and authority of refactoring as a human decision.
Use the Wayfinder task as the primary review spec source, preserve separate Standards and Spec axes plus the smell baseline, and decide whether to retain the local Risk axis and pre-commit review timing.
Adapt Matt Pocock's Wayfinder planning-versus-execution boundary, HITL protection, and frontier/claim concepts, while rejecting tracker-specific labels, child-issue assumptions, assignee claims, issue IDs, and native blocking mechanics.
Learn from Kun Chen's `no-mistakes` that preventing AI slop requires a fixed ordered gate, rich intent, isolated validation, structured findings, bounded auto-fix, human escalation for judgment calls, trusted validation configuration, and CI-backed proof before public handoff.
Worktree isolation is expected to be essential for parallel Wayfinder implementation.
Treehouse leasing is the strongest candidate when available: acquire an isolated reusable worktree, create or check out the task branch inside it, record lease identity in the ticket, avoid destructive cleanup when dirty, and release with identity checks after successful handoff.
Keep Herdr worktree and pane orchestration external to the core skill unless the destination expands, while remaining compatible with Herdr-managed worktrees, setup hooks, and `.worktreeinclude`-style ignored-file copying.
Do not package `codebase-design` as part of this workflow; fold the small amount of useful seam and public-interface testing guidance into `test-driven-development` and `review` instead.
Treat worktree orchestration, dirty-repo guards, lease cleanup, visible Herdr panes, and multi-agent execution as Pi extension or external-tool integrations outside this skill migration.
The `implement` skill defines execution protocol rather than policing admissible work sources: when selected work has a Wayfinder task artifact it follows Wayfinder claim, blocker, result, resolution, and Frontier protocol, and when no artifact exists the implementation artifact is simply the working code plus normal review, commit, and handoff output.
The `implement` skill is worktree-compatible rather than a worktree orchestrator: it assumes the session already has the right checkout, checks dirty state, never auto-stashes, uses or creates a non-default branch from an updated default branch when needed, follows repository, user, or orchestrator branch naming, preserves the old blocker-reachability guardrail, and only uses integration-branch or wide-refactor branch strategy when the plan explicitly calls for that exception.
The review skill is named `review`; it selects a context-appropriate change set, states that scope, emits a structured report rather than a gate artifact or pass/fail verdict, covers Risk, Standards, Intent, Evidence, and Documentation when applicable, may run targeted checks, remains report-only, uses independent dimension reviewers with single-agent fallback, keeps reviewer prompts as self-contained files under the skill directory, and preserves ambiguity where agent judgment is useful.
The `test-driven-development` skill folds in minimal public-interface and seam guidance instead of depending on packaged `codebase-design`, requires tests to be written by someone other than the implementation agent with an explicit fallback only when independent workers are unavailable, isolates the implementation agent's behavior backlog from the test writer, runs red-green one behavior at a time, requires independent expected-value sources, forbids implementation agents from editing test-writer-authored tests, and preserves the old local refactor-after-green behavior.
The code is the implementation artifact; Wayfinder task closeout records durable coordination facts only, uses `status` as lifecycle authority, may update acceptance-criterion checkboxes as useful detail, keeps Implementation Notes concise, leaves partial or ambiguous outcome disposition to agent judgment, and must keep lifecycle recording honest.
No extras are in scope beyond the packaged `implement`, `test-driven-development`, and `review` skills: do not add legacy `.claude/tasks` compatibility shims, dedicated worktree-extension documentation, Herdr integration, or Treehouse integration.
The `implement` skill uses `test-driven-development` as a strong default when behavior can usefully be specified and tested before implementation, consumes it as process discipline rather than a report artifact, must run `review` before final handoff or Wayfinder task resolution, lets the agent choose review timing as long as review covers the final intended handoff state, fixes or explicitly accepts blocking review findings, uses judgment for non-blocking findings, and prescribes no other supporting skill invocations.
## Not yet specified
None.
## Out of scope
Implementing the migrated skills is outside this map until the route is complete and the user explicitly asks for destination work.
Building a Pi extension for worktree orchestration, dirty-repo guards, lease cleanup, visible Herdr panes, or multi-agent execution is outside this skill migration.
The skill workflow should remain compatible with such an extension.

67
projects/skills/039-implement-skill-old-workflow-research.md Normal file
View File

@@ -0,0 +1,67 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:42:05-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill old workflow research
## Question
What behavior should the migrated `implement` skill preserve, adapt, or reject from the old local `/implement` skill and the old skills it depends on?
## Findings
The old `/implement` skill is task-file driven and explicitly refuses to infer a task from context.
It expects a `.claude/tasks/<NNNN>-slug.md` path produced by `/to-tasks`, checks any `blocked-by` entries by reading referenced task files, and treats a blocker as unresolved if it has any unchecked acceptance criterion.
A Wayfinder-aware migration should preserve explicit work selection, but adapt readiness checks from legacy task-file checkboxes to Wayfinder ticket metadata: an implementation task is actionable when the ticket is unblocked by resolved blockers and claimed by the current session before work starts.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`.
The old workflow has strong git guardrails.
It syncs `main` with `git pull --ff-only`, branches as `task-<NNNN>-<slug>`, never branches from a sibling task branch, refuses to stash uncommitted work automatically, never resets diverged `main`, and reuses an existing task branch without rebasing it.
A migrated skill should preserve the safety properties, but must redesign branch naming because Wayfinder artifact names are human-readable artifact links with identifiers inside filenames, not legacy `.claude/tasks` stems.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`.
The old workflow treats blocker work not reachable from `main` as a stop-and-ask condition because the blocker's PR is likely unmerged.
Wayfinder metadata can prove planning blockers are resolved, but it cannot prove code from prerequisite implementation tickets has landed on `main`.
A migrated skill should keep an explicit reachability check for implementation blockers that correspond to prior code changes, or else record a policy decision that Wayfinder task resolution is allowed to precede merge.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`.
The old implementation step delegates test-first work to `/test-driven-development` where possible and tells the agent to run typechecking regularly, focused tests regularly, and the full suite at the end.
The local `/test-driven-development` dependency adds stricter rules: tests verify behavior through public interfaces, avoid tautological assertions, proceed one test at a time through tracer bullets, and use a test-writer sub-agent while the main agent writes implementation.
A migrated skill should preserve the intent to use TDD at agreed seams, but should not blindly import Claude-specific sub-agent mechanics if the target runtime lacks them.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/SKILL.md`.
The old staging rule is intentionally conservative: stage created and modified files specifically, not with `git add -A`, so unrelated untracked work is not swept in.
This remains valid for a Wayfinder-aware implementation workflow and should be preserved.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`.
The old review step runs `/review-uncommitted` with the task file as the spec source, then addresses findings before continuing.
The review dependency reviews `git diff HEAD` across Risk, Standards, and Spec axes, requires new files to already be tracked so they appear in the diff, and aggregates the Risk block plus Standards and Spec findings.
A migrated skill should preserve a pre-commit review gate, but adapt the spec source to the Wayfinder task ticket artifact and decide whether the risk axis belongs in the new review contract.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/review-uncommitted/SKILL.md`.
The old closeout updates the task artifact as part of the implementation commit.
It marks each acceptance criterion `[x]` when satisfied or `[-]` when deliberately dropped, appends `## Implementation Notes` for deviations, keeps permanent provenance and blocker frontmatter untouched, and stages the task file with code.
A migrated skill should preserve recording deviations and acceptance-criterion outcomes in the task artifact, but adapt lifecycle status to Wayfinder's `claimed` to `resolved` transition rather than treating checkboxes as the authoritative lifecycle.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/TASK-FORMAT.md`.
The old commit and PR mechanics are opinionated.
It makes one commit for the whole task, follows the repository's commit convention, references the task in the subject, pushes `task-<NNNN>-<slug>`, opens a ready PR against `main` using the repo forge CLI, includes the task path, summary, deviations, the review Risk block, and only unaddressed Standards and Spec findings, and does not ask before pushing or opening the PR.
A migrated skill should preserve the one-task-one-commit bias and PR body usefulness, but adapt task references to Wayfinder artifact links and decide whether automatic push and PR creation remain acceptable for every target repo.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`.
The legacy `/to-tasks` dependency produces tracer-bullet vertical slices as files under `.claude/tasks`, with `spec` and `blocked-by` frontmatter and checkbox acceptance criteria.
The already-packaged `slice` migration replaced that output with open, unclaimed Wayfinder task tickets in the AI-artifacts destination, using Wayfinder parent and `blocked-by` links instead of legacy stems.
The migrated `implement` skill should consume the Wayfinder task-ticket format created by `slice`, not the old `.claude/tasks` format.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/to-tasks/TASK-FORMAT.md`, `/home/alexion/Documents/ai-artifacts/projects/skills/031-slice-skill-map.md`.
## Conclusion
The migrated `implement` skill should preserve explicit task selection, blocker safety, conservative git branching from `main`, no automatic stashing or destructive resets, TDD where appropriate, regular verification, specific staging, pre-commit review, deviation notes, one commit per task, and useful PR reporting.
It should adapt task identity, blocker readiness, branch naming, spec source, task closeout, PR references, and lifecycle state from legacy `.claude/tasks` conventions to Wayfinder task-ticket artifacts.
It should reject legacy assumptions that a task is identified by a `.claude/tasks` basename, that checkbox completion is the authoritative lifecycle, and that `spec` or `blocked-by` frontmatter from `.claude/tasks` exists.

56
projects/skills/040-implement-skill-matt-skills-discovery-research.md Normal file
View File

@@ -0,0 +1,56 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:42:05-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill Matt skills discovery research
## Question
Which Matt Pocock `mattpocock/skills` skills are relevant primary sources for migrating `implement`, and which ones need dedicated follow-up research tickets?
## Findings
The primary repository is `mattpocock/skills`, described by GitHub as "Skills for Real Engineers. Straight from my .agents directory." and organized under `skills/engineering`, `skills/productivity`, `skills/in-progress`, `skills/misc`, and `skills/deprecated`.
The engineering directory contains `implement`, `to-tickets`, `tdd`, `code-review`, and `wayfinder`, which are directly relevant to an implementation workflow that consumes tickets, builds code, tests, reviews, and understands Wayfinder semantics.
Source: `https://api.github.com/repos/mattpocock/skills`, `https://api.github.com/repos/mattpocock/skills/contents/skills/engineering?ref=main`.
Matt Pocock's `implement` skill is the closest direct comparison.
It implements work from a spec or set of tickets, uses `/tdd` where possible at pre-agreed seams, runs typechecking and tests, reviews with `/code-review`, and commits to the current branch.
It is much shorter and less prescriptive than the local old `/implement`, so it needs dedicated research to decide what simplicity to import and what local guardrails to keep.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/implement/SKILL.md`.
Matt Pocock's `to-tickets` skill is relevant because it defines the producer side of ticket implementation work.
It creates tracer-bullet tickets, blocking edges, a frontier concept, tracker publication, and a wide-refactor expand-contract exception.
It needs dedicated research to compare its ticket assumptions with local `slice` and Wayfinder task artifacts.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/to-tickets/SKILL.md`.
Matt Pocock's `tdd` skill is relevant because both Matt's and the old local implementation workflows delegate test-first mechanics to TDD.
It emphasizes pre-agreed seams, one test and one minimal implementation per cycle, and defers refactoring to review.
It needs dedicated research because the local TDD skill differs by using a test-writer sub-agent and more detailed anti-tautology mechanics.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/tdd/SKILL.md`.
Matt Pocock's `code-review` skill is relevant because Matt's `implement` uses it as the review gate.
It reviews a branch against a fixed point with Standards and Spec axes in parallel sub-agents, whereas the old local review skill reviews uncommitted changes and also includes a Risk axis.
It needs dedicated research for deciding which review gate a migrated `implement` skill should require.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/code-review/SKILL.md`.
Matt Pocock's `wayfinder` skill is relevant because it is the upstream-like version of the planning map workflow.
It uses issue trackers, labels, child issues, assignees, and native blocking relationships, while the local Wayfinder uses AI-artifacts Markdown, metadata claims, wikilinks, and self-resolving tickets.
It needs dedicated research only for contrast, so the migrated `implement` skill does not accidentally import tracker-specific assumptions.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/wayfinder/SKILL.md`.
The productivity `handoff` and in-progress `claude-handoff` skills are adjacent but not central.
They summarize a conversation for a fresh agent and can suggest skills, but they do not define implementation execution, task lifecycle, review, branch, worktree, or PR policy.
They do not need dedicated follow-up research for this map unless a later decision expands the destination to session handoff automation.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/productivity/handoff/SKILL.md`, `https://raw.githubusercontent.com/mattpocock/skills/main/skills/in-progress/claude-handoff/SKILL.md`.
## Conclusion
Create dedicated follow-up research tickets for Matt Pocock's `implement`, `to-tickets`, `tdd`, `code-review`, and `wayfinder` skills.
Do not create follow-up research for Matt's handoff skills unless the map later expands into session handoff automation.

73
projects/skills/041-implement-skill-wayfinder-contract-research.md Normal file
View File

@@ -0,0 +1,73 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:42:05-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill Wayfinder contract research
## Question
What Wayfinder artifact and lifecycle rules must a migrated `implement` skill follow when claiming, executing, resolving, and reporting Wayfinder task tickets?
## Findings
Wayfinder plans by default and treats implementation as the edge of the map unless an effort explicitly permits execution in its Notes.
A general `implement` skill can be the explicit destination-work executor, but it should not silently execute arbitrary Wayfinder planning tickets.
It should restrict itself to Wayfinder task tickets that represent implementation handoff work or to maps whose Notes explicitly allow execution.
Source: `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`.
Every Wayfinder ticket is either HITL or AFK and has one ticket tag.
Task tickets use `ticket/task/afk` or `ticket/task/human`; Research, Prototype, and Grill tickets have separate resolution skills and are not implementation slices.
A migrated `implement` skill can execute a `ticket/task/human` when it represents implementation work, but it must block and surface a precise human-input checkpoint when the task reaches the human-dependent step.
It should stop with a plain explanation when asked to execute a non-task decision ticket.
Sources: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`, user correction in this session.
Ticket metadata is authoritative for lifecycle and readiness.
A ticket is on the Frontier when `status: open`, every `blocked-by` artifact is satisfied, and it has no claim.
A ticket blocker is satisfied when its status is `resolved`, and a non-ticket blocker is satisfied when the artifact exists.
The migrated skill should verify these metadata conditions before claiming, rather than using legacy acceptance-checkbox completion as the readiness source.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Claims must be persisted before work starts.
Claiming means setting `status: claimed`, `claimed-by` to the current execution-session identifier, and `claimed-at` to the current timestamp.
The acting agent should use `PI_SESSION_ID` when available.
The migrated `implement` skill should claim exactly one actionable ticket before changing code, and should avoid consuming multiple tickets implicitly.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Wayfinder tickets are self-resolving artifacts.
The canonical result lives in the same ticket artifact, and a resolved implementation task should leave enough result detail for future readers without moving the result into the map.
For `implement`, this implies appending implementation notes, verification results, commit hash, branch name, PR URL when available, deliberately dropped acceptance criteria, and any unaddressed review findings to the ticket artifact before setting `status: resolved`.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
The map is a route summary, not the store for ticket-level detail.
Only the Frontier links to tickets or artifacts, and Decisions so far contains concise plain-language decisions for resolved Wayfinder decision tickets.
Implementation task completion should update the map lifecycle and Frontier if the task belongs to a Wayfinder map, but the detailed implementation report belongs in the task ticket.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Wayfinder requires shared artifacts to be re-read immediately before writes because concurrent sessions may be editing the same effort.
A migrated `implement` skill should re-read the task ticket before claim, before closeout, and before any map Frontier repair.
It should detect stale status, foreign claims, and changed blockers rather than overwriting them.
Source: `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Wayfinder's user-facing reference rule is by human-readable title in the destination's link style, never by bare identifier, filename, or slug.
The migrated skill should refer to the task as a wikilink title when reporting, recording PR text, or writing related map updates, while file paths may still appear where tools need concrete paths.
Sources: `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`, `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
The AI-artifacts vault convention requires project artifacts to be flat and named `<NNN>-<scope-slug>[-<subject-slug>]-<artifact-type>.md`, with identifiers allocated by incrementing the root `.counter` before creation.
`implement` usually consumes an existing ticket rather than allocating new artifacts, but any follow-up task artifacts it creates must honor the destination's `AGENTS.md` and counter rules.
Source: `/home/alexion/Documents/ai-artifacts/AGENTS.md`.
The existing `slice` skill map records the intended producer side of the same contract: implementation slices become Wayfinder task tickets with `## What to build`, `## Acceptance criteria`, and optional `## Implementation Notes`, and the tickets are open and unclaimed until an implementer claims them.
The migrated `implement` skill should be compatible with that produced format.
Source: `/home/alexion/Documents/ai-artifacts/projects/skills/031-slice-skill-map.md`.
## Conclusion
A Wayfinder-aware `implement` skill should execute exactly one actionable implementation task ticket at a time, claim it in metadata before code changes, respect `blocked-by` and existing claims, record implementation results in the same ticket artifact, transition it to `resolved`, and repair the owning map's Frontier without storing implementation detail in the map.
It may execute HITL task tickets when they are implementation work, but must pause at the point human input is required and record the blocked state plainly.
It should not execute research, prototype, grill, blocked, claimed, or out-of-scope tickets as normal implementation work.

110
projects/skills/042-implement-skill-no-mistakes-research.md Normal file
View File

@@ -0,0 +1,110 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:46:29-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill no mistakes research
## Question
What should the migrated `implement` skill learn from Kun Chen's `no-mistakes` code review workflow?
## Findings
Kun Chen's `no-mistakes` is a local git proxy and validation gate.
Its README says pushing to the `no-mistakes` remote spins up a disposable worktree, runs review, tests, docs, lint, push, PR, and CI, and forwards the branch only after every check is green.
The migrated `implement` skill should consider separating local implementation from final shipping validation, rather than treating one in-context review pass as the whole quality gate.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/README.md`.
`no-mistakes` is explicitly agent-agnostic and supports agents including `pi`.
Its skill drives `no-mistakes axi`, a non-interactive TOON interface, and the pipeline can apply safe fixes while escalating intent-touching findings to the human.
A local `implement` skill can remain tool-agnostic while optionally detecting and delegating to `no-mistakes` when installed and initialized.
Sources: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/README.md`, `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
The `no-mistakes` skill distinguishes validate-only mode from task-first mode.
Task-first mode checks scope with `git status`, preserves unrelated pre-existing uncommitted changes, commits only task changes, creates a feature branch when the user is on the default branch, then validates committed work.
The migrated `implement` skill should preserve this strict scope boundary and should treat committed branch state as the input to any downstream validation gate.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
`no-mistakes` requires a rich `--intent`, defined as the user's objective in their terms plus decisions, tradeoffs, constraints, and approaches ruled in or out.
The migrated `implement` skill should derive review and PR context from the Wayfinder task's `## What to build`, acceptance criteria, parent decisions, and implementation notes, not merely from the diff or file list.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
The `no-mistakes` test-quality rule rejects tests that only grep, parse, snapshot, or inspect implementation source strings as proof of behavior.
It requires public or executable interfaces, observable behavior, typed or normalized semantic models for declarative artifacts, and regression tests that fail before the fix when feasible.
The migrated `implement` skill should import this as a review and TDD standard because skill and artifact repos are prone to source-string pseudo-tests.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
The `no-mistakes` gate has clear custody rules while a run is active.
At a gate, the driver reads structured findings and responds approve, fix, or skip; it does not edit code manually while the pipeline owns findings and fixes.
The migrated `implement` skill should either avoid invoking such a pipeline or respect custody strictly once it has delegated validation.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
The anti-slop mechanism is not just "run a code review".
The documented claim is that a stable pipeline gives "passed the gate" a fixed meaning: intent, rebase, review, test, document, lint, push, PR, and CI happen in order, and push/PR/CI happen only after local checks pass.
This prevents a common agent failure mode where the agent declares done after a narrow local edit or a self-selected test subset.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/concepts/pipeline.md`.
Concretely, it attacks slop by removing the implementing agent's discretion over what "done" means.
The implementer cannot choose to skip rebase, skip docs, skip lint, skip CI, or call a cherry-picked test enough.
The fixed ordered gate externalizes those checks into a separate executor and stops before public push if any step produces unresolved findings.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
It attacks plausible-but-wrong code by feeding author intent into review, test detection, evidence validation, documentation checks, lint fixes, CI fixes, and PR drafting.
The review step treats authoritative intent as enforceable for source-verifiable acceptance criteria, so a diff can fail because it does not do the requested thing even when it compiles and looks tidy.
The test step validates the change and requested intent with the smallest relevant evidence-oriented tests or manual checks, and when no targeted check can establish intent it must write or improve a focused test, produce evidence, or report a warning finding.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
It attacks fake tests by making source-content-only tests a first-class violation for agents that write, repair, or review tests.
Review flags newly added violations and requires same-pattern tests encountered in the accepted change's scope to be removed or made semantic.
The test guidance requires observable behavior, state, output, side effects, failure modes, or a typed or normalized semantic model instead of grepping implementation text.
Sources: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`, `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/internal/testguidance/guidance.go`.
It attacks "review theater" by requiring structured output.
The review agent returns severity, file location, description, and action, while approval rules require a pause for error or warning findings and for ask-user findings.
That makes defects machine-actionable and prevents them from disappearing inside a flattering narrative summary.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
It attacks unsafe autonomous cleanup by distinguishing mechanical fixes from intent questions.
`auto-fix` can be handed back to the pipeline, but `ask-user` is for findings that challenge the author's intent or product behavior, and review auto-fix is disabled by default.
That keeps the validation agent from silently rewriting product decisions to make its own review pass.
Sources: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`, `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
It attacks stale-base and unreviewed-history slop through rebase and push binding.
The rebase step rebases onto the latest upstream and reports conflicts, and the push step reloads the durable review-approved commit before remote mutation.
Push refuses when the approval binding is missing or when the proposed commit does not equal or descend from the reviewed commit, so later unreviewed changes cannot slip through as if they had passed review.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
It attacks "works locally but fails publicly" by putting PR creation and CI monitoring after local gates.
The CI step watches hosted CI, fetches failed job logs where supported, auto-fixes failures within limits, and pauses with findings when failures or merge conflicts persist.
This closes the gap between local agent confidence and actual host validation.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/pipeline-steps.md`.
The pipeline requires every step either to complete, return structured findings with severity and action, trigger bounded auto-fix, pause for approval when blocking or ask-user findings remain, or fail fatally.
This prevents silent degradation: unresolved review, test, docs, or lint issues become explicit findings instead of prose buried in an agent summary.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/concepts/pipeline.md`.
`no-mistakes` uses intent before review and evidence collection.
The review step can compare the diff to the user's actual goal, while the test step can run targeted validation and gather user-facing evidence when intent is known.
This targets slop where code is syntactically plausible but does not satisfy the requested behavior.
Sources: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/concepts/pipeline.md`, `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/repo-config.md`.
Repository configuration separates trusted default-branch settings from pushed-branch settings.
By default, code-executing fields such as test, lint, format commands and selected agent are read from the trusted default-branch copy, so a feature branch cannot self-authorize weaker validation commands on the daemon host.
This prevents a slop or malicious branch from weakening its own gate.
Source: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/docs/src/content/docs/reference/repo-config.md`.
The review and fix loop classifies findings as auto-fix, ask-user, or no-op, with ask-user reserved for product intent or judgment calls.
That design limits autonomous fixing to mechanical work and forces human attention where an AI could otherwise paper over a disagreement with the user's intent.
Sources: `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/README.md`, `https://raw.githubusercontent.com/kunchenguid/no-mistakes/main/skills/no-mistakes/SKILL.md`.
## Conclusion
The migrated `implement` skill should learn from `no-mistakes` that preventing AI slop requires a fixed ordered gate, rich intent, isolated validation, structured findings, bounded auto-fix, human escalation for judgment calls, trusted validation configuration, and CI-backed proof before public handoff.
It should preserve unrelated changes, commit only task scope, provide rich reviewer intent, reject source-grep pseudo-tests, and optionally hand shipping validation to an external gate that runs in a disposable worktree.
It should not blindly replace the local workflow with `no-mistakes`, because that would require repository initialization, a configured pipeline agent, and accepting the gate's branch custody model.

51
projects/skills/043-implement-skill-treehouse-research.md Normal file
View File

@@ -0,0 +1,51 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:46:29-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill treehouse research
## Question
What should the migrated `implement` skill learn from Kun Chen's `treehouse` workflow about using git worktrees for implementation sessions?
## Findings
Kun Chen's `treehouse` manages a pool of reusable isolated git worktrees per repository under a configured root, defaulting to `~/.treehouse/`.
It is designed so each agent gets its own environment instantly without cloning, conflicts, or coordination overhead, while preserving dependencies and build cache between sessions.
The migrated `implement` skill should consider worktree isolation as a stronger default than mutating the user's current checkout when the tool is available.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
Treehouse worktrees use detached HEAD reset to the local or remote default branch that is further ahead, avoiding branch-name conflicts at acquisition time.
An implementation skill that expects to create a named branch may need to create the task branch after entering or leasing the worktree, rather than relying on the worktree manager to allocate the feature branch.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
Treehouse marks worktrees as in-use through process scans and short-lived owner reservations, and has durable leases for automation with `treehouse get --lease`.
A leased worktree is never handed out later and never pruned until released with `treehouse return`.
For a non-interactive `implement` workflow, `treehouse get --lease --lease-holder <session> --json` is more appropriate than opening a subshell.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
Treehouse leases include a random `lease_id`, `lease_holder`, and `leased_at`, and `treehouse return` can require `--if-lease-id` and `--if-lease-holder`.
This gives automation ABA protection so cleanup cannot accidentally release a later acquisition of the same path.
A migrated skill should record the lease path and identity in the Wayfinder task artifact if it uses Treehouse, and release with identity checks during cleanup.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
Treehouse treats tracked changes and untracked files as dirty, even when repository config hides untracked files from normal `git status` output.
Its prune and destroy commands are dry-run or safe by default and skip dirty, unmerged, unverifiable, in-use, and leased worktrees unless explicit destructive flags are provided.
The migrated `implement` skill should preserve this safety stance and should not destroy or return a dirty leased worktree without surfacing the risk.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
Treehouse supports user-level lifecycle hooks, including `post_create`, and routes hook stdout to stderr when using `get --lease` so stdout remains machine-readable.
This makes it suitable for dependency installation, environment setup, and cache reuse outside the `implement` skill itself.
The migrated skill should avoid duplicating environment bootstrap when a worktree manager's hooks own it.
Source: `https://raw.githubusercontent.com/kunchenguid/treehouse/main/README.md`.
## Conclusion
If worktree automation is in scope, the migrated `implement` skill should prefer optional Treehouse leasing over ad hoc `git worktree` management: acquire an isolated reusable worktree, create or check out the task branch inside it, record lease identity in the ticket, avoid destructive cleanup when dirty, and release with `--if-lease-id` after successful handoff.
This should remain optional unless the user decides every implementation must run outside the current checkout.

60
projects/skills/044-implement-skill-herdr-worktree-research.md Normal file
View File

@@ -0,0 +1,60 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:46:29-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill Herdr worktree research
## Question
What Herdr worktree conventions or plugins are relevant to the migrated `implement` skill's branch and workspace handling?
## Findings
Herdr itself has built-in worktree management according to `herdr-worktrunk`'s README, which says Herdr ships `herdr worktree create/open/remove/list`.
The same source says the Worktrunk plugin exists because Worktrunk adds lifecycle hooks that Herdr's built-in worktree commands lack.
The migrated `implement` skill should not assume it must create panes itself if Herdr is already the user's workspace manager, but lifecycle setup may need a plugin or external manager.
Source: `https://raw.githubusercontent.com/devashish2203/herdr-worktrunk/main/README.md`.
`herdr-worktrunk` opens existing or newly created worktrees as either Herdr tabs or native linked-worktree workspaces, and it delegates unmerged branch and untracked-file safety to Worktrunk during removal.
This suggests an implementation workflow can treat Herdr as presentation and Worktrunk as branch/worktree lifecycle, rather than combining all responsibilities inside `implement`.
Source: `https://raw.githubusercontent.com/devashish2203/herdr-worktrunk/main/README.md`.
`herdr-sessionizer` fuzzy-opens projects and Git worktrees into configured Herdr workspaces, using layouts to bootstrap tabs, pane splits, commands, and per-repo overrides.
It supports a Worktree action to create or reopen a Git worktree workspace.
This is relevant for interactive human-driven session startup, but less relevant for a skill that should run inside an already-started Pi process.
Source: `https://raw.githubusercontent.com/andrewchng/herdr-sessionizer/main/README.md`.
`herdr-plugin-workspace-manager` applies declarative tab, pane, environment, startup-command, and agent layouts automatically to every new worktree.
It can wait until Herdr reports an agent ready for input and optionally hand it a prompt, and it can remove worktrees whose upstream branch is gone.
A future orchestration layer could use this to launch implementer/reviewer/tester panes, but the core `implement` skill should not depend on it unless the destination expands to Herdr orchestration.
Source: `https://raw.githubusercontent.com/razajamil/herdr-plugin-workspace-manager/main/README.md`.
`herdr-worktree-setup` listens for Herdr's `worktree.created` event and runs per-project setup steps such as copying `.env`, `mise trust`, `direnv allow`, and package installation.
It exposes `HERDR_MAIN_REPO`, `HERDR_WORKTREE`, and `HERDR_BRANCH` to those steps.
If `implement` uses Herdr-created worktrees, it should rely on such setup hooks rather than scripting environment copying itself.
Source: `https://raw.githubusercontent.com/tdi/herdr-worktree-setup/main/README.md`.
`herdr-worktree-from-linear` and `herdr-worktree-from-pr` create worktrees from external tracker items or PRs and open them as Herdr workspaces.
They are useful references for selecting a branch base, reusing an existing worktree, and separating worktree creation from setup plugins.
They are less directly applicable to Wayfinder Markdown task tickets unless a later decision adds a tracker bridge.
Sources: `https://raw.githubusercontent.com/tdi/herdr-worktree-from-linear/main/README.md`, `https://raw.githubusercontent.com/tdi/herdr-worktree-from-pr/main/README.md`.
`herdr-worktreeinclude` copies gitignored files matching `.worktreeinclude` into newly created Herdr worktrees and explicitly cites Claude Code's `.worktreeinclude` convention.
For implementation worktrees, this is a safer project-declared way to copy local config than having `implement` guess which ignored files are needed.
Source: `https://raw.githubusercontent.com/tanshio/herdr-worktreeinclude/main/README.md`.
`pi-herd` is a Pi-first Herdr orchestration project that creates visible lead and worker sessions, keeps source-changing roles in isolated git worktrees, and stores durable run artifacts under `.pi-herd/runs/`.
This is relevant if the implement workflow later becomes multi-agent orchestration, but it is broader than a single-ticket `implement` skill.
Source: `https://raw.githubusercontent.com/ribbons-digital/pi-herd/main/README.md`.
## Conclusion
Herdr research supports keeping worktree and pane orchestration optional and external to the core `implement` skill.
The skill should be compatible with Herdr-managed worktrees, should not duplicate lifecycle setup hooks, and should prefer project-declared mechanisms such as `.worktreeinclude` or worktree setup plugins for ignored local config.
Dedicated Herdr orchestration belongs outside the first migrated `implement` contract unless the user explicitly broadens the destination.

59
projects/skills/045-implement-skill-pi-worktree-extensions-research.md Normal file
View File

@@ -0,0 +1,59 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:46:29-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement skill Pi worktree extensions research
## Question
What Pi extension APIs or examples are relevant if the migrated `implement` workflow should integrate with git worktrees or session/workspace automation?
## Findings
Pi extensions can subscribe to lifecycle events, register custom tools, intercept tool calls, add commands, prompt users through `ctx.ui`, persist session state through entries, and customize rendering.
Extension use cases explicitly include git checkpointing, path protection, file watchers, external integrations, and CI triggers.
This means worktree integration is better suited to an optional Pi extension or external command than to static skill prose when automation needs session lifecycle hooks.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/extensions.md`.
Pi extension placement supports global and project-local extensions, with project-local `.pi/extensions` loaded only after trust resolution.
A worktree integration that runs project-controlled setup commands must respect trust boundaries and should not make the `implement` skill silently load project-local automation.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/extensions.md`.
Pi exposes session lifecycle hooks including `session_before_switch`, `session_before_fork`, `session_shutdown`, `agent_end`, and `agent_settled`.
These hooks are appropriate for guarding dirty repositories, releasing leases, updating status, or coordinating cleanup when a Pi session moves or exits.
A static skill cannot reliably perform those cleanup duties if the user abandons or forks the session mid-run.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/extensions.md`.
The `dirty-repo-guard.ts` example blocks session changes when `git status --porcelain` shows uncommitted changes, defaulting to block in non-interactive mode and asking in UI-capable modes.
This is directly aligned with the old `implement` guardrail against automatic stashing or context switching over dirty work.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/examples/extensions/dirty-repo-guard.ts`.
The `git-checkpoint.ts` example creates `git stash create` checkpoints at each turn and offers to restore the code state when forking.
It demonstrates how Pi can bind source state to conversation entries, but it also relies on stash refs and UI choice rather than durable worktree leases.
The migrated `implement` skill should not depend on this for branch isolation, but a future extension could adapt the concept to record worktree lease state against session entries.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/examples/extensions/git-checkpoint.ts`.
The `git-merge-and-resolve.ts` example fetches and merges the upstream tracking ref after each agent turn only when the working tree is clean, and sends a follow-up user message listing conflict blocks when conflicts appear.
This shows Pi extensions can safely perform git maintenance and feed actionable conflict context back to the model, but automatic merge behavior is a separate policy decision from implementing one Wayfinder task.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/examples/extensions/git-merge-and-resolve.ts`.
The subagent extension example runs separate `pi` subprocesses with isolated contexts, supports parallel and chained workflows, and includes workflow prompts such as implement-and-review.
It can load user-level and trusted project-local agent definitions, and it warns that project-local agents are repo-controlled prompts.
This is relevant if implementation later becomes a visible multi-agent pipeline, but it is not required for a single-ticket skill.
Source: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/examples/extensions/subagent/README.md`.
Pi's docs and examples do not provide a built-in git worktree manager in the inspected extension set.
They provide the extension hooks and subprocess execution APIs needed to integrate external managers such as Treehouse, Herdr, or raw `git worktree`.
Sources: `/nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs/extensions.md`, `rg "worktree" /nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/docs /nix/store/rg248h9sz8dylm8p6a9w9fj4zrv4sgm5-pi-coding-agent-0.82.1/lib/node_modules/pi-monorepo/examples/extensions`.
## Conclusion
Pi supports worktree-adjacent automation through extensions, but not a built-in worktree manager in the inspected docs and examples.
Since parallel Wayfinder implementation needs isolated working trees, the migrated `implement` workflow should plan for worktree acquisition as a real execution concern.
Dirty-repo guards, lease cleanup, visible Herdr panes, and multi-agent execution can still live in extensions or external tools unless the package-scope decision pulls them into the skill itself.

43
projects/skills/053-implement-skill-review-validation-grill.md Normal file
View File

@@ -0,0 +1,43 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T07:38:25-04:00"
blocked-by:
- "[[039-implement-skill-old-workflow-research]]"
- "[[042-implement-skill-no-mistakes-research]]"
- "[[078-implement-skill-matt-code-review-research]]"
tags:
- ticket/grill
---
# Implement workflow review skill contract grill
## Question
What should the packaged review skill be named, and what standalone review contract should it expose?
## Resolution
The packaged review skill should be named `review`.
The previous conflict with Claude Code built-ins does not apply to this packaged workflow.
`review` should preserve agent flexibility rather than overprescribing a rigid mode taxonomy.
It reviews the change set the agent selects from current context, such as uncommitted changes, branch changes, a PR, explicit files, or another clear source.
It states what change set it selected before reviewing, and asks or stops only when the scope is ambiguous enough that a trustworthy review cannot proceed.
`review` produces a structured review report, not a gate artifact and not a pass/fail verdict.
The report should cover Risk, Standards, Intent, Evidence, and Documentation when those dimensions apply.
The skill may run targeted checks when useful, but it remains report-only and does not edit code.
The skill should use independent dimension reviewers when the runtime supports subagents or isolated workers, with a single-agent fallback that preserves separate sections.
Reviewer prompt files should live under the skill directory, for example `skills/review/reviewers/`.
Each reviewer file should be self-contained about its purpose, boundary, rubric, and output expectations.
The top-level `SKILL.md` should orchestrate input capture and aggregation without overdefining each reviewer’s judgment.
Findings should use a flexible shared base schema with dimension-specific additions where useful.
The base shape includes severity, blocking yes/no, location, finding, why it matters, and suggested fix.
Reviewers classify findings as blocking or non-blocking, while the caller or user decides final disposition.
Intent handling should remain flexible.
The reviewer may use a Wayfinder task, issue, spec, direct request, branch context, or other available context as intent source when relevant, but `review` itself should not know about or mutate implementation lifecycle, Wayfinder claiming, task resolution, PR creation, or ticket closeout.

34
projects/skills/054-implement-skill-ticket-closeout-grill.md Normal file
View File

@@ -0,0 +1,34 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T11:22:04-04:00"
blocked-by:
- "[[039-implement-skill-old-workflow-research]]"
- "[[041-implement-skill-wayfinder-contract-research]]"
- "[[079-implement-skill-matt-wayfinder-research]]"
tags:
- ticket/grill
---
# Implement skill ticket closeout grill
## Question
Exactly what should `implement` write into the Wayfinder task ticket, parent map, commit, and PR body when the implementation succeeds, partially succeeds, or fails?
## Resolution
The decision tree is fully walked at the level this workflow should specify.
Do not overprescribe closeout taxonomy.
The code is the implementation artifact.
The Wayfinder ticket closeout records durable coordination facts only.
Wayfinder `status` is the lifecycle authority.
Acceptance criteria checkboxes may be updated as useful closeout detail, with `[x]` for satisfied criteria and `[-]` for deliberately dropped criteria when practical, but checkbox state is not the source of truth.
Implementation Notes should stay concise and capture only what future agents or humans need: deviations, dropped or changed scope, verification, branch, commit, PR, or why the ticket remains unresolved.
The agent uses judgment for partial or ambiguous outcomes, but must keep the recorded lifecycle honest and must not imply completion when the work is not complete.
The parent map should receive only a concise decision or outcome summary as required by Wayfinder.
Detailed implementation records belong in the task ticket, commit, PR, and working code, not in the map.

50
projects/skills/055-implement-skill-tdd-refactor-grill.md Normal file
View File

@@ -0,0 +1,50 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T10:57:40-04:00"
blocked-by:
- "[[039-implement-skill-old-workflow-research]]"
- "[[042-implement-skill-no-mistakes-research]]"
- "[[077-implement-skill-matt-tdd-research]]"
- "[[065-implement-workflow-codebase-design-research]]"
tags:
- ticket/grill
---
# Implement workflow TDD skill contract grill
## Question
What standalone `test-driven-development` skill contract should the workflow expose, and how should it carry the necessary public-interface, seam-placement, test-quality, prefactoring, and refactoring guidance without requiring a separate packaged `codebase-design` skill?
## Resolution
`codebase-design` should not be packaged as part of this workflow.
The useful public-interface and seam guidance should be folded into `test-driven-development` and `review` instead.
`test-driven-development` should include only minimal practical seam guidance: test public behavior through the interface the code exposes or the task requires, identify the smallest public seam that can prove the behavior when unclear, and avoid testing internals just to make RED easy.
Tests are always written by someone other than the agent doing implementation.
The normal contract requires an independent test writer.
If the runtime truly cannot spawn an independent worker, the implementation agent must state that limitation before writing tests and preserve the role separation in-process as much as possible.
The implementation agent must not silently skip this requirement.
Use role names by function.
The implementation agent changes production code and drives the loop.
The test writer writes and edits tests.
The implementation agent gives the test writer one behavior, the public seam and context, an independent expected-value source, and failure output.
The implementation agent must not edit test-writer-authored tests.
Mechanical test defects go back to the test writer.
Semantic disagreement pauses for user or intent clarification.
The implementation agent may keep a private behavior backlog, but that backlog is isolated from the test writer.
The test writer receives one behavior at a time, writes one failing test, and then the implementation agent makes the minimal production change to pass.
Repeat the loop one behavior at a time.
Each test needs an independent source of truth for expected values, such as a spec, task, intent excerpt, worked example, known-good literal, existing behavior being preserved, user clarification, or external standard.
The implementation agent's derived computation is not enough.
Refactoring should match the old local `test-driven-development` behavior.
Never refactor while RED.
After tests pass, the implementation agent may refactor production code.
Test writer updates tests only for deliberate public seam changes or test defects.

28
projects/skills/056-implement-skill-package-scope-grill.md Normal file
View File

@@ -0,0 +1,28 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T11:32:36-04:00"
blocked-by:
- "[[041-implement-skill-wayfinder-contract-research]]"
- "[[045-implement-skill-pi-worktree-extensions-research]]"
tags:
- ticket/grill
---
# Implement skill package scope grill
## Question
Beyond the now-in-scope packaged `implement`, `test-driven-development`, and `review` skills, should this migration also deliver legacy compatibility shims or documentation for how an out-of-scope Pi worktree extension should integrate?
## Resolution
No extras are in scope.
This migration should deliver only the three packaged skills: `implement`, `test-driven-development`, and `review`.
Do not add legacy `.claude/tasks` compatibility shims.
Old task files may be ordinary context only if an agent chooses to read them, but this workflow should not preserve their lifecycle semantics.
Do not add dedicated documentation for a future Pi worktree extension, Herdr, or Treehouse integration.
Worktree orchestration remains out of scope and can define its own contract later.

53
projects/skills/065-implement-workflow-codebase-design-research.md Normal file
View File

@@ -0,0 +1,53 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T00:00:00-04:00"
blocked-by: []
tags:
- ticket/research
---
# Implement workflow codebase design research
## Question
What role should `codebase-design` have in the packaged Wayfinder-aware implementation workflow, especially for `test-driven-development` and review?
## Findings
The old local `codebase-design` skill and Matt Pocock's `codebase-design` skill are nearly the same direct counterpart.
Both define deep-module vocabulary around module, interface, implementation, depth, seam, adapter, leverage, and locality.
Both aim to make code more testable and maintainable by placing behavior behind a small interface at a clean seam.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/codebase-design/SKILL.md`, `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/codebase-design/SKILL.md`.
The old local `test-driven-development` skill explicitly invokes `/codebase-design` during planning to identify deep modules and testability checks, regardless of what triggered TDD.
That makes `codebase-design` part of the old implementation workflow's dependency graph, not just an opportunistic extra.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/SKILL.md`.
The important testing contract is that the interface is the test surface.
Codebase-design says callers and tests cross the same seam, and if tests need to reach past the interface then the module is probably the wrong shape.
This directly supports the TDD and no-mistakes anti-slop rules against implementation-coupled tests.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/codebase-design/SKILL.md`.
The deepening reference classifies dependencies as in-process, local-substitutable, remote-but-owned, or true external, and maps each category to a testing strategy.
This gives `test-driven-development` a concrete way to choose where a seam goes and what adapter or stand-in is legitimate for tests.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/codebase-design/DEEPENING.md`.
The deepening reference also says to replace, not layer, tests when deepening shallow modules.
Old unit tests on shallow modules become waste once tests exist at the deepened module interface, and tests should assert observable outcomes through the interface rather than internal state.
This is relevant to implementation slices that include prefactoring before behavior.
Source: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/codebase-design/DEEPENING.md`.
The design-it-twice reference is a heavier HITL or parallel-agent pattern for exploring alternative interfaces.
It is useful when a task reveals that seam placement or interface shape is a substantive design decision, but it should not become a mandatory step in every implementation slice.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/codebase-design/DESIGN-IT-TWICE.md`, `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/codebase-design/DESIGN-IT-TWICE.md`.
The packaged local skills repository does not currently contain a packaged `codebase-design` skill.
If the workflow includes a packaged `test-driven-development` skill that depends on codebase-design vocabulary, either `codebase-design` should be packaged too, or the TDD skill must inline enough of the deep-module and seam-placement contract to stand alone.
Source: `/home/alexion/wrk/skills/skills`.
## Conclusion
Add `codebase-design` to the implementation workflow scope or explicitly inline its deep-module seam guidance into `test-driven-development` and review.
The cleaner workflow is to package `codebase-design` as a supporting skill because TDD, review, and implementation all need the same vocabulary for seams, interfaces, adapters, test surfaces, and prefactoring.

40
projects/skills/069-implement-workflow-dependency-orchestration-grill.md Normal file
View File

@@ -0,0 +1,40 @@
---
status: resolved
parent: "[[053-implement-skill-review-validation-grill]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T11:35:19-04:00"
blocked-by:
- "[[053-implement-skill-review-validation-grill]]"
- "[[055-implement-skill-tdd-refactor-grill]]"
tags:
- ticket/grill
---
# Implement workflow dependency orchestration grill
## Question
How should `implement` invoke, sequence, and consume the workflow's supporting skills and tools, including `test-driven-development` and `review`?
## Resolution
`implement` should use `test-driven-development` as a strong default when behavior can be usefully specified and tested before implementation.
It may skip TDD when the work is mechanical, documentation-only, exploratory, or when test-first would not add value.
Skipping TDD should be an agent judgment rather than an accident.
`test-driven-development` is process discipline, not a separate artifact.
`implement` records only durable outcomes such as tests added or changed, verification run, and deviations worth noting.
It should not require a TDD report or per-cycle log.
`implement` must run `review` before final handoff or Wayfinder task resolution.
Timing is left to agent judgment: review may happen before commit, after commit, or both.
The review must cover the final intended handoff state, or the agent must explain why it does not.
Blocking review findings should be fixed unless explicitly accepted by the agent or user.
When code changes are made in response to review, `implement` reruns review on the relevant change set.
Accepted blocking findings are recorded where appropriate.
Non-blocking findings are handled by agent judgment: fix when cheap or high-value, otherwise report or record only when useful.
No other supporting skill invocations are prescribed.
The agent may use any skill or tool it judges relevant, but only `test-driven-development` and `review` are named workflow dependencies.
External validation gates such as `no-mistakes` are not part of this implementation workflow.

200
projects/skills/074-implement-workflow-implementation-spec.md Normal file
View File

@@ -0,0 +1,200 @@
---
parent: "[[038-implement-skill-map]]"
tags:
- spec
---
# Implement workflow implementation spec
## Goal
Package the Wayfinder-aware implementation workflow as three skills in this repository: `implement`, `test-driven-development`, and `review`.
The implementation should create source under `skills/implement/`, `skills/test-driven-development/`, and `skills/review/`.
The packaged workflow should carry forward the old Claude Code execution, TDD, and review behavior named in this spec while avoiding legacy `.claude/tasks` lifecycle mechanics.
## Source references
Use these old local skills as source material:
- `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/`
- `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/`
- `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/review-uncommitted/`
Use `[[038-implement-skill-map]]` as the authoritative decision record.
## Deliverables
Create exactly these packaged skills:
- `skills/implement/SKILL.md`
- `skills/test-driven-development/SKILL.md`
- `skills/review/SKILL.md`
Create these reviewer prompt files under `skills/review/reviewers/` for independent review dimensions:
- `skills/review/reviewers/risk.md`
- `skills/review/reviewers/standards.md`
- `skills/review/reviewers/intent.md`
- `skills/review/reviewers/evidence.md`
- `skills/review/reviewers/documentation.md`
Do not package `codebase-design` as part of this workflow.
Fold only the necessary public-interface and seam guidance into `test-driven-development` and `review`.
## Scope exclusions
Do not add legacy `.claude/tasks` compatibility shims.
Old task files may be ordinary context if an agent chooses to read them, but this workflow must not preserve their lifecycle semantics.
Do not build a Pi extension for worktree orchestration, dirty-repo guards, lease cleanup, visible Herdr panes, or multi-agent execution.
Do not add dedicated Herdr, Treehouse, or future worktree-extension integration documentation.
The skills should remain compatible with external orchestration by assuming the current checkout is the assigned execution checkout.
Do not integrate external validation gates such as `no-mistakes` into `implement`.
The no-mistakes research informs local review and TDD design, not a direct runtime dependency.
## `implement` skill contract
`implement` is a workflow executor for scoped implementation work.
It must not police what work the agent is allowed to implement.
It defines execution protocol.
When selected work has a Wayfinder task artifact, `implement` must follow Wayfinder claim, blocker, result, resolution, and Frontier protocol.
When selected work has no Wayfinder artifact, `implement` proceeds with normal implementation, review, commit, and handoff protocol.
In both cases, the implementation artifact is the working code.
`implement` is worktree-compatible, not a worktree orchestrator.
It assumes the current session already has the right checkout.
It should report the checkout and branch it used.
It should not create, lease, clean up, or switch worktrees.
Before changing code, `implement` checks dirty state.
It stops on unrelated or ambiguous uncommitted changes.
It continues only when dirty state is clearly already part of the selected work.
It never auto-stashes.
When starting new work, `implement` uses or creates a non-default branch from an updated default branch when needed.
If an appropriate non-default branch is already prepared, it continues there.
If it must create a branch, branch naming follows repository, user, or orchestrator convention.
If no convention is discoverable, it chooses a clear short descriptive branch name and reports it.
`implement` preserves the old blocker reachability guardrail.
It checks declared blockers where they exist.
It stops when prerequisite implementation work is not reachable from the current base and reports the likely unmerged prerequisite.
It does not automatically branch from, merge, or cherry-pick sibling task work.
Explicit integration-branch or wide-refactor exceptions follow the plan that names the exception.
`implement` uses `test-driven-development` as a strong default when behavior can usefully be specified and tested before implementation.
It may skip TDD when the work is mechanical, documentation-only, exploratory, or when test-first would not add value.
Skipping TDD should be agent judgment, not omission.
`implement` must run `review` before final handoff or Wayfinder task resolution.
Review timing is agent judgment.
Review may happen before commit, after commit, or both.
The review must cover the final intended handoff state, or the agent must explain why it does not.
Blocking review findings should be fixed unless explicitly accepted by the agent or user.
When code changes are made in response to review, `implement` reruns review on the relevant change set.
Accepted blocking findings are recorded in the final handoff or Wayfinder closeout when they affect a future reader's decision to trust or continue the work.
Non-blocking findings are handled by agent judgment.
`implement` should record only durable closeout facts.
For Wayfinder task closeout, `status` is the lifecycle authority.
Acceptance criteria checkboxes may be updated as useful detail with `[x]` for satisfied and `[-]` for deliberately dropped criteria when practical.
Checkbox state is not the source of truth.
Implementation Notes should stay concise and capture only what future agents or humans need: deviations, dropped or changed scope, verification, branch, commit, PR, or why the ticket remains unresolved.
Partial or ambiguous outcomes are left to agent judgment, but lifecycle recording must be honest.
## `test-driven-development` skill contract
`test-driven-development` is process discipline, not a report-producing artifact.
Its result is working behavior plus useful tests.
Tests are always written by someone other than the agent doing implementation.
The normal contract requires an independent test writer.
If the runtime truly cannot spawn an independent worker, the implementation agent must state that limitation before writing tests and preserve role separation in-process as much as possible.
The implementation agent must not silently skip this requirement.
Use role names by function.
The implementation agent changes production code and drives the loop.
The test writer writes and edits tests.
The implementation agent gives the test writer one behavior, public seam and context, an independent expected-value source, and failure output.
The implementation agent must not edit test-writer-authored tests.
Mechanical test defects go back to the test writer.
Semantic disagreement pauses for user or intent clarification.
The implementation agent may keep a private behavior backlog, but that backlog is isolated from the test writer.
The test writer receives one behavior at a time, writes one failing test, and then the implementation agent makes the minimal production change to pass.
Repeat one behavior at a time.
Each test needs an independent source of truth for expected values.
Acceptable sources include a spec, task, intent excerpt, worked example, known-good literal, existing behavior being preserved, user clarification, or external standard.
The implementation agent's derived computation is not enough.
Include minimal public-interface and seam guidance.
Tests should target public behavior through the interface the code exposes or the task requires.
When the seam is unclear, identify the smallest public seam that can prove the behavior.
Avoid testing internals just to make RED easy.
Preserve the old local refactoring behavior.
Never refactor while RED.
After tests pass, the implementation agent may refactor production code.
The test writer updates tests only for deliberate public seam changes or test defects.
## `review` skill contract
The review skill is named `review`.
It is standalone and context-driven.
It does not know about implementation lifecycle, Wayfinder claiming, task resolution, PR creation, or ticket closeout.
`review` selects the relevant change set from current context.
The selected change set may be uncommitted changes, branch changes, a PR, explicit files, or another clear source.
It states what change set it selected before reviewing.
It asks or stops only when scope ambiguity would make the review untrustworthy.
`review` produces a structured review report, not a gate artifact and not a pass/fail verdict.
It remains report-only and must not edit code.
It may run targeted checks when useful.
The report should cover Risk, Standards, Intent, Evidence, and Documentation when those dimensions apply.
Do not overprescribe mode selection or intent-source taxonomy.
The skill should leave room for agent judgment when the selected change set and intent source are clear enough to review.
Use independent dimension reviewers when the runtime supports subagents or isolated workers.
Fallback to a single-agent review when independent workers are unavailable, but preserve separate report sections.
Reviewer prompt files live under `skills/review/reviewers/`.
Each reviewer file should be self-contained about its purpose, boundary, rubric, and output expectations.
The top-level `SKILL.md` orchestrates input capture and aggregation without overdefining each reviewer’s judgment.
Findings should use a flexible shared base schema with dimension-specific additions where useful.
The base shape includes severity, blocking yes/no, location, finding, why it matters, and suggested fix.
Reviewers classify findings as blocking or non-blocking.
The caller or user decides final disposition.
The Evidence reviewer should incorporate the anti-slop lessons from no-mistakes.
It should reject source-grep pseudo-tests as proof of behavior.
It should prefer evidence that demonstrates observable behavior, state, output, side effects, failure modes, or semantic meaning.
## Verification
After implementing the skills, run the repository verification expected for packaged skills.
At minimum run:
```bash
nix flake check "path:$PWD"
```
Use `nix flake check "path:$PWD"` rather than plain `nix flake check` when new skill files are untracked, because plain flake evaluation uses the Git snapshot.
## Acceptance criteria
- [ ] `skills/implement/SKILL.md` exists and implements the contract above.
- [ ] `skills/test-driven-development/SKILL.md` exists and implements the contract above.
- [ ] `skills/review/SKILL.md` exists and implements the contract above.
- [ ] `skills/review/reviewers/risk.md`, `skills/review/reviewers/standards.md`, `skills/review/reviewers/intent.md`, `skills/review/reviewers/evidence.md`, and `skills/review/reviewers/documentation.md` exist.
- [ ] The workflow does not add packaged `codebase-design`.
- [ ] The workflow does not add legacy `.claude/tasks` lifecycle compatibility.
- [ ] The workflow does not build or document a dedicated worktree orchestration integration.
- [ ] Repository verification passes with `nix flake check "path:$PWD"`.

42
projects/skills/075-implement-skill-matt-implement-research.md Normal file
View File

@@ -0,0 +1,42 @@
---
status: resolved
parent: "[[040-implement-skill-matt-skills-discovery-research]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:47:59-04:00"
blocked-by:
- "[[040-implement-skill-matt-skills-discovery-research]]"
tags:
- ticket/research
---
# Implement skill Matt implement research
## Question
What should the migrated local `implement` skill preserve, adapt, or reject from Matt Pocock's `skills/engineering/implement` skill?
## Findings
Matt Pocock's `implement` skill is explicitly invoked and disabled for model invocation, like the old local skill.
It accepts "a spec or set of tickets" rather than a single required task-file path.
The migrated local skill should keep explicit invocation, but decide whether to allow maps, specs, or multiple tickets or to preserve one-ticket execution for Wayfinder claim safety.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/implement/SKILL.md`.
Matt's skill says to implement the work described by the user in the spec or tickets, use `/tdd` where possible at pre-agreed seams, run typechecking regularly, run single test files regularly, and run the full test suite once at the end.
This aligns with the old local workflow and should be preserved.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/implement/SKILL.md`.
Matt's skill reviews with `/code-review` once done and commits work to the current branch.
It does not prescribe syncing `main`, creating a branch, staging specifically, pushing, opening a PR, or closing out a ticket artifact.
The migrated skill should not import this omission wholesale because Wayfinder task lifecycle and old local guardrails need stronger state handling.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/implement/SKILL.md`.
There is no packaged local `implement` counterpart yet, so the practical local counterpart is the old dotfiles `/implement` skill.
Compared with Matt's minimal version, the old local skill owns branch creation, blocker reachability checks, review report reuse, task-file closeout, commit convention discovery, push, PR creation, and final reporting.
The migration should deliberately choose which of those local responsibilities remain in the packaged skill rather than defaulting to Matt's current-branch commit-only model.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/implement/SKILL.md`, `/home/alexion/wrk/skills/skills`.
## Conclusion
Matt's `implement` is useful as a simplicity reference: implement from an explicit spec or tickets, use TDD at agreed seams, verify regularly, review, and commit.
The migrated local skill should remain stricter than Matt's around Wayfinder claiming, branch setup, artifact closeout, and PR or handoff reporting.

43
projects/skills/076-implement-skill-matt-to-tickets-research.md Normal file
View File

@@ -0,0 +1,43 @@
---
status: resolved
parent: "[[040-implement-skill-matt-skills-discovery-research]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:47:59-04:00"
blocked-by:
- "[[040-implement-skill-matt-skills-discovery-research]]"
tags:
- ticket/research
---
# Implement skill Matt to tickets research
## Question
What should the migrated local `implement` skill learn from Matt Pocock's `skills/engineering/to-tickets` ticket, blocker, frontier, and slicing model?
## Findings
Matt's `to-tickets` creates tracer-bullet vertical tickets with blocking edges and a frontier of tickets whose blockers are all done.
Each ticket should deliver a complete path through every required layer, be demoable or verifiable on its own, and fit in a single fresh context window.
The migrated `implement` skill should expect tickets to be coherent implementation slices, not arbitrary file-edit lists.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/to-tickets/SKILL.md`.
Matt's skill includes a wide-refactor exception to strict vertical slicing.
For one mechanical change whose blast radius breaks too many call sites, it recommends expand-contract: add the new form, migrate batches, then delete the old form, with an integration branch only when batches cannot stay green alone.
The migrated `implement` skill needs special handling for task tickets that declare an integration-branch exception, because the old local rule of always branching from `main` may not fit that exceptional path.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/to-tickets/SKILL.md`.
Matt's publishing model depends on an issue tracker, native blocking links where available, and a `ready-for-agent` label.
The local `slice` skill has already adapted this to Wayfinder Markdown task artifacts with `status`, `parent`, `blocked-by`, and Frontier semantics.
The migrated `implement` skill should consume the local Wayfinder representation rather than Matt's tracker labels.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/to-tickets/SKILL.md`, `/home/alexion/Documents/ai-artifacts/projects/skills/031-slice-skill-map.md`.
Compared with the packaged local `slice` skill, Matt's `to-tickets` sizes tickets to a fresh context window and publishes to a tracker, while `slice` sizes slices as coherent single commits and writes Wayfinder `ticket/task/afk` or `ticket/task/human` artifacts.
`slice` also has explicit review-before-write output shape, destination artifact rules, parent-vs-blocker distinction, and map Frontier repair.
`implement` should treat `slice` as the authoritative local producer contract and Matt's skill as upstream rationale for tracer bullets and wide-refactor handling.
Sources: `/home/alexion/wrk/skills/skills/slice/SKILL.md`, `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/to-tickets/SKILL.md`.
## Conclusion
Matt's `to-tickets` reinforces tracer-bullet, blocker, frontier, and wide-refactor concepts.
The migrated `implement` skill should preserve those concepts but reject tracker labels and issue-specific publication mechanics in favor of Wayfinder task metadata.

43
projects/skills/077-implement-skill-matt-tdd-research.md Normal file
View File

@@ -0,0 +1,43 @@
---
status: resolved
parent: "[[040-implement-skill-matt-skills-discovery-research]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:47:59-04:00"
blocked-by:
- "[[040-implement-skill-matt-skills-discovery-research]]"
tags:
- ticket/research
---
# Implement skill Matt TDD research
## Question
What should the migrated local `implement` skill learn from Matt Pocock's `skills/engineering/tdd` testing workflow?
## Findings
Matt's TDD skill centers testing on public seams.
It says tests verify behavior through public interfaces, not implementation details, and that seams must be agreed before writing tests.
The migrated `implement` skill should preserve pre-agreed seams and should source them from the Wayfinder task when present instead of re-litigating them by default.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/tdd/SKILL.md`.
Matt's TDD skill rejects implementation-coupled tests, tautological expected values, and horizontal slicing.
It requires red before green, one seam, one test, one minimal implementation per cycle, and no speculative features.
These rules align with the old local TDD dependency and Kun Chen's no-mistakes test-quality rule.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/tdd/SKILL.md`.
Matt's TDD skill says refactoring belongs to the review stage, not the red-green implementation cycle.
The local old TDD skill allows refactoring after all tests pass.
The migrated `implement` skill should decide whether to keep local post-green refactoring or adopt Matt's stricter review-stage boundary.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/tdd/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/SKILL.md`.
The packaged local skills repository does not currently contain a packaged `tdd` skill.
The available local counterpart is the old Claude Code `test-driven-development` skill in dotfiles, which is more prescriptive than Matt's skill: it uses a test-writer sub-agent, forbids the main agent from editing sub-agent-authored tests, and carries detailed anti-tautology and mocking guidance.
If `implement` is packaged before `tdd`, it cannot declare a packaged `tdd` dependency without also migrating that skill or inlining the necessary testing rules.
Sources: `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/test-driven-development/SKILL.md`, `/home/alexion/wrk/skills/skills`.
## Conclusion
The migrated `implement` skill should preserve Matt's public-seam, anti-tautology, one-test-at-a-time TDD discipline.
The remaining decision is whether refactoring is allowed as a post-green implementation step or only after review.

46
projects/skills/078-implement-skill-matt-code-review-research.md Normal file
View File

@@ -0,0 +1,46 @@
---
status: resolved
parent: "[[040-implement-skill-matt-skills-discovery-research]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:47:59-04:00"
blocked-by:
- "[[040-implement-skill-matt-skills-discovery-research]]"
tags:
- ticket/research
---
# Implement skill Matt code review research
## Question
What should the migrated local `implement` skill learn from Matt Pocock's `skills/engineering/code-review` workflow?
## Findings
Matt's `code-review` reviews the diff between `HEAD` and a fixed point supplied by the user, using three-dot diff against the merge base and listing commits with `git log <fixed-point>..HEAD --oneline`.
This branch-level review fits a committed implementation branch better than the old local `/review-uncommitted`, which reviews `git diff HEAD` before commit.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/code-review/SKILL.md`.
Matt's review has two axes: Standards and Spec.
It deliberately keeps the axes separate so spec fidelity cannot hide code-quality problems and standards compliance cannot hide incorrect behavior.
The old local review adds a Risk axis.
A migrated `implement` skill should decide whether to run uncommitted three-axis review before commit, branch-level two-axis review after commit, or both.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/code-review/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/review-uncommitted/SKILL.md`.
Matt's review locates spec sources from issue references in commits, explicit arguments, matching PRD/spec files, or user clarification, and it asks for tracker setup if issue tracker docs are missing.
For Wayfinder, the explicit task ticket artifact should be the primary spec source, with parent map or artifacts loaded only when needed.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/code-review/SKILL.md`.
Matt's Standards axis includes a Fowler-smell baseline and documented-standard override, matching the old local review's standards approach.
This should be preserved because it gives review teeth even when the repository has sparse standards docs.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/code-review/SKILL.md`, `/home/alexion/wrk/dotfiles/modules/agents/claude-code/skills/review-uncommitted/SKILL.md`.
The packaged local skills repository does not currently contain a direct `code-review` or `review-uncommitted` counterpart.
Its packaged `axi-review` skill is a black-box CLI conformance review against AXI principles, not a code diff review, so it is not a substitute for Matt's `code-review` in the migrated `implement` workflow.
A migrated packaged `implement` must either package or depend on a new local review skill, inline a review gate, or call an external review workflow explicitly.
Source: `/home/alexion/wrk/skills/skills/axi-review/SKILL.md`.
## Conclusion
Matt's `code-review` suggests branch-level review against a fixed point may be a better final gate than uncommitted review alone.
The migrated `implement` skill should preserve separate Standards and Spec axes, keep the smell baseline, use the Wayfinder task as spec source, and decide whether to retain the local Risk axis and pre-commit timing.

46
projects/skills/079-implement-skill-matt-wayfinder-research.md Normal file
View File

@@ -0,0 +1,46 @@
---
status: resolved
parent: "[[040-implement-skill-matt-skills-discovery-research]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-07-31T23:47:59-04:00"
blocked-by:
- "[[040-implement-skill-matt-skills-discovery-research]]"
tags:
- ticket/research
---
# Implement skill Matt Wayfinder research
## Question
What should the migrated local `implement` skill learn from Matt Pocock's `skills/engineering/wayfinder` workflow, and what tracker-specific assumptions should it reject?
## Findings
Matt's Wayfinder is planning by default and says the pull to do the work usually means the map has reached its edge and should hand off.
This matches the local Wayfinder contract and confirms that `implement` should be explicitly invoked as the executor rather than folded into Wayfinder's normal planning loop.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/wayfinder/SKILL.md`, `/home/alexion/.pi/agent/skills/wayfinder/SKILL.md`.
Matt's Wayfinder stores maps and tickets as issue-tracker issues with labels, child issues, assignees as claims, native blocking relationships, and tracker frontier queries.
The local packaged Wayfinder stores them as AI-artifacts Markdown files with YAML `status`, `parent`, `blocked-by`, `claimed-by`, `claimed-at`, tags, and wikilinks.
The migrated `implement` skill should reject Matt's issue IDs, labels, assignees, and native tracker blocking as local storage assumptions.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/wayfinder/SKILL.md`, `/home/alexion/wrk/skills/skills/wayfinder/SKILL.md`, `/home/alexion/.pi/agent/skills/wayfinder/ARTIFACTS.md`.
Compared with packaged local Wayfinder, Matt's version treats tasks as prerequisites that unblock decisions, while the local ecosystem also has `slice` creating implementation handoff task artifacts.
This means `implement` must not infer implementation intent from Matt-style Wayfinder task semantics alone.
It should require the local implementation-task producer contract, map Notes, or explicit user selection to distinguish implementation tasks from planning prerequisite tasks.
Sources: `/home/alexion/wrk/skills/skills/wayfinder/SKILL.md`, `/home/alexion/wrk/skills/skills/slice/SKILL.md`.
Matt's Wayfinder defines Research, Prototype, Grilling, and Task tickets, and says Task work earns its place by unblocking a decision rather than delivering the destination.
The local Wayfinder makes the same distinction but also has `slice` produce implementation task tickets as explicit destination-work handoff artifacts.
The migrated `implement` skill should distinguish planning tasks from implementation tasks by map Notes, ticket body, and producer convention instead of treating every `ticket/task/afk` as implementation work.
Sources: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/wayfinder/SKILL.md`, `/home/alexion/Documents/ai-artifacts/projects/skills/031-slice-skill-map.md`.
Matt's Wayfinder says HITL tickets only resolve through live exchange and the agent never speaks for the human's side.
The migrated `implement` skill should preserve this by refusing to execute HITL tickets as AFK implementation.
Source: `https://raw.githubusercontent.com/mattpocock/skills/main/skills/engineering/wayfinder/SKILL.md`.
## Conclusion
Matt's Wayfinder reinforces the planning-versus-execution boundary, HITL protection, and frontier/claim concepts.
The migrated local `implement` skill should adapt only those concepts and reject tracker-specific labels, child-issue assumptions, assignee claims, issue IDs, and native blocking mechanics.

29
projects/skills/080-implement-skill-ticket-scope-grill.md Normal file
View File

@@ -0,0 +1,29 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T07:12:41-04:00"
blocked-by:
- "[[039-implement-skill-old-workflow-research]]"
- "[[041-implement-skill-wayfinder-contract-research]]"
- "[[075-implement-skill-matt-implement-research]]"
- "[[079-implement-skill-matt-wayfinder-research]]"
tags:
- ticket/grill
---
# Implement skill ticket scope grill
## Question
Should the migrated `implement` skill execute only one explicit actionable Wayfinder implementation task ticket, or should it also accept maps, specs, multiple tickets, or legacy task files?
## Resolution
The `implement` skill should not prescribe what work the agent is allowed to implement.
It defines the execution protocol, not the admissible work-source taxonomy.
The artifact produced by implementation is the working code.
When the selected work has a Wayfinder task artifact, `implement` follows the Wayfinder protocol for claim, blocker awareness, result recording, resolution, and Frontier repair.
When the selected work does not have a Wayfinder artifact, `implement` proceeds with the normal implementation, review, commit, and handoff protocol without creating or requiring a tracking artifact.
The skill should not police whether the work should have been a Wayfinder ticket.

42
projects/skills/081-implement-skill-branch-worktree-policy-grill.md Normal file
View File

@@ -0,0 +1,42 @@
---
status: resolved
parent: "[[038-implement-skill-map]]"
claimed-by: "019fbb66-80d0-7a01-8ac9-01255adfc7b2"
claimed-at: "2026-08-01T07:19:49-04:00"
blocked-by:
- "[[039-implement-skill-old-workflow-research]]"
- "[[043-implement-skill-treehouse-research]]"
- "[[044-implement-skill-herdr-worktree-research]]"
- "[[045-implement-skill-pi-worktree-extensions-research]]"
- "[[076-implement-skill-matt-to-tickets-research]]"
tags:
- ticket/grill
---
# Implement skill branch worktree policy grill
## Question
What branch and worktree policy should `implement` follow for normal tickets, parallel Wayfinder task execution, and wide-refactor or integration-branch exceptions?
## Resolution
`implement` should assume the caller, current session, future Pi extension, Treehouse, Herdr, or human operator has already provided the right checkout.
It is worktree-compatible, not a worktree orchestrator.
It verifies and reports the checkout where it is working, but it does not create, lease, clean up, or switch worktrees.
Before starting, `implement` checks for uncommitted changes.
It stops when changes are unrelated or ambiguous, and continues only when the dirty state is clearly already part of the selected work.
It never auto-stashes.
When starting new work, `implement` uses or creates a non-default branch from an updated default branch.
If it is already on an appropriate non-default branch prepared for this work, it continues.
If it is on the default branch, it fast-forwards the default branch and creates a task branch.
If the default branch cannot fast-forward cleanly, it stops.
Branch naming follows repository, user, or orchestrator convention.
If no convention is discoverable and `implement` must create a branch, it chooses a clear short descriptive name and reports it.
Dependency branch handling preserves the old `/implement` guardrail.
`implement` checks declared blockers and stops when prerequisite implementation work is not reachable from the current base, reporting which prerequisite appears unmerged.
It does not automatically branch from, merge, or cherry-pick sibling task work.
Explicitly planned integration-branch or wide-refactor exceptions may use the branch strategy stated by the plan.