ma-agents 3.4.9 → 3.5.1

package/.opencode/skills/logging-best-practices/examples/javascript.md

@@ -1,77 +0,0 @@
-# JavaScript/TypeScript Logging Examples
-
-## Backend (Node.js with `pino` or `winston`)
-
-```typescript
-import pino from 'pino';
-
-const logger = pino({
-  level: process.env.LOG_LEVEL || 'info',
-  formatters: {
-    level: (label) => {
-      return { severity: label.toUpperCase() };
-    },
-  },
-  base: {
-    process_name: 'api-gateway',
-    container_id: process.env.HOSTNAME || 'unknown'
-  }
-});
-
-async function handleRequest(req, res) {
-  const traceId = req.headers['x-trace-id'];
-  try {
-    logger.info({ 
-      msg: 'Handling incoming request', 
-      trace_id: traceId,
-      path: req.path,
-      placement: 'router.ts:12'
-    });
-    
-    // ... logic
-  } catch (error) {
-    // Mandatory Exception Logging
-    logger.error({
-      msg: 'Request handler failed',
-      trace_id: traceId,
-      err: error, // Pino automatically formats the stack trace
-      severity: 'ERROR',
-      placement: 'router.ts:25'
-    });
-    res.status(500).send('Internal Server Error');
-  }
-}
-```
-
-## Frontend (Browser)
-
-```javascript
-const logToServer = async (logEntry) => {
-  try {
-    await fetch('/api/logs', {
-      method: 'POST',
-      body: JSON.stringify({
-        ...logEntry,
-        datetime: new Date().toISOString(),
-        browser: navigator.userAgent,
-        process_name: 'frontend-spa'
-      })
-    });
-  } catch (e) {
-    console.error('Failed to ship logs', e);
-  }
-};
-
-// Global error handler
-window.onerror = function(msg, url, lineNo, columnNo, error) {
-  logToServer({
-    severity: 'ERROR',
-    message: msg,
-    placement: `${url}:${lineNo}`,
-    exception: {
-      message: error?.message,
-      stack: error?.stack
-    }
-  });
-};
-```

package/.opencode/skills/logging-best-practices/examples/python.md

@@ -1,57 +0,0 @@
-# Python Logging Examples
-
-## Structured Logging with `structlog`
-
-```python
-import structlog
-import os
-
-logger = structlog.get_logger()
-
-def process_data(data):
-    try:
-        # Algorithmic step logging
-        logger.info("calculation_step_started",
-                    step="matrix_multiplication",
-                    data_size=len(data),
-                    placement="processor.py:45")
-        
-        result = perform_complex_math(data)
-        return result
-    except Exception as e:
-        # Mandatory Exception Logging
-        logger.error("calculation_failed",
-                     exception_type=type(e).__name__,
-                     exception_msg=str(e),
-                     stack_trace=True, # structlog captures this
-                     severity="ERROR",
-                     placement="processor.py:52",
-                     container_id=os.getenv("HOSTNAME"))
-        raise
-```
-
-## Standard Library with JSON Formatter
-
-```python
-import logging
-import json
-from datetime import datetime
-
-class JsonFormatter(logging.Formatter):
-    def format(self, record):
-        log_entry = {
-            "datetime": datetime.utcnow().isoformat(),
-            "severity": record.levelname,
-            "message": record.getMessage(),
-            "placement": f"{record.filename}:{record.lineno}",
-            "process_name": record.processName,
-            "trace_id": getattr(record, 'trace_id', 'none')
-        }
-        if record.exc_info:
-            log_entry["exception"] = self.formatException(record.exc_info)
-        return json.dumps(log_entry)
-
-# usage
-logger = logging.getLogger("backend_service")
-logger.error("Database connection failed", exc_info=True)
-```

package/.opencode/skills/logging-best-practices/references/logging-standards.md

