singleton-sd Idea to Delivery
Use this skill when an idea has been refined enough to become executable project work.
Hierarchy
- Tiny isolated change: one implementation task.
- Medium feature: one Epic/initiative plus roughly 2–5 independently deliverable tasks.
- Large/cross-cutting feature: discovery/design first, then an Epic plus delivery slices and human gates.
Default rule: one independently mergeable PR = one implementation task. Do not split by technical layer when the slices cannot be meaningfully delivered or tested independently.
Epic contract
An Epic describes the outcome and coordination boundary. Include goal, context, chosen architecture/design reference, scope, non-goals, success criteria, child slices, human gates, dependency graph, parallel lanes, rollout/preview strategy, and completion rule.
Implementation task contract
Each agent-ready task should include:
- Goal
- Context
- Scope
- Testable acceptance criteria
- Technical direction / relevant repository paths when known
- Out of scope
- Dependencies by ticket title
- Preview/seed scenarios for user-facing work or reproducible bugs
- Automated test expectations
- Human test expectations
- Parent Epic/initiative reference
Do not make a task agent-ready while material product/architecture questions remain unresolved.
Classification
Keep workflow queues separate from architecture/domain classification. Prefer structured fields when the project supports them. Use each project's vocabulary; the values below are common examples, not a global enum.
- Area: project-defined technical/product surface (examples: Web App, API, Marketing, Infrastructure, Developer Experience, Cross-cutting)
- Pillar: project-defined domain capability (examples: Tenant, Permissions, Notifications, Platform) or None
- Work Type: Feature | Bug | Technical Debt | Discovery | Infrastructure | Documentation | Human Action
- Execution: AI | Human | AI + Human
Use tags only for exceptional overlapping attributes such as security, UX, breaking changes, cost, needs-decision, or preview-required.
Discovery-to-delivery flow
- Inspect existing work and architecture to avoid duplicates and contradictions.
- Identify unresolved decisions; keep discovery separate while they remain material.
- Document architecture/design decisions in the project's source of truth.
- Define the Epic outcome.
- Slice into independently mergeable/testable implementation tasks.
- Represent true manual gates as explicit human-operation tasks.
- Wire dependencies.
- Produce parallel execution lanes.
- Mark only dependency-safe, fully refined implementation tasks ready for agents.
- Produce an agent kickoff prompt that points to the Epic, dependencies, repository rules, and one-task/one-PR convention.
Parallel plan
Finish planning with a compact execution map:
Epic: <title>
Lane A — foundation
1. <task>
2. <task>
Lane B — independent work
1. <task>
Human gates
- <manual task> — required before/after <task>
Join
- <integration task> waits on required lanes/gates
Planning is not implementation: do not claim execution work merely because you created or refined it.