oh-my-customcode 0.23.2 → 0.24.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/README.md +5 -5
- package/package.json +1 -1
- package/templates/.claude/agents/sec-codeql-expert.md +51 -0
- package/templates/.claude/skills/cve-triage/SKILL.md +90 -0
- package/templates/.claude/skills/jinja2-prompts/SKILL.md +85 -0
- package/templates/.claude/skills/research/SKILL.md +257 -0
- package/templates/manifest.json +4 -4
package/README.md
CHANGED
|
@@ -21,7 +21,7 @@ Like oh-my-zsh transformed shell customization, oh-my-customcode makes personali
|
|
|
21
21
|
|
|
22
22
|
| Feature | Description |
|
|
23
23
|
|---------|-------------|
|
|
24
|
-
| **Batteries Included** |
|
|
24
|
+
| **Batteries Included** | 42 agents, 66 skills, 22 guides, 18 rules, 2 hooks, 4 contexts, ontology graph - ready to use out of the box |
|
|
25
25
|
| **Sub-Agent Model** | Supports hierarchical agent orchestration with specialized roles |
|
|
26
26
|
| **Dead Simple Customization** | Create a folder + markdown file = new agent or skill |
|
|
27
27
|
| **Mix and Match** | Use built-in components, create your own, or combine both |
|
|
@@ -107,7 +107,7 @@ Claude Code selects the appropriate model and parallelizes independent tasks (up
|
|
|
107
107
|
|
|
108
108
|
## What's Included
|
|
109
109
|
|
|
110
|
-
### Agents (
|
|
110
|
+
### Agents (42)
|
|
111
111
|
|
|
112
112
|
| Category | Count | Agents |
|
|
113
113
|
|----------|-------|--------|
|
|
@@ -122,9 +122,9 @@ Claude Code selects the appropriate model and parallelizes independent tasks (up
|
|
|
122
122
|
| **Architecture** | 2 | arch-documenter, arch-speckit-agent |
|
|
123
123
|
| **Infrastructure** | 2 | infra-docker-expert, infra-aws-expert |
|
|
124
124
|
| **QA** | 3 | qa-planner, qa-writer, qa-engineer |
|
|
125
|
-
| **Total** | **
|
|
125
|
+
| **Total** | **42** | |
|
|
126
126
|
|
|
127
|
-
### Skills (
|
|
127
|
+
### Skills (66)
|
|
128
128
|
|
|
129
129
|
| Category | Count | Skills |
|
|
130
130
|
|----------|-------|--------|
|
|
@@ -225,7 +225,7 @@ your-project/
|
|
|
225
225
|
│ ├── be-fastapi-expert.md
|
|
226
226
|
│ ├── mgr-creator.md
|
|
227
227
|
│ └── ...
|
|
228
|
-
├── skills/ # Skill modules (
|
|
228
|
+
├── skills/ # Skill modules (66 directories, each with SKILL.md)
|
|
229
229
|
│ ├── go-best-practices/
|
|
230
230
|
│ ├── react-best-practices/
|
|
231
231
|
│ ├── secretary-routing/
|
package/package.json
CHANGED
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: sec-codeql-expert
|
|
3
|
+
description: Expert security code analyst using CodeQL for vulnerability detection, call graph analysis, and SARIF output. Use for security audits, CVE triage, code pattern analysis, and vulnerability validation.
|
|
4
|
+
model: sonnet
|
|
5
|
+
memory: project
|
|
6
|
+
tools:
|
|
7
|
+
- Read
|
|
8
|
+
- Write
|
|
9
|
+
- Edit
|
|
10
|
+
- Grep
|
|
11
|
+
- Glob
|
|
12
|
+
- Bash
|
|
13
|
+
---
|
|
14
|
+
|
|
15
|
+
You are a security-focused code analyst specializing in CodeQL-based vulnerability detection and assessment.
|
|
16
|
+
|
|
17
|
+
## Capabilities
|
|
18
|
+
|
|
19
|
+
- Run CodeQL queries against codebases (C/C++, JavaScript, Python, Java, Go)
|
|
20
|
+
- Analyze call graphs and data flow paths
|
|
21
|
+
- Detect vulnerability patterns aligned with OWASP Top 10 and CWE classifications
|
|
22
|
+
- Generate SARIF-formatted results for CI/CD integration
|
|
23
|
+
- Triage CVE reports against the target codebase
|
|
24
|
+
- Identify attack surface and risk areas
|
|
25
|
+
- Produce remediation guidance with severity ratings
|
|
26
|
+
|
|
27
|
+
## Workflow
|
|
28
|
+
|
|
29
|
+
1. **Receive target** — file, directory, or repository path
|
|
30
|
+
2. **Select query suite** — choose language-appropriate CodeQL pack
|
|
31
|
+
3. **Execute analysis** — use CodeQL MCP server if available, fall back to CodeQL CLI
|
|
32
|
+
4. **Process results** — parse SARIF output, deduplicate findings
|
|
33
|
+
5. **Assess severity** — classify by CWE, assign CVSS-informed severity (Critical/High/Medium/Low)
|
|
34
|
+
6. **Report** — structured findings with location, description, and remediation steps
|
|
35
|
+
|
|
36
|
+
## Integration
|
|
37
|
+
|
|
38
|
+
- Prefers CodeQL MCP server (`github/codeql-action` compatible) when available
|
|
39
|
+
- Falls back to `codeql` CLI: `codeql database create` → `codeql database analyze`
|
|
40
|
+
- All findings reference CWE IDs and include file:line locations
|
|
41
|
+
- SARIF output compatible with GitHub Advanced Security and other SAST platforms
|
|
42
|
+
|
|
43
|
+
## Report Format
|
|
44
|
+
|
|
45
|
+
```
|
|
46
|
+
[Finding] CWE-{id}: {title}
|
|
47
|
+
Severity: Critical | High | Medium | Low
|
|
48
|
+
Location: {file}:{line}
|
|
49
|
+
Description: {what and why it's vulnerable}
|
|
50
|
+
Remediation: {concrete fix guidance}
|
|
51
|
+
```
|
|
@@ -0,0 +1,90 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: cve-triage
|
|
3
|
+
description: CVE triage workflow for vulnerability analysis, reproduction assessment, and patch verification
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# CVE Triage Skill
|
|
8
|
+
|
|
9
|
+
A structured workflow for triaging CVE reports against a codebase. Coordinates security analysis, reproduction assessment, and patch verification.
|
|
10
|
+
|
|
11
|
+
## Triage Phases
|
|
12
|
+
|
|
13
|
+
### Phase 1: CVE Intake
|
|
14
|
+
|
|
15
|
+
- Parse CVE identifier and advisory details
|
|
16
|
+
- Identify affected component, version range, and CWE classification
|
|
17
|
+
- Determine if codebase uses the affected component
|
|
18
|
+
|
|
19
|
+
### Phase 2: Impact Assessment
|
|
20
|
+
|
|
21
|
+
- Locate affected code paths via grep/CodeQL
|
|
22
|
+
- Assess exploitability in the project's specific context
|
|
23
|
+
- Determine severity (CRITICAL/HIGH/MEDIUM/LOW/NONE)
|
|
24
|
+
- Check if existing mitigations reduce impact
|
|
25
|
+
|
|
26
|
+
### Phase 3: Reproduction Analysis
|
|
27
|
+
|
|
28
|
+
- Design minimal reproduction scenario
|
|
29
|
+
- Identify prerequisites (configuration, network access, authentication)
|
|
30
|
+
- Assess if reproduction is feasible in test environment
|
|
31
|
+
|
|
32
|
+
### Phase 4: Remediation
|
|
33
|
+
|
|
34
|
+
- Identify available patches or versions
|
|
35
|
+
- Assess upgrade compatibility and breaking changes
|
|
36
|
+
- Propose mitigation if patch unavailable
|
|
37
|
+
- Generate remediation plan with effort estimate
|
|
38
|
+
|
|
39
|
+
## Output Format
|
|
40
|
+
|
|
41
|
+
```markdown
|
|
42
|
+
## CVE Triage Report: {CVE-ID}
|
|
43
|
+
|
|
44
|
+
### Summary
|
|
45
|
+
| Field | Value |
|
|
46
|
+
|-------|-------|
|
|
47
|
+
| CVE | {CVE-ID} |
|
|
48
|
+
| CWE | {CWE-ID}: {description} |
|
|
49
|
+
| CVSS | {score} ({severity}) |
|
|
50
|
+
| Affected | {component} {version range} |
|
|
51
|
+
| Project Impact | {CRITICAL/HIGH/MEDIUM/LOW/NONE} |
|
|
52
|
+
|
|
53
|
+
### Analysis
|
|
54
|
+
{Detailed analysis of how CVE affects this codebase}
|
|
55
|
+
|
|
56
|
+
### Remediation
|
|
57
|
+
| Option | Effort | Risk |
|
|
58
|
+
|--------|--------|------|
|
|
59
|
+
| {option 1} | {effort} | {risk} |
|
|
60
|
+
|
|
61
|
+
### Action Items
|
|
62
|
+
- [ ] {item 1}
|
|
63
|
+
- [ ] {item 2}
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## Integration
|
|
67
|
+
|
|
68
|
+
- Uses sec-codeql-expert for code analysis when available
|
|
69
|
+
- Results feed into security documentation
|
|
70
|
+
- Can be triggered as part of /research security analysis
|
|
71
|
+
|
|
72
|
+
## Agent Selection
|
|
73
|
+
|
|
74
|
+
| Phase | Agent | Model |
|
|
75
|
+
|-------|-------|-------|
|
|
76
|
+
| CVE Intake | Explore | haiku |
|
|
77
|
+
| Impact Assessment | sec-codeql-expert | sonnet |
|
|
78
|
+
| Reproduction | sec-codeql-expert | sonnet |
|
|
79
|
+
| Remediation | appropriate-expert | sonnet |
|
|
80
|
+
|
|
81
|
+
## Workflow
|
|
82
|
+
|
|
83
|
+
```
|
|
84
|
+
1. Receive CVE identifier or advisory
|
|
85
|
+
2. Phase 1: Parse and classify the vulnerability
|
|
86
|
+
3. Phase 2: Search codebase for affected components
|
|
87
|
+
4. Phase 3: Evaluate reproduction feasibility
|
|
88
|
+
5. Phase 4: Propose remediation with effort/risk tradeoffs
|
|
89
|
+
6. Generate triage report in standard format
|
|
90
|
+
```
|
|
@@ -0,0 +1,85 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: jinja2-prompts
|
|
3
|
+
description: Parameterized prompt templates using Jinja2 patterns for reusable, dynamic agent prompts
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Jinja2 Prompt Templates
|
|
8
|
+
|
|
9
|
+
## Purpose
|
|
10
|
+
|
|
11
|
+
Define reusable, parameterized prompt templates for agent tasks. Templates enable consistent prompt formatting across workflows while allowing dynamic content injection.
|
|
12
|
+
|
|
13
|
+
## Template Syntax
|
|
14
|
+
|
|
15
|
+
Use Jinja2-style variable interpolation in prompt strings:
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
{{ variable }} — Variable substitution
|
|
19
|
+
{% if condition %}...{% endif %} — Conditional sections
|
|
20
|
+
{% for item in list %}...{% endfor %} — Iteration
|
|
21
|
+
{{ variable | default("fallback") }} — Default values
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
## Security Rules
|
|
25
|
+
|
|
26
|
+
- Templates MUST be author-written (stored in skill files), never user-supplied
|
|
27
|
+
- Use `SandboxedEnvironment` (NOT `Environment` or `from_string()` directly)
|
|
28
|
+
- No access to `env()`, `os`, `subprocess`, or any system functions
|
|
29
|
+
- Variable allowlist: only explicitly provided context variables are accessible
|
|
30
|
+
- NEVER render user-controlled strings as templates — treat them as plain data
|
|
31
|
+
|
|
32
|
+
## Template Locations
|
|
33
|
+
|
|
34
|
+
```
|
|
35
|
+
.claude/skills/<skill-name>/templates/
|
|
36
|
+
├── analysis.md.j2
|
|
37
|
+
├── report.md.j2
|
|
38
|
+
└── triage.md.j2
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Usage Pattern
|
|
42
|
+
|
|
43
|
+
```yaml
|
|
44
|
+
# In skill or workflow definition
|
|
45
|
+
template: analysis.md.j2
|
|
46
|
+
variables:
|
|
47
|
+
target: "{{ repository_url }}"
|
|
48
|
+
scope: "security"
|
|
49
|
+
depth: "comprehensive"
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Rendered by orchestrator before passing to agent as prompt.
|
|
53
|
+
|
|
54
|
+
## Common Templates
|
|
55
|
+
|
|
56
|
+
### Research Team Prompt
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
Role: {{ domain }} {{ role }} analyst
|
|
60
|
+
Scope: {{ topic }}
|
|
61
|
+
|
|
62
|
+
Tasks:
|
|
63
|
+
{% for task in tasks %}
|
|
64
|
+
{{ loop.index }}. {{ task }}
|
|
65
|
+
{% endfor %}
|
|
66
|
+
|
|
67
|
+
Output format:
|
|
68
|
+
{{ output_format }}
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
### CVE Triage Prompt
|
|
72
|
+
|
|
73
|
+
```
|
|
74
|
+
Analyze {{ cve_id }} ({{ cwe_classification }})
|
|
75
|
+
Affected component: {{ component }} {{ version_range }}
|
|
76
|
+
{% if existing_mitigations %}
|
|
77
|
+
Known mitigations: {{ existing_mitigations }}
|
|
78
|
+
{% endif %}
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
## Integration
|
|
82
|
+
|
|
83
|
+
- Used by `/research` skill for team prompt generation
|
|
84
|
+
- Used by `cve-triage` skill for standardized analysis prompts
|
|
85
|
+
- Compatible with DAG orchestration node prompts
|
|
@@ -0,0 +1,257 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: research
|
|
3
|
+
description: 10-team parallel deep analysis with cross-verification for any topic, repository, or technology. Use when user invokes /research or asks for comprehensive research.
|
|
4
|
+
context: fork
|
|
5
|
+
user-invocable: true
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Research Skill
|
|
9
|
+
|
|
10
|
+
Orchestrates 10 parallel research teams for comprehensive deep analysis of any topic, GitHub repository, or technology. Produces a structured report with ADOPT/ADAPT/AVOID taxonomy.
|
|
11
|
+
|
|
12
|
+
**Orchestrator-only** — only the main conversation uses this skill (R010). Teams execute as subagents.
|
|
13
|
+
|
|
14
|
+
## Usage
|
|
15
|
+
|
|
16
|
+
```
|
|
17
|
+
/research <topic-or-url>
|
|
18
|
+
/research https://github.com/user/repo
|
|
19
|
+
/research "distributed consensus algorithms"
|
|
20
|
+
/research Rust async runtime comparison
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Architecture — 4 Phases
|
|
24
|
+
|
|
25
|
+
### Phase 1: Parallel Research (10 teams, batched per R009)
|
|
26
|
+
|
|
27
|
+
Teams operate in breadth/depth pairs across 5 domains:
|
|
28
|
+
|
|
29
|
+
| Pair | Domain | Team | Role | Focus |
|
|
30
|
+
|------|--------|------|------|-------|
|
|
31
|
+
| 1 | Architecture | T1 | Breadth | Survey, catalog, enumerate structure |
|
|
32
|
+
| | | T2 | Depth | Deep-dive patterns, validate assumptions |
|
|
33
|
+
| 2 | Security | T3 | Breadth | Vulnerability scan, attack surface enumeration |
|
|
34
|
+
| | | T4 | Depth | Exploit validation, risk quantification |
|
|
35
|
+
| 3 | Integration | T5 | Breadth | Compatibility mapping, dependency analysis |
|
|
36
|
+
| | | T6 | Depth | Effort estimation, value assessment |
|
|
37
|
+
| 4 | Comparative | T7 | Breadth | Alternative survey, market landscape |
|
|
38
|
+
| | | T8 | Depth | Feature comparison, benchmark data |
|
|
39
|
+
| 5 | Innovation | T9 | Breadth | Novel pattern identification, idea extraction |
|
|
40
|
+
| | | T10 | Depth | Feasibility validation, adaptation design |
|
|
41
|
+
|
|
42
|
+
**Batching order** (max 4 concurrent per R009):
|
|
43
|
+
```
|
|
44
|
+
Batch 1: T1, T2, T3, T4 (Architecture + Security)
|
|
45
|
+
Batch 2: T5, T6, T7, T8 (Integration + Comparative)
|
|
46
|
+
Batch 3: T9, T10 (Innovation)
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### Phase 2: Cross-Verification Loop (min 2, max 5 rounds)
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
Team findings ──→ opus 4.6 verification ──→ codex-exec xhigh verification
|
|
53
|
+
│ │
|
|
54
|
+
└── Contradiction detected? ── YES ──→ Round N+1
|
|
55
|
+
NO ──→ Consensus reached → Phase 3
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
Each round:
|
|
59
|
+
1. **opus 4.6**: Deep reasoning verification — checks logical consistency, identifies gaps, challenges assumptions
|
|
60
|
+
2. **codex-exec xhigh** (if available): Independent code-level verification — validates technical claims, tests feasibility
|
|
61
|
+
3. **Contradiction resolution**: Reconcile divergent findings between teams and verifiers
|
|
62
|
+
4. **Convergence check**: All major claims verified with no outstanding contradictions → proceed
|
|
63
|
+
|
|
64
|
+
Convergence expected by round 3. Hard stop at round 5.
|
|
65
|
+
|
|
66
|
+
### Phase 3: Synthesis
|
|
67
|
+
|
|
68
|
+
1. Cross-team gap analysis — identify areas no team covered
|
|
69
|
+
2. Unified priority ranking — weight findings by confidence and impact
|
|
70
|
+
3. ADOPT / ADAPT / AVOID taxonomy generation
|
|
71
|
+
|
|
72
|
+
### Phase 4: Output
|
|
73
|
+
|
|
74
|
+
1. Structured markdown report (see Output Format below)
|
|
75
|
+
2. GitHub issue auto-created with findings
|
|
76
|
+
3. Action items with effort estimates
|
|
77
|
+
|
|
78
|
+
## Execution Rules
|
|
79
|
+
|
|
80
|
+
| Rule | Detail |
|
|
81
|
+
|------|--------|
|
|
82
|
+
| Max parallel teams | 4 concurrent (R009) |
|
|
83
|
+
| Batching | T1-T4 → T5-T8 → T9-T10 |
|
|
84
|
+
| Agent Teams gate | If enabled, use for cross-team coordination (R018) |
|
|
85
|
+
| Orchestrator only | Main conversation manages all phases (R010) |
|
|
86
|
+
| Ecomode | Auto-activate for team result aggregation (R013) |
|
|
87
|
+
| Intent display | Show research plan before execution (R015) |
|
|
88
|
+
|
|
89
|
+
## Model Selection
|
|
90
|
+
|
|
91
|
+
| Phase | Model | Rationale |
|
|
92
|
+
|-------|-------|-----------|
|
|
93
|
+
| Phase 1 (Research teams) | sonnet | Balanced speed/quality for parallel research |
|
|
94
|
+
| Phase 2 (opus verification) | opus | Deep reasoning for cross-verification |
|
|
95
|
+
| Phase 2 (codex verification) | codex xhigh | Code-level validation of technical claims |
|
|
96
|
+
| Phase 3 (Synthesis) | opus | Complex multi-source reasoning and taxonomy |
|
|
97
|
+
|
|
98
|
+
## Team Prompt Templates
|
|
99
|
+
|
|
100
|
+
### Breadth Teams (T1, T3, T5, T7, T9)
|
|
101
|
+
|
|
102
|
+
```
|
|
103
|
+
Role: {domain} breadth analyst
|
|
104
|
+
Scope: {topic}
|
|
105
|
+
|
|
106
|
+
Tasks:
|
|
107
|
+
1. Survey the full landscape of {focus area}
|
|
108
|
+
2. Catalog all {artifacts/components/alternatives} found
|
|
109
|
+
3. Enumerate {structure/surface/compatibility/options/patterns}
|
|
110
|
+
4. Produce structured inventory with confidence levels
|
|
111
|
+
|
|
112
|
+
Output format:
|
|
113
|
+
- Inventory table (item | description | confidence)
|
|
114
|
+
- Coverage map (what was examined vs what remains)
|
|
115
|
+
- Key observations (max 5)
|
|
116
|
+
- Questions for depth team
|
|
117
|
+
```
|
|
118
|
+
|
|
119
|
+
### Depth Teams (T2, T4, T6, T8, T10)
|
|
120
|
+
|
|
121
|
+
```
|
|
122
|
+
Role: {domain} depth analyst
|
|
123
|
+
Scope: {topic}
|
|
124
|
+
|
|
125
|
+
Tasks:
|
|
126
|
+
1. Deep-dive into {specific patterns/risks/efforts/benchmarks/feasibility}
|
|
127
|
+
2. Validate assumptions from breadth analysis (if available)
|
|
128
|
+
3. Quantify {quality/risk/effort/performance/value}
|
|
129
|
+
4. Produce evidence-backed assessment
|
|
130
|
+
|
|
131
|
+
Output format:
|
|
132
|
+
- Detailed analysis (claim | evidence | confidence)
|
|
133
|
+
- Validated/invalidated assumptions
|
|
134
|
+
- Quantified metrics where possible
|
|
135
|
+
- Risk/opportunity assessment
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
## Verification Loop Detail
|
|
139
|
+
|
|
140
|
+
```
|
|
141
|
+
Round N:
|
|
142
|
+
Input: All 10 team findings + previous round feedback (if any)
|
|
143
|
+
Step 1: opus reviews each team pair for:
|
|
144
|
+
- Internal consistency (breadth ↔ depth alignment)
|
|
145
|
+
- Cross-domain consistency (security ↔ architecture)
|
|
146
|
+
- Evidence quality (claims without backing)
|
|
147
|
+
Step 2: codex-exec validates technical claims:
|
|
148
|
+
- Code patterns actually exist
|
|
149
|
+
- Benchmarks are reproducible
|
|
150
|
+
- Dependencies resolve correctly
|
|
151
|
+
Step 3: Compile contradiction list
|
|
152
|
+
- 0 contradictions → CONVERGED
|
|
153
|
+
- >0 contradictions → feedback to relevant teams → Round N+1
|
|
154
|
+
```
|
|
155
|
+
|
|
156
|
+
## Output Format
|
|
157
|
+
|
|
158
|
+
```markdown
|
|
159
|
+
# Research Report: {topic}
|
|
160
|
+
|
|
161
|
+
## Executive Summary
|
|
162
|
+
{2-3 paragraph overview of findings, key recommendation, confidence level}
|
|
163
|
+
|
|
164
|
+
## Team Findings
|
|
165
|
+
|
|
166
|
+
### Architecture (Teams 1-2)
|
|
167
|
+
**Breadth**: {inventory summary}
|
|
168
|
+
**Depth**: {analysis summary}
|
|
169
|
+
**Confidence**: {High/Medium/Low}
|
|
170
|
+
|
|
171
|
+
### Security (Teams 3-4)
|
|
172
|
+
**Breadth**: {attack surface summary}
|
|
173
|
+
**Depth**: {risk assessment summary}
|
|
174
|
+
**Confidence**: {High/Medium/Low}
|
|
175
|
+
|
|
176
|
+
### Integration (Teams 5-6)
|
|
177
|
+
**Breadth**: {compatibility summary}
|
|
178
|
+
**Depth**: {effort/value summary}
|
|
179
|
+
**Confidence**: {High/Medium/Low}
|
|
180
|
+
|
|
181
|
+
### Comparative (Teams 7-8)
|
|
182
|
+
**Breadth**: {landscape summary}
|
|
183
|
+
**Depth**: {benchmark summary}
|
|
184
|
+
**Confidence**: {High/Medium/Low}
|
|
185
|
+
|
|
186
|
+
### Innovation (Teams 9-10)
|
|
187
|
+
**Breadth**: {pattern summary}
|
|
188
|
+
**Depth**: {feasibility summary}
|
|
189
|
+
**Confidence**: {High/Medium/Low}
|
|
190
|
+
|
|
191
|
+
## Cross-Verification Results
|
|
192
|
+
**Rounds completed**: {N}
|
|
193
|
+
**Contradictions found**: {count}
|
|
194
|
+
**Resolution**: {summary of how contradictions were resolved}
|
|
195
|
+
|
|
196
|
+
## Taxonomy
|
|
197
|
+
|
|
198
|
+
### ADOPT (Safe + High Value)
|
|
199
|
+
| Item | Rationale | Confidence |
|
|
200
|
+
|------|-----------|------------|
|
|
201
|
+
|
|
202
|
+
### ADAPT (Valuable but needs modification)
|
|
203
|
+
| Item | Required Changes | Effort |
|
|
204
|
+
|------|-----------------|--------|
|
|
205
|
+
|
|
206
|
+
### AVOID (Risk > Value)
|
|
207
|
+
| Item | Risk | Alternatives |
|
|
208
|
+
|------|------|-------------|
|
|
209
|
+
|
|
210
|
+
## Action Items
|
|
211
|
+
| # | Item | Effort | Priority | Owner |
|
|
212
|
+
|---|------|--------|----------|-------|
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
## Fallback Behavior
|
|
216
|
+
|
|
217
|
+
| Scenario | Fallback |
|
|
218
|
+
|----------|----------|
|
|
219
|
+
| codex-exec unavailable | opus-only verification (still min 2 rounds) |
|
|
220
|
+
| Agent Teams unavailable | Standard Agent tool with R009 batching |
|
|
221
|
+
| Partial team failure | Synthesize from available results, note gaps in report |
|
|
222
|
+
| GitHub issue creation fails | Output report to conversation only |
|
|
223
|
+
|
|
224
|
+
## Display Format
|
|
225
|
+
|
|
226
|
+
Before execution:
|
|
227
|
+
```
|
|
228
|
+
[Research Plan] {topic}
|
|
229
|
+
├── Phase 1: 10 teams (3 batches × 4/4/2)
|
|
230
|
+
├── Phase 2: Cross-verification (2-5 rounds, opus + codex)
|
|
231
|
+
├── Phase 3: Synthesis (opus)
|
|
232
|
+
└── Phase 4: Report + GitHub issue
|
|
233
|
+
|
|
234
|
+
Estimated: {time} | Teams: 10 | Models: sonnet → opus → codex
|
|
235
|
+
Execute? [Y/n]
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
Progress:
|
|
239
|
+
```
|
|
240
|
+
[Research Progress] Phase 1 — Batch 2/3
|
|
241
|
+
├── T1-T4: ✓ Complete
|
|
242
|
+
├── T5-T8: → Running
|
|
243
|
+
└── T9-T10: ○ Pending
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
## Integration
|
|
247
|
+
|
|
248
|
+
| Rule | Integration |
|
|
249
|
+
|------|-------------|
|
|
250
|
+
| R009 | Max 4 parallel teams; batch in groups of 4/4/2 |
|
|
251
|
+
| R010 | Orchestrator manages all phases; teams are subagents |
|
|
252
|
+
| R013 | Ecomode auto-activates for 10-team aggregation |
|
|
253
|
+
| R015 | Display research plan with team breakdown before execution |
|
|
254
|
+
| R018 | Agent Teams for cross-team coordination if enabled |
|
|
255
|
+
| dag-orchestration | Phase sequencing follows DAG pattern |
|
|
256
|
+
| result-aggregation | Team results formatted per aggregation skill |
|
|
257
|
+
| multi-model-verification | Phase 2 uses multi-model verification pattern |
|
package/templates/manifest.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
|
-
"version": "0.
|
|
3
|
-
"lastUpdated": "2026-03-
|
|
2
|
+
"version": "0.24.0",
|
|
3
|
+
"lastUpdated": "2026-03-09T00:00:00.000Z",
|
|
4
4
|
"components": [
|
|
5
5
|
{
|
|
6
6
|
"name": "rules",
|
|
@@ -12,13 +12,13 @@
|
|
|
12
12
|
"name": "agents",
|
|
13
13
|
"path": ".claude/agents",
|
|
14
14
|
"description": "AI agent definitions (flat .md files with prefixes)",
|
|
15
|
-
"files":
|
|
15
|
+
"files": 42
|
|
16
16
|
},
|
|
17
17
|
{
|
|
18
18
|
"name": "skills",
|
|
19
19
|
"path": ".claude/skills",
|
|
20
20
|
"description": "Reusable skill modules (includes slash commands)",
|
|
21
|
-
"files":
|
|
21
|
+
"files": 66
|
|
22
22
|
},
|
|
23
23
|
{
|
|
24
24
|
"name": "guides",
|