ma-agents 2.16.2 → 2.17.0

package/lib/bmad-customizations/bmm-mil498.customize.yaml

@@ -14,20 +14,23 @@ persona:
 
 menu:
   - trigger: bmad-mil-generate-srs
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-srs.md"
+    workflow: "bmm/workflows/mil498/srs/workflow.yaml"
     description: "Generate SRS (Software Requirements Specification)"
   - trigger: bmad-mil-generate-sdd
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-sdd.md"
+    workflow: "bmm/workflows/mil498/sdd/workflow.yaml"
     description: "Generate SDD (Software Design Description)"
   - trigger: bmad-mil-generate-sdp
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-sdp.md"
+    workflow: "bmm/workflows/mil498/sdp/workflow.yaml"
     description: "Generate SDP (Software Development Plan)"
   - trigger: bmad-mil-generate-ocd
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-ocd.md"
+    workflow: "bmm/workflows/mil498/ocd/workflow.yaml"
     description: "Generate OCD (Operational Concept Description)"
   - trigger: bmad-mil-generate-sss
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-sss.md"
+    workflow: "bmm/workflows/mil498/sss/workflow.yaml"
     description: "Generate SSS (System/Subsystem Specification)"
   - trigger: bmad-mil-generate-std
-    workflow: "bmm/workflows/mil498/bmad-mil-generate-std.md"
+    workflow: "bmm/workflows/mil498/std/workflow.yaml"
     description: "Generate STD (Software Test Description)"
+  - trigger: bmad-mil-generate-ssdd
+    workflow: "bmm/workflows/mil498/ssdd/workflow.yaml"
+    description: "Generate SSDD (System/Subsystem Design Description)"

package/lib/bmad-customizations/mil498.md

@@ -62,12 +62,13 @@ You must fully embody this agent's persona and follow all activation instruction
 <menu>
     <item cmd="MH">[MH] Redisplay Menu Help</item>
     <item cmd="CH">[CH] Chat with Joseph about MIL-STD-498</item>
-    <item cmd="GS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-srs.md">[GS] Generate SRS: Software Requirements Specification</item>
-    <item cmd="GD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdd.md">[GD] Generate SDD: Software Design Description</item>
-    <item cmd="GP" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdp.md">[GP] Generate SDP: Software Development Plan</item>
-    <item cmd="GO" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-ocd.md">[GO] Generate OCD: Operational Concept Description</item>
-    <item cmd="SS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sss.md">[SS] Generate SSS: System/Subsystem Specification</item>
-    <item cmd="GT" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-std.md">[GT] Generate STD: Software Test Description</item>
+    <item cmd="GS" workflow="{project-root}/_bmad/bmm/workflows/mil498/srs/workflow.yaml">[GS] Generate SRS: Software Requirements Specification</item>
+    <item cmd="GD" workflow="{project-root}/_bmad/bmm/workflows/mil498/sdd/workflow.yaml">[GD] Generate SDD: Software Design Description</item>
+    <item cmd="GP" workflow="{project-root}/_bmad/bmm/workflows/mil498/sdp/workflow.yaml">[GP] Generate SDP: Software Development Plan</item>
+    <item cmd="GO" workflow="{project-root}/_bmad/bmm/workflows/mil498/ocd/workflow.yaml">[GO] Generate OCD: Operational Concept Description</item>
+    <item cmd="SS" workflow="{project-root}/_bmad/bmm/workflows/mil498/sss/workflow.yaml">[SS] Generate SSS: System/Subsystem Specification</item>
+    <item cmd="GT" workflow="{project-root}/_bmad/bmm/workflows/mil498/std/workflow.yaml">[GT] Generate STD: Software Test Description</item>
+    <item cmd="SD" workflow="{project-root}/_bmad/bmm/workflows/mil498/ssdd/workflow.yaml">[SD] Generate SSDD: System/Subsystem Design Description</item>
     <item cmd="DA">[DA] Dismiss Agent</item>
 </menu>
 </agent>

package/lib/bmad-workflows/mil498/ocd/instructions.md

