Add slice skill

skills/slice/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: slice
+description: Turn a settled plan, spec, conversation, or artifact into Wayfinder task tickets for tracer-bullet implementation 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 task 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/task/afk` and `ticket/task/human` artifacts.
+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 task 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/task/afk
+---
+
+# <task name>
+
+## Question
+
+<one precise implementation action sized to one agent session>
+```
+
+Use `ticket/task/human` instead of `ticket/task/afk` when execution or validation requires human input.
+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 task type
+
+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.
+Examples include subjective UI judgment, physical device checks, unavailable credentials, external account approval, or behavior only the human can confirm.
+Do not mark a task human merely because it is important or risky.
+Make the required human involvement explicit in the task body.
+
+If slicing reveals a precise unresolved planning question, do not disguise it as an implementation task.
+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 task subtype.
+
+## 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**: AFK or human
+   **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 task artifacts
+
+Allocate filenames and identifiers according to the destination convention.
+Create one Wayfinder task 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 task 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 task 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 task 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 task artifacts and map Frontier agree with current ticket metadata.
+
+## 8. Report
+
+Report the created task artifacts by title using the destination's link style.
+Summarize the current Frontier.
+Mention any assumptions, unresolved planning questions, or human-dependent validation tasks.
+
+Done when the user can choose the next implementation task from the Frontier.