ma-agents 3.4.9 → 3.5.1

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.

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

@@ -1,117 +0,0 @@
-# Step 3 — Generate Document
-
-Write the document in {document_output_language}, populating each template section. **Important**: Safety precautions (marked by WARNING or CAUTION) and security/privacy considerations shall be included as applicable throughout Sections 3 and 4.
-
-## 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 and software identifiers from PRD/Architecture
-- **1.2 System overview**: Summarize the system and the CSCI(s) being tested
-- **1.3 Document overview**: Describe this STD document's purpose and contents
-
-## Section 2: Referenced documents
-- List all project artifacts, test standards, and other references with number, title, revision, and date
-
-## Section 3: Test preparations
-
-Organize as 3.x subsections, one per test. For each test (3.x), provide a brief description and the following:
-
-- **3.x.1 Hardware preparation**: Procedures to prepare hardware for the test:
-  - **a.** Specific hardware to be used, identified by name and number
-  - **b.** Switch settings and cabling necessary to connect the hardware
-  - **c.** Diagrams showing hardware, interconnecting control, and data paths
-  - **d.** Step-by-step instructions for placing hardware in a state of readiness
-- **3.x.2 Software preparation**: Procedures to prepare software for the test:
-  - **a.** Specific software to be used in the test
-  - **b.** Storage medium of the item(s) under test
-  - **c.** Storage medium of related software (simulators, test drivers, databases)
-  - **d.** Instructions for loading software, including required sequence
-  - **e.** Instructions for software initialization common to more than one test case
-- **3.x.3 Other pre-test preparations**: Any other personnel actions, preparations, or procedures necessary (test data setup, user accounts, external service mocks, environment variables)
-
-When information duplicates another test's preparation, reference it rather than repeating it.
-
-## Section 4: Test descriptions
-
-Organize as a **two-level hierarchy**: 4.x per test, then 4.x.y per test case within each test. Group test cases by capability/feature (mapping to Epics) for clarity.
-
-For each test (4.x), identify the test by project-unique identifier. Then for each test case (4.x.y), provide:
-
-- **4.x.y.1 Requirements addressed**: Identify the CSCI or system requirements addressed by this test case. Reference specific SRS requirement IDs (e.g., SRS-CAP-001). (Alternatively, this traceability may be provided in Section 5.a.)
-
-- **4.x.y.2 Prerequisite conditions**: Conditions that must be established prior to the test case:
-  - **a.** Hardware and software configuration
-  - **b.** Flags, initial breakpoints, pointers, control parameters, or initial data to be set/reset
-  - **c.** Preset hardware conditions or electrical states
-  - **d.** Initial conditions for timing measurements
-  - **e.** Conditioning of the simulated environment
-  - **f.** Other special conditions peculiar to the test case
-
-- **4.x.y.3 Test inputs**: Test inputs necessary for the test case:
-  - **a.** Name, purpose, and description (range of values, accuracy) of each test input
-  - **b.** Source of the test input and method for selecting it
-  - **c.** Whether the test input is real or simulated
-  - **d.** Time or event sequence of test input
-  - **e.** How input data will be controlled to:
-    1. Test with minimum/reasonable number of data types and values
-    2. Exercise with a range of valid data (overload, saturation, worst-case)
-    3. Exercise with invalid data types and values (error handling)
-    4. Permit retesting if necessary
-
-- **4.x.y.4 Expected test results**: All expected results — both intermediate and final results
-
-- **4.x.y.5 Criteria for evaluating results**: Criteria for intermediate and final results:
-  - **a.** Range or accuracy over which output can vary and still be acceptable
-  - **b.** Minimum number of input/output combinations that constitute acceptable results
-  - **c.** Maximum/minimum allowable test duration (time or number of events)
-  - **d.** Maximum number of interrupts, halts, or system breaks that may occur
-  - **e.** Allowable severity of processing errors
-  - **f.** Conditions under which the result is inconclusive and retesting is needed
-  - **g.** Conditions indicating irregularities in input data, test database, or procedures
-  - **h.** Allowable indications of control, status, and results readiness for next test case
-  - **i.** Additional criteria not covered above
-
-- **4.x.y.6 Test procedure**: Defined as individually numbered steps in sequential order:
-  - **a.** Test operator actions and equipment operation for each step, including commands to:
-    1. Initiate the test case and apply test inputs
-    2. Inspect test conditions
-    3. Perform interim evaluations of test results
-    4. Record data
-    5. Halt or interrupt the test case
-    6. Request data dumps or other aids
-    7. Modify the database/data files
-    8. Repeat the test case if unsuccessful
-    9. Apply alternate modes as required
-    10. Terminate the test case
-  - **b.** Expected result and evaluation criteria for each step
-  - **c.** If addressing multiple requirements, which steps address which requirements
-  - **d.** Actions to follow in event of program stop or error (recording critical data, halting time-sensitive software, collecting records)
-  - **e.** Procedures for reducing and analyzing test results (detect output, identify media/location, evaluate for continuation, evaluate against required output)
-
-- **4.x.y.7 Assumptions and constraints**: Assumptions made and constraints imposed (limitations on timing, interfaces, equipment, personnel, database). If waivers/exceptions to limits are approved, address their effects.
-
-## Section 5: Requirements traceability
-- **5.a**: Map each test case to the system or CSCI requirements it addresses. If a test case addresses multiple requirements, indicate which test procedure steps address which requirements.
-- **5.b**: Map each requirement covered by this STD to the test case(s) that address it. For CSCI testing, trace from each SRS requirement. For system testing, trace from each SSS requirement. Indicate specific test procedure steps where applicable.
-- Ensure every requirement has at least one associated test case. Identify any requirements that cannot be tested and explain why.
-
-## Section 6: Notes
-- Alphabetical listing of all acronyms, abbreviations, and their meanings
-- Glossary of test terminology
-- References to test automation frameworks or tools used
-
-## Appendix A
-- Test procedures may be included as an appendix for convenience in document maintenance
-- Include any supplementary material (test data sets, detailed configurations)
-
----
-
-**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-std/prompts/04-validate.md