@@ -1,29 +0,0 @@
-# Logging Standards Reference
-
-This document defines the semantic conventions and levels used in the Logging Best Practices skill.
-
-## Log Levels
-
-| Level | Usage |
-| :--- | :--- |
-| **TRACE** | Fine-grained informational events (mostly for debugging logic flows). |
-| **DEBUG** | Detailed information for developer troubleshooting. |
-| **INFO** | Regular operational events (startup, shutdown, successful requests). |
-| **WARN** | Potential issues or degraded states that don't stop the service. |
-| **ERROR** | Operational failures that affect a specific request or operation. |
-| **CRITICAL** | System-wide failures requiring immediate attention. |
-
-## OpenTelemetry Semantic Conventions
-
-To ensure interoperability, use the following field names where possible:
-
-- `timestamp`: The time when the event occurred.
-- `severity_text`: The string representation of the log level.
-- `body`: The primary log message.
-- `attributes.service.name`: The value of `process_name`.
-- `attributes.container.id`: The value of `container_id`.
-- `attributes.code.filepath`: Path to the source file.
-- `attributes.code.lineno`: Line number in the source file.
-- `attributes.exception.type`: Class name of the exception.
-- `attributes.exception.message`: Message from the exception.
-- `attributes.exception.stacktrace`: Full stack trace.

package/.opencode/skills/mil498-ocd/SKILL.md

@@ -1,30 +0,0 @@
----
-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

@@ -1,5 +0,0 @@
-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

