ma-agents 2.17.1 → 2.19.0

package/README.md

@@ -61,7 +61,7 @@ skills/code-review/
 | Joseph (MIL-STD-498) | `_bmad/skills/` | `generic` | `_bmad/bmm/agents/mil498.md` |
 | Antigravity | `_bmad/skills/` | `generic` | `_bmad/bmm/agents/antigravity.md` |
 
-## Available Skills (25)
+## Available Skills (27)
 
 | Skill ID | Domain | Description |
 | :--- | :--- | :--- |
@@ -72,6 +72,8 @@ skills/code-review/
 | `test-accompanied-development` | Quality | Enforces "test-alongside" policy for every public method |
 | `code-documentation` | Quality | Enforces PEP 257, Doxygen, JSDoc, and XML standards |
 | `skill-creator` | Meta | Guide for creating new skills to extend agent capabilities |
+| `document-revision-history` | Documentation | Manages revision history tables at the beginning of generated documents |
+| `ai-audit-trail` | Audit | Tracks AI agent session activity, time spent, and token usage |
 | **Security** | | |
 | `python-security-skill` | Python | OWASP Top 10 2025 aligned guardrails for Python |
 | `js-ts-security-skill` | JS/TS | Security verification for JS/TS codebases (OWASP aligned) |

package/lib/agents.js

