mumucc 0.4.4 → 0.4.10

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/parallel-debugging/references/hypothesis-testing.md

@@ -0,0 +1,120 @@
+# Hypothesis Testing Reference
+
+Task templates, evidence formats, and arbitration decision trees for parallel debugging.
+
+## Hypothesis Task Template
+
+```markdown
+## Hypothesis Investigation: {Hypothesis Title}
+
+### Hypothesis Statement
+
+{Clear, falsifiable statement about the root cause}
+
+### Failure Mode Category
+
+{Logic Error | Data Issue | State Problem | Integration Failure | Resource Issue | Environment}
+
+### Investigation Scope
+
+- Files to examine: {file list or directory}
+- Related tests: {test files}
+- Git history: {relevant date range or commits}
+
+### Evidence Criteria
+
+**Confirming evidence** (if I find these, hypothesis is supported):
+
+1. {Observable condition 1}
+2. {Observable condition 2}
+
+**Falsifying evidence** (if I find these, hypothesis is wrong):
+
+1. {Observable condition 1}
+2. {Observable condition 2}
+
+### Report Format
+
+- Confidence: High/Medium/Low
+- Evidence: list with file:line citations
+- Causal chain: step-by-step from cause to symptom
+- Recommended fix: if confirmed
+```
+
+## Evidence Report Template
+
+```markdown
+## Investigation Report: {Hypothesis Title}
+
+### Verdict: {Confirmed | Falsified | Inconclusive}
+
+### Confidence: {High (>80%) | Medium (50-80%) | Low (<50%)}
+
+### Confirming Evidence
+
+1. `src/api/users.ts:47` — {description of what was found}
+2. `src/middleware/auth.ts:23` — {description}
+
+### Contradicting Evidence
+
+1. `tests/api/users.test.ts:112` — {description of what contradicts}
+
+### Causal Chain (if confirmed)
+
+1. {First cause} →
+2. {Intermediate effect} →
+3. {Observable symptom}
+
+### Recommended Fix
+
+{Specific code change with location}
+
+### Additional Notes
+
+{Anything discovered that may be relevant to other hypotheses}
+```
+
+## Arbitration Decision Tree
+
+```
+All investigators reported?
+├── NO → Wait for remaining reports
+└── YES → Count confirmed hypotheses
+          ├── 0 confirmed
+          │   ├── Any medium confidence? → Investigate further
+          │   └── All low/falsified? → Generate new hypotheses
+          ├── 1 confirmed
+          │   └── High confidence?
+          │       ├── YES → Declare root cause, propose fix
+          │       └── NO → Flag as likely cause, recommend verification
+          └── 2+ confirmed
+              └── Are they related?
+                  ├── YES → Compound issue (multiple contributing causes)
+                  └── NO → Rank by confidence, declare highest as primary
+```
+
+## Common Hypothesis Patterns by Error Type
+
+### "500 Internal Server Error"
+
+1. Unhandled exception in request handler (Logic Error)
+2. Database connection failure (Resource Issue)
+3. Missing environment variable (Environment)
+
+### "Race condition / intermittent failure"
+
+1. Shared state mutation without locking (State Problem)
+2. Async operation ordering assumption (Logic Error)
+3. Cache staleness window (State Problem)
+
+### "Works locally, fails in production"
+
+1. Environment variable mismatch (Environment)
+2. Different dependency version (Environment)
+3. Resource limits (memory, connections) (Resource Issue)
+
+### "Regression after deploy"
+
+1. New code introduced bug (Logic Error)
+2. Configuration change (Integration Failure)
+3. Database migration issue (Data Issue)

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/parallel-feature-development/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: parallel-feature-development
+description: Coordinate parallel feature development with file ownership strategies, conflict avoidance rules, and integration patterns for multi-agent implementation. Use this skill when decomposing a large feature into independent work streams, when two or more agents need to implement different layers of the same system simultaneously, when establishing file ownership to prevent merge conflicts in a shared codebase, when designing interface contracts so parallel implementers can build against each other's APIs before they are ready, or when deciding whether to use vertical slices versus horizontal layers for a full-stack feature.
+version: 1.0.2
+---
+
+# Parallel Feature Development
+
+Strategies for decomposing features into parallel work streams, establishing file ownership boundaries, avoiding conflicts, and integrating results from multiple implementer agents.
+
+## When to Use This Skill
+
+- Decomposing a feature for parallel implementation
+- Establishing file ownership boundaries between agents
+- Designing interface contracts between parallel work streams
+- Choosing integration strategies (vertical slice vs horizontal layer)
+- Managing branch and merge workflows for parallel development
+
+## File Ownership Strategies
+
+### By Directory
+
+Assign each implementer ownership of specific directories:
+
+```
+implementer-1: src/components/auth/
+implementer-2: src/api/auth/
+implementer-3: tests/auth/
+```
+
+**Best for**: Well-organized codebases with clear directory boundaries.
+
+### By Module
+
+Assign ownership of logical modules (which may span directories):
+
+```
+implementer-1: Authentication module (login, register, logout)
+implementer-2: Authorization module (roles, permissions, guards)
+```
+
+**Best for**: Feature-oriented architectures, domain-driven design.
+
+### By Layer
+
+Assign ownership of architectural layers:
+
+```
+implementer-1: UI layer (components, styles, layouts)
+implementer-2: Business logic layer (services, validators)
+implementer-3: Data layer (models, repositories, migrations)
+```
+
+**Best for**: Traditional MVC/layered architectures.
+
+## Conflict Avoidance Rules
+
+### The Cardinal Rule
+
+**One owner per file.** No file should be assigned to multiple implementers.
+
+### When Files Must Be Shared
+
+If a file genuinely needs changes from multiple implementers:
+
+1. **Designate a single owner** — One implementer owns the file
+2. **Other implementers request changes** — Message the owner with specific change requests
+3. **Owner applies changes sequentially** — Prevents merge conflicts
+4. **Alternative: Extract interfaces** — Create a separate interface file that the non-owner can import without modifying
+
+### Interface Contracts
+
+When implementers need to coordinate at boundaries:
+
+```typescript
+// src/types/auth-contract.ts (owned by team-lead, read-only for implementers)
+export interface AuthResponse {
+  token: string;
+  user: UserProfile;
+  expiresAt: number;
+}
+
+export interface AuthService {
+  login(email: string, password: string): Promise<AuthResponse>;
+  register(data: RegisterData): Promise<AuthResponse>;
+}
+```
+
+Both implementers import from the contract file but neither modifies it.
+
+## Integration Patterns
+
+### Vertical Slice
+
+Each implementer builds a complete feature slice (UI + API + tests):
+
+```
+implementer-1: Login feature (login form + login API + login tests)
+implementer-2: Register feature (register form + register API + register tests)
+```
+
+**Pros**: Each slice is independently testable, minimal integration needed.
+**Cons**: May duplicate shared utilities, harder with tightly coupled features.
+
+### Horizontal Layer
+
+Each implementer builds one layer across all features:
+
+```
+implementer-1: All UI components (login form, register form, profile page)
+implementer-2: All API endpoints (login, register, profile)
+implementer-3: All tests (unit, integration, e2e)
+```
+
+**Pros**: Consistent patterns within each layer, natural specialization.
+**Cons**: More integration points, layer 3 depends on layers 1 and 2.
+
+### Hybrid
+
+Mix vertical and horizontal based on coupling:
+
+```
+implementer-1: Login feature (vertical slice — UI + API + tests)
+implementer-2: Shared auth infrastructure (horizontal — middleware, JWT utils, types)
+```
+
+**Best for**: Most real-world features with some shared infrastructure.
+
+## Branch Management
+
+### Single Branch Strategy
+
+All implementers work on the same feature branch:
+
+- Simple setup, no merge overhead
+- Requires strict file ownership to avoid conflicts
+- Best for: small teams (2-3), well-defined boundaries
+
+### Multi-Branch Strategy
+
+Each implementer works on a sub-branch:
+
+```
+feature/auth
+  ├── feature/auth-login      (implementer-1)
+  ├── feature/auth-register    (implementer-2)
+  └── feature/auth-tests       (implementer-3)
+```
+
+- More isolation, explicit merge points
+- Higher overhead, merge conflicts still possible in shared files
+- Best for: larger teams (4+), complex features
+
+## Troubleshooting
+
+**Implementers are blocking each other waiting for shared code.**
+Extract the shared piece into its own interface contract file owned by the team-lead and have implementers import from it. Neither implementer modifies the contract — they only implement against it.
+
+**Merge conflicts appear even with clear ownership rules.**
+A file was assigned to two agents, or a config/index file (e.g., `index.ts`, `__init__.py`) that auto-imports everything was modified by both. Designate one owner for all barrel/index files, or have the lead merge them at the end.
+
+**An implementer finishes early but the integration step is blocked.**
+Use a staging interface: the finished implementer writes a stub or mock of the downstream dependency so the other implementer can continue working. Replace with the real implementation at integration time.
+
+**The feature decomposition turned out wrong mid-stream.**
+Stop new work, have the lead redistribute files, and communicate the change via broadcast. Sunk cost on partially written code is acceptable — continuing with the wrong split is worse.
+
+**Tests written by one implementer fail against code written by another.**
+Interface contracts drifted: the implementer who owns the API changed a signature without notifying the test implementer. Enforce the rule that contract files require a broadcast before modification.
+
+## Related Skills
+
+- [team-composition-patterns](../team-composition-patterns/SKILL.md) — Choose the right team size and agent types before decomposing work
+- [team-communication-protocols](../team-communication-protocols/SKILL.md) — Coordinate integration handoffs and plan approvals between implementers

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/parallel-feature-development/references/file-ownership.md

