ma-agents 3.6.2 → 3.8.0

package/lib/bmad-extension-plugin/skills/mil498-ocd/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: mil498-ocd
+description: Generate MIL-STD-498 Operational Concept Description (OCD)
+type: complex-workflow
+triggers:
+  - "generate OCD"
+  - "create operational concept description"
+---
+
+# MIL-498: Operational Concept Description (OCD)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81430
+
+## Workflow
+
+This workflow generates a MIL-STD-498 OCD document through progressive steps.
+The OCD describes the system from the user's and stakeholder's perspective, extracting operational concepts from existing project artifacts.
+
+### Steps
+
+1. [Discover Project Artifacts](prompts/01-discover-project-artifacts.md)
+2. [Load Template](prompts/02-load-template.md)
+3. [Generate Document](prompts/03-generate-document.md)
+4. [Validate](prompts/04-validate.md)
+5. [Review](prompts/05-review.md)
+6. [Save](prompts/06-save.md)
+
+### Template
+
+Output template: [template.md](template.md)

package/lib/bmad-extension-plugin/skills/mil498-ocd/bmad-skill-manifest.yaml

@@ -0,0 +1,5 @@
+type: skill
+name: mil498-ocd
+module: ma-skills
+description: Generate MIL-STD-498 Operational Concept Description (OCD)
+version: "1.0.0"

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/01-discover-project-artifacts.md

@@ -0,0 +1,26 @@
+# 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.
+
+## 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
+
+---
+
+**CONFIRMATION GATE**: Present the list of discovered artifacts to the user. Wait for the user to confirm before proceeding to the next step.

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/02-load-template.md

@@ -0,0 +1,10 @@
+# Step 2 — Load Template
+
+Read the OCD template from:
+[template.md](../template.md)
+
+This defines the required DID sections and content expectations for each paragraph.
+
+---
+
+**CONFIRMATION GATE**: Confirm to the user that the template has been loaded and summarize the major sections. Wait for the user to confirm before proceeding to document generation.

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/03-generate-document.md

@@ -0,0 +1,90 @@
+# 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.
+
+## 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, with number, title, revision, and date
+
+## Section 3: Current system or situation
+- **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 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 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
+
+---
+
+**CONFIRMATION GATE**: Present the generated document to the user for initial review. Wait for the user to confirm the content before proceeding to validation.

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/04-validate.md

@@ -0,0 +1,14 @@
+# Step 4 — Validate
+
+Before presenting to the user, verify:
+- 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}
+
+---
+
+**CONFIRMATION GATE**: Present the validation results to the user. List any issues found and corrections made. Wait for the user to confirm before proceeding to the review step.

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/05-review.md

@@ -0,0 +1,15 @@
+# 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 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.
+
+---
+
+**CONFIRMATION GATE**: Wait for the user to approve the document or request changes. If changes are requested, apply them and re-present for approval. Do not proceed to save until the user explicitly approves.

package/lib/bmad-extension-plugin/skills/mil498-ocd/prompts/06-save.md

@@ -0,0 +1,15 @@
+# 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
+- Number of changes justified (Section 4)
+- Number of impacts identified (Section 7)
+- Any sections marked "Not applicable"
+
+---
+
+**CONFIRMATION GATE**: Confirm to the user that the document has been saved successfully and present the summary. The workflow is now complete.

package/lib/bmad-extension-plugin/skills/mil498-ocd/template.md