@@ -0,0 +1,99 @@
+# Generate Operational Concept Description (OCD)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81430
+
+## Objective
+
+Generate a compliant OCD document by describing the system from the user's and stakeholder's perspective, extracting operational concepts from existing project artifacts into the MIL-STD-498 OCD template structure.
+
+## Step 1 — Discover Project Artifacts
+
+Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
+
+| Priority | Artifact | Search Pattern |
+|----------|----------|----------------|
+| Required | PRD | `**/prd.md`, `**/prd-*.md` |
+| Recommended | Architecture | `**/architecture.md`, `**/architecture-*.md` |
+| Recommended | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
+| Optional | Product Brief | `**/product-brief*.md` |
+| Optional | Epics & Stories | `**/epics*.md`, `**/stories/*.md` |
+
+If the **PRD** is missing, warn the user and ask whether to proceed with available data or stop.
+
+## Step 2 — Load Template
+
+Read the OCD template from:
+`{template}`
+
+This defines the required DID sections and content expectations for each paragraph.
+
+## Step 3 — Generate Document
+
+Write the document in {document_output_language}, populating each template section. The OCD should be written in language accessible to users and stakeholders, minimizing technical jargon.
+
+### Section 1: Scope
+- **1.1 Identification**: Extract system name, version, identifiers from PRD
+- **1.2 System overview**: Summarize the system purpose from the user's perspective
+- **1.3 Document overview**: Describe this OCD document's purpose and contents
+
+### Section 2: Referenced documents
+- List all project artifacts used as input sources
+
+### Section 3: Current system or situation
+- **3.1 Background, objectives, and scope**: Describe the problem domain and business objectives from the PRD
+- **3.2 Operational policies and constraints**: Current business rules and constraints
+- **3.3 Description of current system or situation**: How things work today — existing workflows, pain points, limitations. Include:
+  - Operational environment
+  - Major components and interconnections
+  - Interfaces to external systems
+  - User roles and their current interactions
+- **3.4 Users or involved personnel**: Identify all user types and stakeholders from PRD/UX
+- **3.5 Support concept**: Current support and maintenance approach (if applicable)
+
+### Section 4: Justification for and nature of changes
+- **4.1 Justification for changes**: Why the new system is needed — business drivers from PRD
+- **4.2 Description of needed changes**: What must change to meet objectives
+- **4.3 Priorities among the changes**: Rank changes by business importance
+
+### Section 5: Concept for the proposed system
+- **5.1 Background, objectives, and scope**: Vision for the new system from Product Brief/PRD
+- **5.2 Operational policies and constraints**: New policies and constraints
+- **5.3 Description of the proposed system**: How the new system will work. For each operational scenario:
+  - User roles involved
+  - Step-by-step workflow
+  - System behavior and responses
+  - Extract scenarios from UX Designs and Stories
+- **5.4 Users or involved personnel**: How user roles change with the new system
+- **5.5 Support concept**: Planned support and maintenance approach
+
+### Section 6: Operational scenarios
+- Document key end-to-end scenarios from UX Designs and Epics
+- Each scenario should describe: trigger, actors, sequence of actions, expected outcomes
+- Include both normal operation and exception/error scenarios
+
+### Section 7: Notes
+- Glossary, acronyms, and background information
+
+## Step 4 — Validate
+
+Before presenting to the user, verify:
+- All template sections are populated or marked "Not applicable" with justification
+- Document is written from the user/stakeholder perspective, not the developer perspective
+- Operational scenarios are complete and realistic
+- Document is written in {document_output_language}
+
+## Step 5 — Review
+
+Present the complete document to {user_name} for review.
+Highlight any sections where information was inferred or assumptions were made.
+Offer to refine any section based on feedback.
+
+## Step 6 — Save
+
+Write the final document to:
+`{output_folder}/planning-artifacts/OCD.md`
+
+Confirm the file was saved and display a summary of:
+- Number of user roles identified
+- Number of operational scenarios documented
+- Any sections marked "Not applicable"

package/lib/bmad-workflows/mil498/ocd/workflow.yaml

@@ -0,0 +1,15 @@
+name: "bmad-mil-generate-ocd"
+version: "1.0.0"
+description: "Generate a MIL-STD-498 Operational Concept Description (OCD). Use when the user says 'generate OCD' or 'generate operational concept description'"
+
+config_source: "{project-root}/_bmad/bmm/config.yaml"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+output_folder: "{config_source}:output_folder"
+date: system-generated
+
+installed_path: "{project-root}/_bmad/bmm/workflows/mil498/ocd"
+instructions: "{installed_path}/instructions.md"
+
+template: "{project-root}/_bmad/bmm/templates/mil498/OCD.md"

