ma-agents 3.4.9 → 3.5.1

package/.opencode/skills/mil498-srs/prompts/03-generate-document.md

@@ -1,100 +0,0 @@
-# Step 3 — Generate Document
-
-Write the document in {document_output_language}, populating each template section. Each requirement shall be assigned a project-unique identifier, be stated so that an objective test can be defined for it, and be annotated with qualification method(s) and traceability to system requirements.
-
-## 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 software name, version, CSCI identifiers from the SSDD, PRD, and Architecture
-- **1.2 System overview**: Summarize purpose, nature, development history from PRD. Identify this CSCI's role within the system
-- **1.3 Document overview**: Describe this SRS document's purpose, contents, and any security/privacy considerations
-
-## Section 2: Referenced documents
-- List all predecessor MIL-STD-498 documents (SSDD, SSS) and project artifacts used, with number, title, revision, and date
-
-## Section 3: Requirements
-
-- **3.1 Required states and modes**: Identify operational modes from Architecture (e.g., normal, degraded, maintenance, training). If none, state "The CSCI does not have distinct operational states or modes." If states/modes exist, correlate each requirement or group of requirements to the applicable states/modes.
-
-- **3.2 CSCI capability requirements**: Map Epics/features from the PRD to numbered capability requirements (3.2.1, 3.2.2, etc.). **Only include capabilities allocated to this CSCI per the SSDD.** Each requirement must have:
-  - A unique project identifier (e.g., SRS-CAP-001)
-  - Clear, testable acceptance criteria
-  - Parameters: response times, throughput, accuracy, capacity, priorities, continuous operation requirements as applicable
-  - Error handling: behavior under unexpected, unallowed, or out-of-bounds conditions
-  - Provisions for continuity of operations in emergencies
-
-- **3.3 CSCI external interface requirements**:
-  - **3.3.1 Interface identification and diagrams**: Identify all required external interfaces with project-unique identifiers. Designate interfacing entities by name, number, version. State which have fixed vs. developing characteristics. Provide interface diagrams.
-  - **3.3.x (per interface)**: For each external interface, specify requirements imposed on the CSCI. State other entities' characteristics as assumptions ("When [entity] does this, the CSCI shall..."). Cover:
-    - **a.** Priority the CSCI must assign the interface
-    - **b.** Type of interface (real-time data transfer, storage-and-retrieval, etc.)
-    - **c.** Data elements: names/identifiers (project-unique, natural-language, technical), data types, sizes/formats, units, ranges, accuracy/precision, timing/frequency/volume constraints, security/privacy constraints, sources and recipients
-    - **d.** Data element assemblies: records, messages, files, displays — names, structure, medium, visual/auditory characteristics, relationships, constraints, sources and recipients
-    - **e.** Communication methods: links/media, message formatting, flow control, data transfer rates, routing/addressing, transmission services, security considerations
-    - **f.** Protocols: priority/layer, packeting/fragmentation, error control/recovery, synchronization, status/reporting
-    - **g.** Physical compatibility (dimensions, tolerances, loads, plug compatibility, voltages)
-
-- **3.4 CSCI internal interface requirements**: Document internal component interfaces. If all internal interfaces are left to design, state so. If requirements exist, follow the same topics as 3.3.x.
-
-- **3.5 CSCI internal data requirements**: Identify persistent data stores, databases, and data models. If all decisions are left to design, state so. If requirements exist, follow data element topics from 3.3.x.c and 3.3.x.d.
-
-- **3.6 Adaptation requirements**: Site-specific or installation-dependent data and operational parameters that may vary
-
-- **3.7 Safety requirements**: Requirements for preventing/minimizing unintended hazards — safeguards against inadvertent actions and non-actions
-
-- **3.8 Security and privacy requirements**: Security/privacy environment, type/degree of protection, risks to withstand, required safeguards, policy requirements, accountability, certification criteria
-
-- **3.9 CSCI environment requirements**: Runtime environment constraints (hardware, operating system)
-
-- **3.10 Computer resource requirements**:
-  - **3.10.1 Computer hardware requirements**: Required hardware — processors, memory, I/O devices, auxiliary storage, communications/network equipment (number, type, size, capacity, characteristics)
-  - **3.10.2 Computer hardware resource utilization requirements**: Maximum allowable utilization (e.g., % of processor, memory, I/O, storage, network capacity) with conditions for measurement
-  - **3.10.3 Computer software requirements**: Required software (OS, DBMS, network software, utilities, simulators) with nomenclature, version, and documentation references
-  - **3.10.4 Computer communications requirements**: Geographic locations, network topology, transmission techniques, data transfer rates, gateways, system use times, data volume, time boundaries, peak volumes, diagnostics
-
-- **3.11 Software quality factors**: Quantitative requirements for: functionality, reliability, maintainability, availability, flexibility, portability, reusability, testability, usability
-
-- **3.12 Design and implementation constraints**: Constraints on architecture, databases, standard components, Government-furnished property; required design/implementation standards, programming languages; flexibility/expandability for anticipated growth
-
-- **3.13 Personnel-related requirements**: Number of users, skill levels, duty cycles, training needs, human factors engineering (capabilities/limitations of humans, foreseeable errors, critical indicator placement, auditory signals)
-
-- **3.14 Training-related requirements**: Training software or features to be included
-
-- **3.15 Logistics-related requirements**: System maintenance, software support, transportation, supply-system requirements, facility/equipment impacts
-
-- **3.16 Other requirements**: Any additional requirements not covered above
-
-- **3.17 Packaging requirements**: Requirements for packaging, labeling, and handling for delivery
-
-- **3.18 Precedence and criticality of requirements**: Order of precedence, criticality, or assigned weights. Identify requirements critical to safety, security, or privacy for special treatment
-
-## Section 4: Qualification provisions
-For each requirement in Section 3, specify the qualification method(s). A table may be used, or requirements may be annotated inline:
-- **a.** Demonstration: Observable functional operation without instrumentation
-- **b.** Test: Operation using instrumentation or special test equipment
-- **c.** Analysis: Processing of accumulated data from other methods
-- **d.** Inspection: Visual examination of code, documentation
-- **e.** Special qualification methods: Special tools, techniques, procedures, facilities, or acceptance limits
-
-## Section 5: Requirements traceability
-- **5.a**: Map each CSCI requirement to the system (or subsystem) requirements it addresses. Note: some CSCI requirements may trace to "system implementation" or system design decisions rather than specific higher-level requirements.
-- **5.b**: Map each system requirement allocated to this CSCI to the CSCI requirements that address it. All allocated system requirements shall be accounted for.
-
-## Section 6: Notes
-- Alphabetical listing of all acronyms, abbreviations, and their meanings
-- Glossary of terms and definitions
-
-## Appendix A
-- Include any supplementary material (requirement matrices, data dictionaries) that supports the main body
-
----
-
-**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-srs/prompts/04-validate.md

