clarify-requirementslisted

Use when a delivery run's promoted (draft) requirements need the Solution Architect's own clarification pass before technical design: raising the technical/architectural questions the Business Analyst would not have surfaced — ownership gaps, integration-boundary conflicts, NFR infeasibility, contradiction with an existing decision record — and resolving every one with the human in writing. This is the clarify_requirements action of the design stretch — one Agent-tool dispatch with subagent_type solution-architect — distinct from resolve-open-questions (the BA's business-truth questions) and technical-design (which must not start while these questions are open).
BhangeeF16/kaizen · ★ 0 · Web & Frontend · score 65

Install: claude install-skill BhangeeF16/kaizen

# Clarify Requirements Raise and resolve the Solution Architect's own open questions against the promoted requirements. The BA validated business truth, not technical feasibility — the absence of BA questions does not mean there are none. ## Dispatch One synchronous `Agent`-tool call, `subagent_type: solution-architect`. ## Required inputs - `planning.md`. - The requirement register with all rows promoted (draft status). ## Required outputs (all mandatory) - Solution-Architect open questions recorded in `design.md` — technical/architectural gaps the Business Analyst would not have surfaced (ownership, integration boundary, NFR feasibility, contradiction with an existing ADR or business rule). - Every recorded question answered interactively with the user and in writing, or an explicit statement that none were raised. ## Rules - This gate is separate from the BA's: resolving the BA's questions does not resolve these. - A score below minimum at the following checkpoint routes back here, not forward. ## Result Report each required output produced (with its location), the result (pass / pass_with_risks / blocked / failure), and blocking questions as an explicit list (empty list stated explicitly).