package/lib/bmad-workflows/mil498/sdd/instructions.md

@@ -0,0 +1,104 @@
+# Generate Software Design Description (SDD)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81435
+
+## Objective
+
+Generate a compliant SDD document by mapping the system's software design and architecture to the MIL-STD-498 Software Design Description template structure. This document describes the design of a CSCI (Computer Software Configuration Item).
+
+**Note**: This workflow uses the SSDD template structure adapted for CSCI-level design, as both SDD and SSDD follow the same DID pattern but at different abstraction levels.
+
+## Step 1 — Discover Project Artifacts
+
+Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
+
+| Priority | Artifact | Search Pattern |
+|----------|----------|----------------|
+| Required | Architecture | `**/architecture.md`, `**/architecture-*.md` |
+| Required | PRD | `**/prd.md`, `**/prd-*.md` |
+| Recommended | Epics & Stories | `**/epics*.md`, `**/epic-*.md`, `**/stories/*.md` |
+| Recommended | SRS | `**/SRS.md` |
+| Optional | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
+| Optional | Product Brief | `**/product-brief*.md` |
+
+If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
+
+## Step 2 — Load Template
+
+Read the design document template from:
+`{template}`
+
+This defines the required DID sections. Adapt the system-level language to CSCI-level software design.
+
+## Step 3 — Generate Document
+
+Write the document in {document_output_language}, populating each template section:
+
+### Section 1: Scope
+- **1.1 Identification**: Identify the CSCI by name, version, and project-unique identifier
+- **1.2 System overview**: Summarize the system and this CSCI's role within it
+- **1.3 Document overview**: Describe this SDD document's purpose and contents
+
+### Section 2: Referenced documents
+- List all project artifacts and external references used
+
+### Section 3: CSCI-wide design decisions
+
+Describe design decisions that apply across the entire CSCI:
+- **Architectural patterns**: Extract from Architecture document (e.g., MVC, microservices, event-driven)
+- **Technology stack**: Languages, frameworks, libraries, and their versions
+- **Behavioral design**: How the CSCI behaves from the user's perspective
+- **Database/data design**: How data stores appear to users and external systems
+- **Safety, security, privacy**: Approaches to meeting these requirements
+- **Other decisions**: Flexibility, availability, maintainability approaches
+
+Each decision should reference the requirement(s) it satisfies.
+
+### Section 4: CSCI architectural design
+
+- **4.1 CSCI components**: Identify all software components (modules, packages, services). Assign project-unique identifiers. Show static relationships (component diagrams). State each component's purpose and allocated requirements
+- **4.2 Concept of execution**: Describe dynamic behavior — data flow, control flow, state transitions, timing, concurrency, error handling. Use diagrams where helpful
+- **4.3 Interface design**: Document interfaces between components and with external entities. For each interface provide:
+  - Data elements with types, sizes, formats, units, ranges
+  - Communication methods and protocols
+  - Error handling and recovery
+
+### Section 5: CSCI detailed design
+
+For each component identified in Section 4.1, describe:
+- Internal structure and sub-components
+- Algorithms and processing logic (map from Stories/Epics)
+- Internal data structures and data flows
+- Constraints and limitations
+
+### Section 6: Requirements traceability
+- **6.a**: Map each CSCI component to the requirements it addresses (from SRS or PRD)
+- **6.b**: Map each requirement to the components that implement it
+
+### Section 7: Notes
+- Glossary of design terms, acronyms, and abbreviations
+
+## Step 4 — Validate
+
+Before presenting to the user, verify:
+- All template sections are populated or marked "Not applicable" with justification
+- Components have unique identifiers
+- Design decisions reference their driving requirements
+- Interfaces are described consistently from both sides
+- Document is written in {document_output_language}
+
+## Step 5 — Review
+
+Present the complete document to {user_name} for review.
+Highlight any design decisions where assumptions were made.
+Offer to refine any section based on feedback.
+
+## Step 6 — Save
+
+Write the final document to:
+`{output_folder}/planning-artifacts/SDD.md`
+
+Confirm the file was saved and display a summary of:
+- Number of components identified
+- Number of interfaces documented
+- Any sections marked "Not applicable"