@@ -0,0 +1,80 @@
+# File Ownership Decision Framework
+
+How to assign file ownership when decomposing features for parallel development.
+
+## Ownership Decision Process
+
+### Step 1: Map All Files
+
+List every file that needs to be created or modified for the feature.
+
+### Step 2: Identify Natural Clusters
+
+Group files by:
+
+- Directory proximity (files in the same directory)
+- Functional relationship (files that import each other)
+- Layer membership (all UI files, all API files)
+
+### Step 3: Assign Clusters to Owners
+
+Each cluster becomes one implementer's ownership boundary:
+
+- No file appears in multiple clusters
+- Each cluster is internally cohesive
+- Cross-cluster dependencies are minimized
+
+### Step 4: Define Interface Points
+
+Where clusters interact, define:
+
+- Shared type definitions (owned by lead or a designated implementer)
+- API contracts (function signatures, request/response shapes)
+- Event contracts (event names and payload shapes)
+
+## Ownership by Project Type
+
+### React/Next.js Frontend
+
+```
+implementer-1: src/components/{feature}/   (UI components)
+implementer-2: src/hooks/{feature}/        (custom hooks, state)
+implementer-3: src/api/{feature}/          (API client, types)
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Express/Fastify Backend
+
+```
+implementer-1: src/routes/{feature}.ts, src/controllers/{feature}.ts
+implementer-2: src/services/{feature}.ts, src/validators/{feature}.ts
+implementer-3: src/models/{feature}.ts, src/repositories/{feature}.ts
+shared:        src/types/{feature}.ts      (owned by lead)
+```
+
+### Full-Stack (Next.js)
+
+```
+implementer-1: app/{feature}/page.tsx, app/{feature}/components/
+implementer-2: app/api/{feature}/route.ts, lib/{feature}/
+implementer-3: tests/{feature}/
+shared:        types/{feature}.ts          (owned by lead)
+```
+
+### Python Django
+
+```
+implementer-1: {app}/views.py, {app}/urls.py, {app}/forms.py
+implementer-2: {app}/models.py, {app}/serializers.py, {app}/managers.py
+implementer-3: {app}/tests/
+shared:        {app}/types.py              (owned by lead)
+```
+
+## Conflict Resolution
+
+When two implementers need to modify the same file:
+
+1. **Preferred: Split the file** — Extract the shared concern into its own file
+2. **If can't split: Designate one owner** — The other implementer sends change requests
+3. **Last resort: Sequential access** — Implementer A finishes, then implementer B takes over
+4. **Never**: Let both modify the same file simultaneously

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/parallel-feature-development/references/merge-strategies.md

@@ -0,0 +1,75 @@
+# Integration and Merge Strategies
+
+Patterns for integrating parallel work streams and resolving conflicts.
+
+## Integration Patterns
+
+### Pattern 1: Direct Integration
+
+All implementers commit to the same branch; integration happens naturally.
+
+```
+feature/auth ← implementer-1 commits
+             ← implementer-2 commits
+             ← implementer-3 commits
+```
+
+**When to use**: Small teams (2-3), strict file ownership (no conflicts expected).
+
+### Pattern 2: Sub-Branch Integration
+
+Each implementer works on a sub-branch; lead merges them sequentially.
+
+```
+feature/auth
+  ├── feature/auth-login     ← implementer-1
+  ├── feature/auth-register  ← implementer-2
+  └── feature/auth-tests     ← implementer-3
+```
+
+Merge order: follow dependency graph (foundation → dependent → integration).
+
+**When to use**: Larger teams (4+), overlapping concerns, need for review gates.
+
+### Pattern 3: Trunk-Based with Feature Flags
+
+All implementers commit to the main branch behind a feature flag.
+
+```
+main ← all implementers commit
+     ← feature flag gates new code
+```
+
+**When to use**: CI/CD environments, short-lived features, continuous deployment.
+
+## Integration Verification Checklist
+
+After all implementers complete:
+
+1. **Build check**: Does the code compile/bundle without errors?
+2. **Type check**: Do TypeScript/type annotations pass?
+3. **Lint check**: Does the code pass linting rules?
+4. **Unit tests**: Do all unit tests pass?
+5. **Integration tests**: Do cross-component tests pass?
+6. **Interface verification**: Do all interface contracts match their implementations?
+
+## Conflict Resolution
+
+### Prevention (Best)
+
+- Strict file ownership eliminates most conflicts
+- Interface contracts define boundaries before implementation
+- Shared type files are owned by the lead and modified sequentially
+
+### Detection
+
+- Git merge will report conflicts if they occur
+- TypeScript/lint errors indicate interface mismatches
+- Test failures indicate behavioral conflicts
+
+### Resolution Strategies
+
+1. **Contract wins**: If code doesn't match the interface contract, the code is wrong
+2. **Lead arbitrates**: The team lead decides which implementation to keep
+3. **Tests decide**: The implementation that passes tests is correct
+4. **Merge manually**: For complex conflicts, the lead merges by hand

package/defaults/plugin-seed/marketplaces/claude-code-workflows/plugins/agent-teams/skills/task-coordination-strategies/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: task-coordination-strategies
+description: Decompose complex tasks, design dependency graphs, and coordinate multi-agent work with proper task descriptions and workload balancing. Use this skill when breaking down work for agent teams, managing task dependencies, or monitoring team progress.
+version: 1.0.2
+---
+
+# Task Coordination Strategies
+
+Strategies for decomposing complex tasks into parallelizable units, designing dependency graphs, writing effective task descriptions, and monitoring workload across agent teams.
+
+## When to Use This Skill
+
+- Breaking down a complex task for parallel execution
+- Designing task dependency relationships (blockedBy/blocks)
+- Writing task descriptions with clear acceptance criteria
+- Monitoring and rebalancing workload across teammates
+- Identifying the critical path in a multi-task workflow
+
+## Task Decomposition Strategies
+
+### By Layer
+
+Split work by architectural layer:
+
+- Frontend components
+- Backend API endpoints
+- Database migrations/models
+- Test suites
+
+**Best for**: Full-stack features, vertical slices
+
+### By Component
+
+Split work by functional component:
+
+- Authentication module
+- User profile module
+- Notification module
+
+**Best for**: Microservices, modular architectures
+
+### By Concern
+
+Split work by cross-cutting concern:
+
+- Security review
+- Performance review
+- Architecture review
+
+**Best for**: Code reviews, audits
+
+### By File Ownership
+
+Split work by file/directory boundaries:
+
+- `src/components/` — Implementer 1
+- `src/api/` — Implementer 2
+- `src/utils/` — Implementer 3
+
+**Best for**: Parallel implementation, conflict avoidance
+
+## Dependency Graph Design
+
+### Principles
+
+1. **Minimize chain depth** — Prefer wide, shallow graphs over deep chains
+2. **Identify the critical path** — The longest chain determines minimum completion time
+3. **Use blockedBy sparingly** — Only add dependencies that are truly required
+4. **Avoid circular dependencies** — Task A blocks B blocks A is a deadlock
+
+### Patterns
+
+**Independent (Best parallelism)**:
+
+```
+Task A ─┐
+Task B ─┼─→ Integration
+Task C ─┘
+```
+
+**Sequential (Necessary dependencies)**:
+
+```
+Task A → Task B → Task C
+```
+
+**Diamond (Mixed)**:
+
+```
+        ┌→ Task B ─┐
+Task A ─┤          ├→ Task D
+        └→ Task C ─┘
+```
+
+### Using blockedBy/blocks
+
+```
+TaskCreate: { subject: "Build API endpoints" }         → Task #1
+TaskCreate: { subject: "Build frontend components" }    → Task #2
+TaskCreate: { subject: "Integration testing" }          → Task #3
+TaskUpdate: { taskId: "3", addBlockedBy: ["1", "2"] }  → #3 waits for #1 and #2
+```
+
+## Task Description Best Practices
+
+Every task should include:
+
+1. **Objective** — What needs to be accomplished (1-2 sentences)
+2. **Owned Files** — Explicit list of files/directories this teammate may modify
+3. **Requirements** — Specific deliverables or behaviors expected
+4. **Interface Contracts** — How this work connects to other teammates' work
+5. **Acceptance Criteria** — How to verify the task is done correctly
+6. **Scope Boundaries** — What is explicitly out of scope
+
+### Template
+
+```
+## Objective
+Build the user authentication API endpoints.
+
+## Owned Files
+- src/api/auth.ts
+- src/api/middleware/auth-middleware.ts
+- src/types/auth.ts (shared — read only, do not modify)
+
+## Requirements
+- POST /api/login — accepts email/password, returns JWT
+- POST /api/register — creates new user, returns JWT
+- GET /api/me — returns current user profile (requires auth)
+
+## Interface Contract
+- Import User type from src/types/auth.ts (owned by implementer-1)
+- Export AuthResponse type for frontend consumption
+
+## Acceptance Criteria
+- All endpoints return proper HTTP status codes
+- JWT tokens expire after 24 hours
+- Passwords are hashed with bcrypt
+
+## Out of Scope
+- OAuth/social login
+- Password reset flow
+- Rate limiting
+```
+
+## Workload Monitoring
+
+### Indicators of Imbalance
+
+| Signal                     | Meaning             | Action                      |
+| -------------------------- | ------------------- | --------------------------- |
+| Teammate idle, others busy | Uneven distribution | Reassign pending tasks      |
+| Teammate stuck on one task | Possible blocker    | Check in, offer help        |
+| All tasks blocked          | Dependency issue    | Resolve critical path first |
+| One teammate has 3x others | Overloaded          | Split tasks or reassign     |
+
+### Rebalancing Steps
+
+1. Call `TaskList` to assess current state
+2. Identify idle or overloaded teammates
+3. Use `TaskUpdate` to reassign tasks
+4. Use `SendMessage` to notify affected teammates
+5. Monitor for improved throughput