Clear reconciled wayfinder subagents

AGENTS.md

@@ -32,3 +32,5 @@ The domain glossary lives at `$(xdg-user-dir DOCUMENTS)/ai-artifacts/projects/sk
   Customize only the surfaces required to fit the local workflow rather than turning incidental choices into new contracts.
 - The installed `gitea-axi pr view` does not support `--fields`.
   Use plain `gitea-axi pr view <number>`.
+- Wayfinder `ticket/task/human` tickets can still be implementation work.
+  They are blocked only at the point where human input is required.

skills/grill/SKILL.md

@@ -10,6 +10,9 @@ Keep going not until it feels like you understand each other, but until the deci
 
 Ask one question at a time, in plain text, and wait for the answer before the next.
 Never use an interactive question tool.
+While the interview is active, every assistant turn must end with exactly one of: the next numbered question, the final decision summary, or a plain statement that grill is paused because the user explicitly changed tasks.
+If the turn includes a correction, file edit, apology, or explanation, follow it with the next numbered question unless the user explicitly paused grill or changed tasks.
+Do not use dangling transition phrases such as “continuing” unless the continuation is actually present in the same message.
 Every question carries **options** — the concrete choices, each with its trade-offs — followed by your **recommendation**, the option you would pick and why.
 When the question turns on an existing document, artifact, or piece of code, open it with a **context quote**: blockquote the exact passage, so the user sees what you mean without hunting for it.
 

skills/implement/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: implement
+description: Implement scoped work using the local implementation workflow, following Wayfinder ticket protocol when an implementation ticket artifact is part of the selected work.
+disable-model-invocation: true
+---
+
+# implement
+
+Implement scoped work and hand off working code.
+This skill defines execution protocol rather than deciding what work the agent is allowed to implement.
+When selected work has a Wayfinder ticket artifact, follow the Wayfinder artifact lifecycle.
+When selected work has no Wayfinder artifact, implement normally and use the same review, commit, and handoff discipline without creating a tracking artifact.
+
+This skill delegates to other skills by name.
+Before satisfying a delegated skill step, explicitly load that skill's `SKILL.md` with `read` unless the harness has already injected that skill's full content into the current context.
+Do not satisfy a delegated skill step by imitating its title from memory.
+
+## 1. Establish the selected work
+
+Identify the work to implement from the user's request and current context.
+Use a Wayfinder implementation ticket artifact, issue, spec, direct request, branch context, or other clear source when that is what the agent has selected.
+Do not require a Wayfinder artifact and do not create one just to satisfy this skill.
+Old `.claude/tasks` files may be ordinary context, but their lifecycle semantics are not part of this workflow.
+
+When the selected work has a Wayfinder ticket artifact, re-read it before claiming.
+Verify that blockers are satisfied by the artifact metadata and that no other session has claimed it.
+Claim it before changing code by setting `status: claimed`, `claimed-by` to the current session identifier, and `claimed-at` to the current timestamp.
+Use `PI_SESSION_ID` when available.
+
+Done when the selected work is clear, and any Wayfinder ticket artifact is freshly read and claimed when applicable.
+
+## 2. Verify the execution checkout
+
+Assume the current checkout is the assigned execution checkout.
+Do not create, lease, clean up, or switch worktrees.
+Report the checkout path and branch when useful for handoff.
+
+Check the working tree before changing code.
+Stop on unrelated or ambiguous uncommitted changes.
+Continue only when dirty state is clearly already part of the selected work.
+Never auto-stash.
+
+For source-changing implementation work that will be committed, work on a non-default branch unless repository context explicitly directs otherwise.
+If an appropriate non-default branch is already prepared, continue there.
+If you are on the default branch, fast-forward the default branch first and create a task branch.
+Stop if the default branch cannot fast-forward cleanly.
+Follow repository, user, or orchestrator branch naming conventions.
+If no convention is discoverable and you must create a branch, choose a clear short descriptive name and report it.
+
+Check declared implementation blockers where they exist.
+Stop when prerequisite implementation work is not reachable from the current base, and report the likely unmerged prerequisite.
+Do not automatically branch from, merge, or cherry-pick sibling task work.
+Follow an explicit integration-branch or wide-refactor plan only when the selected work names that exception.
+
+Done when the checkout, branch, dirty state, and reachable prerequisites are safe for the selected implementation work.
+
+## 3. Implement the work
+
+Use `test-driven-development` as a strong default when behavior can usefully be specified and tested before implementation.
+Load `test-driven-development` before deciding whether it applies.
+Skip it only when the work is mechanical, documentation-only, exploratory, or when test-first would not add value.
+When skipping it, state the reason before implementation.
+Skipping test-driven development is an agent judgment, not an omission.
+
+Build the selected work in the assigned checkout.
+Run focused verification while working and run broader verification when the repository or change calls for it.
+Treat working code and tests as the implementation artifact.
+Do not create a separate process report for test-driven development.
+Record only durable outcomes such as tests added or changed, verification run, and deviations worth noting.
+
+Stage created and modified files intentionally.
+Do not use broad staging that sweeps unrelated files into the change.
+
+Done when the selected work is implemented as working code and locally verified to the level the change warrants.
+
+## 4. Review the final intended handoff state
+
+Load and run `review` before reporting final handoff or resolving a Wayfinder ticket.
+Choose review timing by judgment.
+Review may happen before commit, after commit, or both.
+The review must cover the final intended handoff state, including a local uncommitted handoff when no commit is made.
+Do not report final handoff until review has run or you have explained why review could not cover that state.
+
+Fix blocking review findings unless the agent or user explicitly accepts them.
+When code changes are made in response to review, rerun `review` on the relevant change set.
+Record accepted blocking findings in the final handoff or Wayfinder closeout when they affect a future reader's decision to trust or continue the work.
+Handle non-blocking findings by judgment.
+Fix them when cheap or high-value, and otherwise report or record only when useful.
+
+Done when review has covered the final intended handoff state and blocking findings are fixed or explicitly accepted.
+
+## 5. Commit and hand off
+
+Follow the repository's commit and PR conventions.
+Discover those conventions from repository instructions or recent history rather than assuming them.
+Commit only the selected work.
+Use one commit when that is the natural shape, but follow the repository's convention when it expects a different history shape.
+
+Push and open a PR when the repository and selected workflow call for that handoff.
+If there is no remote or no supported forge workflow, stop after the local handoff point and report what remains for a human.
+Keep PR and handoff text focused on what was built, verification, review disposition, and any deviations that matter.
+
+Done when the implementation has a concrete handoff state: committed locally, pushed, opened as a PR, or stopped with the exact remaining human action reported.
+
+## 6. Close out Wayfinder artifacts when present
+
+When the selected work has a Wayfinder ticket artifact, re-read it before closeout.
+Record durable coordination facts only.
+Wayfinder `status` is the lifecycle authority.
+Acceptance criteria checkboxes may be updated as useful detail with `[x]` for satisfied criteria and `[-]` for deliberately dropped criteria when practical.
+Checkbox state is not the source of truth.
+
+Keep Implementation Notes concise.
+Capture only what future agents or humans need: deviations, dropped or changed scope, verification, branch, commit, PR, or why the ticket remains unresolved.
+Use judgment for partial or ambiguous outcomes, but keep lifecycle recording honest.
+Do not imply completion when the work is not complete.
+
+When resolving a Wayfinder ticket, set `status: resolved` and repair the owning map's Frontier according to Wayfinder artifact rules.
+Put detailed implementation records in the ticket, commit, PR, and working code rather than in the map.
+The parent map should receive only the concise outcome summary required by Wayfinder.
+
+Done when any Wayfinder ticket and parent map agree with the implementation's actual lifecycle state.

skills/prototype/LOGIC.md

@@ -76,14 +76,17 @@ If the host project has no task runner, put the command at the top of the protot
 
 Done when a fresh user can launch the prototype with one documented command.
 
-### 6. Hand it over
+### 6. Evaluate it
 
-Give the user the run command.
+In HITL mode, give the user the run command.
 They drive it themselves.
 The interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" because those expose bugs in the idea.
 Add actions when the feedback needs them.
 
-Done when the user can exercise the model and the prototype exposes every state transition needed to reach a verdict.
+In AFK mode, run the command yourself and drive the hard cases that answer the stated question.
+Record the observations that support the verdict.
+
+Done when the evaluator can exercise the model and the prototype exposes every state transition needed to reach a verdict.
 
 ## Production mapping
 

skills/prototype/SKILL.md

@@ -7,6 +7,9 @@ description: Build a throwaway prototype to answer a design question. Use when t
 
 A prototype is **throwaway code that answers one question**.
 The question decides the branch.
+The interaction mode decides who reaches the verdict.
+Use AFK mode when the question has objective observable criteria the agent can test end to end.
+Use HITL mode when the verdict depends on human judgment, taste, or UX feel.
 
 ## 1. Pick a branch
 
@@ -39,11 +42,13 @@ Done when exactly one branch and one design question govern the prototype.
 
 ## 2. Build and reach a verdict
 
-Follow the selected branch through its handover step and iterate on the prototype in response to the user's feedback.
+Follow the selected branch through its evaluation step.
+In HITL mode, hand the prototype to the user and iterate in response to their feedback.
+In AFK mode, run the prototype yourself and evaluate the objective observations against the question.
 Do not treat a runnable prototype as the result.
 The result is the verdict that answers the design question.
 
-Done when the user has reached an explicit verdict or stated that the prototype did not resolve the question.
+Done when the verdict is explicit, or when the prototype establishes that it did not resolve the question.
 
 ## 3. Capture the primary source
 
@@ -61,11 +66,13 @@ Use the naming convention declared there, or infer it from nearby artifacts when
 Do not assume a counter, numeric prefix, slug shape, or artifact-type suffix unless the destination convention requires it.
 If no convention can be determined, choose the least surprising lowercase descriptive Markdown filename and state that the destination did not define a naming convention.
 
-When the caller provides an allocated filename and `parent`, use them exactly and do not advance any counter.
+When the caller provides an existing ticket artifact path, use it exactly, do not allocate a filename, and complete that artifact in place.
-Create only the Prototype artifact and leave the parent artifact unchanged.
 Otherwise, allocate any identifier required by the destination convention and include `parent` only when an earlier artifact directly caused the prototype.
 
-The Prototype artifact links the throwaway branch and preserves the question, run instructions, verdict, and branch-appropriate evidence:
+The Prototype artifact links the throwaway branch and preserves the question, run instructions, verdict, and branch-appropriate evidence.
+When the resolved file is an existing ticket artifact, preserve its workflow metadata and complete the result in that file.
+
+The branch-appropriate evidence is:
 
 - UI evidence uses screenshots.
 - Logic evidence uses useful code snippets and, where needed, a short interaction transcript.

skills/prototype/UI.md

@@ -99,12 +99,15 @@ Put the switcher in a single shared component so both sub-shapes can reuse it. L
 
 Done when mouse and keyboard controls cycle through every shareable variant without intercepting text-editing keys, and the switcher cannot render in production.
 
-### 5. Hand it over
+### 5. Evaluate it
 
-Surface the URL and the `?variant=` keys.
+In HITL mode, surface the URL and the `?variant=` keys.
 The user flips through the variants and may combine elements rather than choosing one unchanged.
 
-Done when the user can compare every variant in its host context and the prototype exposes enough contrast to reach a verdict.
+In AFK mode, open the URL yourself, compare every variant against the stated objective criteria, and record the observations that support the verdict.
+Use HITL instead when the decision depends on taste, product judgment, or UX feel.
+
+Done when the evaluator can compare every variant in its host context and the prototype exposes enough contrast to reach a verdict.
 
 ## Production mapping
 

skills/research/SKILL.md

@@ -22,11 +22,10 @@ Use the naming convention declared there, or infer it from nearby artifacts when
 Do not assume a counter, numeric prefix, slug shape, or artifact-type suffix unless the destination convention requires it.
 If no convention can be determined, choose the least surprising lowercase descriptive Markdown filename and state that the destination did not define a naming convention.
 
-When the caller provides an allocated filename and `parent`, use them exactly and do not advance any counter.
+When the caller provides an existing ticket artifact path, use it exactly, do not allocate a filename, and complete that artifact in place.
-Create only the Research artifact and leave the parent artifact unchanged.
 Otherwise, allocate any identifier required by the destination convention and include `parent` only when an earlier artifact directly caused the research.
 
-Done when one authoritative output path and its metadata are settled according to the destination convention.
+Done when one authoritative Research artifact path and its metadata are settled according to the destination convention.
 
 ## 2. Investigate the question
 
@@ -40,6 +39,7 @@ Done when the question is answered as far as primary evidence permits and every
 ## 3. Write the Research artifact
 
 Write the findings to the resolved Markdown file and follow the destination's artifact conventions.
+When the resolved file is an existing ticket artifact, preserve its workflow metadata and complete the result in that file.
 Keep the question, findings, limitations, and citations sufficient for a future reader to evaluate the result without reconstructing the research session.
 Do not create a source dump or research log.
 

skills/review/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: review
+description: Produce a structured, report-only review of a context-selected change set across risk, standards, intent, evidence, and documentation.
+---
+
+# review
+
+Review a change set selected from context and produce a structured review report.
+This skill is standalone and context-driven.
+It does not know about implementation lifecycle, Wayfinder claiming, task resolution, PR creation, or ticket closeout.
+It must not edit code.
+
+Reviewer prompts live under [`reviewers/`](reviewers/).
+Load the relevant reviewer files before running independent dimension reviews.
+
+## 1. Select and capture the change set
+
+Select the relevant change set from current context.
+The change set may be uncommitted changes, branch changes, a PR, explicit files, or another clear source.
+State what change set you selected before reviewing.
+Ask or stop only when scope ambiguity would make the review untrustworthy.
+
+Capture enough material for reviewers to inspect the selected change set.
+This may include a diff, changed-file list, commit list, PR details, relevant intent source, available verification evidence, and repository instructions or standards sources.
+Do not overprescribe mode selection or intent-source taxonomy.
+Use agent judgment when the selected change set and intent source are clear enough to review.
+
+Done when the chosen change set is explicit and reviewers have enough input to judge it.
+
+## 2. Run dimension reviews
+
+Run independent dimension reviewers through whatever real context boundary the current harness provides.
+A separate agent, worker, subprocess, or documented headless session is sufficient when each reviewer can inspect its dimension without seeing the parent review's intermediate conclusions.
+Use one reviewer per dimension when practical.
+If no real context boundary is available, stop before reviewing and report that independent review cannot be completed in the current runtime.
+Do not replace independent reviewers with in-process role switches.
+
+Use these reviewer files:
+
+- [`reviewers/risk.md`](reviewers/risk.md)
+- [`reviewers/standards.md`](reviewers/standards.md)
+- [`reviewers/intent.md`](reviewers/intent.md)
+- [`reviewers/evidence.md`](reviewers/evidence.md)
+- [`reviewers/documentation.md`](reviewers/documentation.md)
+
+Each reviewer should follow its own purpose, boundary, rubric, and output expectations.
+The shared base finding shape is flexible:
+
+```markdown
+- **Severity**: error | warning | info
+  **Blocking**: yes | no
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <impact>
+  **Suggested fix**: <concrete next action, or none>
+```
+
+Reviewers may add dimension-specific fields where useful.
+Reviewers classify findings as blocking or non-blocking.
+The caller or user decides final disposition.
+
+Done when each applicable dimension has returned findings or a clear statement that the dimension does not apply.
+
+## 3. Run targeted checks when useful
+
+Run targeted checks when they are needed to assess a dimension.
+Prefer focused commands that clarify evidence, risk, or standards conformance.
+Do not turn review into a full external validation pipeline.
+If a full suite or expensive check is clearly needed, explain why before relying on it.
+
+Record commands and artifacts that materially influenced the review.
+Do not present unrun checks as evidence.
+
+Done when the review has enough evidence for its findings and limitations are stated honestly.
+
+## 4. Aggregate the structured review report
+
+Produce a structured review report, not a gate artifact and not a pass/fail verdict.
+Keep sections separate so one dimension does not mask another.
+Deduplicate exact duplicates only.
+Mention when separate dimensions independently flag the same issue.
+
+Use this report shape unless the selected change set calls for a small adaptation:
+
+```markdown
+## Reviewed change set
+
+<what was reviewed and how it was captured>
+
+## Risk
+
+<risk reviewer section>
+
+## Standards
+
+<standards reviewer section>
+
+## Intent
+
+<intent reviewer section>
+
+## Evidence
+
+<evidence reviewer section>
+
+## Documentation
+
+<documentation reviewer section>
+
+## Summary
+
+- Blocking findings: <count>
+- Non-blocking findings: <count>
+- Targeted checks run: <commands or none>
+- Evidence limitations: <limitations or none>
+```
+
+Do not invent a pass/fail verdict.
+Use blocking findings present or absent as the review's actionable summary.
+
+Done when the report states the reviewed change set, preserves every applicable dimension, and summarizes blocking status and evidence limitations.

skills/review/reviewers/documentation.md

@@ -0,0 +1,30 @@
+# Documentation reviewer
+
+Review only documentation consequences of the selected change set.
+Do not make Risk, Standards, Intent, or Evidence findings unless the issue directly affects documentation correctness.
+
+Look for user-facing, operator-facing, contributor-facing, and agent-facing documentation that should change because behavior, interfaces, commands, options, workflows, or constraints changed.
+Also look for stale documentation introduced or left behind by the change.
+Do not demand new documentation surfaces for every change.
+Prefer updating the existing owner of the fact when one is discoverable.
+
+Documentation findings may be non-blocking when the change is internal and no durable reader would be misled.
+They may be blocking when users, operators, future contributors, or agents would reasonably make a wrong decision from stale or missing documentation.
+
+## Output format
+
+```markdown
+## Documentation
+
+### Findings
+
+Use `No findings.` when this reviewer has no findings.
+
+- **Severity**: <error|warning|info>
+  **Blocking**: <yes|no>
+  **Documentation owner**: <file, artifact, or none known>
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <reader impact>
+  **Suggested fix**: <concrete next action, or none>
+```

skills/review/reviewers/evidence.md

@@ -0,0 +1,38 @@
+# Evidence reviewer
+
+Review only whether the selected change set has convincing evidence.
+Do not make Risk, Standards, Intent, or Documentation findings unless the issue directly affects evidentiary value.
+
+Check tests, commands, artifacts, manual checks, and any evidence the change provides.
+You may recommend or run targeted checks when the orchestrating review context allows it.
+Do not present unrun checks as evidence.
+
+Reject source-grep pseudo-tests as proof of behavior.
+A test whose only evidence is matching implementation source text, tokens, lines, syntax, prompt phrases, regexes, AST shapes, or incidental snapshots does not prove behavior.
+Prefer evidence that demonstrates observable behavior, state, output, side effects, failure modes, or semantic meaning through a public or executable interface.
+
+For declarative artifacts, prefer invoking the real consumer or parsing into a typed or normalized semantic model.
+Reading file contents is legitimate when the file itself is the owned output or serialized contract under test.
+
+## Output format
+
+```markdown
+## Evidence
+
+Evidence checked:
+
+- <command, test, artifact, or none>
+
+### Findings
+
+Use `No findings.` when this reviewer has no findings.
+
+- **Severity**: <error|warning|info>
+  **Blocking**: <yes|no>
+  **Evidence checked**: <command, test, artifact, or none>
+  **Evidence gap**: <what remains unproven, or none>
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <trust or verification impact>
+  **Suggested fix**: <concrete next action, or none>
+```

skills/review/reviewers/intent.md

@@ -0,0 +1,33 @@
+# Intent reviewer
+
+Review only whether the selected change set satisfies the apparent intent.
+Do not make Risk, Standards, Evidence, or Documentation findings unless the issue directly changes intent fidelity.
+
+Use the clearest available intent source from context.
+Possible sources include a Wayfinder task, issue, spec, direct request, PR description, branch context, commit messages, or conversation context.
+Do not invent requirements.
+When intent is inferred rather than explicit, say so and treat it with appropriate caution.
+
+Look for missing requested behavior, partial implementation, behavior outside the selected scope, and implementations that appear to satisfy wording while violating the underlying request.
+Do not require remote branch, PR, or CI outcomes when another workflow step owns those outcomes.
+
+## Output format
+
+```markdown
+## Intent
+
+Intent source: <source or none>
+Intent confidence: <explicit|inferred|unavailable>
+
+### Findings
+
+Use `No findings.` when this reviewer has no findings.
+
+- **Severity**: <error|warning|info>
+  **Blocking**: <yes|no>
+  **Intent source**: <task, spec, issue, request, branch context, or none>
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <intent or correctness impact>
+  **Suggested fix**: <concrete next action, or none>
+```

skills/review/reviewers/risk.md

@@ -0,0 +1,46 @@
+# Risk reviewer
+
+Review only risk.
+Do not make Standards, Intent, Evidence, or Documentation findings unless the issue directly changes the risk assessment.
+
+Assess how much attention the selected change set warrants before handoff.
+Use the worst-factor-wins rubric from the old local review workflow.
+Rate each factor Low, Medium, or High with a concise reason:
+
+- Blast radius.
+- Reversibility.
+- Test coverage.
+- Sensitive domain.
+- Size and complexity.
+- Runtime criticality.
+
+Overall risk is the highest factor.
+Risk alone need not block.
+Missing evidence for a risky change may be blocking when a future reader should not trust the handoff without more proof.
+
+## Output format
+
+```markdown
+## Risk
+
+**Overall: <LOW|MEDIUM|HIGH>**
+
+- Blast radius: <rating> — <reason>
+- Reversibility: <rating> — <reason>
+- Test coverage: <rating> — <reason>
+- Sensitive domain: <rating> — <reason>
+- Size and complexity: <rating> — <reason>
+- Runtime criticality: <rating> — <reason>
+
+### Findings
+
+Use `No findings.` when this reviewer has no findings.
+
+- **Severity**: <error|warning|info>
+  **Blocking**: <yes|no>
+  **Risk factor**: <factor or none>
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <risk impact>
+  **Suggested fix**: <concrete next action, or none>
+```

skills/review/reviewers/standards.md

@@ -0,0 +1,43 @@
+# Standards reviewer
+
+Review only repository standards and maintainability.
+Do not make Risk, Intent, Evidence, or Documentation findings unless the issue directly affects standards conformance.
+
+Use repository instructions and discovered standards sources such as `AGENTS.md`, `CONTRIBUTING.md`, coding standards, or nearby conventions.
+When documented standards conflict with generic advice, the repository standard wins.
+
+Also apply this smell baseline when tooling or project standards do not already cover the issue:
+
+- Mysterious Name.
+- Duplicated Code.
+- Feature Envy.
+- Data Clumps.
+- Primitive Obsession.
+- Repeated Switches.
+- Shotgun Surgery.
+- Divergent Change.
+- Speculative Generality.
+- Message Chains.
+- Middle Man.
+- Refused Bequest.
+
+Treat smell findings as judgment calls, not automatic hard violations.
+Skip anything deterministic tooling already enforces unless the current review evidence shows the tool is not being run.
+
+## Output format
+
+```markdown
+## Standards
+
+### Findings
+
+Use `No findings.` when this reviewer has no findings.
+
+- **Severity**: <error|warning|info>
+  **Blocking**: <yes|no>
+  **Standard source**: <file and rule, smell baseline, or convention>
+  **Location**: <file, line, command, artifact, or none>
+  **Finding**: <specific issue>
+  **Why it matters**: <maintainability or standards impact>
+  **Suggested fix**: <concrete next action, or none>
+```

skills/slice/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: slice
+description: Turn a settled plan, spec, conversation, or artifact into Wayfinder implementation tickets for tracer-bullet slices. Run deliberately as /skill:slice when the user asks to slice work.
+disable-model-invocation: true
+---
+
+# slice
+
+Turn settled source material into implementation-ready Wayfinder tickets.
+Use this when the user asks to slice a plan, spec, conversation, or artifact into agent-grabbable implementation work.
+Do not use this to resolve planning fog.
+If the source contains unresolved decisions, report them instead of inventing implementation slices.
+
+`slice` writes Wayfinder `ticket/implementation` artifacts for implementation slices and `ticket/task/human` artifacts only when the slice cannot proceed without human action.
+It does not write legacy `.claude/tasks/` files.
+
+## 1. Gather source material
+
+Work from the current conversation first.
+If the caller passes paths, artifact links, issue references, or URLs, read the referenced body and relevant comments or nearby artifact context before slicing.
+When source material names a Wayfinder artifact, use that artifact as the default provenance parent.
+When no source artifact exists, use the active Wayfinder map if one is clear from context.
+When neither exists, create or select the minimal Wayfinder parent required by the destination's artifact rules before writing tickets.
+
+Explore the codebase when the current implementation state is not already understood.
+Use the project's established vocabulary and respect relevant ADRs, context artifacts, and repository instructions.
+Look for prefactoring that makes the change easier before slicing the behavior.
+
+Done when the source, project context, and default parent artifact are known.
+
+## 2. Resolve the artifact destination
+
+Resolve the destination before naming files.
+Use an explicitly supplied destination directory exactly.
+Otherwise, default to `$(xdg-user-dir DOCUMENTS)/ai-artifacts/projects/<project>` when the AI-artifacts vault is available, where `<project>` is the lowercase basename of the current working directory.
+If that vault is unavailable, fall back to `./docs` in the current project.
+Create the destination directory only when a new artifact requires it.
+Read the destination's `AGENTS.md` before any artifact write.
+
+Follow the destination's filename, identifier, slug, frontmatter, and wikilink conventions.
+If Wayfinder artifact reference is available, read it before writing.
+The minimum Wayfinder ticket contract is:
+
+```markdown
+---
+status: open
+parent: "[[<source-artifact-or-map>]]"
+blocked-by: []
+tags:
+  - ticket/implementation
+---
+
+# <task name>
+
+## Question
+
+<one precise implementation action sized to one agent session>
+```
+
+Use `ticket/task/human` instead of `ticket/implementation` when execution or validation requires human input before implementation can proceed.
+Do not create claims.
+Tickets start open and unclaimed.
+
+Done when the destination and artifact conventions are known.
+
+## 3. Draft slices
+
+Break the work into tracer-bullet slices.
+Each normal slice must deliver a narrow complete path through every layer the change requires.
+Do not create horizontal layer-only slices.
+Reject any proposed slice whose title or delivered behavior is only parsing, only schema, only API, only UI, only tests, or only documentation when those layers are part of one user-visible change.
+For a small feature, one slice is usually correct because parsing, behavior, tests, and documentation belong in the same coherent commit.
+A completed slice must be demoable or verifiable on its own.
+A slice should make sense as one coherent commit.
+Put prefactoring slices before behavior slices that depend on them.
+
+Record blocking edges while drafting.
+Use blockers only for work that genuinely gates the slice.
+A slice with no blockers can start immediately.
+Use `parent` for provenance and `blocked-by` for prerequisites.
+
+Use the wide-refactor exception when a single mechanical change has a blast radius that prevents any vertical slice from landing green.
+Sequence that work as expand, migration batches, and contract.
+The expand slice adds the new form beside the old so nothing breaks.
+Each migration batch is sized by blast radius and is blocked by the expand slice.
+The contract slice removes the old form and is blocked by every migration batch.
+When migration batches cannot stay green alone, keep the sequence but state the integration-branch constraint and add a final integrate-and-verify slice.
+
+Done when every currently implementable slice has a title, type, blockers, delivered behavior, acceptance criteria, and any needed handoff notes.
+
+## 4. Classify ticket type
+
+Use `ticket/implementation` when an agent can complete and verify the implementation slice without live human input.
+Use `ticket/task/human` when execution or validation depends on the user before implementation can proceed.
+Examples include subjective UI judgment, physical device checks, unavailable credentials, external account approval, or behavior only the human can confirm.
+Do not mark a ticket human merely because it is important or risky.
+Make the required human involvement explicit in the ticket body.
+
+If slicing reveals a precise unresolved planning question, do not disguise it as an implementation ticket.
+Report it and stop, unless the caller asks to create the appropriate Wayfinder research, prototype, or grill ticket.
+
+Done when each proposed slice has the correct ticket type.
+
+## 5. Review before writing
+
+Present the proposed breakdown and wait for approval unless the caller explicitly asks for noninteractive output.
+For each slice show exactly this review shape:
+
+```markdown
+1. **Title**: <proposed task title>
+   **Type**: implementation or human task
+   **Blocked by**: <proposed blockers, or None>
+   **What it delivers**: <end-to-end behavior or implementation result>
+   **Acceptance criteria**:
+   - <observable completion check>
+```
+
+Ask the user whether the granularity feels right, whether the blocking edges are correct, 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`.
+
+Done when the proposed slices are approved or noninteractive assumptions are explicit.
+
+## 6. Write ticket artifacts
+
+Allocate filenames and identifiers according to the destination convention.
+Create one Wayfinder ticket artifact per approved slice.
+Use the destination's wikilink style when referring to artifacts.
+Never refer to a ticket by a bare identifier, filename, or slug in user-facing text.
+
+Each ticket body should use this shape:
+
+```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>
+```
+
+Keep `## Implementation Notes` empty when no guidance earns its place.
+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.
+
+Done when every approved slice has exactly one open, unclaimed Wayfinder ticket artifact.
+
+## 7. Advance the Frontier
+
+Re-read the map or parent artifact before editing shared state.
+If there is a Wayfinder map, recompute its Frontier from ticket metadata.
+A ticket belongs on the Frontier when it is open, every blocker is satisfied, and it has no claim.
+The map's Frontier is the only map section that links to ticket artifacts.
+Do not copy ticket details into the map.
+
+If the destination uses identifier allocation and concurrent writes caused duplicate identifiers or filenames, preserve pre-existing artifacts, rename current outputs, update wikilinks, and advance the counter as needed.
+
+Done when the ticket artifacts and map Frontier agree with current ticket metadata.
+
+## 8. Report
+
+Report the created ticket artifacts by title using the destination's link style.
+Summarize the current Frontier.
+Mention any assumptions, unresolved planning questions, or human-dependent validation tickets.
+
+Done when the user can choose the next implementation task from the Frontier.