package/lib/bmad-workflows/mil498/sdd/workflow.yaml

@@ -0,0 +1,16 @@
+name: "bmad-mil-generate-sdd"
+version: "1.0.0"
+description: "Generate a MIL-STD-498 Software Design Description (SDD). Use when the user says 'generate SDD' or 'generate software design description'"
+
+config_source: "{project-root}/_bmad/bmm/config.yaml"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+output_folder: "{config_source}:output_folder"
+date: system-generated
+
+installed_path: "{project-root}/_bmad/bmm/workflows/mil498/sdd"
+instructions: "{installed_path}/instructions.md"
+
+# SDD uses SSDD template structure adapted for CSCI-level design
+template: "{project-root}/_bmad/bmm/templates/mil498/SSDD.md"

package/lib/bmad-workflows/mil498/sdp/instructions.md

@@ -0,0 +1,98 @@
+# Generate Software Development Plan (SDP)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81427
+
+## Objective
+
+Generate a compliant SDP document by extracting project planning, methodology, and management information from existing project artifacts into the MIL-STD-498 SDP template structure.
+
+## Step 1 — Discover Project Artifacts
+
+Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
+
+| Priority | Artifact | Search Pattern |
+|----------|----------|----------------|
+| Required | Product Brief | `**/product-brief*.md` |
+| Required | PRD | `**/prd.md`, `**/prd-*.md` |
+| Recommended | Architecture | `**/architecture.md`, `**/architecture-*.md` |
+| Recommended | Project Context | `**/project-context.md` |
+| Optional | Sprint Status | `**/sprint-status*.yaml`, `**/sprint-status*.md` |
+| Optional | Epics | `**/epics*.md` |
+
+If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
+
+## Step 2 — Load Template
+
+Read the SDP template from:
+`{template}`
+
+This defines the required DID sections and content expectations for each paragraph.
+
+## Step 3 — Generate Document
+
+Write the document in {document_output_language}, populating each template section:
+
+### Section 1: Scope
+- **1.1 Identification**: Extract project name, version, identifiers from PRD
+- **1.2 System overview**: Summarize from Product Brief and PRD
+- **1.3 Document overview**: Describe this SDP document's purpose
+- **1.4 Relationship to other plans**: Reference any related project plans
+
+### Section 2: Referenced documents
+- List all project artifacts and standards used
+
+### Section 3: Overview of required work
+- **Requirements and constraints**: From PRD scope and constraints
+- **Documentation requirements**: What MIL-STD-498 documents are planned
+- **Life cycle position**: Current project phase
+- **Acquisition strategy**: From Product Brief
+- **Schedule and resource constraints**: From PRD or Sprint Status
+- **Other constraints**: Security, methods, standards, interdependencies
+
+### Section 4: Plans for general software development activities
+- **4.1 Software development process**: Describe the BMAD-METHOD lifecycle and how it maps to MIL-STD-498 activities
+- **4.2 General plans for software development**: High-level approach to requirements analysis, design, implementation, testing
+- Map the BMAD workflow (Product Brief → PRD → Architecture → Epics → Stories → Implementation) to MIL-STD-498 activities
+
+### Section 5: Plans for performing detailed software development activities
+- **Requirements analysis**: How requirements are gathered and validated (BMAD PRD creation)
+- **Software design**: How architecture and detailed design are produced
+- **Coding and testing**: Implementation approach, testing strategy
+- **Integration**: How components are integrated
+- **Qualification testing**: Test planning and execution approach
+
+### Section 6: Schedules and activity network
+- Map Epics/Sprint plans to a development schedule if available
+- Identify milestones and deliverables
+
+### Section 7: Project organization and resources
+- Development team structure from Product Brief
+- Tools, environments, and infrastructure from Architecture/Project Context
+
+### Additional sections (as defined in template)
+- Populate all remaining template sections based on available project information
+- Mark sections "Not applicable" with justification where information is unavailable
+
+## Step 4 — Validate
+
+Before presenting to the user, verify:
+- All template sections are populated or marked "Not applicable" with justification
+- Development process description accurately reflects the actual methodology
+- Schedule information is consistent with available Sprint/Epic data
+- Document is written in {document_output_language}
+
+## Step 5 — Review
+
+Present the complete document to {user_name} for review.
+Highlight any sections where information was inferred or assumptions were made.
+Offer to refine any section based on feedback.
+
+## Step 6 — Save
+
+Write the final document to:
+`{output_folder}/planning-artifacts/SDP.md`
+
+Confirm the file was saved and display a summary of:
+- Development phases identified
+- Key milestones documented
+- Any sections marked "Not applicable"

