ma-agents 3.4.8 → 3.5.0

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.

package/.opencode/skills/mil498-sss/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
-- Requirements are at the system level (not CSCI/software level)
-- Every requirement has a unique identifier and is testable
-- 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)
-- Design constraints (3.12) cover items a through f including physical requirements where applicable
-- Qualification methods are specified for all requirements including special methods (4.e)
-- Section 5 correctly handles system vs. subsystem distinction
-- 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-sss/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 system capabilities captured?
-- Are the interface requirements (3.3) accurate and complete?
-- Are there physical or environmental constraints not captured in 3.9 and 3.12?
-- 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-sss/prompts/06-save.md

@@ -1,15 +0,0 @@
-# Step 6 — Save
-
-Write the final document to:
-`{output_folder}/planning-artifacts/SSS.md`
-
-Confirm the file was saved and display a summary of:
-- Total system 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-std/SKILL.md

@@ -1,30 +0,0 @@
----
-name: mil498-std
-description: Generate MIL-STD-498 Software Test Description (STD)
-type: complex-workflow
-triggers:
-  - "generate STD"
-  - "create software test description"
----
-
-# MIL-498: Software Test Description (STD)
-
-> MIL-STD-498 Data Item Description: DI-IPSC-81439
-
-## Workflow
-
-This workflow generates a MIL-STD-498 STD document through progressive steps.
-The STD defines the test preparations, test cases, and test procedures for software qualification testing.
-
-### 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-std/bmad-skill-manifest.yaml

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

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

@@ -1,42 +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 | Epics & Stories | `**/epics*.md`, `**/epic-*.md`, `**/stories/*.md` |
-| Required | Architecture | `**/architecture.md`, `**/architecture-*.md` |
-| Recommended | SRS | `**/SRS.md` |
-| Recommended | PRD | `**/prd.md`, `**/prd-*.md` |
-| Optional | Existing test files | `**/test/**`, `**/tests/**`, `**/__tests__/**`, `**/*.test.*`, `**/*.spec.*` |
-
-If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
-
-## Document Dependencies
-
-The STD defines test descriptions that verify requirements specified in the SRS. It should be generated after both the SSDD and the SRS for the CSCI being tested.
-
-| Predecessor | Relationship | Search Pattern |
-|-------------|-------------|----------------|
-| SRS (Software Requirements Specification) | **Required** — provides the requirements that tests must verify | `**/SRS.md`, `**/SRS-*.md` |
-| SSDD (System/Subsystem Design Description) | **Required** — provides system context and CSCI decomposition | `**/SSDD.md` |
-| SDD (Software Design Description) | Recommended — provides design details useful for test planning | `**/SDD.md`, `**/SDD-*.md` |
-
-If the SRS has NOT been generated yet, **alert {user_name}**: "The SRS has not been generated yet. The STD needs the SRS to know which requirements must be verified by tests. 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 STD benefits from the system design context in the SSDD. Would you like to proceed without it, or generate the SSDD first?"
-
-If predecessor documents exist, they MUST be loaded and used as primary inputs. Test cases MUST trace back to specific SRS requirements.
-
-## CSCI/System Scoping
-
-Ask {user_name}: **"Is this STD for CSCI-level testing or system-level testing? If CSCI-level, which CSCI?"**
-
-- For CSCI-level testing: requirements come from the CSCI's SRS
-- For system-level testing: requirements come from the SSS
-
-If the SSDD exists, present the list of CSCIs and ask the user to select scope.
-
----
-
-**CONFIRMATION GATE**: Present the list of discovered artifacts and the selected test scope to the user. Wait for the user to confirm before proceeding to the next step.

package/.opencode/skills/mil498-std/prompts/02-load-template.md

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