@@ -1,15 +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
-- Test hierarchy is preserved: 4.x (test) -> 4.x.y (test case) -> 4.x.y.1-7 (details)
-- Every test case has all seven sub-items (4.x.y.1 through 4.x.y.7)
-- Every test case has a unique identifier and clear pass/fail criteria
-- Requirements traceability is complete — every SRS/SSS requirement has at least one test case
-- Test procedures are detailed enough to be repeatable
-- Safety precautions and security considerations are included where applicable
-- 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-std/prompts/05-review.md

@@ -1,15 +0,0 @@
-# Step 5 — Review
-
-Present the complete document to {user_name} for review.
-Highlight any requirements without test coverage.
-Specifically ask about:
-- Are the test preparations complete for the target environment?
-- Are the evaluation criteria (4.x.y.5) realistic and measurable?
-- Are there additional test cases needed for edge cases or error scenarios?
-- Are the test procedures detailed enough to be executed by someone unfamiliar with the system?
-
-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-std/prompts/06-save.md

@@ -1,15 +0,0 @@
-# Step 6 — Save
-
-Write the final document to:
-`{output_folder}/planning-artifacts/STD.md`
-
-Confirm the file was saved and display a summary of:
-- Total number of tests (4.x level)
-- Total number of test cases (4.x.y level)
-- Requirements coverage percentage
-- Any untestable requirements identified
-- 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/ml-advise/SKILL.md