@@ -233,7 +233,7 @@ const agents = [
   {
     id: 'bmm-mil498',
     name: 'MIL-STD-498 Expert',
-    version: '1.0.0',
+    version: '2.0.0',
     category: 'bmad',
     description: 'MIL-STD-498 Documentation Expert',
     getProjectPath: () => path.join(process.cwd(), '_bmad', 'skills', 'mil498'),

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

@@ -20,6 +20,15 @@ Search the project for the following artifacts. Communicate in {communication_la
 
 If the **PRD** is missing, warn the user and ask whether to proceed with available data or stop.
 
+### Document Dependencies
+
+The OCD is the **first document** in the MIL-STD-498 generation chain. It has no MIL-STD-498 predecessor documents — it draws from project artifacts (PRD, Product Brief, UX Designs) only.
+
+**Note**: The OCD feeds into the SSS and other downstream documents. Ensure the operational scenarios and user descriptions are thorough, as they will be referenced by:
+- **SSS** — for deriving system requirements from operational needs
+- **SSDD** — for understanding operational context behind design decisions
+- **SDP** — for understanding the operational environment
+
 ## Step 2 — Load Template
 
 Read the OCD template from:
@@ -31,54 +40,97 @@ This defines the required DID sections and content expectations for each paragra
 
 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.
 
+### Revision History
+
+Before writing any content, add a **Revision History table** immediately after the document title. If this is a new document, create the table with version `1.0`. If updating an existing document, read the existing revision history and add a new row with an incremented version number and a summary of all changes made in this session. See the `document-revision-history` skill for full formatting rules.
+
+```markdown
+| Version | Date | Author | Changes |
+|---------|------|--------|---------|
+| 1.0 | {date} | Agent ({model}) | Initial document generation |
+```
+
 ### 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
+- List all project artifacts used as input sources, with number, title, revision, and date
 
 ### 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)
+- **3.1 Background, objectives, and scope**: Describe the problem domain, mission/objectives, and scope from the PRD
+- **3.2 Operational policies and constraints**: Current business rules, operational policies, and constraints
+- **3.3 Description of current system or situation**: How things work today. Describe differences associated with different states or modes of operation. Include all of the following (items a through h per the DID):
+  - **a.** The operational environment and its characteristics
+  - **b.** Major system components and the interconnections among them
+  - **c.** Interfaces to external systems or procedures
+  - **d.** Capabilities/functions of the current system
+  - **e.** Charts and descriptions depicting inputs, outputs, data flow, and manual/automated processes sufficient to understand the current system from the user's point of view
+  - **f.** Performance characteristics: speed, throughput, volume, frequency
+  - **g.** Quality attributes: reliability, maintainability, availability, flexibility, portability, usability, efficiency
+  - **h.** Provisions for safety, security, privacy, and continuity of operations in emergencies
+- **3.4 Users or involved personnel**: Identify all user types and stakeholders. Include organizational structures, training/skills, responsibilities, activities, and interactions
+- **3.5 Support concept**: Current support and maintenance approach — support agencies, facilities, equipment, support software, repair/replacement criteria, maintenance levels and cycles
 
 ### 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
+- **4.1 Justification for change**:
+  - **a.** New or modified aspects of user needs, threats, missions, objectives, environments, interfaces, personnel, or other factors requiring a new/modified system
+  - **b.** Deficiencies or limitations in the current system that make it unable to respond to these factors
+- **4.2 Description of needed changes**: New or modified capabilities, functions, processes, interfaces, or other changes needed
+- **4.3 Priorities among the changes**: Identify each change as essential, desirable, or optional. Prioritize the desirable and optional changes
+- **4.4 Changes considered but not included**: Identify changes that were considered but excluded, with rationale for not including them
+- **4.5 Assumptions and constraints**: Any assumptions and constraints applicable to the changes identified
+
+### Section 5: Concept for the new or modified system
+- **5.1 Background, objectives, and scope**: Vision, mission/objectives, and scope for the new system from Product Brief/PRD
+- **5.2 Operational policies and constraints**: New or changed operational policies and constraints
+- **5.3 Description of the new or modified system**: How the new system will work. Describe differences associated with different states or modes. Include all of the following (items a through h, mirroring Section 3.3):
+  - **a.** The operational environment and its characteristics
+  - **b.** Major system components and the interconnections among them
+  - **c.** Interfaces to external systems or procedures
+  - **d.** Capabilities/functions of the new or modified system
+  - **e.** Charts and descriptions depicting inputs, outputs, data flow, and manual/automated processes from the user's point of view
+  - **f.** Performance characteristics: speed, throughput, volume, frequency
+  - **g.** Quality attributes: reliability, maintainability, availability, flexibility, portability, usability, efficiency
+  - **h.** Provisions for safety, security, privacy, and continuity of operations in emergencies
+- **5.4 Users/affected personnel**: How user roles change with the new system — organizational structures, training/skills, responsibilities, and interactions
+- **5.5 Support concept**: Planned support approach — support agencies, facilities, equipment, support software, repair/replacement criteria, maintenance levels and cycles
 
 ### 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
+- Document one or more operational scenarios that illustrate the role of the new/modified system
+- Each scenario should include: the system's interaction with users, interfaces with other systems, and all states/modes identified
+- Include: events, actions, stimuli, information, interactions
+- Cover both normal operation and exception/error scenarios
+- Reference may be made to other media (e.g., videos, mockups) to provide part of this information
+
+### Section 7: Summary of impacts
+- **7.1 Operational impacts**: Anticipated operational impacts on user, acquirer, developer, and support agencies. Include: changes in interfaces with operating centers, procedure changes, use of new data sources, changes in data input quantity/type/timing, changes in data retention, new modes of operation
+- **7.2 Organizational impacts**: Anticipated organizational impacts. Include: modification of responsibilities, addition/elimination of positions, training/retraining needs, changes in number/skill levels/locations of personnel
+- **7.3 Impacts during development**: Anticipated impacts during the development effort. Include: meetings/discussions, database development/modification, training, parallel operation of new and existing systems, testing impacts, monitoring activities
+
+### Section 8: Analysis of the proposed system
+- **8.1 Summary of advantages**: Qualitative and quantitative summary of advantages — new capabilities, enhanced capabilities, improved performance, and their relationship to deficiencies identified in 4.1
+- **8.2 Summary of disadvantages/limitations**: Qualitative and quantitative summary of disadvantages — degraded/missing capabilities, less-than-desired performance, excessive resource use, undesirable operational impacts, conflicts with user assumptions
+- **8.3 Alternatives and trade-offs considered**: Major alternatives considered, trade-offs among them, and rationale for the decisions reached
+
+### Section 9: Notes
+- Alphabetical listing of all acronyms, abbreviations, and their meanings
+- Glossary of terms and definitions
+- Background information to aid understanding
+
+### Appendix A
+- Include any supplementary material (charts, detailed data, classified information) that supports the main body
+- Reference each appendix from the main body where the data would normally appear
 
 ## Step 4 — Validate
 
 Before presenting to the user, verify:
-- All template sections are populated or marked "Not applicable" with justification
+- All template sections (1-9 and Appendix A) are populated or marked "Not applicable" with justification
 - Document is written from the user/stakeholder perspective, not the developer perspective
+- Sections 3.3 and 5.3 cover all eight items (a through h)
+- Section 4 includes all five subsections (4.1-4.5)
+- Section 7 (impacts) and Section 8 (analysis) are present and substantive
 - Operational scenarios are complete and realistic
 - Document is written in {document_output_language}
 
@@ -86,6 +138,12 @@ Before presenting to the user, verify:
 
 Present the complete document to {user_name} for review.
 Highlight any sections where information was inferred or assumptions were made.
+Specifically ask about:
+- Are the current system descriptions (Section 3) accurate?
+- Are the operational scenarios (Section 6) complete?
+- Are there additional impacts (Section 7) not captured?
+- Does the analysis (Section 8) accurately represent advantages and disadvantages?
+
 Offer to refine any section based on feedback.
 
 ## Step 6 — Save
@@ -96,4 +154,6 @@ Write the final document to:
 Confirm the file was saved and display a summary of:
 - Number of user roles identified
 - Number of operational scenarios documented
+- Number of changes justified (Section 4)
+- Number of impacts identified (Section 7)
 - Any sections marked "Not applicable"

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

@@ -4,9 +4,9 @@
 
 ## 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).
+Generate a compliant SDD document by mapping the CSCI's software design to the MIL-STD-498 Software Design Description template structure. The SDD describes the design of a single CSCI (Computer Software Configuration Item) — its internal architecture, components (CSCs), interfaces, and detailed unit design.
 
-**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.
+**Critical principle**: The SDD is a **per-CSCI document**. It designs the internal structure of ONE CSCI as defined in the SSDD. The primary inputs are the SRS (what this CSCI must do), the Architecture document (how it's built), and the Epics/Stories (detailed behavioral specifications and acceptance criteria).
 
 ## Step 1 — Discover Project Artifacts
 
@@ -15,82 +15,171 @@ Search the project for the following artifacts. Communicate in {communication_la
 | 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` |
+| Required | Epics | `**/epics*.md`, `**/epic-*.md` |
+| Required | User Stories | `**/stories/*.md`, `**/story-*.md`, `**/user-stories*.md` |
+| Recommended | PRD | `**/prd.md`, `**/prd-*.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.
 
+### Document Dependencies
+
+The SDD is a **per-CSCI document** that designs the internal structure of a CSCI against its requirements. It MUST be generated after the SRS (which defines what the CSCI must do) and the SSDD (which defines the CSCI boundaries).
+
+| Predecessor | Relationship | Search Pattern |
+|-------------|-------------|----------------|
+| SRS (Software Requirements Specification) | **Required** — provides the CSCI requirements this SDD designs against | `**/SRS.md`, `**/SRS-*.md` |
+| SSDD (System/Subsystem Design Description) | **Required** — defines CSCI boundaries, system-wide design decisions, and allocated requirements | `**/SSDD.md` |
+| SSS (System/Subsystem Specification) | Optional — provides system-level requirements context | `**/SSS.md` |
+
+If the SRS has NOT been generated yet, **alert {user_name}**: "The SRS has not been generated yet. The SDD designs the internal structure of a CSCI against the requirements defined in its SRS. Would you like to proceed without the SRS, or generate the SRS first?"
+
+If the SSDD has NOT been generated yet, **alert {user_name}**: "The SSDD has not been generated yet. The SDD needs the SSDD to understand CSCI boundaries and system-wide design decisions. Would you like to proceed without the SSDD, or generate the SSDD first?"
+
+If predecessor documents exist, they MUST be loaded and used as primary inputs. The SDD should reference them in Section 2 and trace design decisions to SRS requirements.
+
+### CSCI Scoping
+
+Ask {user_name}: **"Which CSCI is this SDD for?"**
+
+If the SSDD exists, present the list of CSCIs defined in it and ask the user to select one. The SDD will describe the design of ONLY the selected CSCI — its internal CSCs (Computer Software Components) and software units.
+
+If generating SDD documents for multiple CSCIs, generate them one at a time, each as a separate document.
+
+### Source Mapping
+
+For the selected CSCI, the agent must:
+1. From the **SSDD**: Extract the CSCI's allocated system requirements, its CSCs, and the system-wide design decisions that constrain it
+2. From the **SRS**: Extract all CSCI requirements (capabilities, interfaces, quality factors, constraints) — these are what the SDD must design against
+3. From the **Architecture**: Extract the internal structure, technology stack, patterns, and integration approach for this CSCI's components
+4. From **Epics/Stories**: Extract detailed behavioral specifications, acceptance criteria, algorithms, business rules, and processing logic that inform the detailed design (Section 5)
+
 ## Step 2 — Load Template
 
-Read the design document template from:
+Read the SDD template from:
 `{template}`
 
-This defines the required DID sections. Adapt the system-level language to CSCI-level software design.
+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:
+Write the document in {document_output_language}, populating each template section.
+
+### Revision History
+
+Before writing any content, add a **Revision History table** immediately after the document title. If this is a new document, create the table with version `1.0`. If updating an existing document, read the existing revision history and add a new row with an incremented version number and a summary of all changes made in this session. See the `document-revision-history` skill for full formatting rules.
+
+```markdown
+| Version | Date | Author | Changes |
+|---------|------|--------|---------|
+| 1.0 | {date} | Agent ({model}) | Initial document generation |
+```
 
 ### 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.1 Identification**: Identify the CSCI by name, version, and project-unique identifier (as assigned in the SSDD)
+- **1.2 System overview**: Summarize the system and this CSCI's role within it, referencing the SSDD
 - **1.3 Document overview**: Describe this SDD document's purpose and contents
 
 ### Section 2: Referenced documents
-- List all project artifacts and external references used
+- List all predecessor MIL-STD-498 documents (SSDD, SRS, SSS) and project artifacts used. Include number, title, revision, and date
 
 ### 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
+**CRITICAL BEHAVIORAL GUIDANCE**: Like the SSDD, this section describes the CSCI's behavioral design — how it will behave from a user's point of view, ignoring internal implementation. Follow these rules:
 
-Each decision should reference the requirement(s) it satisfies.
+1. **Requirements-driven**: Every design decision MUST cite the specific SRS requirement(s) it satisfies
+2. **Behavioral, not implementation**: Describe patterns and approaches first, then technology choices parenthetically if essential
+3. **State-dependent decisions**: If a design decision depends on CSCI states or modes, indicate this dependency
+
+Document the following CSCI-wide design decisions (items a through e per the DID):
+
+- **a. CSCI behavioral design**: How the CSCI behaves in response to inputs and conditions — actions, response times, algorithms/rules, error handling. Describe from the user's perspective. Reference SRS capability requirements (3.2.x)
+- **b. Database/data file design**: How databases and data files within this CSCI appear to users and external systems. Reference SRS internal data requirements (3.5). If Database Design Descriptions (DBDDs) exist, they may be referenced
+- **c. Safety, security, privacy**: Selected approaches to meeting safety, security, and privacy requirements for this CSCI. Place in **separate subparagraphs** for critical requirements. Reference SRS sections 3.7, 3.8
+- **d. Other CSCI-wide design decisions**: Flexibility, availability, maintainability approaches. Rationale for architectural patterns selected. Reference SRS quality factors (3.11) and design constraints (3.12)
+- **e. Design and implementation standards**: Standards to be followed for design, coding, testing (reference SDP if available)
 
 ### 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
+- **4.1 CSCI components** (items a through f — all are required):
+
+  **a.** Identify all CSCs (Computer Software Components) within this CSCI — modules, packages, services, libraries. Each CSC shall have a project-unique identifier. Also identify software units within CSCs where applicable.
+
+  **b.** Show static ("consists of") relationships using component/class/package diagrams. Multiple relationship views may be presented.
+
+  **c.** State each CSC's purpose and the SRS requirements allocated to it. (Alternatively, allocation may be provided in Section 6.a.)
+
+  **d.** Identify each CSC's development status: new development, existing reuse as-is, existing design reuse, reengineering, etc. For existing components, provide identifying information.
+
+  **e.** Describe **resource utilization** — allocation of computer hardware resources (processor capacity, memory, I/O, storage) to each CSC. State conditions under which utilization will be measured. (This differs from SSDD 4.1.e which describes hardware; here it's about utilization allocation.)
+
+  **f.** Describe the CSCI's **program library** — contents including computer files, data files, program files, and their relationships.
+
+- **4.2 Concept of execution**:
+  - Describe dynamic relationships between CSCs — how they interact during operation
+  - Include: execution flow, data flow, state transitions, timing/sequencing, priorities, interrupt handling, concurrent execution, dynamic allocation/deallocation, exception handling
+  - Use sequence diagrams, state transition diagrams, or timing diagrams where helpful
+
+- **4.3 Interface design**:
+  - **4.3.1 Interface identification and diagrams**: List all interfaces (between CSCs and with external entities) with project-unique identifiers. Identify fixed vs. developing interfaces. Provide interface diagrams.
+  - **4.3.x (per interface)**: For each interface, document as applicable:
+    - **a.** Priority assigned to the interface
+    - **b.** Type of interface (real-time data transfer, storage-and-retrieval, etc.)
+    - **c.** Data elements: names/identifiers, data types, sizes/formats, units, ranges, accuracy/precision, timing/frequency constraints, security constraints, sources and recipients
+    - **d.** Data element assemblies: records, messages, data structures — names, structure, medium, relationships, constraints
+    - **e.** Communication methods: links/media, message formatting, flow control, data transfer rates, routing
+    - **f.** Protocols: priority/layer, packeting, error control/recovery, synchronization
+    - **g.** Physical compatibility considerations
 
 ### 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
+**This is the most important section of the SDD.** For each software unit identified in Section 4.1, provide a detailed design description. Organize as subsections (5.x per CSC, or 5.x per software unit):
+
+For each software unit (5.x), document the following items (a through f per the DID):
+
+- **a. Unit design decisions**: Design decisions specific to this unit, including algorithms, processing logic, data transformations, and business rules. **Extract from Epics and User Stories** — map Story acceptance criteria to specific processing logic. Reference the SRS requirements this unit satisfies.
+- **b. Design constraints**: Any constraints on the unit's design imposed by the CSCI-wide decisions, standards, or external interfaces
+- **c. Programming language**: If different from the CSCI-wide language specified in Section 3.e
+- **d. Control flow / logic description**: Describe the unit's control logic — how it processes inputs, makes decisions, handles conditions. Use flowcharts, pseudocode, or decision tables where helpful. Map from Story acceptance criteria and business rules.
+- **e. Data elements and structures**: Internal data elements, record layouts, data structures, file formats used by the unit
+- **f. Restrictions and limitations**: Any restrictions on the unit's use, dependencies, known limitations, or assumptions
 
 ### 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
+- **6.a**: Map each CSC/software unit to the SRS requirements it addresses
+- **6.b**: Map each SRS requirement to the CSCs/units that implement it
+- Ensure every SRS requirement allocated to this CSCI is accounted for in both directions
 
 ### Section 7: Notes
-- Glossary of design terms, acronyms, and abbreviations
+- Alphabetical listing of all acronyms, abbreviations, and their meanings
+- Glossary of design terms and definitions
+
+### Appendix A
+- Include any supplementary material (detailed algorithms, data dictionaries, message format specifications) that supports the main body
 
 ## 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
+- All template sections (1-7 and Appendix A) are populated or marked "Not applicable" with justification
+- This SDD covers exactly ONE CSCI as defined in the SSDD
+- Every CSC has a project-unique identifier
+- CSCI-wide design decisions (Section 3) are framed as behavioral responses to SRS requirements
+- Section 5 (detailed design) has entries for every software unit, with algorithms and logic extracted from Epics/Stories
+- Resource utilization (4.1.e) and program library (4.1.f) are documented
+- Interface descriptions (4.3.x) cover all seven aspects (a through g) where applicable
+- Requirements traceability (Section 6) covers all SRS requirements in both directions
 - 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.
+Highlight any sections where information was inferred or assumptions were made.
+Specifically ask about:
+- Is the CSC decomposition correct for this CSCI?
+- Are the algorithms and processing logic in Section 5 accurately extracted from the Stories?
+- Are there design decisions not captured in the Architecture or Epics?
+- Is the resource utilization allocation realistic?
+
 Offer to refine any section based on feedback.
 
 ## Step 6 — Save
@@ -98,7 +187,13 @@ Offer to refine any section based on feedback.
 Write the final document to:
 `{output_folder}/planning-artifacts/SDD.md`
 
+(If this is not the first CSCI's SDD, save as `SDD-{CSCI-identifier}.md`)
+
 Confirm the file was saved and display a summary of:
-- Number of components identified
+- CSCI identifier and name
+- Number of CSCs identified
+- Number of software units with detailed design
 - Number of interfaces documented
+- Number of SRS requirements traced
+- Requirements coverage percentage
 - Any sections marked "Not applicable"