@@ -0,0 +1,169 @@
+# 1. Scope.
+
+This section shall be divided into the following paragraphs.
+
+## 1.1 Identification.
+
+This paragraph shall contain a full identification of the system to which this document applies, including, as applicable, identification number(s), title(s), abbreviation(s), version number(s), and release number(s).
+
+## 1.2 System overview.
+
+This paragraph shall briefly state the purpose of the system to which this document applies. It shall describe the general nature of the system; summarize the history of system development, operation, and maintenance; identify the project sponsor, acquirer, user, developer, and support agencies; identify current and planned operating sites; and list other relevant documents.
+
+## 1.3 Document overview.
+
+This paragraph shall summarize the purpose and contents of this document and shall describe any security or privacy considerations associated with its use.
+
+# 2. Referenced documents.
+
+This section shall list the number, title, revision, and date of all documents referenced in this document. This section shall also identify the source for all documents not available through normal Government stocking activities.
+
+# 3. Current system or situation.
+
+This section shall be divided into the following paragraphs to describe the system or situation as it currently exists.
+
+## 3.1 Background, objectives, and scope.
+
+This paragraph shall describe the background, mission or objectives, and scope of the current system or situation.
+
+## 3.2 Operational policies and constraints.
+
+This paragraph shall describe any operational policies and constraints that apply to the current system or situation.
+
+## 3.3 Description of current system or situation.
+
+This paragraph shall provide a description of the current system or situation, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
+
+a. The operational environment and its characteristics
+
+b. Major system components and the interconnections among these components
+
+c. Interfaces to external systems or procedures
+
+d. Capabilities/functions of the current system
+
+e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the current system or situation from the user's point of view
+
+f. Performance characteristics, such as speed, throughput, volume, frequency
+
+g. Quality attributes, such as 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.
+
+This paragraph shall describe the types of users of the system, or personnel involved in the current situation, including, as applicable, organizational structures, training/skills, responsibilities, activities, and interactions with one another.
+
+## 3.5 Support concept.
+
+This paragraph shall provide an overview of the support concept for the current system, including, as applicable to this document, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
+
+# 4. Justification for and nature of changes.
+
+This section shall be divided into the following paragraphs.
+
+## 4.1 Justification for change.
+
+This paragraph shall:
+
+a. Describe new or modified aspects of user needs, threats, missions, objectives, environments, interfaces, personnel or other factors that require a new or modified system
+
+b. Summarize deficiencies or limitations in the current system or situation that make it unable to respond to these factors
+
+## 4.2 Description of needed changes.
+
+This paragraph shall summarize new or modified capabilities/functions, processes, interfaces, or other changes needed to respond to the factors identified in 4.1.
+
+## 4.3 Priorities among the changes.
+
+This paragraph shall identify priorities among the needed changes. It shall, for example, identify each change as essential, desirable, or optional, and prioritize the desirable and optional changes.
+
+## 4.4 Changes considered but not included.
+
+This paragraph shall identify changes considered but not included in 4.2, and rationale for not including them.
+
+## 4.5 Assumptions and constraints.
+
+This paragraph shall identify any assumptions and constraints applicable to the changes identified in this section.
+
+# 5. Concept for a new or modified system.
+
+This section shall be divided into the following paragraphs to describe a new or modified system.
+
+## 5.1 Background, objectives, and scope.
+
+This paragraph shall describe the background, mission or objectives, and scope of the new or modified system.
+
+## 5.2 Operational policies and constraints.
+
+This paragraph shall describe any operational policies and constraints that apply to the new or modified system.
+
+## 5.3 Description of the new or modified system.
+
+This paragraph shall provide a description of the new or modified system, identifying differences associated with different states or modes of operation (for example, regular, maintenance, training, degraded, emergency, alternative-site, wartime, peacetime). The distinction between states and modes is arbitrary. A system may be described in terms of states only, modes only, states within modes, modes within states, or any other scheme that is useful. If the system operates without states or modes, this paragraph shall so state, without the need to create artificial distinctions. The description shall include, as applicable:
+
+a. The operational environment and its characteristics
+
+b. Major system components and the interconnections among these components
+
+c. Interfaces to external systems or procedures
+
+d. Capabilities/functions of the new or modified system
+
+e. Charts and accompanying descriptions depicting inputs, outputs, data flow, and manual and automated processes sufficient to understand the new or modified system or situation from the user's point of view
+
+f. Performance characteristics, such as speed, throughput, volume, frequency
+
+g. Quality attributes, such as reliability, maintainability, availability, flexibility, portability, usability, efficiency
+
+h. Provisions for safety, security, privacy, and continuity of operations in emergencies
+
+## 5.4 Users/affected personnel.
+
+This paragraph shall describe the types of users of the new or modified system, including, as applicable, organizational structures, training/skills, responsibilities, and interactions with one another.
+
+## 5.5 Support concept.
+
+This paragraph shall provide an overview of the support concept for the new or modified system, including, as applicable, support agency(ies); facilities; equipment; support software; repair/replacement criteria; maintenance levels and cycles; and storage, distribution, and supply methods.
+
+# 6. Operational scenarios.
+
+This section shall describe one or more operational scenarios that illustrate the role of the new or modified system, its interaction with users, its interface to other systems, and all states or modes identified for the system. The scenarios shall include events, actions, stimuli, information, interactions, etc., as applicable. Reference may be made to other media, such as videos, to provide part or all of this information.
+
+# 7. Summary of impacts.
+
+This section shall be divided into the following paragraphs.
+
+## 7.1 Operational impacts.
+
+This paragraph shall describe anticipated operational impacts on the user, acquirer, developer, and support agency(ies). These impacts may include changes in interfaces with computer operating centers; change in procedures; use of new data sources; changes in quantity, type, and timing of data to be input to the system; changes in data retention requirements; and new modes of operation based on peacetime, alert, wartime, or emergency conditions.
+
+## 7.2 Organizational impacts.
+
+This paragraph shall describe anticipated organizational impacts on the user, acquirer, developer, and support agency(ies). These impacts may include modification of responsibilities; addition or elimination of responsibilities or positions; need for training or retraining; and changes in number, skill levels, position identifiers, or location of personnel in various modes of operation.
+
+## 7.3 Impacts during development.
+
+This paragraph shall describe anticipated impacts on the user, acquirer, developer, and support agency(ies) during the development effort. These impacts may include meetings/discussions regarding the new system; development or modification of databases; training; parallel operation of the new and existing systems; impacts during testing of the new system; and other activities needed to aid or monitor development.
+
+# 8. Analysis of the proposed system.
+
+## 8.1 Summary of advantages.
+
+This paragraph shall provide a qualitative and quantitative summary of the advantages to be obtained from the new or modified system. This summary shall include new capabilities, enhanced capabilities, and improved performance, as applicable, and their relationship to deficiencies identified in 4.1.
+
+## 8.2 Summary of disadvantages/limitations.
+
+This paragraph shall provide a qualitative and quantitative summary of disadvantages or limitations of the new or modified system. These disadvantages and limitations shall include, as applicable, degraded or missing capabilities, degraded or less-than-desired performance, greater-than-desired use of computer hardware resources, undesirable operational impacts, conflicts with user assumptions, and other constraints.
+
+## 8.3 Alternatives and trade-offs considered.
+
+This paragraph shall identify and describe major alternatives considered to the system or its characteristics, the trade-offs among them, and rationale for the decisions reached.
+
+# 9. Notes.
+
+This section shall contain any general information that aids in understanding this document (e.g., background information, glossary, rationale). This section shall include an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this document and a list of any terms and definitions needed to understand this document.
+
+# A. Appendixes.
+
+Appendixes may be used to provide information published separately for convenience in document maintenance (e.g., charts, classified data). As applicable, each appendix shall be referenced in the main body of the document where the data would normally have been provided. Appendixes may be bound as separate documents for ease in handling. Appendixes shall be lettered alphabetically (A, B, etc.).

