--- name: "dd-workflow" description: "Generate a Design Direction document from business requirements. Use when the user requests a DD, or when triage identifies DD 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" --- # Design Direction (DD) Workflow ## Overview Generate a Design Direction document — a high-level strategic document validating a business need or idea with business value, options analysis, decisions, and risks. The DD is always the first artifact in the design chain (DD → SD → TD). ## Prerequisites Checklist - [ ] Input: Business requirement, initiative brief, or problem statement - [ ] Confluence MCP server available - [ ] Jira MCP server available ## Step-by-Step Guide ### Step 1: Input Identification See [Discovery Pattern](references/discovery-pattern.md) for the full search methodology. #### Accept Input Accept the input from: Confluence page, chat attachment, pasted content, or Jira reference. #### Search for Context Search Confluence and Jira for: - Related business requirements or initiative briefs - Existing Design Directions in the same domain - Related Jira epics or initiatives - Stakeholder documents or decision records #### Present Findings ``` Input document: [title/summary] Related artifacts found: - [list with Confluence/Jira links] I will create a new Design Direction based on [input]. Proceed? ``` Wait for user confirmation before continuing. --- ### Step 2: Input Validation See [DD Validation Rules](references/dd-validation.md) for complete validation criteria. Validate that all required inputs for a DD 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.** **REQUIRED INPUT:** Confirm the target AWS region early (architecture.md default is ap-southeast-1 Singapore). If data residency requirements suggest a different region, resolve this as a DD decision before proceeding. --- ### Step 3: Brainstorming (Iterative) #### Load Context Reference these during brainstorming: - [Architecture](references/architecture.md) — Approved patterns, AWS services, serverless-first - [Principles](references/principles.md) — Enterprise architecture principles enforcement - [Cyber Security DD](references/cyber-security-dd-v1.md) — Cybersecurity rules for DD - [Software Assets](references/software_assets.md) — Registered software assets catalogue #### Instructions - Propose the core design approach based on validated inputs - Consider existing software assets to decide to Modify or build a new system/service - This step is a LOOP — continue refining until the user explicitly accepts - Only proceed to Step 4 when user confirms ("proceed", "accepted", "looks good", or similar) #### DD-Specific Brainstorming Scope **Design Component Clarification:** When identifying Design Components: - Ask the user explicitly: "Is this a new system, or a new feature within an existing system?" - A new product with its own UI, data, and logic is almost always a NEW Business Application - "Modify" means adding an entry point, integration hook, or data field to an existing system - Do NOT conflate "the product is new" with "we should modify existing systems to deliver it" Discuss and refine: - **Problem statement** — Is the problem clearly defined? - **Business value** — What value does solving this deliver? - **Options analysis** — What are the possible solutions? (minimum 2-3 options) - Option 1: [description, pros, cons, cost estimate, timescale, dependencies, risks] - Option 2: [description, pros, cons, cost estimate, timescale, dependencies, risks] - Option 3: Do nothing / defer - Note: Prototyping/piloting is a delivery practice within any Build approach — do NOT present it as a separate strategic option. - **Buy vs Build** — If a BUY option exists, has market research been done? - **Outcome-driven options** — Options MUST be framed around achieving the desired business outcome, NOT replicating the current process. - **Balanced presentation** — Do NOT pre-select a recommended option unless the user explicitly directs it. - **Component impact** — What existing components change? Any new components? - **Key decisions** — What decisions need to be made? - **Risks** — What risks are identified? (description, cause, impact, likelihood, consequence, rating, mitigation) #### Timeline Estimation Guidance When estimating Build timelines, account for AI-assisted development tools. A serverless AWS application with well-defined requirements typically takes 4–12 weeks with AI-assisted development, not 6–8 months. Buy options often take LONGER due to procurement processes (RFP, vendor evaluation, DPA). #### Output — MANDATORY Save **Before proceeding to Step 4, the finalised brainstorming output MUST be saved to disk.** Save to: `{workspace}/output/{artifact-name}-brainstorm.md` The brainstorm file MUST contain ALL structured sections (Problem Statement, Business Value, Options Analysis, Key Decisions, Risks, Design Components, End-to-End Flow, Assumptions, Governance Tier, Open Questions). See [Governance](references/governance.md) for tier calculation. **CRITICAL:** The brainstorm MUST be presented in chat AND explicitly approved by the user before proceeding. A user saying "proceed to SD" triggers the brainstorm step for SD — it is NOT implicit approval to skip brainstorming. --- ### Step 4: Document Generation #### Load Context (additional) - [Risk Assessment Framework](references/risk-assessment-framework.md) — Likelihood × Consequence matrix - [Conceptual Data Model](references/conceptual-data-model.md) — CDM guidance (DD only) - [Data Standards](references/data-standards.md) — Data and privacy principles #### Load Template Fetch the DD template from Confluence Template `3060957265` (space ID1) using `getConfluenceTemplate`. New DD pages has to be created using this template. #### Generate 1. **Read the brainstorm file** — this is the authoritative source for all design content 2. Read the template to understand the required document structure 3. Generate the DD document as Markdown following the template structure 4. Map brainstorm content to template sections 5. Align to architecture principles (serverless-first, approved AWS services) 6. Apply principles enforcement checklist 7. Score risks using the risk assessment matrix 8. **Design Components at DD level:** ONLY Business Applications. Do NOT include infrastructure services (AWS Cognito, Amazon Bedrock, DynamoDB) as design components. 9. **Template row completeness:** ALL rows from the template tables MUST be included (especially Architecture Principles Alignment — all 49 principles) 10. If deviating from guidance, CALL OUT with "⚠️ DEVIATION" callout #### Output Save generated document to: `{workspace}/output/dd-{artifact-name}.md` --- ### Step 5: Diagram Create a **C1 (Context) level diagram** using the `diagram-workflow` skill and following [Diagramming Standards](references/diagramming-standards.md): - Fill colours for lifecycle stage (Strategic=Pistachio, Emerging=Sky, Contained=Banana, Retiring=Rose, External=No fill) - Outline colours for design impact (New=Sapphire dotted, No change=Emerald solid, Modify=Orange dotted, Decomm=Red dotted) - Arrow colours for interaction type (New=Sapphire, No change=Emerald, Modify=Orange, Decomm=Red, Manual=Black dotted) --- ### 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: User requests SD/TD but no DD exists **Solution:** Inform the user that DD is always the first required artifact. Create the DD first. ### Issue: Template cannot be fetched **Solution:** STOP and inform the user. Never generate without the template structure. ### Issue: Brainstorm not approved **Solution:** Continue iterating. Never proceed to generation without explicit user approval. ## Best Practices - The DD focuses on WHAT and WHY, not HOW (that's for SD/TD) - Keep options analysis balanced — don't pre-select an option unless directed - Business value should be quantifiable where possible - Risks should reference the risk assessment framework