skills/subagents/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: subagents
+description: Delegate isolated work through Pi subagent tools. Use when a workflow needs an independent worker, fresh context, parallel reviewers, or hidden role separation.
+disable-model-invocation: true
+---
+
+# subagents
+
+## 1. Confirm support
+
+Prefer tool calls when the current runtime exposes them.
+The supported tool names are `subagent_spawn`, `subagent_batch`, `subagent_list`, `subagent_status`, `subagent_result`, and `subagent_cancel`.
+
+If these tools are unavailable, do not pretend that an in-process role switch is a subagent.
+State that Pi subagent tools are unavailable in the current runtime.
+Do not perform the delegated subagent work in-process.
+
+Done when the run has a supported subagent tool path.
+
+## 2. Prepare a bounded prompt
+
+Give each subagent a self-contained prompt.
+Include the role, task, repository path, relevant files or artifacts, constraints, and expected output shape.
+Do not expose private planning state that the workflow is trying to isolate.
+For test-driven development, send one behavior at a time rather than a backlog.
+For review, send one review dimension at a time unless batching independent dimensions.
+
+Use `context: "independent"` for a fresh worker by default.
+Use `context: "fork"` only when the child intentionally needs the parent transcript as starting context.
+Choose named agents only when the project has configured them.
+Do not invent named agents as part of the delegation.
+
+Done when the prompt is narrow enough that the subagent can complete without sharing hidden state or requiring follow-up orchestration.
+
+## 3. Spawn and track workers
+
+Use `subagent_spawn` for one worker.
+Use `subagent_batch` when several independent workers can run in parallel.
+Both spawn tools return before the child work is complete.
+Record accepted child ids and per-entry failures.
+Use `subagent_list` or `subagent_status` to track lifecycle when needed.
+Use `subagent_result` to retrieve completion output.
+Use `subagent_cancel` for stale or no-longer-needed workers.
+
+Do not claim the delegated work is complete until every required child result is available or a failed child has an explicit disposition.
+Treat `queued`, `starting`, `running`, and `settling` as incomplete states.
+Treat `failed`, `cancelled`, `timed_out`, and `orphaned` as failures unless the caller explicitly accepts the missing result.
+
+Done when every required worker result has been collected or every missing result has a stated disposition.
+
+## 4. Integrate results
+
+Use subagent output as evidence, not as an unquestioned command.
+Preserve which child produced each material finding.
+When subagents disagree, report the disagreement rather than averaging it away.
+When a subagent result changes implementation direction, verify the relevant facts in the parent context before editing code.
+
+Done when the parent has integrated child results into the caller workflow with provenance and limitations visible.

