opencode-mad 0.4.1 → 1.0.1

package/skills/mad-workflow/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mad-workflow
-description: Multi-Agent Dev workflow for parallel development with git worktrees and subagents
+description: Multi-Agent Dev workflow for parallel development with git worktrees and specialized agents
 license: MIT
 compatibility: opencode
 metadata:
@@ -10,129 +10,96 @@ metadata:
 
 # MAD Workflow
 
-MAD (Multi-Agent Dev) enables parallel software development by decomposing tasks into independent subtasks, each running in isolated git worktrees with dedicated subagents.
+MAD (Multi-Agent Dev) enables parallel software development by decomposing tasks into independent subtasks, each running in isolated git worktrees with dedicated specialized agents.
 
-## Core Concepts
+## Architecture
 
-### Worktrees
-Git worktrees provide isolated working directories, each on its own branch. This allows multiple tasks to be developed simultaneously without conflicts.
-
-### Subagents
-- **mad-developer**: Implements a single focused task in a worktree
-- **mad-fixer**: Resolves build errors, test failures, and conflicts
-
-### Signal Files
-- `.agent-task`: Task description (created by orchestrator)
-- `.agent-done`: Completion marker with summary
-- `.agent-blocked`: Block marker with reason
-- `.agent-error`: Error details from failed tests
-
-## Workflow Steps
+```
+USER REQUEST → ORCHESTRATOR → ANALYSTE → ARCHITECTE → Plan
+                    ↓
+    ┌───────────────┼───────────────┐
+    ↓               ↓               ↓
+DEVELOPER 1    DEVELOPER 2    DEVELOPER 3
+(worktree)     (worktree)     (worktree)
+    ↓               ↓               ↓
+    └───────────────┼───────────────┘
+                    ↓
+         TESTER / REVIEWER / SECURITY
+                    ↓
+              MERGER / FIXER (if needed)
+                    ↓
+              FINAL CHECK → PUSH
+```
 
-## CRITICAL: Parallel Execution is MANDATORY
+## Specialized Agents
 
-The entire purpose of MAD is to run tasks IN PARALLEL. 
+| Agent | Role |
+|-------|------|
+| **mad-analyste** | Understands codebase, finds patterns |
+| **mad-architecte** | Creates task breakdown, file ownership |
+| **mad-developer** | Writes code in isolated worktrees |
+| **mad-tester** | Runs tests, verifies functionality |
+| **mad-reviewer** | Checks quality, best practices |
+| **mad-security** | Audits for vulnerabilities |
+| **mad-fixer** | Fixes errors, test failures |
+| **mad-merger** | Resolves git merge conflicts |
 
-### ❌ WRONG - Sequential (defeats the purpose)
-```
-Message 1: mad_worktree_create(branch: "feat-a", ...)
-Message 2: mad_worktree_create(branch: "feat-b", ...)
-Message 3: Task(subagent_type: "mad-developer", ...) for feat-a
-Message 4: Task(subagent_type: "mad-developer", ...) for feat-b
-```
+## Signal Files
 
-### ✅ CORRECT - Parallel (the whole point!)
-```
-Single Message containing:
-  mad_worktree_create(branch: "feat-a", ...)
-  mad_worktree_create(branch: "feat-b", ...)
-  mad_worktree_create(branch: "feat-c", ...)
-
-Single Message containing:
-  Task(subagent_type: "mad-developer", ...) for feat-a
-  Task(subagent_type: "mad-developer", ...) for feat-b  
-  Task(subagent_type: "mad-developer", ...) for feat-c
-```
+- `.agent-task`: Task description
+- `.agent-done`: Completion marker
+- `.agent-blocked`: Block marker
+- `.agent-error`: Error details
 
-If you're not parallelizing, you're not using MAD correctly!
+## Workflow Phases
 
-### 1. Decomposition
-Analyze the request and identify parallelizable components:
-- Different modules/features
-- Independent files
-- Separable concerns
+1. **Analysis**: Analyste understands codebase
+2. **Planning**: Architecte creates plan with file ownership
+3. **Approval**: User validates plan ("GO")
+4. **Development**: Parallel developer spawning
+5. **QA**: Testers, Reviewers, Security in parallel
+6. **Resolution**: Fixer/Merger if issues
+7. **Finalization**: Merge, final check, push, cleanup
 
-### 2. Worktree Creation
-For each subtask:
-```
-mad_worktree_create(
-  branch: "feat/feature-name",
-  task: "Detailed task description"
-)
-```
+## CRITICAL: Parallel Execution
 