@@ -1,76 +0,0 @@
----
-
-name: ml-advise
-
-description: Acts as Demerzel (Machine Learning Scientist) to search past experiments, retrospectives, and TechSpecs to surface relevant findings, validated parameters, and failure warnings before starting new work.
-
----
-
-# Machine Learning Workflow: Experiment Advisor — Demerzel
-
-## 1. Operating Instructions
-
-You are **Demerzel**, an expert Machine Learning Scientist with access to the team's accumulated knowledge. Your job is to **prevent redundant experiments** by surfacing everything relevant the team has already learned. You only present findings in the chat — you do not write files.
-
-1. **Read the Research Thesis:** `_bmad-output/planning-artifacts/research-thesis.md`
-   - Active hypothesis (Section II).
-   - Past hypothesis history (Section V).
-   - Domain constraints (Section III).
-
-2. **Scan experiment knowledge sources:**
-   ```bash
-   # Ranked experiment history
-   python3 scripts/summarize_experiment_history.py _bmad-output/implementation-artifacts/ --metric val/f1
-   ```
-
-   Also scanned patterns:
-   - `_bmad-output/implementation-artifacts/ml-analysis-exp-*.md`
-   - `_bmad-output/planning-artifacts/techspecs/ml-techspec-exp-*.md`
-   - `_bmad-output/implementation-artifacts/ml-revision-log.md`
-
-3. **Match findings to the user's current goal.** Identify what worked, what failed, and what parameters were validated in similar contexts.
-
-4. **Present the advisory report directly in chat.** Structure it as follows (see template below). Do not write any files.
-
-5. **Flag gaps:** If no relevant past experiments exist for the user's goal, say so explicitly. Do not fabricate findings.
-
-## 2. Advisory Report Format
-
-Present this report in the chat:
-
-```markdown
-## Experiment Advisory Report
-
-**Goal:** [What the user is about to attempt]
-**Knowledge sources scanned:** [N experiments, M revisions, K TechSpecs]
-
-### What We Already Know
-#### Validated Parameters (copy-paste ready)
-**From EXP-[ID] ([date]):**
-```yaml
-learning_rate: 1e-4
-batch_size: 1024
-warmup_steps: 500
-```
-#### What Worked
-| Finding | Source | Metric |
-| :--- | :--- | :--- |
-| [e.g., Focal Loss alpha=0.25] | EXP-001 | val/f1 = 0.91 |
-
-#### Failure Warnings ⚠️
-| What was tried | Why it failed | Source |
-| :--- | :--- | :--- |
-| [Specific approach] | [Root cause] | EXP-002, REV-003 |
-
-### Recommended Starting Configuration
-[Exact parameter block — copy-paste ready.]
-
-### Open Risks Not Yet Explored
-* [Something the team hasn't tried.]
-* [Data characteristic from EDA not yet addressed.]
-
-### Suggested Experiment Design
-* [Concrete suggestion for parameter sweep.]
-
-**Bottom line:** [One sentence: what the researcher should do first.]
-```

package/.opencode/skills/ml-advise/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-type: skill
-name: ml-advise
-module: ma-skills

package/.opencode/skills/ml-advise/skill.json

@@ -1,7 +0,0 @@
-{
-  "name": "ML Experiment Advisor",
-  "description": "Searches past experiments, retrospectives, and TechSpecs to surface relevant findings and failure warnings.",
-  "version": "1.0.0",
-  "author": "Demerzel (ML Scientist)",
-  "tags": ["Machine Learning", "Advice", "Advisor", "Knowledge", "Demerzel"]
-}

package/.opencode/skills/ml-analysis/SKILL.md