skills/test-driven-development/SKILL.md

@@ -0,0 +1,77 @@
+---
+name: test-driven-development
+description: Drive red-green-refactor implementation with tests written by someone other than the implementation agent, using public behavior and independent expected values.
+---
+
+# test-driven-development
+
+Use test-driven development as process discipline for behavior-bearing changes.
+The result is working behavior plus useful tests, not a separate report artifact.
+
+## 1. Establish roles and behavior backlog
+
+Name the two functional roles before writing tests.
+The implementation agent changes production code and drives the loop.
+The test writer writes and edits tests.
+Tests are always written by someone other than the agent doing implementation.
+
+Launch an independent test writer through whatever real context boundary the current harness provides.
+A separate agent, worker, subprocess, or documented headless session is sufficient when it cannot see the implementation agent's private backlog.
+If no real context boundary is available, stop before writing tests and report that test-driven development cannot be completed in the current runtime.
+Do not replace the independent test writer with an in-process role switch.
+Do not silently skip the independent-test-writer requirement.
+
+The implementation agent may keep a private behavior backlog.
+Keep that backlog isolated from the test writer.
+The test writer receives one behavior at a time, not the whole backlog.
+
+Done when roles are explicit and the implementation agent has the next behavior ready without exposing the whole backlog to the test writer.
+
+## 2. Choose the public seam and source of truth
+
+Test 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.
+Do not test internals just to make RED easy.
+
+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.
+
+Done when the next behavior has a public seam, enough context for the test writer, and an independent expected-value source.
+
+## 3. Run one red-green cycle
+
+Give the test writer exactly one behavior, the public seam and context, the independent expected-value source, and any relevant project test conventions.
+The test writer writes or edits one test for that behavior and confirms it fails for the intended reason.
+A failing test should fail because the behavior is missing or wrong, not because of import, syntax, fixture, or collection errors.
+
+The implementation agent writes the minimal production code needed to pass that test.
+The implementation agent must not edit test-writer-authored tests.
+If the test has a mechanical defect, send the error back to the test writer.
+If the implementation agent believes the test asserts the wrong semantics, pause for user or intent clarification.
+
+Done when one behavior has a meaningful failing test and then passes through production-code changes made by the implementation agent.
+
+## 4. Repeat behavior by behavior
+
+Repeat the red-green cycle one behavior at a time.
+Do not bulk-write tests before implementation.
+Do not let the test writer see the behavior backlog.
+Do not add speculative behavior while making the current test pass.
+
+Run focused verification as each behavior lands.
+Use broader verification when the repository or change warrants it.
+
+Done when every selected behavior has passed through the one-behavior red-green loop or has been deliberately deferred by the implementation agent's judgment.
+
+## 5. Refactor only after green
+
+Never refactor while RED.
+After tests pass, the implementation agent may refactor production code.
+Refactoring means changing code structure without changing externally observable behavior.
+
+The test writer updates tests only for deliberate public seam changes or test defects.
+A test failure during refactoring normally means production behavior broke.
+Fix production code unless the public seam changed deliberately.
+
+Done when refactoring, if any, is complete and the relevant tests remain green.

