Slice

Name: Slice
Author: davidlee

davidlee/doctrine

78 installs
1 repo stars
Updated August 3, 2026
davidlee/doctrine

Scopes emerging code-changing intent into a Doctrine slice with a scope document and metadata before any design or implementation.

About

Converts code-changing intent into one coherent scoped slice, creating slice-nnn.toml/md and making in-scope, out-of-scope, affected surface, and closure intent explicit. A developer uses it when change intent has emerged and no governing slice covers it yet.

doctrine slice new scaffolds metadata and scope document
Seeds coarse scope-relevant selectors for the affected surface

Slice by the numbers

78 all-time installs (skills.sh)
Ranked #1,461 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
Data as of Aug 4, 2026 (Skillselion catalog sync)

npx skills add https://github.com/davidlee/doctrine --skill slice

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/davidlee/doctrine/slice.svg)](https://skillselion.com/skills/davidlee/doctrine/slice)

Installs	78
repo stars	★ 1
Last updated	August 3, 2026
Repository	davidlee/doctrine ↗

What it does

Scopes emerging code-changing intent into a Doctrine slice with a scope document and metadata before any design or implementation.

Files

SKILL.mdMarkdownGitHub ↗

Slice

You are converting intent into a concrete, scoped unit of change. A slice is one coherent change — not a project-global decision (that is an ADR) and not evergreen spec material (.doctrine/spec/).

Process

1. Confirm the frame. Code-changing intent, and no governing slice already covers it. Pull the constraints first: /canon for ADRs and .doctrine/spec/tech/, and conventions; /retrieve-memory for subsystem gotchas on the surface you will touch.

2. Create the slice:

   doctrine slice new "<title>" [--slug <slug>]

Allocates the next id and scaffolds slice-nnn.toml (metadata, relations, lifecycle status — starts at proposed) + slice-nnn.md (scope document).

3. Make scope explicit in slice-nnn.md:

what changes, and why
in scope vs out of scope (name the boundary)
affected surface — concrete paths / modules
risks, assumptions, open questions
verification / closure intent — how "done" will be judged

Seed the affected surface as coarse `scope-relevant` selectors — a rough path/glob fence on where the change lives, captured now while scope is fresh:

   doctrine slice selector add <id> "src/foo/**" "src/bar.rs" --intent scope-relevant

These are intentionally loose (the exact touch-set is /design's job). They feed the audit-time slice conformance delta; an unfenced slice has nothing to diff git actuals against.

4. Record structure in slice-nnn.toml: metadata, lifecycle status. Honour the storage rule — structured data in TOML, prose in MD, never queried/derived data in prose. Relations are written with `doctrine link`, not hand-authored rows — it validates the pair against RELATION_RULES (the legal vocabulary; using-doctrine.md § Relating entities). e.g. governed_by an ADR, specs a spec, supersedes a prior slice.

5. Check the altitude. If the work is really a project-global decision → doctrine adr new. If it is evergreen specification → author a tech spec (doctrine spec new tech) or a product spec (doctrine spec new product). Keep the slice to one shippable change; split if it sprawls.

You MUST shape the design before planning: record the lifecycle move (doctrine slice status <id> design — bare number) and hand off to /design. Do not jump to /plan or /execute from a bare slice — /route's gate forbids it. If genuine tradeoffs or unknowns surface while scoping, /consult.