sdlc-speclisted

# From intent to spec Second file in the chain (`ai-native-sdlc`). Requirements and design were separate phases owned by separate people for accountability reasons. The accountability is worth keeping; the two-phase handoff is not — it's slow, and meaning leaks at the boundary. Here it's one pass, and the reviewer reviews instead of writing. ## Before you start An accepted intent file (`sdlc-intent`). Whatever policy must constrain the design — security rules, API conventions, accessibility, brand — carries far more weight when it's written down as a skill (`sdlc-claude-md`), because then it shapes the design as it's written rather than being discovered in review three weeks later. ## The pass Load the intent and the policy skills, then ask for a design that: - solves the problem the intent states, in the existing codebase, not in the abstract - conforms to the policies in force, naming which one drove which decision - **calls out every place two requirements or two policies can't both hold** Run it by hand until you trust the shape, then make it a slash command. Eventually the intent's acceptance triggers it and opens the spec as a PR — at which point the first human involvement is the review. ## Conflicts are the deliverable The design is the boring part. The valuable output is the list of things that can't be cleanly satisfied, because those are exactly what a careful analyst would have escalated. Surface rather than solve when: - two policies pull in opposite