skills/wayfinder/ARTIFACTS.md

@@ -20,6 +20,8 @@ If no convention can be determined, choose the least surprising lowercase descri
 
 Refer to artifacts through the link style used by the destination.
 Never use a bare identifier as a human-facing reference.
+Ticket filenames use the substantive artifact type as their artifact-type suffix: `research`, `prototype`, `grill`, `task`, or `implementation`.
+Do not use `ticket` as a filename artifact-type suffix.
 
 ## Map
 
@@ -50,7 +52,7 @@ tags:
 
 ## Decisions so far
 
-<one plain-language decision per resolved ticket, without artifact links>
+<one plain-language decision or implementation outcome per resolved ticket, without artifact links>
 
 ## Not yet specified
 
@@ -69,8 +71,8 @@ Repair the Frontier whenever it is missing, stale, or inconsistent with ticket s
 Order Frontier links by the destination's declared ordering unless the user chooses another ticket.
 Fall back to filename order when no ordering is declared.
 
-Under **Decisions so far**, record one concise, self-contained decision for each resolved ticket.
+Under **Decisions so far**, record one concise, self-contained decision or implementation outcome for each resolved ticket.
-Do not link the ticket or its result artifacts, identify the ticket, or copy supporting detail from the canonical resolution into the map.
+Do not link or identify the resolved ticket, or copy supporting detail from the canonical resolution into the map.
 
 ## Tickets
 
