sdlc-design
sdlc-design
Write intent/<slug>/spec.md from an accepted intent. In a normal run, wait for approval; an explicitly authorized autonomous queue may approve after the confidence assessment below. On approval, read sdlc-apply and execute it from the plan step. Do not implement.
Keep requirements and design in spec.md. Do not write a design.md. Trace the accepted outcome and each material constraint to observable requirements/scenarios; use the user's concrete examples and limits where provided. Do not silently replace the wanted behavior with an easier implementation. Carry missing product decisions forward for resolution, not invented defaults.
Keep explicit automation, named providers or integrations, and requested data coverage as requirements. Preserve short decisive user wording or a source excerpt in the relevant requirement/scenario when it could be easy to lose. Do not move a requested outcome into Out of scope without explicit user acceptance; unrequested implementation non-goals may clarify the boundary. Autonomous approval cannot authorize reducing the accepted outcome. If access, credentials, or a dependency is unavailable, record the blocker and complete useful authorized work, but leave the requested capability blocked until delivered or until the user explicitly accepts a different outcome after seeing the tradeoff. For critical automation or integrations, specify an observable end-to-end scenario; a manual fallback does not satisfy it.
Check added scope as well as missing scope. Additional screens, required inputs, acknowledgements, reconfirmation steps or gates beyond the requested flow are product decisions, not routine implementation details. Trace each to an explicit user request or an evidenced binding constraint in existing artifacts; broad autonomy, generic product goals and agent-authored requirements do not supply that authority. Autonomous approval cannot expand the accepted outcome. Keep necessary internal validation, security and error handling tied to the changed flow, but do not turn known external limits into an unrequested user ceremony. If a new product decision is genuinely needed and authority is missing, present the concrete tradeoff before implementing it. An agent-created guard is not justification for another feature needed solely to configure that guard. Size the solution to the stated users and deployment; do not assume organizational approval, compliance administration or future multi-user needs. Prefer the smallest design that delivers the complete requested behavior.
Apply YAGNI after understanding the affected flow: reuse suitable existing code and patterns, then prefer standard-library, native-platform or installed-dependency capabilities when they meet the requirements. Add custom code or a dependency only for a demonstrated gap. Avoid speculative configuration, extension points and scaffolding for future features; retain abstractions justified by current contracts or clarity. This is a quick design choice, not a new research or review stage. Minimize implementation complexity, not requested capability: preserve explicit outcomes, compatibility, validation, error handling, security and accessibility. Readable, complete code wins over fewer lines; simplification cannot silently substitute a lesser outcome.
Before you start
Resolve assets/ and scripts/ against this skill's installed directory supplied by the host, not the product repo. Commands use python3 as an example; choose an available Python 3.8+ interpreter and quote resolved paths. Load a required next skill through the host or its installed SKILL.md; if it or its resources are unavailable, hand off at that gate rather than inventing them.
Need intent/<slug>/intent.md with status: accepted (or an accept in this session). If it is still draft, go back to sdlc-plan. An existing draft spec may be resumed here; revise it rather than copying the template over it.
The workflow authorizes owned artifact commits unless the user or host restricts them. Before writing, record the repository, branch, HEAD, staged paths, and working-tree/untracked paths. Reuse an owned checkout first; default new worktrees to <agreed-project-workspace>/.worktrees/. Never move a live checkout. Use a clean isolated worktree if existing work would overlap or be absorbed; otherwise stop the commit and explain the conflict. Never reset or stash someone else's changes. Stage only this concern. Use Conventional Commits (type(scope): imperative summary, optional scope), a blank line, and a sentence on why; mark breaking changes with ! or BREAKING CHANGE:. Do not push unless asked.