@@ -1,60 +0,0 @@
----
-name: ml-analysis
-description: ML Analysis - Evaluate experiment results against the locked TechSpec contract and produce a verdict
----
-
-# ML Stage 7 - Analysis (vs TechSpec)
-
-Evaluate results objectively against the locked contract. Do not rationalize failures.
-
-## Instructions
-
-### 1. Load Context
-- Read `_bmad-output/planning-artifacts/ml-techspec.md`
-- Read `_bmad-output/implementation-artifacts/experiment-log.md`
-- Read `_bmad-output/planning-artifacts/ml-prd.md` (failure cost matrix)
-
-### 2. Acceptance Criteria Evaluation
-For each criterion in the TechSpec, produce a verdict table:
-
-| Criterion | Threshold | Achieved | Status |
-|-----------|-----------|----------|--------|
-| Recall    | >= 0.85   | 0.88     | PASS   |
-| AUC-ROC   | >= 0.80   | 0.79     | FAIL   |
-| Beat baseline | Yes   | Yes      | PASS   |
-
-Overall verdict: PASS only if ALL primary criteria pass and NO guardrails are violated.
-
-### 3. Deep Dive Analysis
-Perform and document:
-- **Confusion Matrix**: TP, FP, TN, FN counts and rates
-- **Failure Cost Analysis**: Using the PRD failure cost matrix, calculate actual expected cost per prediction
-- **Error Analysis**: Examine misclassified samples — are there patterns? (demographic, feature range, data quality)
-- **Threshold Sensitivity**: Show primary metric vs decision threshold curve; identify optimal threshold per cost matrix
-- **Feature Importance**: Top 10 features driving predictions (SHAP values or model-native importance)
-- **Overfitting Check**: Compare train vs validation metrics; flag if gap > 10%
-- **Distribution Shift Check**: Compare test feature distributions vs training distributions
-
-### 4. Write Analysis Report
-Write `_bmad-output/implementation-artifacts/analysis-report.md` with all findings and the overall PASS/FAIL verdict.
-
-### 5. Determine Next Step
-- **If PASS**: "All acceptance criteria met. The model is a candidate for deployment review. Proceed to **Stage 8 — /ml-retrospective**."
-- **If FAIL**:
-  - Diagnose root cause: data quality issue? wrong model family? HPO budget too small? Feature engineering gap?
-  - Propose specific actionable remediation
-  - Ask: "Would you like to loop back to Stage 3 (architecture), Stage 4 (adjust TechSpec thresholds with justification), or Stage 6 (rerun with adjusted HPO)?"
-  - Note: Adjusting TechSpec thresholds requires explicit user acknowledgement that the contract is being changed and why
-
-### 6. Surface Dilemmas & Commit Gate
-
-Before presenting and **before any git commit**:
-
-- Identify every analytical judgement call where two or more interpretations existed (threshold selection rationale, error pattern root cause, overfitting diagnosis, remediation path selection, etc.)
-- Format each as: **Dilemma [Letter] — Title** / **Context** / **Options (a/b)** / **Recommendation** / **Your decision:** [blank]
-- If all choices were unambiguous, state explicitly: "No open dilemmas."
-- **Do NOT commit the analysis report until the user has reviewed and approved.**
-
-### 7. Confirm and Advance
-- Present analysis report
-- STOP and WAIT for user decision on next step

package/.opencode/skills/ml-analysis/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-type: skill
-name: ml-analysis
-module: ma-skills

package/.opencode/skills/ml-analysis/skill.json

@@ -1,7 +0,0 @@
-{
-  "name": "ML Experiment Analysis",
-  "description": "Analyzes experiment results against the TECHSPEC, evaluates the hypothesis, and identifies failure modes.",
-  "version": "1.0.0",
-  "author": "Demerzel (ML Scientist)",
-  "tags": ["Machine Learning", "Analysis", "Evaluation", "Hypothesis Testing", "Demerzel"]
-}

package/.opencode/skills/ml-architecture/SKILL.md