package/lib/bmad-extension-plugin/skills/mil498-requirement-quality/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: mil498-requirement-quality
+description: Evaluate and verify requirements quality against 14 established criteria (Clarity, Single Verb, Sentence Structure, Glossary Presence, Necessity, Implementation-Independence, Unambiguity, Completeness, Feasibility, Testability, Stakeholder Alignment, Convention Conformance, Understandability, Precision). Use when writing, reviewing, or validating requirements in any document — MIL-STD-498 SRS/SSDD/SSS, PRD functional/non-functional requirements, or any requirements section.
+type: analysis
+triggers:
+  - "review requirements"
+  - "validate requirements"
+  - "check requirement quality"
+  - "requirements quality assurance"
+  - "verify requirements"
+  - "audit requirements"
+---
+
+# Requirements Quality Assurance
+
+You are an AI assistant specialized in requirements quality assurance.
+
+## Purpose
+
+Evaluate every requirement in the provided document or section against 14 quality criteria. Produce a structured audit table per requirement, then list missing artifacts.
+
+## When to Apply
+
+Apply this skill whenever:
+- Writing or reviewing requirements in any MIL-STD-498 document (SRS, SSDD, SSS, OCD)
+- Writing or reviewing FR/NFR sections in a PRD
+- Verifying Epics, User Stories, or Acceptance Criteria
+- Any agent generates or describes a requirement
+
+## Evaluation Criteria
+
+| # | Criterion | Definition |
+|---|-----------|------------|
+| 1 | **Clarity & Directness** | No source-form verbs (e.g., "to save", "to keep"). States the required behavior, not a capability. |
+| 2 | **Single Primary Verb** | Each requirement contains exactly one main action verb; any conditions are separated by commas or placed on a new line. |
+| 3 | **Sentence Structure** | Follows the pattern: `Condition + Subject + Predicate + Object [+ Constraint]`. |
+| 4 | **Glossary Presence** | All domain-specific terms used in the requirement are defined in a dedicated glossary. |
+| 5 | **Necessity** | The requirement appears only once in the document and does not duplicate another. If conceptually identical to another, identify which requirement it duplicates. |
+| 6 | **Implementation-Independent** | Describes the need, not a specific solution or technology. |
+| 7 | **Unambiguous** | Has only one possible interpretation for all relevant stakeholders. |
+| 8 | **Completeness** | Self-contained; does not rely on other requirements for its meaning. |
+| 9 | **Feasibility** | Realistic and achievable within reasonable cost, schedule, and technology limits. |
+| 10 | **Testability** | Can be verified by a concrete test or inspection. |
+| 11 | **Stakeholder Alignment** | Accurately reflects the expressed needs of the identified stakeholders. |
+| 12 | **Conformance to Conventions** | Uses the project's standard format (e.g., Epic → User Stories → Acceptance Criteria) and consistent look-and-feel. |
+| 13 | **Understandability** | Written in plain language that the supplier can readily comprehend. |
+| 14 | **Precision** | Uses definite nouns, explicit units, and avoids vague qualifiers (e.g., "approximately", "usually", "high"). |
+
+## Output Format
+
+For each requirement, produce a table with these columns:
+
+| Requirement Title | Requirement Summary | Requirement Type | Criterion | Pass/Fail | Comments / Suggested Revision |
+|---|---|---|---|---|---|
+| [title] | [one-line summary] | [type] | 1 | ✅ / ❌ | [comment or revision if failed] |
+| | | | 2 | ✅ / ❌ | |
+| | | | ... | | |
+| | | | 14 | ✅ / ❌ | |
+
+**Requirement Type codes:**
+- `FR` — Functional Requirement
+- `NFR` — Non-Functional Requirement
+- `UC` — Use Case
+- `US` — User Story
+- `AC` — Acceptance Criteria
+- `SYS` — System Requirement
+- `PERF` — Performance
+- `SEC` — Security
+- `INT` — Interface
+
+## Post-Table: Missing Elements
+
+After all requirement tables, include a **Missing Elements** section:
+
+```
+### Missing Elements
+
+- Glossary: [list domain-specific terms lacking a definition]
+- Acceptance Criteria: [list User Stories with no AC]
+- Story Points: [list stories with no estimate]
+- Traceability: [list requirements not traced to a parent requirement or stakeholder need]
+- Other: [any absent Agile or MIL-498 artifacts]
+```
+
+If nothing is missing, state: *No missing elements identified.*
+
+## Overall Quality Score
+
+Conclude with:
+
+```
+### Overall Quality Score
+
+X / Y criteria passed across Z requirements (P%)
+```
+
+## Instructions
+
+1. Identify and number all requirements in the provided section
+2. For each requirement, assess all 14 criteria
+3. Mark ✅ Pass or ❌ Fail for each criterion
+4. For every ❌, provide a specific, actionable suggested revision in the Comments column
+5. For Criterion 5 (Necessity), if a duplicate is found, name the duplicating requirement by title
+6. After all tables, complete the Missing Elements section
+7. Compute and display the Overall Quality Score