@@ -1,16 +0,0 @@
-# Step 4 — Validate
-
-Before presenting to the user, verify:
-- All template sections (1-6 and Appendix A) are populated or marked "Not applicable" with justification
-- Every requirement has a unique identifier (SRS-xxx-nnn format)
-- Every requirement is testable and traceable to a system requirement
-- External interfaces (3.3.x) cover all seven categories (a through g) where applicable
-- Computer resource requirements (3.10) has all four subsections (3.10.1-3.10.4)
-- Qualification methods are specified for all requirements including special methods (4.e)
-- Cross-references between sections are consistent
-- Requirements are scoped to this CSCI only (not system-wide)
-- 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-srs/prompts/05-review.md

@@ -1,15 +0,0 @@
-# Step 5 — Review
-
-Present the complete document to {user_name} for review.
-Highlight any sections where information was inferred or assumptions were made.
-Specifically ask about:
-- Are all capability requirements for this CSCI captured?
-- Are the interface requirements (3.3) accurate and complete?
-- Are there additional constraints or quality requirements?
-- Is the precedence/criticality ranking (3.18) correct?
-
-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-srs/prompts/06-save.md

@@ -1,18 +0,0 @@
-# Step 6 — Save
-
-Write the final document to:
-`{output_folder}/planning-artifacts/SRS.md`
-
-(If this is not the first CSCI's SRS, save as `SRS-{CSCI-identifier}.md`)
-
-Confirm the file was saved and display a summary of:
-- CSCI identifier and name
-- Total number of requirements identified
-- Number of capabilities documented
-- Number of interfaces specified
-- Qualification methods assigned
-- 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-ssdd/SKILL.md

@@ -1,32 +0,0 @@
----
-name: mil498-ssdd
-description: Generate MIL-STD-498 System/Subsystem Design Description (SSDD)
-type: complex-workflow
-triggers:
-  - "generate SSDD"
-  - "create system design description"
-  - "create subsystem design description"
----
-
-# MIL-498: System/Subsystem Design Description (SSDD)
-
-> MIL-STD-498 Data Item Description: DI-IPSC-81432
-
-## Workflow
-
-This workflow generates a MIL-STD-498 SSDD document through progressive steps.
-The SSDD describes the system-level design — how the system is organized into components (HWCIs, CSCIs, and manual operations) and how they interact.
-
-### Steps
-
-1. [Discover Project Artifacts](prompts/01-discover-project-artifacts.md)
-2. [Load Template](prompts/02-load-template.md)
-3. [CSCI Discovery Interview](prompts/03-csci-discovery-interview.md)
-4. [Generate Document](prompts/04-generate-document.md)
-5. [Validate](prompts/05-validate.md)
-6. [Review](prompts/06-review.md)
-7. [Save](prompts/07-save.md)
-
-### Template
-
-Output template: [template.md](template.md)

package/.opencode/skills/mil498-ssdd/bmad-skill-manifest.yaml

@@ -1,5 +0,0 @@
-type: skill
-name: mil498-ssdd
-module: ma-skills
-description: Generate MIL-STD-498 System/Subsystem Design Description (SSDD)
-version: "1.0.0"

package/.opencode/skills/mil498-ssdd/prompts/01-discover-project-artifacts.md

@@ -1,32 +0,0 @@
-# Step 1 — Discover Project Artifacts
-
-Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
-
-| Priority | Artifact | Search Pattern |
-|----------|----------|----------------|
-| Required | PRD | `**/prd.md`, `**/prd-*.md` |
-| Required | Architecture | `**/architecture.md`, `**/architecture-*.md` |
-| Recommended | Product Brief | `**/product-brief*.md` |
-| Recommended | SSS | `**/SSS.md` |
-| Optional | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
-| Optional | Epics | `**/epics*.md`, `**/epic-*.md` |
-| Optional | Any client documentation | Ask {user_name} if there are additional documents to consider |
-
-If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
-
-## Document Dependencies
-
-The SSDD is best generated after the following MIL-STD-498 predecessor documents:
-
-| Predecessor | Relationship | Search Pattern |
-|-------------|-------------|----------------|
-| SSS (System/Subsystem Specification) | Recommended — provides the system requirements the SSDD designs against | `**/SSS.md` |
-| OCD (Operational Concept Description) | Optional — provides operational context | `**/OCD.md` |
-
-If predecessor documents exist, they MUST be loaded and used as primary inputs. The SSDD should reference them in Section 2 and trace design decisions to their requirements.
-
-If recommended predecessors have NOT been generated yet, **alert {user_name}**: "The SSS has not been generated yet. The SSDD is typically produced after the SSS, since it designs against system requirements defined there. Would you like to proceed without it, or generate the SSS first?"
-
----
-
-**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-ssdd/prompts/02-load-template.md

@@ -1,10 +0,0 @@
-# Step 2 — Load Template
-
-Read the SSDD 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 the CSCI discovery interview.

package/.opencode/skills/mil498-ssdd/prompts/03-csci-discovery-interview.md

@@ -1,43 +0,0 @@
-# Step 2.5 — CSCI Discovery Interview
-
-Before generating the document, you must establish the correct CSCI decomposition through an interactive interview with {user_name}. **Do NOT map repositories, microservices, or deployment units 1:1 to CSCIs.** A CSCI is a configuration item — a logically cohesive unit that is independently specified, designed, tested, and managed.
-
-## Phase A: Initial Analysis
-
-Analyze the Architecture document and identify:
-- All services, modules, repositories, and deployment units mentioned
-- Functional domains they belong to (e.g., detection, alerting, user management, frontend)
-- Shared release cycles, shared teams, shared test suites
-- Data coupling between components (which services share databases or communicate frequently?)
-
-## Phase B: Propose CSCI Hypothesis
-
-Present {user_name} with a proposed CSCI decomposition that groups related services/modules into logically cohesive CSCIs. For each proposed CSCI:
-- Give it a descriptive name and project-unique identifier
-- List the services/modules/components it contains (these become CSCs — Computer Software Components — within the CSCI)
-- State the functional rationale for the grouping
-- Identify the system requirements allocated to it
-
-## Phase C: Guided Questions
-
-Ask {user_name} the following questions to validate and refine the decomposition:
-
-1. **Release boundaries**: "Which of these services/modules share a release cycle and are always deployed together?"
-2. **Team boundaries**: "Which components are developed and maintained by the same team?"
-3. **Test boundaries**: "Which components are always tested together as a unit?"
-4. **Delivery boundaries**: "What are your contractual or organizational delivery boundaries — what does the customer/stakeholder receive as distinct deliverables?"
-5. **Configuration management**: "Which components are independently baselined and version-controlled as a unit?"
-
-## Phase D: Refine and Confirm
-
-Based on {user_name}'s answers:
-- Merge or split CSCIs as needed
-- Ensure each CSCI has clear functional cohesion
-- Assign final project-unique identifiers (e.g., CSCI-SA for Situational Awareness, CSCI-FE for Frontend)
-- Get explicit approval from {user_name} before proceeding to document generation
-
-**Do NOT proceed to Step 3 until {user_name} approves the CSCI decomposition.**
-
----
-
-**CONFIRMATION GATE**: The user MUST explicitly approve the final CSCI decomposition before proceeding. Do not continue to document generation until approval is received.

package/.opencode/skills/mil498-ssdd/prompts/04-generate-document.md

@@ -1,96 +0,0 @@
-# Step 3 — Generate Document
-
-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**: Extract system name, version, and project-unique identifiers from PRD/Product Brief
-- **1.2 System overview**: Summarize system purpose, history, stakeholders, and operating sites from Product Brief and PRD
-- **1.3 Document overview**: Describe this SSDD document's purpose, contents, and any security/privacy considerations
-
-## Section 2: Referenced documents
-- List all project artifacts, standards, and external references used as inputs. Include number, title, revision, and date for each
-
-## Section 3: System-wide design decisions
-
-**CRITICAL BEHAVIORAL GUIDANCE**: This section describes the system's behavioral design — how it will behave from a user's point of view in meeting its requirements, ignoring internal implementation. Follow these rules strictly:
-
-1. **Requirements-driven**: Every design decision MUST cite the specific requirement(s) it satisfies (e.g., "To satisfy NFR-P2 (< 1s detection latency)...")
-2. **Behavioral, not implementation**: Describe patterns and approaches, NOT specific tools or products. Write "An asynchronous message distribution pattern is selected..." NOT "RabbitMQ serves as the message broker..."
-3. **Technology names belong in the Architecture document**, not here. If a technology choice is essential context, mention it parenthetically after the behavioral description
-4. **State-dependent decisions**: If a design decision depends on system states or modes, indicate this dependency explicitly
-
-For each of the following subsections, document the design decisions and reference their driving requirements:
-
-- **a. Input/output design**: What the system accepts and produces. Describe system inputs, outputs, and user/external interfaces from the user's perspective. If Interface Design Descriptions (IDDs) exist, they may be referenced
-- **b. Behavioral design**: How the system behaves in response to inputs and conditions — actions, response times, performance characteristics, selected algorithms/rules, and handling of invalid inputs or error conditions. Describe behavioral patterns (event-driven processing, request-response cycles, etc.) without naming specific tools
-- **c. Database/data design**: How databases and data files appear to users and external systems. Describe data models, storage approaches, and data lifecycle from the user's perspective. If Database Design Descriptions (DBDDs) exist, they may be referenced
-- **d. Safety, security, privacy**: Selected approaches to meeting safety, security, and privacy requirements. Place these in **separate subparagraphs** as the DID requires special treatment for critical requirements
-- **e. Hardware/physical design choices**: Physical characteristics if applicable (for hardware-software systems) — size, color, shape, weight, materials, markings
-- **f. Other system-wide decisions**: Flexibility, availability, maintainability approaches. Describe the rationale for architectural patterns selected (e.g., "A service-isolation pattern is selected to satisfy NFR-A1 availability requirement, enabling independent failure recovery")
-
-## Section 4: System architectural design
-
-- **4.1 System components** (items a through f — all are required):
-
-  **a.** Identify all system components using the approved CSCI decomposition from Step 2.5. Each CSCI shall have a project-unique identifier. For each CSCI, list the CSCs (services, modules) it contains. Also identify HWCIs and manual operations as applicable. Note: a database may be treated as a CSCI or as part of a CSCI.
-
-  **b.** Show the static ("consists of") relationships using component/block diagrams. Multiple relationship views may be presented (structural, deployment, data ownership).
-
-  **c.** State each component's purpose and the system requirements allocated to it. (Alternatively, allocation may be provided in Section 5.a.)
-
-  **d.** Identify each component's development status: new development, existing reuse as-is, existing design reuse, reengineering, planned for a specific build, etc. For existing components, provide identifying information (name, version, documentation references, location).
-
-  **e.** For each computer system or hardware aggregate, describe computer hardware resources: processors, memory, I/O devices, auxiliary storage, communications/network equipment. Include:
-    - Manufacturer, model, speed/capacity for processors
-    - Type, size, speed, configuration for memory
-    - Type, speed/capacity for I/O devices
-    - Type, amount, speed for auxiliary storage
-    - Data transfer rates, topologies, protocols for network equipment
-    - Growth capabilities and diagnostic capabilities
-    - Resource utilization allocation per CSCI (e.g., "20% of resource capacity allocated to CSCI-SA")
-
-  **f.** Present a **specification tree** — a diagram that identifies and shows the relationships among the planned specifications for the system components. This is a tree showing which specification documents (SSS, SRS, SDD, IRS, etc.) apply to which components.
-
-- **4.2 Concept of execution**:
-  - Describe dynamic relationships between components — how they interact during system operation
-  - Include: execution flow, data flow, dynamically controlled sequencing, state transitions, timing/sequencing, priorities, interrupt handling, concurrent execution, dynamic allocation/deallocation, exception handling
-  - Use sequence diagrams, timing diagrams, or state transition diagrams where helpful
-
-- **4.3 Interface design**:
-  - **4.3.1 Interface identification and diagrams**: List all interfaces with project-unique identifiers. Identify interfacing entities by name, number, version. State which entities have fixed interface characteristics vs. developing ones. Provide interface diagrams.
-  - **4.3.x (per interface)**: For each interface, document the following 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 (project-unique, natural-language, technical), data types, sizes/formats, units, ranges, accuracy/precision, timing/frequency/volume constraints, security/privacy constraints, sources and recipients
-    - **d.** Data element assemblies: records, messages, files, displays — their names, structure, medium, visual/auditory characteristics, relationships, constraints, sources and recipients
-    - **e.** Communication methods: links/media, message formatting, flow control, data transfer rates, routing/addressing, transmission services, safety/security considerations
-    - **f.** Protocols: priority/layer, packeting/fragmentation, error control/recovery, synchronization, status/reporting
-    - **g.** Physical compatibility considerations (dimensions, tolerances, loads, voltages, plug compatibility)
-
-## Section 5: Requirements traceability
-- **5.a**: Map each system component to the system requirements it satisfies
-- **5.b**: Map each system requirement to the components that address it
-- Ensure every system requirement is accounted for in both directions
-
-## Section 6: Notes
-- Alphabetical listing of all acronyms, abbreviations, and their meanings
-- Glossary of terms and definitions needed to understand this document
-- 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-ssdd/prompts/05-validate.md

@@ -1,14 +0,0 @@
-# Step 4 — Validate
-
-Before presenting to the user, verify:
-- All template sections (1-6 and Appendix A) are populated or marked "Not applicable" with justification
-- Every CSCI has a project-unique identifier and represents a logically cohesive grouping (not a 1:1 service mapping)
-- The specification tree (4.1.f) is present and shows relationships among planned specifications
-- System-wide design decisions (Section 3) are framed as behavioral responses to requirements — **no tool/product names appear as primary descriptions**
-- Interface descriptions (4.3.x) cover all seven aspects (a through g) where applicable
-- Requirements traceability (Section 5) covers all system requirements in both directions
-- 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-ssdd/prompts/06-review.md

@@ -1,16 +0,0 @@
-# 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:
-- Is the CSCI decomposition correct? Are there components that should be merged or split?
-- Are the interface descriptions accurate and complete?
-- Are there additional design decisions not captured in the Architecture?
-- Does Section 3 correctly describe behavioral design without leaking implementation details?
-- Is the specification tree in 4.1.f accurate?
-
-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-ssdd/prompts/07-save.md

@@ -1,16 +0,0 @@
-# Step 6 — Save
-
-Write the final document to:
-`{output_folder}/planning-artifacts/SSDD.md`
-
-Confirm the file was saved and display a summary of:
-- Number of CSCIs identified (with their identifiers)
-- Number of CSCs per CSCI
-- Number of interfaces documented
-- Number of system-wide design decisions captured
-- Specification tree completeness
-- 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-sss/SKILL.md

@@ -1,31 +0,0 @@
----
-name: mil498-sss
-description: Generate MIL-STD-498 System/Subsystem Specification (SSS)
-type: complex-workflow
-triggers:
-  - "generate SSS"
-  - "create system specification"
-  - "create subsystem specification"
----
-
-# MIL-498: System/Subsystem Specification (SSS)
-
-> MIL-STD-498 Data Item Description: DI-IPSC-81431
-
-## Workflow
-
-This workflow generates a MIL-STD-498 SSS document through progressive steps.
-The SSS specifies requirements at the system or subsystem level, not at the software (CSCI) level.
-
-### 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-sss/bmad-skill-manifest.yaml

@@ -1,5 +0,0 @@
-type: skill
-name: mil498-sss
-module: ma-skills
-description: Generate MIL-STD-498 System/Subsystem Specification (SSS)
-version: "1.0.0"

package/.opencode/skills/mil498-sss/prompts/01-discover-project-artifacts.md

@@ -1,31 +0,0 @@
-# Step 1 — Discover Project Artifacts
-
-Search the project for the following artifacts. Communicate in {communication_language}. Inform {user_name} which artifacts were found and which are missing.
-
-| Priority | Artifact | Search Pattern |
-|----------|----------|----------------|
-| Required | Product Brief | `**/product-brief*.md` |
-| Required | PRD | `**/prd.md`, `**/prd-*.md` |
-| Recommended | Architecture | `**/architecture.md`, `**/architecture-*.md` |
-| Optional | OCD | `**/OCD.md` |
-| Optional | UX Designs | `**/ux-design*.md` |
-
-If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
-
-## Document Dependencies
-
-The SSS is typically one of the earliest MIL-STD-498 documents generated, after the OCD. It defines system-level requirements that downstream documents (SSDD, SRS) will design against and trace to.
-
-| Predecessor | Relationship | Search Pattern |
-|-------------|-------------|----------------|
-| OCD (Operational Concept Description) | Recommended — provides operational context and user needs | `**/OCD.md` |
-
-If the OCD has been generated, it MUST be loaded and used as an input — particularly for deriving capability requirements (3.2) and understanding operational scenarios.
-
-If the OCD has NOT been generated yet, **inform {user_name}**: "The OCD has not been generated yet. The SSS benefits from the operational context in the OCD. Would you like to proceed without it, or generate the OCD first?"
-
-**Note**: The SSS feeds into the SSDD, SRS, and STD. Ensure requirements are written to be traceable — each requirement needs a unique identifier that downstream documents can reference.
-
----
-
-**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-sss/prompts/02-load-template.md

@@ -1,10 +0,0 @@
-# Step 2 — Load Template
-
-Read the SSS 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-sss/prompts/03-generate-document.md

@@ -1,108 +0,0 @@
-# Step 3 — Generate Document
-
-Write the document in {document_output_language}, populating each template section. Keep requirements at the **system/subsystem level** — avoid low-level software implementation details. Each requirement shall be assigned a project-unique identifier, be stated so that an objective test can be defined for it, and be annotated with qualification method(s).
-
-## 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/Product Brief
-- **1.2 System overview**: Summarize system purpose, nature, and stakeholders
-- **1.3 Document overview**: Describe this SSS document's purpose, contents, and any security/privacy considerations
-
-## Section 2: Referenced documents
-- List all project artifacts and external standards used, with number, title, revision, and date
-
-## Section 3: Requirements
-
-- **3.1 Required states and modes**: Identify system-level operational states from Architecture/PRD (e.g., operational, maintenance, degraded, emergency). If none, state so explicitly. If states/modes exist, correlate each requirement to the applicable states/modes.
-
-- **3.2 System capability requirements**: Map high-level PRD features and Product Brief goals to system capabilities (3.2.1, 3.2.2, etc.). Each requirement must have:
-  - A unique identifier (SSS-CAP-001 format)
-  - Clear, testable statement
-  - Parameters: response times, throughput, accuracy, capacity, priorities as applicable
-  - Error handling: behavior under unexpected, unallowed, or out-of-bounds conditions
-  - Provisions for continuity of operations in emergencies
-
-- **3.3 System external interface requirements**:
-  - **3.3.1 Interface identification and diagrams**: Identify all required external interfaces with project-unique identifiers. Designate interfacing entities by name, number, version. State which have fixed vs. developing characteristics. Provide interface diagrams.
-  - **3.3.x (per interface)**: For each external interface, specify requirements imposed on the system. Cover:
-    - **a.** Priority the system must assign 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, files, displays — names, structure, medium, characteristics, relationships, constraints
-    - **e.** Communication methods: links/media, message formatting, flow control, data transfer rates, routing, transmission services, security considerations
-    - **f.** Protocols: priority/layer, packeting, error control/recovery, synchronization, status/reporting
-    - **g.** Physical compatibility (dimensions, tolerances, loads, plug compatibility, voltages)
-
-- **3.4 System internal interface requirements**: Interfaces between major subsystems. If left to design or component specs, state so. If requirements exist, follow 3.3 topics.
-
-- **3.5 System internal data requirements**: System-level data stores, data flows between subsystems. If left to design or component specs, state so.
-
-- **3.6 Adaptation requirements**: Installation and site-specific configuration needs, operational parameters that may vary
-
-- **3.7 Safety requirements**: Requirements for preventing/minimizing unintended hazards to personnel, property, and environment. Include nuclear component requirements if applicable.
-
-- **3.8 Security and privacy requirements**: Security/privacy environment, type/degree of protection, risks, safeguards, policy, accountability, certification criteria
-
-- **3.9 System environment requirements**: Physical, regulatory, and operational environment constraints. For hardware-software systems: transportation, storage, operation conditions (wind, rain, temperature, shock, noise, electromagnetic radiation, explosions)
-
-- **3.10 Computer resource requirements**:
-  - **3.10.1 Computer hardware requirements**: Required hardware — processors, memory, I/O devices, auxiliary storage, communications/network equipment (number, type, size, capacity)
-  - **3.10.2 Computer hardware resource utilization requirements**: Maximum allowable utilization (% of processor, memory, I/O, storage, network capacity) with conditions for measurement
-  - **3.10.3 Computer software requirements**: Required software (OS, DBMS, network software, utilities) with nomenclature, version, and documentation references
-  - **3.10.4 Computer communications requirements**: Geographic locations, network topology, transmission techniques, data transfer rates, gateways, use times, data volume, time boundaries, peak volumes, diagnostics
-
-- **3.11 System quality factors**: Quantitative requirements for: functionality, reliability (e.g., MTBF for equipment), maintainability, availability, flexibility, portability, reusability, testability, usability
-
-- **3.12 Design and construction constraints**: Requirements constraining system design and construction. For hardware-software systems, include physical requirements:
-  - **a.** Architecture constraints: required subsystems, standard/military/existing components, Government-furnished property
-  - **b.** Design/construction standards, data standards, programming languages, workmanship requirements
-  - **c.** Physical characteristics: weight limits, dimensional limits, color, protective coatings, interchangeability, transportability, setup requirements
-  - **d.** Materials: allowed/prohibited materials, toxic material handling, electromagnetic radiation limits
-  - **e.** Nameplates, part marking, serial/lot number marking, other identifying markings
-  - **f.** Flexibility and expandability for anticipated growth, technology changes, threat changes, mission changes
-
-- **3.13 Personnel-related requirements**: Number of users, skill levels, duty cycles, training needs, human factors engineering (capabilities/limitations, foreseeable errors, critical indicator placement, adjustable workstations, error message color/duration, auditory signals)
-
-- **3.14 Training-related requirements**: Training devices and training materials to be included in the system
-
-- **3.15 Logistics-related requirements**: System maintenance, software support, transportation modes, supply-system requirements, facility impacts, equipment impacts
-
-- **3.16 Other requirements**: Additional requirements not covered above. Examples: system documentation requirements (specifications, drawings, manuals, test plans)
-
-- **3.17 Packaging requirements**: Requirements for packaging, labeling, and handling for delivery
-
-- **3.18 Precedence and criticality of requirements**: Order of precedence, criticality, or assigned weights. Identify requirements critical to safety, security, or privacy
-
-## Section 4: Qualification provisions
-For each requirement in Section 3, specify the qualification method(s). A table may be used:
-- **a.** Demonstration: Observable functional operation without instrumentation
-- **b.** Test: Operation using instrumentation or special test equipment
-- **c.** Analysis: Processing of accumulated data (reduction, interpolation, extrapolation)
-- **d.** Inspection: Visual examination of system components, documentation
-- **e.** Special qualification methods: Special tools, techniques, procedures, facilities, acceptance limits, standard samples, preproduction samples, pilot models/lots
-
-## Section 5: Requirements traceability
-- For **system-level specifications**: This paragraph does not apply (state so).
-- For **subsystem-level specifications**:
-  - **5.a**: Map each subsystem requirement to the system requirements it addresses. Note: some requirements may trace to "system implementation" or system design decisions.
-  - **5.b**: Map each system requirement allocated to this subsystem to the subsystem requirements that address it. All allocated requirements shall be accounted for.
-
-## Section 6: Notes
-- Alphabetical listing of all acronyms, abbreviations, and their meanings
-- Glossary of terms and definitions
-
-## Appendix A
-- Include any supplementary material (requirement matrices, charts, classified data) that supports the main body
-
----
-
-**CONFIRMATION GATE**: Present the generated document to the user for initial review. Wait for the user to confirm the content before proceeding to validation.