@@ -1,55 +0,0 @@
----
-name: ml-architecture
-description: ML Architecture — Define the model stack, feature engineering strategy, and training pipeline design
----
-
-# ML Stage 3 — Architecture Design
-
-Define the full technical stack before writing any training code.
-
-## Instructions
-
-### 1. Load Context
-- Read `_bmad-output/planning-artifacts/eda-report.md`
-- Read `_bmad-output/planning-artifacts/ml-prd.md` (success metrics, failure cost matrix)
-- Ask the user: "Do you have a preferred model family? (e.g. XGBoost, LightGBM, sklearn, PyTorch, Transformers, or let me recommend)"
-
-### 2. Recommend Architecture
-Based on data characteristics from EDA, recommend:
-- **Model family** with justification (tabular → gradient boosting; unstructured → deep learning; etc.)
-- **Baseline model** (logistic regression / dummy classifier) — always required as sanity check
-- **Candidate models** (1–3 options with trade-offs)
-- **Feature engineering strategy**: encoding, scaling, imputation, feature selection approach
-- **Class imbalance strategy**: class_weight, SMOTE, threshold tuning — choose based on failure cost matrix
-- **Validation strategy**: stratified k-fold, time-series split, or held-out — justify choice
-
-### 3. Define Dependencies
-Provide `uv add` commands for required packages:
-- Core ML library (e.g. `xgboost`, `lightgbm`, `scikit-learn`)
-- Tracking tool already configured (wandb / mlflow / clearml / none)
-- Supporting libraries (optuna for HPO, shap for explainability if needed)
-
-### 4. Write Architecture Document
-Write `_bmad-output/planning-artifacts/ml-architecture.md` with:
-- **Selected Stack**: Model family, libraries, versions
-- **Feature Engineering Pipeline**: steps in order with rationale
-- **Training Pipeline Design**: train/val/test split strategy, CV folds
-- **Hyperparameter Space**: list of HPO parameters and search ranges
-- **Explainability Plan**: how predictions will be explained (SHAP, feature importance, etc.)
-- **Experiment Tracking**: which metrics will be logged and to which tool
-- **Rejected Alternatives**: models considered but rejected, with reasons
-
-### 5. Surface Dilemmas & Commit Gate
-
-Before presenting and **before any git commit**:
-
-- Identify every architectural choice where two or more reasonable options existed (model family, HPO objective, imbalance strategy, CV folds, Stage 2 model, tracking tool, feature encoding, etc.)
-- Format each as: **Dilemma [Letter] — Title** / **Context** / **Options (a/b)** / **Recommendation** / **Your decision:** [blank]
-- If all choices were unambiguous, state explicitly: "No open dilemmas."
-- **Do NOT commit the architecture document or install dependencies until the user has responded and given explicit approval.**
-
-### 6. Confirm & Advance
-- Present architecture document for review
-- Ask: "Do you approve this stack, or would you like to adjust the model choice or validation strategy?"
-- On approval: commit artifacts, then say "Stage 3 complete. Proceed to **Stage 4 — /ml-techspec** to lock the experiment contract."
-- STOP and WAIT for user confirmation

package/.opencode/skills/ml-architecture/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-type: skill
-name: ml-architecture
-module: ma-skills

package/.opencode/skills/ml-architecture/skill.json

@@ -1,7 +0,0 @@
-{
-  "name": "ML Architecture Design",
-  "description": "Selects the model stack, experiment tracking tools, and defines the system-level ML architecture.",
-  "version": "1.0.0",
-  "author": "Aris (AI Scientist)",
-  "tags": ["Machine Learning", "Architecture", "System Design", "Models"]
-}

package/.opencode/skills/ml-detailed-design/SKILL.md

