--- name: "sd-workflow" description: "Generate a Solution Design document from an approved Design Direction. Use when the user requests an SD, or when triage identifies SD as the next artifact in the design chain." license: "MIT" metadata: author: "Srinivas K, Mahesvaran S, Srikanth Y, Thirukumaran V, Vignesh V R" version: "1.0.0" --- # Solution Design (SD) Workflow ## Overview Generate a Solution Design document — a high-level architecture document with the selected option from the DD, event specifications, conceptual data model, cybersecurity and privacy alignment, and new decisions or risks. ## Prerequisites Checklist - [ ] Input: Approved Design Direction (DD) document — **MANDATORY** - [ ] Confluence MCP server available - [ ] Jira MCP server available **CRITICAL RULE:** An SD cannot be created without an approved DD. If no applicable DD exists: 1. Inform the user that a Design Direction must be completed first 2. Route to `dd-workflow` skill to create the DD 3. Only return to the SD workflow after the DD is approved ## Step-by-Step Guide ### Step 1: Input Identification See [Discovery Pattern](references/discovery-pattern.md) for the full search methodology. #### Accept Input Accept the DD reference from: Confluence page, chat attachment, pasted content, or direct reference. #### Search for Context Search Confluence and Jira for: - The referenced Design Direction (full content) - Related Solution Designs in the same domain - Technical standards or patterns relevant to the selected option - Related Jira epics, stories, or technical tasks - Any existing architecture decision records (ADRs) #### Present Findings ``` Design Direction: [DD title and link] Selected option from DD: [option name/summary] Related artifacts found: - [list with Confluence/Jira links] I will create a Solution Design based on [DD reference], implementing [selected option]. Proceed? ``` Wait for user confirmation before continuing. --- ### Step 2: Input Validation See [SD Validation Rules](references/sd-validation.md) for complete validation criteria. Validate that all required inputs for an SD are present. If any are missing, request them from the user before proceeding. **Do NOT proceed to Step 3 until all required inputs are validated.** --- ### Step 3: Brainstorming (Iterative) #### Load Context Reference these during brainstorming: - [Architecture](references/architecture.md) — Approved patterns, AWS services - [Cloud Reference Architecture](references/cloud-reference-architecture.md) — AWS reference patterns - [Principles](references/principles.md) — Enterprise architecture principles - [Cyber Security SD](references/cyber-security-sd-v1.md) — Cybersecurity rules for SD - [Logical Data Model](references/logical-data-model.md) — Logical data model guidance #### Instructions - Propose the solution architecture based on the selected DD option - This step is a LOOP — continue refining until the user explicitly accepts - Only proceed to Step 4 when user confirms #### SD-Specific Rules **Service Boundaries:** Before designing the data model, confirm service boundaries with the user. Each microservice MUST own its data store. If proposing a shared database, explicitly justify why and get user approval. **Data Model Completeness:** Before presenting the brainstorm, verify that every FR capability area has corresponding data entities. Cross-reference the FR table against proposed entities. #### Brainstorming Scope Discuss and refine: - **Solution overview** — How does the selected option translate to architecture? - **Component design** — What components are involved? New vs modified? - **Event specifications** — What events are produced/consumed? Event schemas? - **Conceptual data model** — Key entities, relationships, data flows - **Integration points** — How does this integrate with existing systems? - **Cybersecurity alignment** — How does the solution align with security principles? - **Privacy alignment** — How does the solution handle PII and privacy requirements? - **Non-functional requirements** — Performance, scalability, availability targets - **New decisions** — Decisions that emerge from the solution design - **New risks** — Risks identified during solution design #### Output — MANDATORY Save Save to: `{workspace}/output/sd-{artifact-name}-brainstorm.md` The brainstorm file MUST contain ALL structured sections (Solution Overview, Component Design, Event Specifications, Data Model, Integration Points, Cybersecurity Alignment, Privacy Alignment, NFRs, New Decisions, New Risks, Governance Tier, Assumptions, Open Questions). **CRITICAL:** Present brainstorm in chat and get explicit user approval before proceeding. --- ### Step 4: Document Generation #### Load Context (additional) - [Risk Assessment Framework](references/risk-assessment-framework.md) #### Load Template Fetch the SD template from Confluence Template `3630235684` (space ID1) using `getConfluenceTemplate`. New SD pages has to be created using this template. #### Generate 1. **Read the brainstorm file** — authoritative source for all design content 2. Read the template structure 3. Generate the SD document as Markdown following the template 4. Map brainstorm content to template sections 5. Align to architecture principles 6. Apply principles enforcement checklist 7. Score risks using the risk assessment matrix 8. Align to cybersecurity and data/privacy standards 9. Ensure traceability back to the DD 10. **Verify completeness:** Every component, event, decision, and risk from the brainstorm MUST appear 11. If deviating, mark with "⚠️ DEVIATION" callout #### Output Save generated document to: `{workspace}/output/sd-{artifact-name}.md` --- ### Step 5: Diagram Create a **C2 (Container) level diagram** using the `diagram-workflow` skill and following [Diagramming Standards](references/diagramming-standards.md): - Show the system boundary with containers (applications, data stores, message brokers) - Include Tech Stack labels on each container (required at C2 level) - Include PII indicators where applicable - Follow colour conventions for lifecycle stage, design impact, and interaction type --- ### Step 6: Review & Publish **HARD RULE:** The publish step MUST NOT proceed unless the template has been fetched in the SAME session. Present the generated document for human review. **If user approves and requests Confluence publish:** Use the `confluence-publish` skill. ## Troubleshooting ### Issue: No approved DD exists **Solution:** Route to `dd-workflow` skill first. The design chain is strictly DD → SD → TD. ### Issue: Selected option unclear from DD **Solution:** Ask the user to clarify which option was selected and why. ### Issue: NFRs are vague **Solution:** Help the user define them with sensible defaults for their domain. ## Best Practices - The SD focuses on HOW at a high level (components, events, data model) - Must maintain traceability to the DD's selected option - Cybersecurity and privacy sections are mandatory — never skip them - Event specifications should include: event name, producer, consumer, schema outline - Conceptual data model should show entities and relationships (not physical tables)