@@ -89,16 +91,18 @@ tags:
 
 ## Question
 
-<one precise question or prerequisite action sized to one agent session>
+<one precise question, prerequisite action, or implementation slice sized to one agent session>
 ```
 
 Use one of these tags:
 
 - `ticket/research`
-- `ticket/prototype`
+- `ticket/prototype/afk`
+- `ticket/prototype/hitl`
 - `ticket/grill`
 - `ticket/task/afk`
 - `ticket/task/human`
+- `ticket/implementation`
 
 `parent` records provenance.
 An initial ticket points to the map.
@@ -108,8 +112,10 @@ An artifact may have many children, which agents find by searching for backlinks
 `blocked-by` records zero or more upstream artifacts that must resolve before the ticket becomes actionable.
 It is independent of `parent`.
 A ticket blocker is satisfied when its status is `resolved`.
-A non-ticket result blocker is satisfied when its artifact exists.
+A non-ticket blocker is satisfied when its artifact exists.
 A ticket is on the Frontier when its status is `open`, every blocker is satisfied, and it has no claim.
+A `ticket/task/afk` ticket is prerequisite work that unblocks the route.
+A `ticket/implementation` ticket is a code, configuration, documentation, or test slice that delivers part of an execution map's destination.
 
 ## Claims and status
 
@@ -125,17 +131,17 @@ Use `PI_SESSION_ID` when available and an equivalent harness session identifier
 Claims do not expire automatically.
 The acting agent uses the available context to recover an abandoned claim.
 
-Only resolved tickets contribute decisions under **Decisions so far**.
+Only resolved tickets contribute decisions or implementation outcomes under **Decisions so far**.
 An out-of-scope ticket is closed, while **Out of scope** states the excluded work and reason in plain language without linking or identifying the ticket.
 
 ## Results
 
-A Grill or Task ticket stores its canonical result under a `## Resolution` section in that ticket.
+A ticket is a self-resolving artifact.
-Research and Prototype tickets leave their question in the ticket and store the result in a child artifact whose `parent` points to the ticket.
+Its canonical result lives in that same artifact rather than in a child result artifact.
 