package/lib/bmad-workflows/mil498/sdp/workflow.yaml

@@ -0,0 +1,15 @@
+name: "bmad-mil-generate-sdp"
+version: "1.0.0"
+description: "Generate a MIL-STD-498 Software Development Plan (SDP). Use when the user says 'generate SDP' or 'generate software development plan'"
+
+config_source: "{project-root}/_bmad/bmm/config.yaml"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+output_folder: "{config_source}:output_folder"
+date: system-generated
+
+installed_path: "{project-root}/_bmad/bmm/workflows/mil498/sdp"
+instructions: "{installed_path}/instructions.md"
+
+template: "{project-root}/_bmad/bmm/templates/mil498/SDP.md"

package/lib/bmad-workflows/mil498/srs/instructions.md

@@ -0,0 +1,103 @@
+# Generate Software Requirements Specification (SRS)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81433
+
+## Objective
+
+Generate a compliant SRS document by extracting and organizing software requirements from existing project artifacts into the MIL-STD-498 SRS template structure.
+
+## Step 1 — Discover Project Artifacts
+
+Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
+
+| Priority | Artifact | Search Pattern |
+|----------|----------|----------------|
+| Required | PRD | `**/prd.md`, `**/prd-*.md` |
+| Required | Architecture | `**/architecture.md`, `**/architecture-*.md` |
+| Recommended | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
+| Recommended | Epics | `**/epics*.md`, `**/epic-*.md` |
+| Optional | Product Brief | `**/product-brief*.md` |
+| Optional | Existing SRS | `**/SRS.md` |
+
+If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
+
+If an existing SRS is found, ask the user whether to update it or generate from scratch.
+
+## Step 2 — Load Template
+
+Read the SRS template from:
+`{template}`
+
+This defines the required DID sections and content expectations for each paragraph.
+
+## Step 3 — Generate Document
+
+Write the document in {document_output_language}, populating each template section:
+
+### Section 1: Scope
+- **1.1 Identification**: Extract software name, version, CSCI identifiers from the PRD and Architecture
+- **1.2 System overview**: Summarize purpose, nature, development history from PRD
+- **1.3 Document overview**: Describe this SRS document's purpose and contents
+
+### Section 2: Referenced documents
+- List all project artifacts used as input sources, with their titles and versions
+
+### Section 3: Requirements
+
+- **3.1 Required states and modes**: Identify operational modes from Architecture (e.g., normal, degraded, maintenance, training). If none, state "The CSCI does not have distinct operational states or modes"
+- **3.2 CSCI capability requirements**: Map each Epic/feature from the PRD to a numbered capability requirement (3.2.1, 3.2.2, etc.). Each requirement must have:
+  - A unique project identifier (e.g., SRS-CAP-001)
+  - Clear, testable acceptance criteria
+  - Parameters: response times, throughput, accuracy, capacity as applicable
+  - Error handling and boundary conditions
+- **3.3 CSCI external interface requirements**: Map external interfaces from the Architecture document. Include user interfaces, hardware interfaces, software interfaces, and communication interfaces
+- **3.4 CSCI internal interface requirements**: Document internal component interfaces from Architecture
+- **3.5 CSCI internal data requirements**: Identify persistent data stores, databases, and data models
+- **3.6 Adaptation requirements**: Document any site-specific or installation-specific requirements
+- **3.7 Safety requirements**: Extract from PRD/Architecture if applicable
+- **3.8 Security and privacy requirements**: Extract from PRD/Architecture
+- **3.9 CSCI environment requirements**: Document runtime environment constraints
+- **3.10 Computer resource requirements**: Extract hardware/software constraints from Architecture
+- **3.11 Software quality factors**: Document quality attributes (reliability, maintainability, portability, etc.)
+- **3.12 Design and implementation constraints**: Technology stack constraints from Architecture
+- **3.13 Personnel-related requirements**: Any user skill or training requirements
+- **3.14 Training-related requirements**: If applicable
+- **3.15 Logistics-related requirements**: If applicable
+- **3.16 Other requirements**: Any requirements not covered above
+- **3.17 Packaging requirements**: Deployment and distribution requirements
+- **3.18 Precedence and criticality of requirements**: Rank requirements by priority
+
+### Section 4: Qualification provisions
+- For each requirement in Section 3, specify the qualification method: Demonstration, Test, Analysis, or Inspection
+
+### Section 5: Requirements traceability
+- **5.a**: Map each SRS requirement to its parent system requirement
+- **5.b**: Map each system requirement to the SRS requirements that address it
+
+### Section 6: Notes
+- Glossary of terms, acronyms, and abbreviations used in this document
+
+## Step 4 — Validate
+
+Before presenting to the user, verify:
+- All template sections are populated or marked "Not applicable" with justification
+- Every requirement has a unique identifier (SRS-xxx-nnn format)
+- Every requirement is testable and traceable
+- Cross-references between sections are consistent
+- Document is written in {document_output_language}
+
+## Step 5 — Review
+
+Present the complete document to {user_name} for review.
+Highlight any sections where information was inferred or assumptions were made.
+Offer to refine any section based on feedback.
+
+## Step 6 — Save
+
+Write the final document to:
+`{output_folder}/planning-artifacts/SRS.md`
+
+Confirm the file was saved and display a summary of:
+- Total number of requirements identified
+- Number of capabilities documented
+- Any sections marked "Not applicable"

