Deprecate inactive skills

deprecated/slice/SKILL.md

@@ -0,0 +1,167 @@
+---
+name: slice
+description: Turn a settled plan, spec, conversation, or artifact into AI-artifacts implementation tasks 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 task artifacts.
+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 AI-artifacts `task/implementation` artifacts for implementation slices.
+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 an artifact, use that artifact as the default provenance parent.
+When no source artifact exists, use `parent: null` unless the destination's artifact rules require a parent.
+
+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.
+The default implementation task artifact type is `implementation-task`.
+The minimum implementation task contract is:
+
+```markdown
+---
+status: open
+parent: "[[<source-artifact>]]"
+blocked-by: []
+claimed-by: null
+claimed-at: null
+tags:
+  - task/implementation
+---
+
+# <task name>
+
+## Question
+
+<one precise implementation action sized to one agent session>
+```
+
+Use `parent: null` when no earlier artifact directly caused the task.
+Do not create claims.
+Tasks 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, blockers, delivered behavior, acceptance criteria, and any needed handoff notes.
+
+## 4. Confirm implementability
+
+Use implementation tasks when an agent can complete and verify the slice without live human input.
+When execution or validation depends on the user before implementation can proceed, report the human dependency instead of writing an agent-grabbable task.
+Examples include subjective UI judgment, physical device checks, unavailable credentials, external account approval, or behavior only the human can confirm.
+Do not block a task merely because it is important or risky.
+Make any required human involvement explicit in the proposed breakdown.
+
+If slicing reveals a precise unresolved planning question, do not disguise it as an implementation task.
+Report it and stop, unless the caller asks for follow-up research, prototyping, or grilling.
+
+Done when each proposed slice is implementable by an agent or its human dependency is explicit.
+
+## 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>
+   **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 implementation task artifact per approved slice.
+Use the destination's wikilink style when referring to artifacts.
+Never refer to a task 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.
+
+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 every approved slice has exactly one open, unclaimed implementation task artifact.
+
+## 7. Report
+
+Report the created task artifacts by title using the destination's link style.
+Mention any assumptions, unresolved planning questions, human-dependent validation, or immediately actionable unblocked tasks.
+
+Done when the user can choose an implementation task.