-When invoking `research` or `prototype`, provide the resolved artifact destination, the filename chosen from that destination's convention, and the ticket link that the result must use as its `parent`.
+When invoking `research`, `prototype`, or `implement`, provide the resolved ticket artifact path.
-The called skill creates the result artifact but does not edit the ticket or map.
+The called skill completes the ticket artifact in place and does not edit the map.
-The coordinating Wayfinder agent validates the returned artifact, marks the ticket resolved, and updates the map.
+The coordinating Wayfinder agent validates the updated ticket artifact, marks the ticket resolved when the called skill has not already done so, and updates the map.
 If a called skill cannot honor this artifact contract, leave the ticket unresolved and record the incompatibility instead of silently storing the result elsewhere.
 
 Navigate the artifact journey forward by finding every note whose `parent` links to the current artifact.

skills/wayfinder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: wayfinder
-description: Plan a huge chunk of work that exceeds one agent session as a durable map of decision tickets, then resolve them one at a time until the way to the destination is clear.
+description: Plan or coordinate a huge chunk of work that exceeds one agent session as a durable map of tickets, then resolve them until the way to the destination is clear.
 disable-model-invocation: true
 ---
 
@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 A loose idea has arrived that is too large for one agent session and wrapped in fog.
 Wayfinding charts the way to a **destination** rather than charging at it.
