From beislid
Breaks approved specs/PRDs into phased vertical slices with durable decisions, HITL/AFK classification, and walking skeleton first. Use when features are too large for one PR.
npx claudepluginhub sandsower/beislidThis skill uses the workspace's default tool permissions.
Takes an approved spec/PRD and produces a phased implementation structure using vertical slices. Each phase cuts through all layers end-to-end rather than building horizontal slabs.
Decomposes large features into concrete, self-contained development phases with DAG dependencies. Each phase delivers testable code; outputs YAML manifest.
Generates detailed implementation plans from approved spec.md files, iterates with human annotations, and outputs structured plan.json with phases, tasks, and steps. Use after spec approval to break into engineer-ready work.
Generates structured phased implementation plans from feature descriptions, sized for 30-50k token sub-agent contexts, with clarifying questions, acceptance criteria, and dependencies. Invoke before multi-phase execution.
Share bugs, ideas, or general feedback.
Takes an approved spec/PRD and produces a phased implementation structure using vertical slices. Each phase cuts through all layers end-to-end rather than building horizontal slabs.
Check for artifacts in order: plans/*-spec.md, plans/*-prd.md, a tracker document/issue linked in conversation, or spec content in the current session. If nothing found, ask the user where it is.
Before phasing, call out the architectural decisions that span the entire feature and must be resolved first: routes, database schema, data models, auth boundaries, service interfaces. These are the skeleton everything else hangs on.
Quiz the user on any unresolved decisions. For each, present your recommendation and why.
Each phase is a tracer bullet that cuts through every layer (UI, API, data, tests) for a thin but complete slice of functionality. The first phase should be the thinnest possible end-to-end path — the "walking skeleton."
- Each phase ships something testable and, ideally, demoable - No phase should be purely "set up infrastructure" — infrastructure comes along with the first feature that needs it - Later phases widen the path, not deepen a single layer - If a phase touches only one layer, it's horizontal — rethink itFor each phase, note:
Output to plans/<feature-name>-structure.md. Keep it under 2 pages.
# [Feature] — Implementation Structure
## Durable Decisions
- [decision]: [resolution and rationale]
## Phase 1: [Walking skeleton] (HITL/AFK)
Cuts through: [layers]
Delivers: [what's testable]
Validates: [what assumption this proves]
## Phase 2: [Next slice] (HITL/AFK)
...
## Phase N: [Final slice] (HITL/AFK)
...
This structure is the handoff to blueprint for the selected phase. Only hand directly to implement when the user explicitly says the implementation design is already approved.