---
name: "triage-workflow"
description: "Identify which architecture artifact to create next (DD, SD, or TD) from a user requirement. Use when the user provides a business requirement without specifying the artifact type, or asks for the next design artifact."
license: "MIT"
metadata:
  author: "Srinivas K, Mahesvaran S, Srikanth Y, Thirukumaran V, Vignesh V R"
  version: "1.0.0"
---

# Triage Workflow

## Overview

Entry point when the user provides a requirement or document without specifying which artifact to create. This workflow searches for existing artifacts, identifies what already exists in the design chain (DD → SD → TD), and proposes the next artifact to generate.

## Prerequisites Checklist

- [ ] User has provided a business requirement, initiative brief, or existing design reference
- [ ] Confluence MCP server is available (for searching existing artifacts)
- [ ] Jira MCP server is available (for searching related work items)

## When to Use

- User says "Generate design for this requirement" without specifying DD/SD/TD
- User provides a document and asks for "the next design artifact"
- User is unsure which artifact is needed

## Step-by-Step Guide

### Step 1: Accept Input

Accept the input document from one of these sources:
- Confluence page (user provides page title, ID, or URL)
- Attached document in chat
- Pasted content in chat
- Jira work item reference

Read and understand the input content. Identify:
- What type of document is this? (Business requirement, initiative brief, existing DD, existing SD, etc.)
- What is the scope/domain?
- Key search terms for finding related artifacts

### Step 2: Discovery — Search for Existing Artifacts

See [Discovery Pattern](references/discovery-pattern.md) for the full search methodology.

Using the search terms identified in Step 1:

1. **Search Confluence** for existing Design Directions, Solution Designs, and Technical Designs related to this requirement
2. **Search Jira** for related epics, stories, or work items
3. Build a picture of what already exists:
   - Existing DDs? (list them with titles and status)
   - Existing SDs? (list them)
   - Existing TDs? (list them)
   - Related Jira items? (list key ones)

### Step 3: Propose Artifact

Based on what exists, propose the next action:

**CRITICAL RULE — DD First:** A Design Direction is ALWAYS the mandatory first artifact in the design chain. Even if the user's requirement appears to be at SD or TD level, if no approved DD exists for this requirement, the DD must be created first. The design hierarchy is strictly: DD → SD → TD. No artifact can be skipped.

| Input Type | Existing Artifacts | Recommendation |
|------------|-------------------|----------------|
| Business Requirement | None | **Create new DD** (mandatory first step) |
| Business Requirement | DD exists (approved) | Create SD |
| Business Requirement | DD + SD exist (approved) | Create TD |
| Business Requirement | DD exists (not approved) | Complete/update DD first |
| Design Direction | No SD | Create SD |
| Design Direction | SD exists | Create TD (or update SD) |
| Solution Design | No TD | Create TD |
| User asks for SD but no DD exists | None | **Create DD first** — inform user that DD is required before SD |
| User asks for TD but no SD exists | DD only | **Create SD first** — inform user that SD is required before TD |
| User asks for TD but no DD or SD | None | **Create DD first** — full chain required |

**Present to user:**
```
Based on my analysis:
- Input: [describe the input document]
- Found existing: [list existing artifacts with links]
- Recommendation: [Create/Update] [artifact type]
- Reason: [why this is the next logical step]
- Design chain status: DD [✅/❌] → SD [✅/❌] → TD [✅/❌]

Would you like to proceed with [artifact type], or would you prefer a different approach?
```

### Step 4: Route to Correct Workflow

Once the user confirms:
- If DD → Activate and follow the `dd-workflow` skill
- If SD → Activate and follow the `sd-workflow` skill
- If TD → Activate and follow the `td-workflow` skill
- If update existing → Load the corresponding workflow with the existing artifact as additional context

## Mandatory Workflow Rules

The following rules are NON-NEGOTIABLE across all workflows:

1. **DD-First:** A Design Direction is always the mandatory first artifact. Even if the user requests an SD or TD directly, if no approved DD exists for the requirement, the DD must be created first. The chain is strictly DD → SD → TD.
2. **Validation cannot be skipped:** Input Validation must complete successfully before brainstorming begins. Missing inputs must be gathered from the user.
3. **Brainstorming cannot be skipped:** Brainstorming is iterative and must result in explicit user approval before document generation begins.
4. **Brainstorm file is mandatory:** The brainstorm output MUST be saved to `{workspace}/output/` before document generation. This file is the single source of truth — the generation step reads from the file, not from chat memory.
5. **Template completeness:** Every section, row, and field from the Confluence template must appear in the generated document. Do NOT condense, summarise, or omit sections.
6. **Template must be fetched from Confluence before generation:** Before generating any DD, SD, or TD document, the agent MUST fetch the corresponding template page from Confluence using `getConfluencePage`. The template page IDs are:
   - DD: `4769349731` (Design Direction Template v2)
   - SD: `4769251461` (Solution Design Template v2)
   - TD: `4769349990` (Technical Design Template v2)
7. **Brainstorming must be presented in chat and explicitly approved:** The agent MUST present the full brainstorm proposal to the user IN CHAT, explicitly ask for approval, and wait for confirmation before proceeding.

## Deviation Policy

The document generation SHOULD align to steering/reference files. However, if the BEST solution requires deviation:

1. The assistant MAY deviate from guidance
2. The assistant MUST explicitly call out which rules are being ignored
3. The assistant MUST explain WHY the deviation produces a better outcome
4. The user MUST acknowledge the deviation before it is included in the final artifact

## Output Convention

Generated artifacts are written to `{workspace}/output/` (workspace root, NOT inside the power directory). This directory should be `.gitignore`d.

## Troubleshooting

### Issue: Cannot find existing artifacts in Confluence
**Solution:** Ask the user for alternative search terms, project codes, or direct Confluence page links. The search might be using the wrong domain keywords.

### Issue: User disagrees with the recommended artifact
**Solution:** Discuss alternatives. The user may have context about existing artifacts that were not found in the search. If the user insists on skipping the DD-first rule, explain the governance requirement but ultimately defer to their decision with a documented deviation.

## Notes

- If the user disagrees with the recommendation, discuss alternatives
- The user may provide additional context that changes the recommendation
- Always explain the reasoning behind the recommendation