-It creates a durable map of questions whose resolutions are decisions, findings, prototypes, or completed prerequisites rather than slices of the destination work.
+It creates a durable map of questions whose resolutions are decisions, findings, prototypes, completed prerequisites, or explicit implementation slices.
 
 Read [`ARTIFACTS.md`](ARTIFACTS.md) before charting or working a map.
 It is the single source of truth for how maps, tickets, claims, blocking, resolutions, and the Frontier live in the resolved artifact destination.
@@ -17,11 +17,14 @@ It is the single source of truth for how maps, tickets, claims, blocking, resolu
 
 Wayfinder plans by default.
 The map is complete when nothing remains to decide before someone performs the destination work.
-The urge to implement the destination usually marks the edge of the map and the time to hand off.
+The urge to implement the destination usually marks the edge of a planning map and the time to hand off.
 An effort may explicitly permit execution in its Notes, but otherwise preserve resolutions rather than deliver the destination.
 
+A map may explicitly be an execution map when the destination is a tracked implementation effort rather than a route to a later handoff.
+Execution maps use the same ticket, claim, and Frontier mechanics, but implementation tickets may deliver slices of the destination.
+
 The destination varies by effort and shapes every ticket.
-It may be a spec to hand off, a decision to lock before planning, or a change whose route must be understood before implementation.
+It may be a spec to hand off, a decision to lock before planning, a change whose route must be understood before implementation, or an implementation effort whose slices need coordination.
 
 ## Refer by name
 
@@ -35,15 +38,18 @@ A HITL ticket only resolves through that exchange.
 The agent never speaks for the human's side.
 
 - **Research** (AFK): Investigate documentation, third-party APIs, or resources outside the current working directory through `research`.
-  The called skill creates a Research artifact and Wayfinder integrates it.
+  The called skill completes the Research ticket artifact in place.
-- **Prototype** (HITL): Raise the fidelity of a logic, state-model, or UI decision through `prototype`.
+- **Prototype** (AFK or HITL): Raise the fidelity of a logic, state-model, or UI decision through `prototype`.
-  The called skill creates a Prototype artifact and Wayfinder integrates it after the human reaches a verdict.
+  Use AFK when the question has objective observable criteria the agent can test end to end.
+  Use HITL when the verdict depends on human judgment, taste, or UX feel.
+  The called skill completes the Prototype ticket artifact in place after the verdict is reached.
 - **Grill** (HITL): Resolve a decision through `grill`.
   This is the default ticket type.
-- **Task** (AFK or HITL): Perform prerequisite work that must happen before a decision can be made.
+- **Task** (AFK or HITL): Perform prerequisite work that fits the map's destination.
+  In a planning map, a Task earns its place by unblocking a decision rather than delivering part of the destination.
   The agent performs it where possible and otherwise gives the human a precise checklist.
-
+- **Implementation** (AFK): Deliver a code, configuration, documentation, or test slice of an execution map through `implement`.
-A Task earns its place by unblocking a decision, not by delivering part of the destination.
+  Implementation tickets expect checkout verification, tests where useful, review, commit or handoff, and Wayfinder closeout.
 
 ## Fog of war
 
@@ -68,8 +74,17 @@ Do not record a scope boundary as a decision on the route.
 
 - A loose idea without a map uses **Chart the map**.
 - An existing map uses **Work through the map**.
+- A session working a map with unblocked AFK Frontier tickets uses **Coordinate workers** inside **Work through the map** when the current harness provides a real isolation or concurrency mechanism.
 
-Never resolve more than one non-Research ticket in a session.
+Worker coordination is the default for AFK Frontier work when an isolation or concurrency mechanism is available.
+The current session acts as coordinator.
+A worker session resolves exactly one claimed ticket and stops.
+A coordinating session may dispatch multiple open Frontier tickets through whatever real isolation or concurrency mechanism the current harness provides.
+A coordinating session does not claim tickets it intends to delegate.
+Each worker claims its own ticket so accountability remains attached to the session doing the work.
+An interactive Wayfinder session may resolve multiple tickets sequentially only when worker coordination is unavailable, unnecessary, or explicitly not selected.
+It must complete the full reconcile, claim, resolve, record, and frontier-advance loop before selecting another ticket.
+Do not auto-consume HITL tickets without user participation.
 
 ## Chart the map
 
