ma-agents 3.4.6 → 3.4.8

package/.opencode/skills/devops-sign-docker-image/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: devops-sign-docker-image
+description: Cryptographically sign Docker images using certificates and Cosign
+type: skill
+triggers:
+  - "sign docker image"
+  - "docker image signing"
+---
+
+# sign-docker-image.md
+# Docker Image Signing Workflow
+
+This workflow guides the DevOps agent through the process of cryptographically signing a Docker image.
+
+## Instructions
+1.  **Select Image**: Identify the image to sign.
+2.  **Get Digest**: Retrieve the immutable digest: `docker inspect --format='{{index .RepoDigests 0}}' {image_name}`.
+3.  **Prepare Certificate**: Locate the certificate file provided by the user.
+4.  **Execute Signing**:
+    - Use the `docker-image-signing` skill.
+    - Path: `skills/docker-image-signing/scripts/sign-image.sh`
+    - Run: `bash skills/docker-image-signing/scripts/sign-image.sh {image_digest} {cert_file} {key_file}`
+5.  **Verify**: Confirm the signature using `cosign verify`.
+6.  **Report**: provide the signed image reference to the user.

package/.opencode/skills/devops-sign-docker-image/bmad-skill-manifest.yaml

@@ -0,0 +1,3 @@
+type: skill
+name: devops-sign-docker-image
+module: ma-skills

package/.opencode/skills/generate-backlog/SKILL.md