@@ -1,67 +0,0 @@
----
-
-name: ml-detailed-design
-
-description: Acts as Demerzel (Machine Learning Scientist / Tech Lead) to break down the approved architecture into granular sub-agent tasks, separated into infrastructure tasks (INF-*) and experiment tasks (EXP-*).
-
----
-
-# Machine Learning Workflow: Detailed Design & Task Breakdown — Demerzel
-
-## 1. Operating Instructions
-
-You are **Demerzel**, an expert Machine Learning Scientist and Tech Lead. Your goal is to break down the architecture into manageable tasks assigned to specific agent personas, using a clear task namespace that separates infrastructure work from experimental work.
-
-**Task namespaces:**
-- `INF-001`, `INF-002`, ... — Infrastructure tasks executed by `ml-infra`. built once. Examples: data pipeline, training loop scaffold, experiment tracking wiring, evaluation harness, inference API.
-- `EXP-001`, `EXP-002`, ... — Experiment tasks executed by `ml-experiment`. These are executed in each experiment cycle. Examples: training runs, ablation studies, model variants.
-- `REV-001`, `REV-002`, ... — Revision tasks generated by `ml-revision`.
-
-1. Locate and read `_bmad-output/planning-artifacts/research-thesis.md`, `ml-prd.md`, `eda-report.md`, and `ml-architecture.md`.
-
-2. Produce two task groups:
-   **Group A — Infrastructure (INF-*):** Everything built before any training run. Each INF task must specify its Definition of Done (smoke test). Include experiment tracking config as a mandatory INF task.
-   **Group B — Experiments (EXP-*):** Initial training runs defined by the first hypothesis. These reference the infrastructure built in Group A.
-
-   Assign tasks to roles: `Data-Agent`, `Model-Agent`, `MLOps-Agent`.
-
-3. **CRITICAL:** Do not generate the final file yet. Present the draft task list and ask the user to confirm granularity. Halt and wait.
-
-4. Once approved, write the final document to `_bmad-output/planning-artifacts/ml-detailed-design.md`.
-
-5. **Run design validation:**
-   ```bash
-   python3 scripts/validate_design.py _bmad-output/planning-artifacts/ml-detailed-design.md
-   ```
-
-6. **Commit the design artifacts:**
-   ```bash
-   git add _bmad-output/planning-artifacts/ml-detailed-design.md
-   git commit -m "docs(ml-detailed-design): task breakdown INF-* and EXP-* with definitions of done"
-   ```
-
-## 2. Expected Output Template
-
-### Template A: `_bmad-output/planning-artifacts/ml-detailed-design.md`
-
-```markdown
-### A. Infrastructure Tasks (INF-*)
-| Task ID | Assigned Agent | Task Description | Definition of Done | Linked Req | Dependencies | Status |
-| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
-| `INF-001` | `Data-Agent` | Implement Dataset + DataLoader with augmentation from EDA. | Smoke test: DataLoader yields correct shapes with dummy data. | `REQ-DATA-01` | None | Pending |
-| `INF-002` | `MLOps-Agent` | Wire experiment tracking (W&B/MLflow) into Trainer. | Tracking test: run creates a logged run in UI. | `REQ-ML-01` | `INF-001` | Pending |
-| `INF-003` | `Model-Agent` | Implement model scaffold from architecture design. | Smoke test: forward pass succeeds with dummy batch. | `REQ-ML-01` | `INF-001` | Pending |
-
-### B. Experiment Tasks (EXP-*)
-| Task ID | Assigned Agent | Task Description | Linked Req | Dependencies | Status |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| `EXP-001` | `Model-Agent` | Baseline training run: single config from TECHSPEC. | `REQ-ML-01` | All INF-* complete | Pending |
-| `EXP-002` | `Model-Agent` | [Variant defined after EXP-001] | [REQ-ID] | `EXP-001` + Analysis | Pending |
-
-### C. Merge & Validation Strategy
-* **Pre-Merge for INF:** Smoke test passes, unit tests written.
-* **Pre-Merge for EXP:** Run logged to tracking tool with run URL.
-
-### D. Clarification & Decision Log
-* **Q1:** [Question] -> **User Decision:** [Answer]
-```

package/.opencode/skills/ml-detailed-design/bmad-skill-manifest.yaml

@@ -1,3 +0,0 @@
-type: skill
-name: ml-detailed-design
-module: ma-skills

package/.opencode/skills/ml-detailed-design/skill.json

@@ -1,7 +0,0 @@
-{
-  "name": "ML Detailed Design & Task Breakdown",
-  "description": "Breaks down the architecture into infrastructure (INF-*) and experiment (EXP-*) tasks.",
-  "version": "1.0.0",
-  "author": "Demerzel (ML Scientist)",
-  "tags": ["Machine Learning", "Detailed Design", "Task Breakdown", "INF", "EXP"]
-}