package/lib/bmad-extension-plugin/skills/mil498-requirement-quality/bmad-skill-manifest.yaml

@@ -0,0 +1,5 @@
+type: skill
+name: mil498-requirement-quality
+module: ma-skills
+description: Evaluate and verify requirements quality against 14 established criteria (Clarity, Single Verb, Structure, Glossary, Necessity, Implementation-Independence, Unambiguity, Completeness, Feasibility, Testability, Stakeholder Alignment, Convention Conformance, Understandability, Precision)
+version: "1.0.0"

package/lib/bmad-extension-plugin/skills/mil498-sdd/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: mil498-sdd
+description: Generate MIL-STD-498 Software Design Description (SDD)
+type: complex-workflow
+triggers:
+  - "generate SDD"
+  - "create software design description"
+---
+
+# MIL-498: Software Design Description (SDD)
+
+> MIL-STD-498 Data Item Description: DI-IPSC-81435
+
+## Workflow
+
+This workflow generates a MIL-STD-498 SDD document through progressive steps.
+The SDD describes the design of a single CSCI — its internal architecture, components (CSCs), interfaces, and detailed unit design.
+
+### Steps
+
+1. [Discover Project Artifacts](prompts/01-discover-project-artifacts.md)
+2. [Load Template](prompts/02-load-template.md)
+3. [Generate Document](prompts/03-generate-document.md)
+4. [Validate](prompts/04-validate.md)
+5. [Review](prompts/05-review.md)
+6. [Save](prompts/06-save.md)
+
+### Template
+
+Output template: [template.md](template.md)

package/lib/bmad-extension-plugin/skills/mil498-sdd/bmad-skill-manifest.yaml

@@ -0,0 +1,5 @@
+type: skill
+name: mil498-sdd
+module: ma-skills
+description: Generate MIL-STD-498 Software Design Description (SDD)
+version: "1.0.0"

package/lib/bmad-extension-plugin/skills/mil498-sdd/prompts/01-discover-project-artifacts.md

@@ -0,0 +1,50 @@
+# 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 | 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)
+
+---
+
+**CONFIRMATION GATE**: Present the list of discovered artifacts and the selected CSCI to the user. Wait for the user to confirm before proceeding to the next step.

package/lib/bmad-extension-plugin/skills/mil498-sdd/prompts/02-load-template.md

@@ -0,0 +1,10 @@
+# Step 2 — Load Template
+
+Read the SDD template from:
+[template.md](../template.md)
+
+This defines the required DID sections and content expectations for each paragraph.
+
+---
+
+**CONFIRMATION GATE**: Confirm to the user that the template has been loaded and summarize the major sections. Wait for the user to confirm before proceeding to document generation.