ma-agents 3.4.9 → 3.5.1

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

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

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

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

package/.opencode/skills/docker-hardening-verification/SKILL.md

@@ -1,28 +0,0 @@
----
-name: Docker Hardening Verification
-description: Audits Docker images for security best practices, least privilege, and OpenShift compliance.
----
-# Docker Hardening Verification
-
-## Purpose
-Audit Docker images to ensure they follow security best practices, specifically focusing on non-root execution and least privilege principles required for hardened clusters like OpenShift.
-
-## Instructions
-1.  **Inspect Image**: Use `docker inspect` or `podman inspect` to check metadata.
-2.  **Verify User**: 
-    - Ensure `USER` is defined and is NOT `root` or `0`.
-    - Recommended: Use a high-numbered UID (e.g., `1001`).
-3.  **Check Permissions**:
-    - Ensure sensitive directories are not world-writable.
-    - Check for `setuid`/`setgid` bits on binaries.
-4.  **OpenShift Compliance**:
-    - Verify that the image doesn't require specific UIDs if it's meant to run with an arbitrary assigned UID (OpenShift's default).
-    - Check if the `/etc/passwd` entry handles arbitrary UIDs (e.g., by using `nss_wrapper` or similar).
-
-## Rules
-- Fail the audit if `USER root` is detected.
-- Flag a warning if many unnecessary packages/tools are present.
-- Ensure only necessary ports are exposed.
-
-## Usage
-Run `scripts/verify-hardening.sh <image_name>`

package/.opencode/skills/docker-hardening-verification/scripts/verify-hardening.sh

@@ -1,39 +0,0 @@
-#!/bin/bash
-# verify-hardening.sh - Part of ma-agents docker-hardening-verification skill
-
-IMAGE=$1
-
-if [ -z "$IMAGE" ]; then
-    echo "Usage: $0 <image_name>"
-    exit 1
-fi
-
-echo "Auditing image: $IMAGE"
-
-# 1. Check User
-USER_VAL=$(docker inspect --format='{{.Config.User}}' "$IMAGE")
-
-if [ -z "$USER_VAL" ] || [ "$USER_VAL" == "root" ] || [ "$USER_VAL" == "0" ]; then
-    echo "[FAIL] Image runs as root! Definining a non-root USER is mandatory for hardened clusters."
-else
-    echo "[PASS] Image runs as user: $USER_VAL"
-fi
-
-# 2. Check for sensitive capabilities (simplified check)
-CAPS=$(docker inspect --format='{{.Config.CapAdd}}' "$IMAGE")
-if [ "$CAPS" != "<nil>" ] && [ -n "$CAPS" ]; then
-    echo "[WARNING] Image has explicitly added capabilities: $CAPS"
-fi
-
-# 3. Check for exposed ports
-PORTS=$(docker inspect --format='{{range $p, $conf := .Config.ExposedPorts}}{{$p}} {{end}}' "$IMAGE")
-echo "[INFO] Exposed ports: ${PORTS:-none}"
-
-# 4. OpenShift specific check (arbitrary UID support)
-# This is a heuristic check looking for common entrypoint patterns
-ENTRYPOINT=$(docker inspect --format='{{.Config.Entrypoint}}' "$IMAGE")
-if [[ "$ENTRYPOINT" == *"bash"* ]]; then
-    echo "[INFO] Entrypoint uses bash, manual check for UID mapping recommended."
-fi
-
-echo "Summary: Audit complete for $IMAGE"

package/.opencode/skills/docker-image-signing/SKILL.md

@@ -1,28 +0,0 @@
----
-name: Docker Image Signing
-description: Automates the signing of Docker images using certificates and Cosign/Notary.
----
-# Docker Image Signing
-
-## Purpose
-Ensure the integrity and authenticity of Docker images by signing them with a cryptographic key/certificate. This prevents unauthorized image substitution and ensures only trusted images are deployed.
-
-## Instructions
-1.  **Tool Selection**: Use `cosign` (recommended) or `notary`.
-2.  **Environment Check**: Verify that the signing tool and Docker/Podman are installed.
-3.  **Signing Process**:
-    - Load the provided certificate/key.
-    - Run the signing command against the target image (using its SHA256 digest for immutability).
-4.  **Verification**: Always run a verification check immediately after signing.
-
-## Rules
-- NEVER sign images by tag alone; use the immutable digest (e.g., `image@sha256:...`).
-- Private keys must be handled as secrets and never stored in the clear.
-- Ensure the certificate provided is valid and not expired.
-
-## Usage
-Run the provided script in `scripts/sign-image.sh` with:
-- `IMAGE`: The image reference with digest.
-- `CERT`: Path to the certificate file.
-- `KEY`: Path to the private key file.
-- `PASSPHRASE`: (Optional) Key passphrase.

package/.opencode/skills/docker-image-signing/scripts/sign-image.sh

@@ -1,33 +0,0 @@
-#!/bin/bash
-# sign-image.sh - Part of ma-agents docker-image-signing skill
-
-IMAGE=$1
-CERT=$2
-KEY=$3
-PASSPHRASE=$4
-
-if [ -z "$IMAGE" ] || [ -z "$CERT" ] || [ -z "$KEY" ]; then
-    echo "Usage: $0 <image_digest> <cert_file> <key_file> [passphrase]"
-    exit 1
-fi
-
-echo "Signing image: $IMAGE"
-
-# Check for cosign
-if command -v cosign &> /dev/null; then
-    echo "Using Cosign for signing..."
-    if [ -n "$PASSPHRASE" ]; then
-        export COSIGN_PASSWORD=$PASSPHRASE
-    fi
-    cosign sign --key "$KEY" --cert "$CERT" "$IMAGE"
-else
-    echo "Error: cosign not found. Please install cosign to use this skill."
-    exit 1
-fi
-
-if [ $? -eq 0 ]; then
-    echo "Successfully signed $IMAGE"
-else
-    echo "Failed to sign $IMAGE"
-    exit 1
-fi

package/.opencode/skills/document-revision-history/SKILL.md

@@ -1,104 +0,0 @@
----
-name: Document Revision History
-description: Manages a revision history table at the beginning of generated documents, tracking changes per version.
----
-# Document Revision History
-
-Manage a revision history table at the beginning of every generated or updated document. This ensures traceability of changes across document versions.
-
-## Policy
-
-### 1. Revision History Table Required
-
-Every document generated or updated by the agent MUST include a **Revision History** table immediately after the document title (before the Table of Contents or Section 1).
-
-### 2. Table Format
-
-Use the following markdown table format:
-
-```markdown
-| Version | Date | Author | Changes |
-|---------|------|--------|---------|
-| 1.0 | 2026-03-02 | Agent (Claude) | Initial document generation |
-```
-
-### 3. Column Definitions
-
-| Column | Description |
-|--------|-------------|
-| **Version** | Document version number (e.g., 1.0, 1.1, 2.0). Use semantic versioning: major version for structural changes, minor for content updates |
-| **Date** | Date of the change in `YYYY-MM-DD` format |
-| **Author** | Who made the change — use `Agent (<model>)` for AI-generated content, or the user's name for user-directed changes |
-| **Changes** | Brief summary of ALL changes made in this version. One line per version — consolidate multiple changes into a single descriptive entry |
-
-### 4. Rules for New Documents
-
-When **generating a new document** for the first time:
-- Add the revision history table immediately after the document title
-- Set version to `1.0`
-- Set date to today's date
-- Set author to `Agent (<model>)` where `<model>` is the AI model name
-- Set changes to `Initial document generation`
-
-### 5. Rules for Updated Documents
-
-When **updating an existing document**:
-- Read the existing revision history table
-- Determine the new version number:
-  - **Minor increment** (e.g., 1.0 → 1.1): Content updates, corrections, additions to existing sections
-  - **Major increment** (e.g., 1.1 → 2.0): Structural changes, section reorganization, significant rewrites
-- Add a **single new row** summarizing ALL changes made in this update session
-- Do NOT create multiple rows for changes made in the same session — consolidate them into one line
-- Preserve all previous revision history entries
-
-### 6. Changes Column Guidelines
-
-Write concise but descriptive change summaries:
-
-**Good examples:**
-- `Added Sections 7-8 (impacts, analysis), expanded interface requirements to cover categories a-g`
-- `Updated capability requirements based on user feedback, added 3 new interfaces`
-- `Fixed traceability matrix, corrected section numbering`
-
-**Bad examples:**
-- `Updated document` (too vague)
-- `Changed section 3.2.1 requirement SRS-CAP-001 description from X to Y, then changed 3.2.2...` (too granular — summarize)
-
-### 7. Placement
-
-The revision history table MUST appear in this order within the document:
-
-```markdown
-# Document Title
-
-| Version | Date | Author | Changes |
-|---------|------|--------|---------|
-| 1.0 | 2026-03-02 | Agent (Claude) | Initial document generation |
-
-> MIL-STD-498 or other document metadata...
-
-## Table of Contents (if applicable)
-
-## 1. Scope
-...
-```
-
-### 8. Multi-Author Sessions
-
-If the user provides their name or the changes are user-directed corrections:
-- Use the user's name as author
-- If both the agent and user contribute in the same session, use `{user_name} / Agent (<model>)`
-
-## Example
-
-A document updated twice would have:
-
-```markdown
-# Software Requirements Specification (SRS)
-
-| Version | Date | Author | Changes |
-|---------|------|--------|---------|
-| 1.0 | 2026-03-01 | Agent (Claude) | Initial document generation from SSDD and PRD artifacts |
-| 1.1 | 2026-03-02 | Joseph / Agent (Claude) | Added 4 interface requirements per user feedback, corrected capability traceability to SSDD |
-| 2.0 | 2026-03-15 | Agent (Claude) | Major rewrite: restructured CSCI decomposition after SSDD v2.0, updated all requirement IDs |
-```

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

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

package/.opencode/skills/git-workflow-skill/SKILL.md

@@ -1,194 +0,0 @@
----
-name: Git Workflow
-description: MANDATORY worktree-based workflow for ALL file-changing activities. Enforces isolated feature branches, conventional commits, and PR-based merging.
----
-# Mandatory Usage Policy (CRITICAL)
-
-**This skill is MANDATORY for all activities that modify tracked files in this repository.**
-
-1.  **Before starting ANY work** that changes source code, config files, or documentation: You MUST run `./scripts/start-feature.sh` (or the equivalent `git worktree add`) to create an isolated feature branch and worktree.
-2.  **During development**: You MUST perform all file-writing activities inside the newly created worktree directory.
-3.  **After completing work**: You MUST run `./scripts/finish-feature.sh` (or the equivalent rebase/push/PR/cleanup sequence) to integrate your changes and clean up the worktree.
-
-**Failure to follow this workflow is a violation of repository standards.**
-
----
-
-# Git Workflow (Worktree-Based)
-
-Multi-agent parallel development using git worktrees. Each agent gets an isolated working directory — no branch switching, no conflicts between agents.
-
-## Bundled Tools
-
-### Scripts (scripts/)
-| Script | Purpose |
-|--------|---------|
-| `start-feature.sh <type> <desc>` | Create worktree + feature branch from dev |
-| `finish-feature.sh [path]` | Rebase, push, create PR, remove worktree |
-| `validate-workflow.sh [--list]` | Check workflow compliance / list worktrees |
-| `install-hooks.sh` | Install git hooks to repo |
-
-### Git Hooks (hooks/)
-| Hook | Purpose |
-|------|---------|
-| `pre-commit` | Blocks commits on dev/main (shared across worktrees) |
-| `commit-msg` | Validates conventional commit format |
-| `prepare-commit-msg` | Adds commit message template |
-
-**Install hooks:** Run `scripts/install-hooks.sh` in target repository.
-
-### Requirements
-- Git (2.15+ for worktree support)
-- GitHub CLI (`gh`) - Required for automatic PR creation
-  ```bash
-  # macOS
-  brew install gh
-  # Windows
-  winget install --id GitHub.cli
-  # Linux
-  apt install gh
-
-  # Authenticate
-  gh auth login
-  ```
-
----
-
-## Mandatory Pre-Change Check
-
-Before making ANY change to repository files (that are not in .gitignore):
-
-1. Check if files to be changed are tracked:
-   ```bash
-   git check-ignore -v <file-path>
-   ```
-   If file is ignored → proceed without this workflow
-   If file is tracked → continue with steps below
-
-2. Verify `dev` branch exists:
-   ```bash
-   git fetch origin
-   git branch -a | grep -E '(^|\/)dev$'
-   ```
-3. If `dev` does not exist → **STOP and ask user** to create it or specify base branch
-
-## Multi-Agent Development Flow
-
-```
-Main repo (stays on dev) ─── always clean, never modified directly
-  │
-  ├── .worktrees/auth-system/     ← Agent 1: feature/auth-system
-  │     └── (isolated copy of repo, own branch, own changes)
-  │
-  ├── .worktrees/api-refactor/    ← Agent 2: bugfix/api-refactor
-  │     └── (isolated copy of repo, own branch, own changes)
-  │
-  └── .worktrees/update-docs/     ← Agent 3: chore/update-docs
-        └── (isolated copy of repo, own branch, own changes)
-
-Each worktree:
-  1. Has its own directory and branch
-  2. Shares git history with the main repo
-  3. Can commit, push, and create PRs independently
-  4. Gets cleaned up automatically after finish-feature.sh
-```
-
-### Starting Work
-
-**Using script (recommended):**
-```bash
-./scripts/start-feature.sh feature my-feature-name
-# Output: .worktrees/my-feature-name/ created
-cd .worktrees/my-feature-name/
-```
-
-**Manual:**
-```bash
-git worktree add .worktrees/<desc> -b feature/<desc> origin/dev
-cd .worktrees/<desc>
-```
-
-### Branch Naming
-
-| Type | Use Case |
-|------|----------|
-| `feature/<desc>` | New functionality |
-| `bugfix/<desc>` | Bug fixes |
-| `hotfix/<desc>` | Urgent production fixes |
-| `chore/<desc>` | Maintenance tasks |
-
-### Completing Work
-
-**Using script (recommended):**
-```bash
-# Run from inside the worktree
-./scripts/finish-feature.sh
-```
-
-This script will:
-1. Validate you're on a feature branch
-2. Validate commit messages (conventional commits)
-3. Rebase on latest `dev` branch
-4. Push the feature branch
-5. **Automatically create a PR to `dev`** (requires `gh` CLI)
-6. **Remove the worktree** (auto-cleanup)
-
-**Note:** If `gh` CLI is not installed, the script will skip PR creation. The branch will still be pushed.
-
-**Manual:**
-```bash
-# From inside the worktree
-git fetch origin dev
-git rebase origin/dev
-git push -u origin <branch-name>
-gh pr create --base dev --head <branch-name>
-
-# Clean up from main repo
-cd /path/to/main/repo
-git worktree remove .worktrees/<desc>
-```
-
-### Managing Worktrees
-
-```bash
-# List all active worktrees
-git worktree list
-# or
-./scripts/validate-workflow.sh --list
-
-# Remove a specific worktree
-git worktree remove .worktrees/<desc>
-
-# Clean up stale references
-git worktree prune
-
-# Validate workflow compliance
-./scripts/validate-workflow.sh
-```
-
-## Commit Format (Conventional Commits)
-
-```
-<type>(<scope>): <description>
-
-[optional body]
-```
-
-**Types:** `feat`, `fix`, `chore`, `docs`, `refactor`, `test`
-
-**Examples:**
-- `feat(auth): add OAuth2 flow support`
-- `fix(api): handle null response from endpoint`
-- `chore(deps): update Helm chart dependencies`
-- `docs(readme): add deployment instructions`
-
-## Critical Rules
-
-- **NEVER** modify tracked files without being in a worktree on a feature branch.
-- **NEVER** commit directly to `dev` or `main`.
-- **ALWAYS** check if a file is gitignored before applying this workflow.
-- **ALWAYS** create a worktree **BEFORE** calling any file-writing tools (write_to_file, replace_file_content, etc.).
-- **ALWAYS** rebase on `dev` before pushing.
-- **ALWAYS** use conventional commit format.
-- **ALWAYS** add `.worktrees/` to your `.gitignore`.
-- **ALWAYS** finish the workflow by creating a PR and removing the worktree once work is verified.