@@ -0,0 +1,183 @@
+---
+name: generate-backlog
+description: Generate or refresh a flat backlog.yaml from epics and bug stories, preserving existing priority and sprint assignments
+type: skill
+triggers:
+  - "generate backlog"
+  - "refresh backlog"
+---
+
+# Generate Backlog Workflow
+
+Generate or refresh a flat `backlog.yaml` from epic stories and bug reports. Preserves existing priority and sprint assignments, appends new items, removes stale items, and re-numbers priorities 1..N.
+
+<workflow>
+
+<step n="1" goal="Load sources">
+  <action>Read `_bmad-output/planning-artifacts/epics.md` — this is the master list of epics with their stories.</action>
+  <check if="epics.md does not exist">
+    <output>**Error:** `_bmad-output/planning-artifacts/epics.md` not found. Cannot generate backlog without an epics file.</output>
+    <action>Exit workflow</action>
+  </check>
+
+  <action>Glob `_bmad-output/implementation-artifacts/bug-*.md` to discover all bug story files.</action>
+  <action>Store the list of bug files as {{bug_files}} (may be empty — zero bugs is valid).</action>
+
+  <action>Read `_bmad-output/implementation-artifacts/sprint-status.yaml` if it exists — this provides the current status of each story (done, in-progress, backlog, etc.).</action>
+  <action>Store the status map as {{status_map}} (keyed by story id). If the file does not exist, use an empty map.</action>
+
+  <action>Read `_bmad-output/implementation-artifacts/backlog.yaml` if it exists — this is the existing backlog to merge with.</action>
+  <action>Store the existing backlog items as {{existing_items}} (list). If the file does not exist, use an empty list.</action>
+
+  <output>
+**Sources loaded:**
+- epics.md: found
+- Bug files: {{bug_files | length}} file(s)
+- sprint-status.yaml: {{status_map exists ? "found" : "not found (empty status)"}}
+- Existing backlog.yaml: {{existing_items | length}} item(s)
+  </output>
+</step>
+
+<step n="2" goal="Extract stories from epics">
+  <action>Parse `epics.md` to extract every story from every epic. Each epic is a level-2 heading (`## Epic N: ...`) and each story within it is a level-3 heading (`### Story N.M: ...`) or a list item following the pattern `- **Story N.M:** Title` or `- N.M: Title`.</action>
+
+  <action>For each story found:
+    - Derive {{story_id}} as a kebab-case slug: `"{epic_number}-{story_number}-{title_slug}"` (e.g., `"5-5-explicit-parameter-passing"`)
+      - Title slug: lowercase, replace spaces/underscores with hyphens, remove non-alphanumeric/non-hyphen characters, collapse consecutive hyphens, trim leading/trailing hyphens
+    - Set {{epic}} to the epic number (integer)
+    - Set {{title}} to the story title text
+    - Look up status from {{status_map}} using the story identifier. If found and status is `done`, skip this story (exclude from backlog). If found, use that status. If not found, default to `backlog`.
+    - Set {{type}} = `story`
+    - Set {{severity}} = `null`
+    - Set {{sprint}} = `null`
+    - Set {{priority}} = `null` (will be assigned during merge/sort)
+  </action>
+
+  <action>Store the extracted stories as {{extracted_stories}} list.</action>
+  <output>Extracted {{extracted_stories | length}} active stories from epics (done items excluded).</output>
+</step>
+
+<step n="3" goal="Extract bugs">
+  <action>For each file in {{bug_files}}:
+    - Read the file and parse the YAML frontmatter (between `---` delimiters)
+    - Extract `title`, `severity`, and `status` from frontmatter
+    - Derive {{bug_id}} from the **filename**, not the title: strip the `bug-` prefix and `.md` extension, then uppercase to `"BUG-{slug}"` (e.g., `bug-login-crash.md` → `BUG-login-crash`)
+    - Use `status` from frontmatter directly (bugs track their own status). If `status` is missing, default to `backlog`. If status is `done`, skip this bug (exclude from backlog).
+    - Build a backlog item:
+      - id: {{bug_id}}
+      - type: `bug`
+      - epic: `null`
+      - title: {{title}}
+      - priority: `null` (assigned during merge/sort)
+      - status: {{frontmatter_status or "backlog"}}
+      - sprint: `null`
+      - severity: {{severity}}
+  </action>
+
+  <action>Store the extracted bugs as {{extracted_bugs}} list.</action>
+  <output>Extracted {{extracted_bugs | length}} active bugs (done items excluded).</output>
+</step>
+
+<step n="4" goal="Merge with existing backlog">
+  <action>Combine {{extracted_stories}} and {{extracted_bugs}} into {{new_items}} list.</action>
+
+  <action>Build a lookup map from {{existing_items}} keyed by `id`.</action>
+
+  <action>For each item in {{new_items}}:
+    - If an item with the same `id` exists in {{existing_items}}:
+      - **Preserve** the existing `priority` value
+      - **Preserve** the existing `sprint` assignment
+      - **Update** `status` from the freshly extracted value (which may reflect sprint-status.yaml changes)
+      - **Update** `title`, `type`, `epic`, `severity` from the freshly extracted values (source of truth)
+    - If no matching item exists in {{existing_items}}:
+      - This is a new item — keep all freshly extracted values
+      - Set `priority` to `null` (will be placed at the end during sort)
+  </action>
+
+  <action>Identify stale items: any item in {{existing_items}} whose `id` does NOT appear in {{new_items}}. These items no longer exist in the source files and should be removed.</action>
+
+  <action>Store the final merged list as {{merged_items}}.</action>
+  <action>Store the count of new items added as {{new_count}}.</action>
+  <action>Store the count of stale items removed as {{stale_count}}.</action>
+  <action>Store the count of preserved items as {{preserved_count}}.</action>
+
+  <output>
+**Merge results:**
+- Preserved (existing): {{preserved_count}}
+- New items added: {{new_count}}
+- Stale items removed: {{stale_count}}
+  </output>
+</step>
+
+<step n="5" goal="Write backlog.yaml">
+  <action>Sort {{merged_items}} for final output:
+    1. Items WITH an existing numeric `priority` come first, sorted ascending by priority
+    2. Items WITHOUT a priority (`null`) come after, sorted by:
+       a. `type`: bugs before stories (bugs get priority attention)
+       b. `severity` for bugs: critical > high > medium > low
+       c. `epic` number ascending for stories (lower epics first)
+       d. `id` alphabetically as final tiebreaker
+  </action>
+
+  <action>Re-number priorities sequentially 1..N across all items in the sorted list.</action>
+
+  <action>Get current ISO timestamp as {{generated_at}}.</action>
+
+  <action>Write `_bmad-output/implementation-artifacts/backlog.yaml` with this structure:
+
+```yaml
+# Flat Backlog — auto-generated by generate-backlog
+# Generated: {{generated_at}}
+# Total items: {{merged_items | length}}
+#
+# Schema per item:
+#   id, type, epic, title, priority, status, sprint, severity
+
+backlog:
+  - id: "5-5-explicit-parameter-passing"
+    type: story
+    epic: 5
+    title: "Explicit Parameter Passing"
+    priority: 1
+    status: backlog
+    sprint: null
+    severity: null
+  # ... remaining items ...
+```
+
+  **YAML output rules:**
+  - Always quote `id` and `title` fields (they contain hyphens and special characters)
+  - `epic` is an integer for stories, `null` for bugs
+  - `sprint` is a string like `"sprint-3"` if assigned, or `null`
+  - `severity` is a string (`critical`, `high`, `medium`, `low`) for bugs, `null` for stories
+  - `status` is one of: `backlog`, `ready-for-dev`, `in-progress`, `review` (done items excluded)
+  - `priority` is always a positive integer (1 = highest priority)
+  - Use 2-space indentation for YAML
+  </action>
+
+  <output>Backlog written to `_bmad-output/implementation-artifacts/backlog.yaml` with {{merged_items | length}} items.</output>
+</step>
+
+<step n="6" goal="Report summary">
+  <output>
+## Backlog Generation Complete
+
+| Metric              | Count |
+|----------------------|-------|
+| Total items          | {{merged_items | length}} |
+| Stories              | {{story_count}} |
+| Bugs                 | {{bug_count}} |
+| New items added      | {{new_count}} |
+| Stale items removed  | {{stale_count}} |
+| Items preserved      | {{preserved_count}} |
+
+**Output:** `_bmad-output/implementation-artifacts/backlog.yaml`
+
+**Next Steps:**
+- Review priorities — new items are appended at the end; reorder as needed
+- Use `/add-to-sprint` to assign high-priority items to the current sprint
+- Use `/sprint-status-view` to see sprint progress
+  </output>
+</step>
+
+</workflow>

package/.opencode/skills/generate-backlog/bmad-skill-manifest.yaml

@@ -0,0 +1,3 @@
+type: skill
+name: generate-backlog
+module: ma-skills

package/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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/.opencode/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"