package/lib/bmad-workflows/mil498/srs/workflow.yaml

@@ -0,0 +1,15 @@
+name: "bmad-mil-generate-srs"
+version: "1.0.0"
+description: "Generate a MIL-STD-498 Software Requirements Specification (SRS). Use when the user says 'generate SRS' or 'generate software requirements specification'"
+
+config_source: "{project-root}/_bmad/bmm/config.yaml"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+output_folder: "{config_source}:output_folder"
+date: system-generated
+
+installed_path: "{project-root}/_bmad/bmm/workflows/mil498/srs"
+instructions: "{installed_path}/instructions.md"
+
+template: "{project-root}/_bmad/bmm/templates/mil498/SRS.md"

package/lib/bmad-workflows/mil498/ssdd/instructions.md

@@ -0,0 +1,118 @@
+# Generate System/Subsystem Design Description (SSDD)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81432
+
+## Objective
+
+Generate a compliant SSDD document by extracting and organizing system architectural design decisions from existing project artifacts into the MIL-STD-498 SSDD template structure. The SSDD describes the system-level design — how the system is organized into components (HWCIs, CSCIs, and manual operations) and how they interact.
+
+## Step 1 — Discover Project Artifacts
+
+Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
+
+| Priority | Artifact | Search Pattern |
+|----------|----------|----------------|
+| Required | PRD | `**/prd.md`, `**/prd-*.md` |
+| Required | Architecture | `**/architecture.md`, `**/architecture-*.md` |
+| Recommended | Product Brief | `**/product-brief*.md` |
+| Recommended | SSS | `**/SSS.md` |
+| Optional | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
+| Optional | Epics | `**/epics*.md`, `**/epic-*.md` |
+| Optional | Any client documentation | Ask {user_name} if there are additional documents to consider |
+
+If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
+
+## Step 2 — Load Template
+
+Read the SSDD template from:
+`{template}`
+
+This defines the required DID sections and content expectations for each paragraph.
+
+## Step 3 — Generate Document
+
+Write the document in {document_output_language}, populating each template section:
+
+### Section 1: Scope
+- **1.1 Identification**: Extract system name, version, and project-unique identifiers from PRD/Product Brief
+- **1.2 System overview**: Summarize system purpose, history, stakeholders, and operating sites from Product Brief and PRD
+- **1.3 Document overview**: Describe this SSDD document's purpose, contents, and any security/privacy considerations
+
+### Section 2: Referenced documents
+- List all project artifacts, standards, and external references used as inputs
+
+### Section 3: System-wide design decisions
+
+Document design decisions that apply across the entire system. For each decision, reference the requirement(s) it satisfies:
+
+- **a. Input/output design**: System inputs, outputs, and user/external interfaces. Describe what the system accepts and produces from the Architecture document
+- **b. Behavioral design**: System behavior in response to inputs and conditions — actions, response times, performance characteristics, algorithms, handling of invalid inputs. Extract from PRD and Architecture
+- **c. Database/data design**: How databases and data files appear to users. Data models and storage approaches from Architecture
+- **d. Safety, security, privacy**: Selected approaches to meeting these requirements from PRD
+- **e. Hardware design choices**: Physical characteristics if applicable (for hardware-software systems)
+- **f. Other system-wide decisions**: Flexibility, availability, maintainability approaches. Technology stack selections and their rationale from Architecture
+
+### Section 4: System architectural design
+
+- **4.1 System components**:
+  - Identify all system components (CSCIs, HWCIs, manual operations) from the Architecture document
+  - Assign project-unique identifiers to each component
+  - Show static relationships using component/block diagrams
+  - State each component's purpose and the system requirements allocated to it
+  - Identify each component's development status (new, reuse, reengineer)
+  - For computer systems: describe hardware resources (processors, memory, I/O, storage, networking) with specifications
+
+- **4.2 Concept of execution**:
+  - Describe dynamic relationships between components from Architecture
+  - Include: execution flow, data flow, state transitions, timing/sequencing, priorities, interrupt handling, concurrency, dynamic allocation
+  - Use sequence diagrams or flow diagrams where helpful
+
+- **4.3 Interface design**:
+  - **4.3.1 Interface identification and diagrams**: List all interfaces with unique identifiers, identify fixed vs. developing interfaces, provide interface diagrams
+  - **4.3.x (per interface)**: For each interface, document:
+    - Interfacing entities and their characteristics
+    - Data elements: names, types, sizes, formats, units, ranges, accuracy, constraints
+    - Data assemblies: records, messages, files, displays with structure and relationships
+    - Communication methods: links, message formats, flow control, data rates, routing
+    - Protocols: layers, packeting, error control, synchronization
+    - Physical compatibility considerations
+
+### Section 5: Requirements traceability
+- **5.a**: Map each system component to the system requirements it satisfies
+- **5.b**: Map each system requirement to the components that address it
+
+### Section 6: Notes
+- Glossary of terms, acronyms, and abbreviations
+- Background information to aid understanding
+
+## Step 4 — Validate
+
+Before presenting to the user, verify:
+- All template sections are populated or marked "Not applicable" with justification
+- Every component has a unique identifier
+- System-wide design decisions reference their driving requirements
+- Interface descriptions are complete and consistent from both sides
+- Requirements traceability covers all system requirements
+- Document is written in {document_output_language}
+
+## Step 5 — Review
+
+Present the complete document to {user_name} for review.
+Highlight any sections where information was inferred or assumptions were made.
+Specifically ask about:
+- Are all system components identified?
+- Are the interface descriptions accurate?
+- Are there additional design decisions not captured in the Architecture?
+
+Offer to refine any section based on feedback.
+
+## Step 6 — Save
+
+Write the final document to:
+`{output_folder}/planning-artifacts/SSDD.md`
+
+Confirm the file was saved and display a summary of:
+- Number of system components identified
+- Number of interfaces documented
+- Number of system-wide design decisions captured
+- Any sections marked "Not applicable"

package/lib/bmad-workflows/mil498/ssdd/workflow.yaml

@@ -0,0 +1,15 @@
+name: "bmad-mil-generate-ssdd"
+version: "1.0.0"
+description: "Generate a MIL-STD-498 System/Subsystem Design Description (SSDD). Use when the user says 'generate SSDD' or 'generate system design description'"
+
+config_source: "{project-root}/_bmad/bmm/config.yaml"
+user_name: "{config_source}:user_name"
+communication_language: "{config_source}:communication_language"
+document_output_language: "{config_source}:document_output_language"
+output_folder: "{config_source}:output_folder"
+date: system-generated
+
+installed_path: "{project-root}/_bmad/bmm/workflows/mil498/ssdd"
+instructions: "{installed_path}/instructions.md"
+
+template: "{project-root}/_bmad/bmm/templates/mil498/SSDD.md"