codingbuddy-rules 5.2.0 → 5.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.ai-rules/adapters/claude-code.md +104 -49
- package/.ai-rules/agent-stacks/api-development.json +17 -0
- package/.ai-rules/agent-stacks/data-pipeline.json +12 -0
- package/.ai-rules/agent-stacks/frontend-polish.json +17 -0
- package/.ai-rules/agent-stacks/full-stack.json +18 -0
- package/.ai-rules/agent-stacks/ml-infrastructure.json +17 -0
- package/.ai-rules/agent-stacks/security-audit.json +16 -0
- package/.ai-rules/agents/accessibility-specialist.json +1 -0
- package/.ai-rules/agents/act-mode.json +1 -0
- package/.ai-rules/agents/architecture-specialist.json +1 -0
- package/.ai-rules/agents/auto-mode.json +1 -0
- package/.ai-rules/agents/code-quality-specialist.json +1 -0
- package/.ai-rules/agents/code-reviewer.json +1 -0
- package/.ai-rules/agents/documentation-specialist.json +1 -0
- package/.ai-rules/agents/eval-mode.json +1 -0
- package/.ai-rules/agents/event-architecture-specialist.json +1 -0
- package/.ai-rules/agents/i18n-specialist.json +1 -0
- package/.ai-rules/agents/integration-specialist.json +1 -0
- package/.ai-rules/agents/observability-specialist.json +1 -0
- package/.ai-rules/agents/performance-specialist.json +1 -0
- package/.ai-rules/agents/plan-mode.json +1 -0
- package/.ai-rules/agents/security-specialist.json +1 -0
- package/.ai-rules/agents/seo-specialist.json +1 -0
- package/.ai-rules/agents/solution-architect.json +6 -6
- package/.ai-rules/agents/technical-planner.json +11 -11
- package/.ai-rules/agents/test-strategy-specialist.json +1 -0
- package/.ai-rules/agents/ui-ux-designer.json +1 -0
- package/.ai-rules/rules/core.md +17 -4
- package/.ai-rules/rules/parallel-execution.md +32 -0
- package/.ai-rules/schemas/agent.schema.json +2 -2
- package/.ai-rules/skills/ship/SKILL.md +35 -0
- package/.ai-rules/skills/systematic-debugging/SKILL.md +39 -0
- package/package.json +1 -1
|
@@ -529,67 +529,57 @@ When `parse_mode` returns `dispatch="auto"` or `dispatchReady` with specialist a
|
|
|
529
529
|
|
|
530
530
|
**Rule:** Every listed specialist MUST be dispatched. Skipping any specialist is a protocol violation.
|
|
531
531
|
|
|
532
|
-
####
|
|
532
|
+
#### Red Flags
|
|
533
533
|
|
|
534
|
-
|
|
534
|
+
| Thought | Reality |
|
|
535
|
+
|---------|---------|
|
|
536
|
+
| "I can handle this analysis myself" | Specialists have domain expertise. Dispatch them. |
|
|
537
|
+
| "It's just a small change" | dispatch="auto" means the system determined specialists are needed. |
|
|
538
|
+
| "I'll save time by skipping" | Skipping causes missed issues that cost more later. |
|
|
539
|
+
| "I'll dispatch later" | Dispatch IMMEDIATELY when dispatch="auto" is returned. |
|
|
535
540
|
|
|
536
|
-
|
|
537
|
-
1. TeamCreate({ team_name: "<task>-specialists" })
|
|
538
|
-
2. Spawn specialists as teammates:
|
|
539
|
-
Agent({ team_name, name: "security-specialist", subagent_type: "general-purpose", prompt: ... })
|
|
540
|
-
Agent({ team_name, name: "code-quality-specialist", subagent_type: "general-purpose", prompt: ... })
|
|
541
|
-
3. Create and assign tasks:
|
|
542
|
-
TaskCreate({ subject: "Security review of auth module" })
|
|
543
|
-
TaskUpdate({ taskId, owner: "security-specialist" })
|
|
544
|
-
4. Specialists work autonomously, report via SendMessage:
|
|
545
|
-
SendMessage({ to: "team-lead", message: "## Security Findings\n- ...", summary: "Security review done" })
|
|
546
|
-
5. Team lead collects all findings
|
|
547
|
-
6. Shutdown: SendMessage({ to: "security-specialist", message: { type: "shutdown_request" } })
|
|
548
|
-
```
|
|
541
|
+
### Execution Model: Outer Transport vs Inner Coordination
|
|
549
542
|
|
|
550
|
-
|
|
543
|
+
CodingBuddy uses a **nested execution model** with two distinct layers:
|
|
551
544
|
|
|
552
|
-
|
|
553
|
-
|
|
554
|
-
|
|
555
|
-
|
|
545
|
+
| Layer | Role | Tool | Scope |
|
|
546
|
+
|-------|------|------|-------|
|
|
547
|
+
| **Outer transport** | Parallel task execution across isolated environments | **TaskMaestro** (tmux + git worktree) or **SubAgent** (background agents) | One pane/agent per issue or task |
|
|
548
|
+
| **Inner coordination** | Specialist collaboration within a single session | **Teams** (experimental) | Multiple specialists within one pane/session |
|
|
556
549
|
|
|
557
|
-
**
|
|
558
|
-
```markdown
|
|
559
|
-
## [Specialist Name] Findings
|
|
550
|
+
> **Key distinction:** TaskMaestro and SubAgent are alternatives for the *outer* layer. Teams is an *inner* layer that can optionally run inside either outer strategy.
|
|
560
551
|
|
|
561
|
-
|
|
562
|
-
- [finding]
|
|
552
|
+
#### Nested Execution Examples
|
|
563
553
|
|
|
564
|
-
|
|
565
|
-
- [finding]
|
|
554
|
+
**Example 1: TaskMaestro (outer) + Teams (inner)**
|
|
566
555
|
|
|
567
|
-
|
|
568
|
-
|
|
569
|
-
|
|
570
|
-
|
|
571
|
-
-
|
|
556
|
+
```
|
|
557
|
+
TaskMaestro session (outer)
|
|
558
|
+
├── Pane 1: Issue #101 (auth feature)
|
|
559
|
+
│ └── Teams session (inner, optional)
|
|
560
|
+
│ ├── security-specialist → reviews auth impl
|
|
561
|
+
│ └── test-strategy-specialist → validates test coverage
|
|
562
|
+
├── Pane 2: Issue #102 (dashboard UI)
|
|
563
|
+
│ └── Single agent (no inner Teams needed)
|
|
564
|
+
└── Pane 3: Issue #103 (API refactor)
|
|
565
|
+
└── Teams session (inner, optional)
|
|
566
|
+
├── architecture-specialist → validates API design
|
|
567
|
+
└── performance-specialist → checks query efficiency
|
|
572
568
|
```
|
|
573
569
|
|
|
574
|
-
|
|
575
|
-
|
|
576
|
-
If Teams-based dispatch fails, fall back to the Agent tool:
|
|
577
|
-
- Use `run_in_background: true` for each specialist
|
|
578
|
-
- Collect results via `TaskOutput`
|
|
579
|
-
- Document the fallback reason in your response
|
|
580
|
-
|
|
581
|
-
#### Red Flags
|
|
570
|
+
**Example 2: SubAgent (outer) without inner Teams**
|
|
582
571
|
|
|
583
|
-
|
|
584
|
-
|
|
585
|
-
|
|
586
|
-
|
|
587
|
-
|
|
588
|
-
|
|
572
|
+
```
|
|
573
|
+
SubAgent dispatch (outer)
|
|
574
|
+
├── Agent 1: security-specialist (run_in_background)
|
|
575
|
+
├── Agent 2: accessibility-specialist (run_in_background)
|
|
576
|
+
└── Agent 3: performance-specialist (run_in_background)
|
|
577
|
+
→ Collect results via TaskOutput
|
|
578
|
+
```
|
|
589
579
|
|
|
590
580
|
### Execution Strategy Selection (MANDATORY)
|
|
591
581
|
|
|
592
|
-
When `parse_mode` returns `availableStrategies
|
|
582
|
+
When `parse_mode` returns `availableStrategies`, select the **outer transport** strategy:
|
|
593
583
|
|
|
594
584
|
1. **Check `availableStrategies`** in the response
|
|
595
585
|
2. **If both strategies available** (`["subagent", "taskmaestro"]`), ask user with AskUserQuestion:
|
|
@@ -600,8 +590,8 @@ When `parse_mode` returns `availableStrategies`:
|
|
|
600
590
|
- Yes → invoke `/taskmaestro` skill to guide installation, then re-check
|
|
601
591
|
- No → proceed with subagent
|
|
602
592
|
4. **Call `dispatch_agents`** with chosen `executionStrategy` parameter:
|
|
603
|
-
- `dispatch_agents({ mode, specialists, executionStrategy: "subagent" })` —
|
|
604
|
-
- `dispatch_agents({ mode, specialists, executionStrategy: "taskmaestro" })` —
|
|
593
|
+
- `dispatch_agents({ mode, specialists, executionStrategy: "subagent" })` — Agent tool flow
|
|
594
|
+
- `dispatch_agents({ mode, specialists, executionStrategy: "taskmaestro" })` — tmux pane assignments
|
|
605
595
|
5. **Execute** based on strategy:
|
|
606
596
|
- **subagent**: Use `dispatchParams` with Agent tool (`run_in_background: true`)
|
|
607
597
|
- **taskmaestro**: Follow `executionHint` — start panes, assign prompts, monitor, collect results
|
|
@@ -626,6 +616,71 @@ When `executionStrategy: "taskmaestro"` is chosen, `dispatch_agents` returns:
|
|
|
626
616
|
|
|
627
617
|
Execute by following the `executionHint` commands sequentially.
|
|
628
618
|
|
|
619
|
+
### Teams as Inner Coordination Layer (Experimental)
|
|
620
|
+
|
|
621
|
+
> **Capability gate:** Teams-based coordination is experimental and depends on Claude Code native Teams support being available at runtime. If Teams APIs (`TeamCreate`, `SendMessage`, etc.) are not available, fall back to the SubAgent dispatch pattern.
|
|
622
|
+
|
|
623
|
+
Teams provide structured specialist coordination **within** a single session or TaskMaestro pane. Use Teams when a task benefits from multiple specialists collaborating and reporting back to a coordinator, rather than running independently.
|
|
624
|
+
|
|
625
|
+
#### When to Use Inner Teams
|
|
626
|
+
|
|
627
|
+
- A single task (or pane) needs input from 2+ specialists who should coordinate
|
|
628
|
+
- Specialist findings need to be collected and consolidated by a team lead
|
|
629
|
+
- The task requires structured message-based reporting between specialists
|
|
630
|
+
|
|
631
|
+
#### When NOT to Use Inner Teams
|
|
632
|
+
|
|
633
|
+
- Each specialist can run independently with no cross-specialist dependencies
|
|
634
|
+
- You are dispatching specialists across separate issues/tasks (use outer transport instead)
|
|
635
|
+
- Teams APIs are not available at runtime
|
|
636
|
+
|
|
637
|
+
#### Teams Workflow (within a session)
|
|
638
|
+
|
|
639
|
+
```
|
|
640
|
+
1. TeamCreate({ team_name: "<task>-specialists" })
|
|
641
|
+
2. Spawn specialists as teammates:
|
|
642
|
+
Agent({ team_name, name: "security-specialist", subagent_type: "general-purpose", prompt: ... })
|
|
643
|
+
Agent({ team_name, name: "code-quality-specialist", subagent_type: "general-purpose", prompt: ... })
|
|
644
|
+
3. Create and assign tasks:
|
|
645
|
+
TaskCreate({ subject: "Security review of auth module" })
|
|
646
|
+
TaskUpdate({ taskId, owner: "security-specialist" })
|
|
647
|
+
4. Specialists work autonomously, report via SendMessage:
|
|
648
|
+
SendMessage({ to: "team-lead", message: "## Security Findings\n- ...", summary: "Security review done" })
|
|
649
|
+
5. Team lead collects all findings
|
|
650
|
+
6. Shutdown: SendMessage({ to: "security-specialist", message: { type: "shutdown_request" } })
|
|
651
|
+
```
|
|
652
|
+
|
|
653
|
+
#### SendMessage-Based Reporting
|
|
654
|
+
|
|
655
|
+
Specialists report findings through `SendMessage` to the team lead. This enables:
|
|
656
|
+
- Structured collection of all specialist outputs
|
|
657
|
+
- Consolidated summary for the user
|
|
658
|
+
- Clear audit trail of what each specialist found
|
|
659
|
+
|
|
660
|
+
**Report format:**
|
|
661
|
+
```markdown
|
|
662
|
+
## [Specialist Name] Findings
|
|
663
|
+
|
|
664
|
+
### Critical
|
|
665
|
+
- [finding]
|
|
666
|
+
|
|
667
|
+
### High
|
|
668
|
+
- [finding]
|
|
669
|
+
|
|
670
|
+
### Medium
|
|
671
|
+
- [finding]
|
|
672
|
+
|
|
673
|
+
### Recommendations
|
|
674
|
+
- [recommendation]
|
|
675
|
+
```
|
|
676
|
+
|
|
677
|
+
#### Fallback: SubAgent Dispatch
|
|
678
|
+
|
|
679
|
+
If Teams APIs are unavailable or Teams-based dispatch fails:
|
|
680
|
+
- Use SubAgent with `run_in_background: true` for each specialist
|
|
681
|
+
- Collect results via `TaskOutput`
|
|
682
|
+
- Document the fallback reason in your response
|
|
683
|
+
|
|
629
684
|
## PR All-in-One Skill
|
|
630
685
|
|
|
631
686
|
Unified commit and PR workflow that:
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "api-development",
|
|
3
|
+
"description": "API development team for building and maintaining backend services",
|
|
4
|
+
"category": "backend",
|
|
5
|
+
"tags": ["api", "backend", "rest", "graphql"],
|
|
6
|
+
"primary_agent": "backend-developer",
|
|
7
|
+
"specialist_agents": [
|
|
8
|
+
"security-specialist",
|
|
9
|
+
"test-engineer",
|
|
10
|
+
"performance-specialist",
|
|
11
|
+
"documentation-specialist"
|
|
12
|
+
],
|
|
13
|
+
"recommended_for": {
|
|
14
|
+
"file_patterns": ["*.controller.ts", "*.service.ts", "*.resolver.ts", "*.route.ts"],
|
|
15
|
+
"modes": ["PLAN", "ACT"]
|
|
16
|
+
}
|
|
17
|
+
}
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "data-pipeline",
|
|
3
|
+
"description": "Data pipeline team for data engineering, analysis, and monitoring",
|
|
4
|
+
"category": "data",
|
|
5
|
+
"tags": ["data", "pipeline", "etl", "analytics"],
|
|
6
|
+
"primary_agent": "data-engineer",
|
|
7
|
+
"specialist_agents": ["data-scientist", "performance-specialist", "observability-specialist"],
|
|
8
|
+
"recommended_for": {
|
|
9
|
+
"file_patterns": ["*.sql", "*.py", "*migration*", "*pipeline*"],
|
|
10
|
+
"modes": ["PLAN", "ACT"]
|
|
11
|
+
}
|
|
12
|
+
}
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "frontend-polish",
|
|
3
|
+
"description": "Frontend polish team for UI/UX refinement, accessibility, and performance",
|
|
4
|
+
"category": "frontend",
|
|
5
|
+
"tags": ["ui", "ux", "accessibility", "frontend", "seo"],
|
|
6
|
+
"primary_agent": "frontend-developer",
|
|
7
|
+
"specialist_agents": [
|
|
8
|
+
"ui-ux-designer",
|
|
9
|
+
"accessibility-specialist",
|
|
10
|
+
"performance-specialist",
|
|
11
|
+
"seo-specialist"
|
|
12
|
+
],
|
|
13
|
+
"recommended_for": {
|
|
14
|
+
"file_patterns": ["*.tsx", "*.css", "*.scss", "*.module.css"],
|
|
15
|
+
"modes": ["EVAL", "ACT"]
|
|
16
|
+
}
|
|
17
|
+
}
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "full-stack",
|
|
3
|
+
"description": "Full-stack development team for end-to-end web application development",
|
|
4
|
+
"category": "development",
|
|
5
|
+
"tags": ["web", "fullstack", "frontend", "backend"],
|
|
6
|
+
"primary_agent": "software-engineer",
|
|
7
|
+
"specialist_agents": [
|
|
8
|
+
"frontend-developer",
|
|
9
|
+
"backend-developer",
|
|
10
|
+
"security-specialist",
|
|
11
|
+
"test-engineer",
|
|
12
|
+
"performance-specialist"
|
|
13
|
+
],
|
|
14
|
+
"recommended_for": {
|
|
15
|
+
"file_patterns": ["*.ts", "*.tsx", "*.js", "*.jsx"],
|
|
16
|
+
"modes": ["PLAN", "ACT", "AUTO"]
|
|
17
|
+
}
|
|
18
|
+
}
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "ml-infrastructure",
|
|
3
|
+
"description": "ML infrastructure team for AI/ML model development and deployment",
|
|
4
|
+
"category": "ml",
|
|
5
|
+
"tags": ["ml", "ai", "model", "inference", "training"],
|
|
6
|
+
"primary_agent": "ai-ml-engineer",
|
|
7
|
+
"specialist_agents": [
|
|
8
|
+
"data-scientist",
|
|
9
|
+
"performance-specialist",
|
|
10
|
+
"observability-specialist",
|
|
11
|
+
"test-engineer"
|
|
12
|
+
],
|
|
13
|
+
"recommended_for": {
|
|
14
|
+
"file_patterns": ["*.py", "*model*", "*predict*", "*train*"],
|
|
15
|
+
"modes": ["PLAN", "ACT", "EVAL"]
|
|
16
|
+
}
|
|
17
|
+
}
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "security-audit",
|
|
3
|
+
"description": "Security audit team for vulnerability assessment and security hardening",
|
|
4
|
+
"category": "security",
|
|
5
|
+
"tags": ["security", "audit", "vulnerability", "compliance"],
|
|
6
|
+
"primary_agent": "security-engineer",
|
|
7
|
+
"specialist_agents": [
|
|
8
|
+
"security-specialist",
|
|
9
|
+
"test-strategy-specialist",
|
|
10
|
+
"code-quality-specialist"
|
|
11
|
+
],
|
|
12
|
+
"recommended_for": {
|
|
13
|
+
"file_patterns": ["*auth*", "*token*", "*session*", "*crypto*"],
|
|
14
|
+
"modes": ["EVAL", "AUTO"]
|
|
15
|
+
}
|
|
16
|
+
}
|
|
@@ -4,6 +4,7 @@
|
|
|
4
4
|
"color": "#8BC34A",
|
|
5
5
|
"role": {
|
|
6
6
|
"title": "Code Quality Engineer",
|
|
7
|
+
"type": "specialist",
|
|
7
8
|
"expertise": [
|
|
8
9
|
"SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion)",
|
|
9
10
|
"DRY (Don't Repeat Yourself) principle",
|
|
@@ -5,6 +5,7 @@
|
|
|
5
5
|
"systemPrompt": "You are a Plan Mode Agent that follows a structured reasoning process for every planning task.\n\n## Structured Reasoning Process (MANDATORY)\n\nBefore producing any plan, you MUST complete all five steps in order:\n\n### Step 0: Research\nRead relevant source code, configuration files, and documentation BEFORE planning.\n- NEVER plan from memory alone — always verify current state by reading files.\n- Identify existing patterns, conventions, and dependencies in the codebase.\n- Check recent git history for related changes.\n\n### Step 1: Decompose\nBreak the problem into discrete sub-problems.\n- Each sub-problem should be independently understandable.\n- Identify dependencies between sub-problems.\n- Order sub-problems by dependency (independent first, dependent last).\n\n### Step 2: Design\nCreate a concrete solution for each sub-problem.\n- Specify exact file paths, function names, and data structures.\n- Define the TDD approach: which tests to write first, expected failures, minimal implementations.\n- Ensure each solution is minimal — YAGNI applies.\n\n### Step 3: Devil's Advocate\nActively argue against your own plan.\n- What could go wrong? What edge cases are missed?\n- Are there simpler alternatives you overlooked?\n- Does the plan introduce unnecessary complexity or coupling?\n- Would this plan survive a critical code review?\n- Document weaknesses found and how the plan addresses them.\n\n### Step 4: Verify\nAll file paths and references in the plan MUST be verified against the actual codebase.\n- Confirmed paths: mark as-is.\n- Unconfirmed paths (not yet verified or file does not exist yet): mark with ⚠️ UNVERIFIED.\n- New files to be created: mark with 🆕 NEW.\n- NEVER assume a file exists without checking.",
|
|
6
6
|
"role": {
|
|
7
7
|
"title": "Plan Mode Agent",
|
|
8
|
+
"type": "utility",
|
|
8
9
|
"mode": "PLAN",
|
|
9
10
|
"purpose": "Mode Agent - delegates to Primary Developer Agent",
|
|
10
11
|
"expertise": [
|
|
@@ -24,14 +24,14 @@
|
|
|
24
24
|
"skills": {
|
|
25
25
|
"required": [
|
|
26
26
|
{
|
|
27
|
-
"name": "
|
|
27
|
+
"name": "brainstorming",
|
|
28
28
|
"purpose": "Explore design options through collaborative dialogue",
|
|
29
29
|
"when": "Starting any new feature or architectural decision"
|
|
30
30
|
}
|
|
31
31
|
],
|
|
32
32
|
"recommended": [
|
|
33
33
|
{
|
|
34
|
-
"name": "
|
|
34
|
+
"name": "writing-plans",
|
|
35
35
|
"purpose": "Document validated designs as implementation plans",
|
|
36
36
|
"when": "After design is finalized, before handoff to Technical Planner"
|
|
37
37
|
}
|
|
@@ -59,7 +59,7 @@
|
|
|
59
59
|
],
|
|
60
60
|
"mandatory_checklist": {
|
|
61
61
|
"🔴 brainstorming_first": {
|
|
62
|
-
"rule": "MUST invoke
|
|
62
|
+
"rule": "MUST invoke brainstorming skill before any design work",
|
|
63
63
|
"verification_key": "brainstorming_first"
|
|
64
64
|
},
|
|
65
65
|
"🔴 multiple_options": {
|
|
@@ -80,7 +80,7 @@
|
|
|
80
80
|
}
|
|
81
81
|
},
|
|
82
82
|
"verification_guide": {
|
|
83
|
-
"brainstorming_first": "Check that
|
|
83
|
+
"brainstorming_first": "Check that brainstorming skill was invoked at start",
|
|
84
84
|
"multiple_options": "Verify 2-3 approaches were presented with pros/cons",
|
|
85
85
|
"incremental_validation": "Design was presented in 200-300 word sections with user validation",
|
|
86
86
|
"document_design": "Design document exists in docs/plans/ with correct naming",
|
|
@@ -92,7 +92,7 @@
|
|
|
92
92
|
"approach": "Brainstorm-First",
|
|
93
93
|
"applies_to": "New features, architecture decisions, technology selection",
|
|
94
94
|
"steps": [
|
|
95
|
-
"1. Invoke
|
|
95
|
+
"1. Invoke brainstorming skill",
|
|
96
96
|
"2. Understand project context (files, docs, commits)",
|
|
97
97
|
"3. Ask clarifying questions one at a time",
|
|
98
98
|
"4. Propose 2-3 approaches with trade-offs",
|
|
@@ -162,7 +162,7 @@
|
|
|
162
162
|
"reference": {
|
|
163
163
|
"project_rules": ".ai-rules/rules/",
|
|
164
164
|
"existing_agents": ".ai-rules/agents/*.json",
|
|
165
|
-
"skills_location": "
|
|
165
|
+
"skills_location": "codingbuddy skills"
|
|
166
166
|
},
|
|
167
167
|
"visual": {
|
|
168
168
|
"eye": "⬢",
|
|
@@ -24,24 +24,24 @@
|
|
|
24
24
|
"skills": {
|
|
25
25
|
"required": [
|
|
26
26
|
{
|
|
27
|
-
"name": "
|
|
27
|
+
"name": "writing-plans",
|
|
28
28
|
"purpose": "Create comprehensive implementation plans",
|
|
29
29
|
"when": "Always when creating implementation plans"
|
|
30
30
|
}
|
|
31
31
|
],
|
|
32
32
|
"recommended": [
|
|
33
33
|
{
|
|
34
|
-
"name": "
|
|
34
|
+
"name": "test-driven-development",
|
|
35
35
|
"purpose": "Ensure TDD approach in plan tasks",
|
|
36
36
|
"when": "Designing test-first task sequences"
|
|
37
37
|
},
|
|
38
38
|
{
|
|
39
|
-
"name": "
|
|
39
|
+
"name": "subagent-driven-development",
|
|
40
40
|
"purpose": "Execute plans with fresh subagent per task",
|
|
41
41
|
"when": "User chooses to execute in current session"
|
|
42
42
|
},
|
|
43
43
|
{
|
|
44
|
-
"name": "
|
|
44
|
+
"name": "executing-plans",
|
|
45
45
|
"purpose": "Execute plans in parallel session",
|
|
46
46
|
"when": "User chooses to execute in separate session"
|
|
47
47
|
}
|
|
@@ -69,7 +69,7 @@
|
|
|
69
69
|
],
|
|
70
70
|
"mandatory_checklist": {
|
|
71
71
|
"🔴 writing_plans_skill": {
|
|
72
|
-
"rule": "MUST invoke
|
|
72
|
+
"rule": "MUST invoke writing-plans skill for plan creation",
|
|
73
73
|
"verification_key": "writing_plans_skill"
|
|
74
74
|
},
|
|
75
75
|
"🔴 bite_sized_tasks": {
|
|
@@ -94,7 +94,7 @@
|
|
|
94
94
|
}
|
|
95
95
|
},
|
|
96
96
|
"verification_guide": {
|
|
97
|
-
"writing_plans_skill": "Check that
|
|
97
|
+
"writing_plans_skill": "Check that writing-plans skill was invoked",
|
|
98
98
|
"bite_sized_tasks": "Each step should be a single action (2-5 minutes)",
|
|
99
99
|
"exact_file_paths": "All paths use exact/path/to/file.ext format",
|
|
100
100
|
"tdd_structure": "Each task has: failing test → verify fail → implement → verify pass → commit",
|
|
@@ -107,7 +107,7 @@
|
|
|
107
107
|
"approach": "TDD-First Planning",
|
|
108
108
|
"applies_to": "Implementation plans, task breakdowns, coding tasks",
|
|
109
109
|
"steps": [
|
|
110
|
-
"1. Invoke
|
|
110
|
+
"1. Invoke writing-plans skill",
|
|
111
111
|
"2. Read design document or requirements",
|
|
112
112
|
"3. Identify all components and dependencies",
|
|
113
113
|
"4. Break into bite-sized tasks (2-5 minutes each)",
|
|
@@ -172,12 +172,12 @@
|
|
|
172
172
|
"execution_options": {
|
|
173
173
|
"subagent_driven": {
|
|
174
174
|
"description": "Execute in current session with fresh subagent per task",
|
|
175
|
-
"skill": "
|
|
175
|
+
"skill": "subagent-driven-development",
|
|
176
176
|
"benefits": ["No context switch", "Fast iteration", "Two-stage review"]
|
|
177
177
|
},
|
|
178
178
|
"parallel_session": {
|
|
179
179
|
"description": "Execute in separate session with checkpoints",
|
|
180
|
-
"skill": "
|
|
180
|
+
"skill": "executing-plans",
|
|
181
181
|
"benefits": ["Parallel work possible", "Clear handoff points"]
|
|
182
182
|
}
|
|
183
183
|
},
|
|
@@ -193,8 +193,8 @@
|
|
|
193
193
|
"reference": {
|
|
194
194
|
"project_rules": ".ai-rules/rules/",
|
|
195
195
|
"existing_agents": ".ai-rules/agents/*.json",
|
|
196
|
-
"skills_location": "
|
|
197
|
-
"plan_examples": "See
|
|
196
|
+
"skills_location": "codingbuddy skills",
|
|
197
|
+
"plan_examples": "See writing-plans skill for examples"
|
|
198
198
|
},
|
|
199
199
|
"visual": {
|
|
200
200
|
"eye": "⎔",
|
package/.ai-rules/rules/core.md
CHANGED
|
@@ -609,11 +609,24 @@ To preserve this implementation session for future reference:
|
|
|
609
609
|
|
|
610
610
|
---
|
|
611
611
|
|
|
612
|
-
###
|
|
612
|
+
### Branch Discipline
|
|
613
613
|
|
|
614
|
-
-
|
|
615
|
-
-
|
|
616
|
-
-
|
|
614
|
+
- Always verify current branch before committing (`git status` / `git branch`)
|
|
615
|
+
- Never commit directly to master/main — always use feature branches
|
|
616
|
+
- If accidentally on master/main, create a new branch before committing
|
|
617
|
+
|
|
618
|
+
### Mode Transition Rules
|
|
619
|
+
|
|
620
|
+
- **PLAN → ACT:** MUST wait for explicit user "ACT" input. Never auto-proceed from PLAN to ACT.
|
|
621
|
+
- **During ACT:** Proceed autonomously. Only stop for errors or blockers.
|
|
622
|
+
- **"Wait for mode transition"** ≠ "wait during execution" — mode transitions require user input, but execution within a mode is continuous.
|
|
623
|
+
|
|
624
|
+
### Error Recovery
|
|
625
|
+
|
|
626
|
+
- **Recoverable errors** (label not found, file missing, command failure, path issues): auto-try alternatives immediately, continue without user confirmation
|
|
627
|
+
- **Unrecoverable errors** (auth failure, critical data loss risk): report to user
|
|
628
|
+
- Only report to user when recovery is impossible
|
|
629
|
+
- Never stop for confirmation on recoverable errors
|
|
617
630
|
- Never break the workflow on error — try alternatives and continue
|
|
618
631
|
|
|
619
632
|
### Path Safety (monorepo)
|
|
@@ -81,6 +81,38 @@ Order waves considering:
|
|
|
81
81
|
|
|
82
82
|
---
|
|
83
83
|
|
|
84
|
+
## Implementation vs Read-Only Task Dispatch
|
|
85
|
+
|
|
86
|
+
Implementation tasks (code changes, file modifications, commits) MUST use tmux-based parallel execution (e.g., taskMaestro), NOT background sub-agents.
|
|
87
|
+
|
|
88
|
+
| Task Type | Dispatch Method | Rationale |
|
|
89
|
+
|-----------|----------------|-----------|
|
|
90
|
+
| **Implementation** (write code, modify files, commit, create PR) | taskMaestro (tmux panes) with git worktree isolation | Full environment, git operations, pre-push checks |
|
|
91
|
+
| **Read-only** (research, analysis, code review, search) | Background sub-agents (Agent tool) | No file mutations, safe to run in parallel without isolation |
|
|
92
|
+
|
|
93
|
+
**Why:** Background sub-agents lack proper git worktree isolation, cannot run pre-push checks reliably, and risk file conflicts when multiple agents write to the same workspace. taskMaestro provides each worker with an isolated worktree, proper shell environment, and full CI toolchain access.
|
|
94
|
+
|
|
95
|
+
## Monorepo Path Safety
|
|
96
|
+
|
|
97
|
+
In monorepo environments, always use absolute paths or `git -C <path>` for git commands to prevent path doubling:
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
# ✅ Correct — absolute path or git -C
|
|
101
|
+
git -C /absolute/path/to/repo status
|
|
102
|
+
git -C "$REPO_ROOT" add src/file.ts
|
|
103
|
+
|
|
104
|
+
# ❌ Wrong — relative path after cd can double
|
|
105
|
+
cd packages/my-lib
|
|
106
|
+
git add packages/my-lib/src/file.ts # Path doubled!
|
|
107
|
+
|
|
108
|
+
# ❌ Wrong — assuming cwd after operations
|
|
109
|
+
git add src/file.ts # May not be in expected directory
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
**Why:** Relative paths in monorepo subdirectories frequently cause `git add` to target wrong files or fail silently. After any `cd` or worktree operation, verify cwd or use absolute paths.
|
|
113
|
+
|
|
114
|
+
---
|
|
115
|
+
|
|
84
116
|
## Sub-Agent Parallelization Strategy
|
|
85
117
|
|
|
86
118
|
When dispatching parallel sub-agents (workers), follow these guidelines:
|
|
@@ -43,8 +43,8 @@
|
|
|
43
43
|
},
|
|
44
44
|
"type": {
|
|
45
45
|
"type": "string",
|
|
46
|
-
"enum": ["primary", "specialist"],
|
|
47
|
-
"description": "Agent type: 'primary' uses top-level activation for PLAN/ACT workflow, 'specialist' uses modes for domain-specific guidance. RECOMMENDED: Always specify for new agents to ensure proper workflow integration."
|
|
46
|
+
"enum": ["primary", "specialist", "utility"],
|
|
47
|
+
"description": "Agent type: 'primary' uses top-level activation for PLAN/ACT workflow, 'specialist' uses modes for domain-specific guidance, 'utility' is for mode agents (PLAN/ACT/EVAL/AUTO). RECOMMENDED: Always specify for new agents to ensure proper workflow integration."
|
|
48
48
|
},
|
|
49
49
|
"expertise": {
|
|
50
50
|
"type": "array",
|
|
@@ -137,6 +137,41 @@ If `custom.ship.globalChecks` is configured, run each global check command after
|
|
|
137
137
|
<command> # executed from project root
|
|
138
138
|
```
|
|
139
139
|
|
|
140
|
+
### Security check (ALL workspaces)
|
|
141
|
+
|
|
142
|
+
Security audit must run across ALL workspaces, not just affected ones:
|
|
143
|
+
|
|
144
|
+
```bash
|
|
145
|
+
# Monorepo — run for ALL workspaces (not just affected):
|
|
146
|
+
<pm> audit
|
|
147
|
+
# Or for npm:
|
|
148
|
+
npm audit --workspaces
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
**Why:** A vulnerability in an unaffected workspace still ships with the project. Security scanning must be comprehensive.
|
|
152
|
+
|
|
153
|
+
### CI workflow self-inclusion check
|
|
154
|
+
|
|
155
|
+
When modifying CI workflow files (e.g., `.github/workflows/*.yml`), verify the workflow's `on.push.paths` or `on.pull_request.paths` filter includes the workflow file itself:
|
|
156
|
+
|
|
157
|
+
```yaml
|
|
158
|
+
# ✅ Correct — workflow file is included in its own paths filter
|
|
159
|
+
on:
|
|
160
|
+
push:
|
|
161
|
+
paths:
|
|
162
|
+
- 'src/**'
|
|
163
|
+
- '.github/workflows/ci.yml' # Self-included
|
|
164
|
+
|
|
165
|
+
# ❌ Wrong — workflow changes won't trigger the workflow
|
|
166
|
+
on:
|
|
167
|
+
push:
|
|
168
|
+
paths:
|
|
169
|
+
- 'src/**'
|
|
170
|
+
# Missing: .github/workflows/ci.yml
|
|
171
|
+
```
|
|
172
|
+
|
|
173
|
+
**Why:** If a workflow file is not in its own paths filter, changes to the workflow itself won't trigger CI, making it impossible to validate workflow changes before merging.
|
|
174
|
+
|
|
140
175
|
If ANY check fails, stop and report the failure. Do NOT proceed to shipping.
|
|
141
176
|
|
|
142
177
|
## Step 6: Check Commit Convention
|
|
@@ -22,6 +22,45 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
|
|
|
22
22
|
|
|
23
23
|
If you haven't completed Phase 1, you cannot propose fixes.
|
|
24
24
|
|
|
25
|
+
## Mandatory 6-Step Debugging Sequence
|
|
26
|
+
|
|
27
|
+
Before ANY debugging attempt, follow this sequence in order:
|
|
28
|
+
|
|
29
|
+
1. **Validate/Check command** — If the external tool has a validate/check/lint command, run it FIRST. Always. No exceptions.
|
|
30
|
+
2. **Official documentation** — Verify system behavior by reading official docs. No guessing how a system works.
|
|
31
|
+
3. **Hypothesis formation** — Form a hypothesis with evidence from steps 1-2.
|
|
32
|
+
4. **Fix implementation** — Implement the fix based on your hypothesis.
|
|
33
|
+
5. **Local verification** — Verify the fix locally before shipping.
|
|
34
|
+
6. **Ship** — Only ship after local verification passes.
|
|
35
|
+
|
|
36
|
+
### Validate First Rule
|
|
37
|
+
|
|
38
|
+
If an external tool, service, or configuration format has a validate/check/lint command, you MUST run it BEFORE any debugging or fix attempts:
|
|
39
|
+
|
|
40
|
+
| Tool/Format | Validate Command |
|
|
41
|
+
|-------------|-----------------|
|
|
42
|
+
| GitHub Actions | `actionlint` or validate via `act --list` |
|
|
43
|
+
| Docker | `docker compose config` |
|
|
44
|
+
| Kubernetes | `kubectl apply --dry-run=client` |
|
|
45
|
+
| Terraform | `terraform validate` |
|
|
46
|
+
| JSON | `jq .` or schema-specific validators |
|
|
47
|
+
| YAML | `yamllint` |
|
|
48
|
+
| TypeScript | `tsc --noEmit` |
|
|
49
|
+
| ESLint config | `eslint --print-config` |
|
|
50
|
+
|
|
51
|
+
**Why:** Validation catches syntax and schema errors instantly. Debugging without validation wastes time on issues the tool itself can detect.
|
|
52
|
+
|
|
53
|
+
### Verify Mental Model Rule
|
|
54
|
+
|
|
55
|
+
Before assuming how an external system works, read the official documentation first:
|
|
56
|
+
|
|
57
|
+
- **Never guess** API behavior, config format, or tool behavior from memory
|
|
58
|
+
- **Always verify** against official docs, especially for version-specific behavior
|
|
59
|
+
- **Check changelogs** when upgrading — behavior may have changed between versions
|
|
60
|
+
- If official docs are unavailable, use `--help`, man pages, or source code as reference
|
|
61
|
+
|
|
62
|
+
**Why:** Stale mental models from past versions or similar-but-different tools cause debugging to chase phantom issues.
|
|
63
|
+
|
|
25
64
|
## When to Use
|
|
26
65
|
|
|
27
66
|
Use for ANY technical issue:
|