-### 3. Parallel Execution
-Spawn subagents simultaneously:
-```
-Task(subagent_type: "mad-developer", ...)
-Task(subagent_type: "mad-developer", ...)
-Task(subagent_type: "mad-developer", ...)
-```
+**The entire purpose of MAD is to run tasks IN PARALLEL.**
 
-### 4. Monitoring
-Check progress:
-```
-mad_status()
-```
+All independent operations MUST be in a single message:
+- Create all worktrees together
+- Spawn all developers together
+- Run all QA agents together
 
-### 5. Testing
-Verify each worktree:
-```
-mad_test(worktree: "feat-feature-name")
-```
+If you're not parallelizing, you're not using MAD correctly!
 
-### 6. Merging
-Merge completed work:
-```
-mad_merge(worktree: "feat-feature-name")
-```
+## File Ownership Rules
 
-> **Note:** `mad_merge` automatically uses `--no-ff` to preserve history. If you ever need to merge manually, always use `git merge --no-ff`.
+Each task MUST have exclusive ownership. Two agents must NEVER modify the same file.
 
-### 7. Cleanup
-Remove finished worktrees:
 ```
-mad_cleanup(worktree: "feat-feature-name")
+Task 1: OWNS /backend/**
+Task 2: OWNS /frontend/**
+Task 3: OWNS /package.json, /README.md
 ```
 
-### 8. Final Check
-Verify global project health:
-```
-mad_final_check()
-```
-This distinguishes session errors from pre-existing issues.
+## Silence Protocol
 
-### 9. Push & CI Watch
-Push to remote and monitor CI:
-```
-mad_push_and_watch()
-```
-This will:
-- Push changes to the remote
-- Detect if GitHub Actions CI exists
-- Watch CI progress in real-time with `gh run watch`
-- Report success or failure with logs
+**CRITICAL: Subagents MUST NOT output verbose commentary.**
 
-If CI fails, create a `fix-ci` worktree to fix the errors.
+### Rules for Subagents:
+1. **No status updates** - Don't say "I'm now going to..."
+2. **No explanations** - Don't explain what you're doing
+3. **No summaries** - Don't summarize at the end
+4. **Actions only** - Just execute tools and complete the task
+5. **Signal via tools** - Use `mad_done` or `mad_blocked` to communicate
 
-## Best Practices
+### Why?
+- Reduces token usage dramatically
+- Speeds up execution
+- Orchestrator monitors via `mad_status`, not agent output
 
-1. **Keep subtasks focused** - Each should be completable in one session
-2. **Name branches clearly** - `feat/`, `fix/`, `refactor/` prefixes
-3. **Test before merge** - Always run mad_test first
-4. **Handle blocks promptly** - Don't let blocked tasks linger
-5. **Merge sequentially** - Avoid merge conflict cascades
-6. **Always use `--no-ff` for merges** - Preserves feature history and enables easy reverts
+### Orchestrator Exception:
+The orchestrator MAY output status to keep the user informed, but should remain concise.
 
 ## Available Tools
 
@@ -140,22 +107,22 @@ If CI fails, create a `fix-ci` worktree to fix the errors.
 |------|---------|
 | `mad_worktree_create` | Create isolated branch |
 | `mad_status` | Dashboard of all worktrees |
+| `mad_visualize` | ASCII art visualization |
 | `mad_test` | Run tests on worktree |
-| `mad_merge` | Merge completed branch |
+| `mad_merge` | Merge completed branch (uses --no-ff) |
 | `mad_cleanup` | Remove worktree |
 | `mad_done` | Mark task complete |
 | `mad_blocked` | Mark task blocked |
 | `mad_read_task` | Read task description |
-| `mad_final_check` | Run global build/lint and categorize errors |
-| `mad_push_and_watch` | Push to remote and watch CI |
-
-## Example
+| `mad_register_agent` | Register agent permissions |
+| `mad_final_check` | Run global build/lint |
+| `mad_push_and_watch` | Push and watch CI |
 
-Request: "Add user authentication with login, signup, and password reset"
+## Best Practices
 
-1. Create 3 worktrees: `feat/auth-login`, `feat/auth-signup`, `feat/auth-reset`
-2. Spawn 3 developer subagents in parallel
-3. Monitor until all complete
-4. Test each, merge sequentially
-5. Cleanup worktrees
-6. Final integration test
+1. **Delegate everything** - Orchestrator never codes
+2. **Keep subtasks focused** - Completable in one session
+3. **Name branches clearly** - `feat/`, `fix/`, `refactor/`
+4. **Test before merge** - Always run QA first
+5. **Merge sequentially** - Avoid conflict cascades
+6. **Register permissions** - Before spawning developers