@@ -86,9 +101,9 @@ Never resolve more than one non-Research ticket in a session.
    Done when the map is the effort root, every precise question has one ticket, every known blocking edge is represented, and the Frontier is current.
 4. **Dispatch Research.**
    Invoke `research` for each Research ticket using whatever isolation or concurrency the caller provides.
-   Integrate each returned Research artifact according to [`ARTIFACTS.md`](ARTIFACTS.md).
+   Reconcile each completed Research ticket according to [`ARTIFACTS.md`](ARTIFACTS.md).
    Leave a ticket open with the reason visible when its Research run cannot complete.
-   Done when every dispatched result is integrated or every incomplete Research ticket records why it remains open.
+   Done when every dispatched Research ticket is resolved or records why it remains open.
 5. **Stop.**
    Stop without resolving a HITL ticket.
    Done when charting has created and dispatched the visible route without consuming its human decision work.
@@ -99,26 +114,63 @@ Never resolve more than one non-Research ticket in a session.
    Read the map at low resolution rather than loading every ticket.
    Reconcile its derived Frontier against ticket metadata.
    Done when the destination, Notes, prior decisions, fog, scope boundary, and current Frontier agree with the artifacts.
-2. **Claim one ticket.**
+2. **Claim one ticket or coordinate workers.**
-   Use the user-named ticket when it is actionable.
+   If unblocked AFK Frontier tickets can be delegated through a real isolation or concurrency mechanism, use **Coordinate workers** instead of claiming a ticket here.
+   Use the user-named ticket when it is actionable and not delegated.
    Otherwise take the first Frontier ticket in the destination's declared ordering, falling back to filename order when no ordering is declared.
-   Persist the claim before doing any work.
+   Persist the claim before doing any direct work.
-   Done when exactly one unblocked ticket records this session's claim with `status: claimed`.
+   Done when exactly one unblocked ticket records this session's claim with `status: claimed`, or the session has switched to worker coordination without claiming delegated tickets.
 3. **Resolve by type.**
-   Invoke `research`, `prototype`, or `grill` for the corresponding ticket type.
+   Invoke `research`, `prototype`, `grill`, or `implement` for the corresponding ticket type.
    Perform a Task through the capability or human checklist it requires.
    Load related artifacts only when needed.
-   Done when the question has a resolution or the prerequisite Task is complete.
+   Done when the question has a resolution, the prerequisite Task is complete, or the implementation slice has a concrete handoff state.
 4. **Record the resolution.**
-   Persist the canonical result, resolve the ticket, and append its concise decision under the map's **Decisions so far** according to [`ARTIFACTS.md`](ARTIFACTS.md).
+   Persist the canonical result in the ticket artifact, resolve the ticket, and append its concise decision or implementation outcome under the map's **Decisions so far** according to [`ARTIFACTS.md`](ARTIFACTS.md).
-   Do not link or identify the resolved ticket or its result artifacts from the map.
+   Do not link or identify the resolved ticket from the map.
-   Done when the resolution lives in exactly one canonical place and the map states only the resulting decision.
+   Done when the resolution lives in the ticket artifact and the map states only the resulting decision or outcome.
 5. **Advance the frontier.**
    Create tickets surfaced by the resolution and wire their blockers.
    Graduate newly precise fog, remove invalidated tickets, move beyond-destination work out of scope, and recompute the Frontier.
    Re-read shared artifacts before each write because other sessions may edit the effort concurrently.
    Done when every newly visible question has exactly one home and the map agrees with all current ticket metadata.
-6. **Complete or stop.**
+6. **Complete, continue, or stop.**
    When no unresolved tickets or fog remain, mark the map complete and stop for an explicit handoff instruction.
+   In a worker session, stop after one ticket is resolved and the frontier is advanced.
+   In an interactive or coordinating session, continue to another Frontier ticket only after reconciling the map and shared artifacts again.
    Otherwise stop.
    Done when the map records its current lifecycle state and no destination work has begun without permission.
+
+## Coordinate workers
+
+1. **Select dispatchable tickets.**
+   Re-read the map and current Frontier before dispatch.
+   Select only open, unclaimed, unblocked AFK tickets.
+   Do not dispatch HITL tickets without live user participation.
+   Include every eligible AFK Frontier ticket unless serial execution or likely conflict requires selecting a smaller batch.
+   Done when every selected ticket is eligible and no selected ticket has been claimed by the coordinator.
+2. **Dispatch workers.**
+   Send each selected worker exactly one ticket, the artifact path, the map context it needs, and the instruction to claim the ticket itself before work.
+   Route Research tickets through `research`, AFK Prototype tickets through `prototype`, Implementation tickets through `implement`, and AFK Task tickets through the focused task capability or checklist they require.
+   Use whatever real isolation or concurrency mechanism the current harness provides.
+   If no such mechanism exists, stop and report that worker coordination is unavailable in this runtime.
+   Use parallel workers when selected tickets are independent.
+   Use serial workers when tickets likely edit the same files, checkout, branch, or shared artifact surfaces.
+   Done when every selected ticket has either a launched worker or a visible dispatch failure.
+3. **Join workers.**
+   Wait for every launched worker to finish, fail, time out, or be cancelled before treating coordination as complete.
+   Do not implement in the coordinator while workers are running.
+   Do not report final handoff while workers are still running.
+   Done when every launched worker has a terminal result or an explicit recovery status.
+4. **Reconcile worker results.**
+   Re-read every shared artifact touched by returned workers.
+   Validate each ticket's claim, status, and canonical result.
+   Detect duplicate surfaced tickets or filenames, preserve pre-existing artifacts, and repair links according to [`ARTIFACTS.md`](ARTIFACTS.md).
+   Record whether a failed worker's claim remains, was reopened, or needs human recovery.
+   When Pi subagents supplied the worker results, call `subagent_clear` for each terminal child only after its findings have been reconciled into the artifacts or recovery record.
+   Done when all returned work is reconciled, every failed or missing worker result has an honest artifact state, and no reconciled terminal subagent remains in the visible work set.
+5. **Advance the frontier.**
+   Recompute the Frontier after reconciliation, not before.
+   Mark the map `complete` only when no live ticket or fog remains.
+   Never use `resolved` as a map status.
+   Done when the map status, Frontier, and ticket metadata agree.