@@ -1,26 +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` |
-| 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

@@ -1,10 +0,0 @@
-# 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

@@ -1,90 +0,0 @@
-# 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

@@ -1,14 +0,0 @@
-# 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

@@ -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 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

@@ -1,15 +0,0 @@
-# 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-sdd/SKILL.md

@@ -1,30 +0,0 @@
----
-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

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

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

@@ -1,50 +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 | Architecture | `**/architecture.md`, `**/architecture-*.md` |
-| Required | Epics | `**/epics*.md`, `**/epic-*.md` |
-| Required | User Stories | `**/stories/*.md`, `**/story-*.md`, `**/user-stories*.md` |
-| Recommended | PRD | `**/prd.md`, `**/prd-*.md` |
-| Optional | UX Designs | `**/ux-design*.md`, `**/ux-*.md` |
-| Optional | Product Brief | `**/product-brief*.md` |
-
-If **required** artifacts are missing, warn the user and ask whether to proceed with available data or stop.
-
-## Document Dependencies
-
-The SDD is a **per-CSCI document** that designs the internal structure of a CSCI against its requirements. It MUST be generated after the SRS (which defines what the CSCI must do) and the SSDD (which defines the CSCI boundaries).
-
-| Predecessor | Relationship | Search Pattern |
-|-------------|-------------|----------------|
-| SRS (Software Requirements Specification) | **Required** — provides the CSCI requirements this SDD designs against | `**/SRS.md`, `**/SRS-*.md` |
-| SSDD (System/Subsystem Design Description) | **Required** — defines CSCI boundaries, system-wide design decisions, and allocated requirements | `**/SSDD.md` |
-| SSS (System/Subsystem Specification) | Optional — provides system-level requirements context | `**/SSS.md` |
-
-If the SRS has NOT been generated yet, **alert {user_name}**: "The SRS has not been generated yet. The SDD designs the internal structure of a CSCI against the requirements defined in its SRS. Would you like to proceed without the SRS, or generate the SRS first?"
-
-If the SSDD has NOT been generated yet, **alert {user_name}**: "The SSDD has not been generated yet. The SDD needs the SSDD to understand CSCI boundaries and system-wide design decisions. Would you like to proceed without the SSDD, or generate the SSDD first?"
-
-If predecessor documents exist, they MUST be loaded and used as primary inputs. The SDD should reference them in Section 2 and trace design decisions to SRS requirements.
-
-## CSCI Scoping
-
-Ask {user_name}: **"Which CSCI is this SDD for?"**
-
-If the SSDD exists, present the list of CSCIs defined in it and ask the user to select one. The SDD will describe the design of ONLY the selected CSCI — its internal CSCs (Computer Software Components) and software units.
-
-If generating SDD documents for multiple CSCIs, generate them one at a time, each as a separate document.
-
-## Source Mapping
-
-For the selected CSCI, the agent must:
-1. From the **SSDD**: Extract the CSCI's allocated system requirements, its CSCs, and the system-wide design decisions that constrain it
-2. From the **SRS**: Extract all CSCI requirements (capabilities, interfaces, quality factors, constraints) — these are what the SDD must design against
-3. From the **Architecture**: Extract the internal structure, technology stack, patterns, and integration approach for this CSCI's components
-4. From **Epics/Stories**: Extract detailed behavioral specifications, acceptance criteria, algorithms, business rules, and processing logic that inform the detailed design (Section 5)
-
----
-
-**CONFIRMATION GATE**: Present the list of discovered artifacts and the selected CSCI to the user. Wait for the user to confirm before proceeding to the next step.

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

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

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

@@ -1,98 +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**: Identify the CSCI by name, version, and project-unique identifier (as assigned in the SSDD)
-- **1.2 System overview**: Summarize the system and this CSCI's role within it, referencing the SSDD
-- **1.3 Document overview**: Describe this SDD document's purpose and contents
-
-## Section 2: Referenced documents
-- List all predecessor MIL-STD-498 documents (SSDD, SRS, SSS) and project artifacts used. Include number, title, revision, and date
-
-## Section 3: CSCI-wide design decisions
-
-**CRITICAL BEHAVIORAL GUIDANCE**: Like the SSDD, this section describes the CSCI's behavioral design — how it will behave from a user's point of view, ignoring internal implementation. Follow these rules:
-
-1. **Requirements-driven**: Every design decision MUST cite the specific SRS requirement(s) it satisfies
-2. **Behavioral, not implementation**: Describe patterns and approaches first, then technology choices parenthetically if essential
-3. **State-dependent decisions**: If a design decision depends on CSCI states or modes, indicate this dependency
-
-Document the following CSCI-wide design decisions (items a through e per the DID):
-
-- **a. CSCI behavioral design**: How the CSCI behaves in response to inputs and conditions — actions, response times, algorithms/rules, error handling. Describe from the user's perspective. Reference SRS capability requirements (3.2.x)
-- **b. Database/data file design**: How databases and data files within this CSCI appear to users and external systems. Reference SRS internal data requirements (3.5). If Database Design Descriptions (DBDDs) exist, they may be referenced
-- **c. Safety, security, privacy**: Selected approaches to meeting safety, security, and privacy requirements for this CSCI. Place in **separate subparagraphs** for critical requirements. Reference SRS sections 3.7, 3.8
-- **d. Other CSCI-wide design decisions**: Flexibility, availability, maintainability approaches. Rationale for architectural patterns selected. Reference SRS quality factors (3.11) and design constraints (3.12)
-- **e. Design and implementation standards**: Standards to be followed for design, coding, testing (reference SDP if available)
-
-## Section 4: CSCI architectural design
-
-- **4.1 CSCI components** (items a through f — all are required):
-
-  **a.** Identify all CSCs (Computer Software Components) within this CSCI — modules, packages, services, libraries. Each CSC shall have a project-unique identifier. Also identify software units within CSCs where applicable.
-
-  **b.** Show static ("consists of") relationships using component/class/package diagrams. Multiple relationship views may be presented.
-
-  **c.** State each CSC's purpose and the SRS requirements allocated to it. (Alternatively, allocation may be provided in Section 6.a.)
-
-  **d.** Identify each CSC's development status: new development, existing reuse as-is, existing design reuse, reengineering, etc. For existing components, provide identifying information.
-
-  **e.** Describe **resource utilization** — allocation of computer hardware resources (processor capacity, memory, I/O, storage) to each CSC. State conditions under which utilization will be measured. (This differs from SSDD 4.1.e which describes hardware; here it's about utilization allocation.)
-
-  **f.** Describe the CSCI's **program library** — contents including computer files, data files, program files, and their relationships.
-
-- **4.2 Concept of execution**:
-  - Describe dynamic relationships between CSCs — how they interact during operation
-  - Include: execution flow, data flow, state transitions, timing/sequencing, priorities, interrupt handling, concurrent execution, dynamic allocation/deallocation, exception handling
-  - Use sequence diagrams, state transition diagrams, or timing diagrams where helpful
-
-- **4.3 Interface design**:
-  - **4.3.1 Interface identification and diagrams**: List all interfaces (between CSCs and with external entities) with project-unique identifiers. Identify fixed vs. developing interfaces. Provide interface diagrams.
-  - **4.3.x (per interface)**: For each interface, document as applicable:
-    - **a.** Priority assigned to the interface
-    - **b.** Type of interface (real-time data transfer, storage-and-retrieval, etc.)
-    - **c.** Data elements: names/identifiers, data types, sizes/formats, units, ranges, accuracy/precision, timing/frequency constraints, security constraints, sources and recipients
-    - **d.** Data element assemblies: records, messages, data structures — names, structure, medium, relationships, constraints
-    - **e.** Communication methods: links/media, message formatting, flow control, data transfer rates, routing
-    - **f.** Protocols: priority/layer, packeting, error control/recovery, synchronization
-    - **g.** Physical compatibility considerations
-
-## Section 5: CSCI detailed design
-
-**This is the most important section of the SDD.** For each software unit identified in Section 4.1, provide a detailed design description. Organize as subsections (5.x per CSC, or 5.x per software unit):
-
-For each software unit (5.x), document the following items (a through f per the DID):
-
-- **a. Unit design decisions**: Design decisions specific to this unit, including algorithms, processing logic, data transformations, and business rules. **Extract from Epics and User Stories** — map Story acceptance criteria to specific processing logic. Reference the SRS requirements this unit satisfies.
-- **b. Design constraints**: Any constraints on the unit's design imposed by the CSCI-wide decisions, standards, or external interfaces
-- **c. Programming language**: If different from the CSCI-wide language specified in Section 3.e
-- **d. Control flow / logic description**: Describe the unit's control logic — how it processes inputs, makes decisions, handles conditions. Use flowcharts, pseudocode, or decision tables where helpful. Map from Story acceptance criteria and business rules.
-- **e. Data elements and structures**: Internal data elements, record layouts, data structures, file formats used by the unit
-- **f. Restrictions and limitations**: Any restrictions on the unit's use, dependencies, known limitations, or assumptions
-
-## Section 6: Requirements traceability
-- **6.a**: Map each CSC/software unit to the SRS requirements it addresses
-- **6.b**: Map each SRS requirement to the CSCs/units that implement it
-- Ensure every SRS requirement allocated to this CSCI is accounted for in both directions
-
-## Section 7: Notes
-- Alphabetical listing of all acronyms, abbreviations, and their meanings
-- Glossary of design terms and definitions
-
-## Appendix A
-- Include any supplementary material (detailed algorithms, data dictionaries, message format specifications) that supports the main body
-
----
-
-**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-sdd/prompts/04-validate.md

@@ -1,16 +0,0 @@
-# Step 4 — Validate
-
-Before presenting to the user, verify:
-- All template sections (1-7 and Appendix A) are populated or marked "Not applicable" with justification
-- This SDD covers exactly ONE CSCI as defined in the SSDD
-- Every CSC has a project-unique identifier
-- CSCI-wide design decisions (Section 3) are framed as behavioral responses to SRS requirements
-- Section 5 (detailed design) has entries for every software unit, with algorithms and logic extracted from Epics/Stories
-- Resource utilization (4.1.e) and program library (4.1.f) are documented
-- Interface descriptions (4.3.x) cover all seven aspects (a through g) where applicable
-- Requirements traceability (Section 6) covers all SRS requirements in both directions
-- Document is written in {document_output_language}
-
----
-
-**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-sdd/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:
-- Is the CSC decomposition correct for this CSCI?
-- Are the algorithms and processing logic in Section 5 accurately extracted from the Stories?
-- Are there design decisions not captured in the Architecture or Epics?
-- Is the resource utilization allocation realistic?
-
-Offer to refine any section based on feedback.
-
----
-
-**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-sdd/prompts/06-save.md

@@ -1,19 +0,0 @@
-# Step 6 — Save
-
-Write the final document to:
-`{output_folder}/planning-artifacts/SDD.md`
-
-(If this is not the first CSCI's SDD, save as `SDD-{CSCI-identifier}.md`)
-
-Confirm the file was saved and display a summary of:
-- CSCI identifier and name
-- Number of CSCs identified
-- Number of software units with detailed design
-- Number of interfaces documented
-- Number of SRS requirements traced
-- Requirements coverage percentage
-- Any sections marked "Not applicable"
-
----
-
-**CONFIRMATION GATE**: Confirm to the user that the document has been saved successfully and present the summary. The workflow is now complete.