super-opencode 1.1.2 → 1.2.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/.opencode/agents/architect.md +54 -31
- package/.opencode/agents/backend.md +61 -34
- package/.opencode/agents/data-agent.md +422 -0
- package/.opencode/agents/devops-agent.md +331 -0
- package/.opencode/agents/frontend.md +63 -36
- package/.opencode/agents/mobile-agent.md +636 -0
- package/.opencode/agents/optimizer.md +25 -18
- package/.opencode/agents/pm-agent.md +114 -50
- package/.opencode/agents/quality.md +36 -29
- package/.opencode/agents/researcher.md +30 -21
- package/.opencode/agents/reviewer.md +39 -32
- package/.opencode/agents/security.md +42 -34
- package/.opencode/agents/writer.md +42 -31
- package/.opencode/commands/soc-analyze.md +55 -31
- package/.opencode/commands/soc-brainstorm.md +48 -26
- package/.opencode/commands/soc-cleanup.md +47 -25
- package/.opencode/commands/soc-deploy.md +271 -0
- package/.opencode/commands/soc-design.md +51 -26
- package/.opencode/commands/soc-explain.md +46 -23
- package/.opencode/commands/soc-git.md +47 -25
- package/.opencode/commands/soc-help.md +35 -14
- package/.opencode/commands/soc-implement.md +59 -29
- package/.opencode/commands/soc-improve.md +42 -20
- package/.opencode/commands/soc-onboard.md +329 -0
- package/.opencode/commands/soc-plan.md +215 -0
- package/.opencode/commands/soc-pm.md +40 -18
- package/.opencode/commands/soc-research.md +43 -20
- package/.opencode/commands/soc-review.md +39 -18
- package/.opencode/commands/soc-test.md +43 -21
- package/.opencode/commands/soc-validate.md +221 -0
- package/.opencode/commands/soc-workflow.md +38 -17
- package/.opencode/skills/confidence-check/SKILL.md +26 -19
- package/.opencode/skills/debug-protocol/SKILL.md +27 -17
- package/.opencode/skills/decision-log/SKILL.md +236 -0
- package/.opencode/skills/doc-sync/SKILL.md +345 -0
- package/.opencode/skills/package-manager/SKILL.md +502 -0
- package/.opencode/skills/package-manager/scripts/README.md +106 -0
- package/.opencode/skills/package-manager/scripts/detect-package-manager.sh +796 -0
- package/.opencode/skills/reflexion/SKILL.md +18 -11
- package/.opencode/skills/security-audit/SKILL.md +19 -14
- package/.opencode/skills/self-check/SKILL.md +30 -14
- package/.opencode/skills/simplification/SKILL.md +19 -5
- package/.opencode/skills/tech-debt/SKILL.md +245 -0
- package/LICENSE +1 -1
- package/README.md +126 -9
- package/dist/cli.js +143 -41
- package/package.json +27 -12
- package/.opencode/settings.json +0 -3
|
@@ -5,9 +5,11 @@ description: Project management and orchestration
|
|
|
5
5
|
# /soc-pm
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
The `/soc-pm` command is the "Orchestrator." It manages the high-level state of the project. It uses the PDCA (Plan-Do-Check-Act) cycle to break down complex goals into `tasks`, track progress, and unblock other agents. It is the owner of `task.md`.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command is the primary interface for the `pm-agent`.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Action |
|
|
@@ -17,34 +19,41 @@ The command is the primary interface for the `pm-agent`.
|
|
|
17
19
|
| **Verify Work** | `review` | `[pm-agent]` | Check deliverables |
|
|
18
20
|
|
|
19
21
|
## 3. Usage & Arguments
|
|
22
|
+
|
|
20
23
|
```bash
|
|
21
24
|
/soc-pm [action] [target] [flags]
|
|
22
25
|
```
|
|
23
26
|
|
|
24
27
|
### Arguments
|
|
25
|
-
|
|
26
|
-
-
|
|
28
|
+
|
|
29
|
+
- **`[action]`**: `plan`, `status`, `review`, `checkpoint`.
|
|
30
|
+
- **`[target]`**: (Optional) Specific feature or milestone.
|
|
27
31
|
|
|
28
32
|
### Flags
|
|
29
|
-
|
|
33
|
+
|
|
34
|
+
- **`--detail`**: Show full task history.
|
|
30
35
|
|
|
31
36
|
## 4. Behavioral Flow (Orchestration)
|
|
32
37
|
|
|
33
38
|
### Phase 1: Plan (The Roadmap)
|
|
34
|
-
|
|
35
|
-
|
|
39
|
+
|
|
40
|
+
1. **Analyze**: Read User Request -> Break into Epics/Stories.
|
|
41
|
+
2. **Document**: updates `task.md` with checkboxes `[ ]`.
|
|
36
42
|
|
|
37
43
|
### Phase 2: Do (Tracking)
|
|
38
|
-
|
|
39
|
-
-
|
|
44
|
+
|
|
45
|
+
- Monitors tool usage.
|
|
46
|
+
- Updates task status to `[/]` (In Progress) or `[x]` (Done).
|
|
40
47
|
|
|
41
48
|
### Phase 3: Check (The Audit)
|
|
42
|
-
|
|
43
|
-
-
|
|
49
|
+
|
|
50
|
+
- **Review**: Did we meet the acceptance criteria?
|
|
51
|
+
- **Reflect**: Use `reflexion` skill if blocked.
|
|
44
52
|
|
|
45
53
|
## 5. Output Guidelines (The Contract)
|
|
46
54
|
|
|
47
55
|
### Project Status Report
|
|
56
|
+
|
|
48
57
|
```markdown
|
|
49
58
|
## Project Status: [Phase]
|
|
50
59
|
|
|
@@ -64,36 +73,49 @@ The command is the primary interface for the `pm-agent`.
|
|
|
64
73
|
## 6. Examples
|
|
65
74
|
|
|
66
75
|
### A. Initial Planning
|
|
76
|
+
|
|
67
77
|
```bash
|
|
68
78
|
/soc-pm plan "Build User Dashboard"
|
|
69
79
|
```
|
|
80
|
+
|
|
70
81
|
*Effect:* Creates `task.md` with breakdown: "Design UI", "Setup API", "Integrate Frontend".
|
|
71
82
|
|
|
72
83
|
### B. Status Update
|
|
84
|
+
|
|
73
85
|
```bash
|
|
74
86
|
/soc-pm status
|
|
75
87
|
```
|
|
88
|
+
|
|
76
89
|
*Effect:* Reads current state and summarizes what has been done vs what is left.
|
|
77
90
|
|
|
78
91
|
## 7. Dependencies & Capabilities
|
|
79
92
|
|
|
80
93
|
### Agents
|
|
81
|
-
|
|
82
|
-
-
|
|
94
|
+
|
|
95
|
+
- **PM Agent**: `@[.opencode/agents/pm-agent.md]` - Self-referential.
|
|
96
|
+
- **All Agents**: Delegates work to them.
|
|
83
97
|
|
|
84
98
|
### Skills
|
|
85
|
-
|
|
99
|
+
|
|
100
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - For unblocking the team.
|
|
86
101
|
|
|
87
102
|
### MCP Integration
|
|
88
|
-
|
|
103
|
+
|
|
104
|
+
- **`filesystem`**: Managing `task.md` and `implementation_plan.md`.
|
|
89
105
|
|
|
90
106
|
## 8. Boundaries
|
|
91
107
|
|
|
92
108
|
**Will:**
|
|
93
|
-
|
|
94
|
-
-
|
|
95
|
-
-
|
|
109
|
+
|
|
110
|
+
- Manage `task.md`.
|
|
111
|
+
- Delegate tasks to other agents.
|
|
112
|
+
- Track overall progress.
|
|
96
113
|
|
|
97
114
|
**Will Not:**
|
|
98
|
-
|
|
99
|
-
-
|
|
115
|
+
|
|
116
|
+
- **Write Code**: It manages those who write code.
|
|
117
|
+
- **Solve Technical Bugs**: It assigns `[backend]` or `[quality]` to solve them.
|
|
118
|
+
|
|
119
|
+
## User Instruction
|
|
120
|
+
|
|
121
|
+
The user have executed the `/soc-pm` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then perform the specified action (plan, status, review, or checkpoint) on the given target (or entire project if none specified), delegate to the pm-agent to manage the `task.md` file through the PDCA cycle—breaking down requests into epics and stories when planning, monitoring progress and updating task statuses during tracking, and verifying deliverables against acceptance criteria when reviewing—and generate a comprehensive project status report showing completed tasks, current focus areas, and any blockers.
|
|
@@ -5,9 +5,11 @@ description: Deep web research and documentation lookup
|
|
|
5
5
|
# /soc-research
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
The `/soc-research` command is the "Archive." It scours the web and internal docs to find definitive truth. It operates on the "Cite or Die" principle: every claim must optionally be backed by a source. It does not hallucinate; it verifies.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command routes to the `researcher` agent.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Tool Used |
|
|
@@ -17,35 +19,42 @@ The command routes to the `researcher` agent.
|
|
|
17
19
|
| **Deep Dive** | `--depth deep` | `[researcher]` | Recursive Search |
|
|
18
20
|
|
|
19
21
|
## 3. Usage & Arguments
|
|
22
|
+
|
|
20
23
|
```bash
|
|
21
24
|
/soc-research [topic] [flags]
|
|
22
25
|
```
|
|
23
26
|
|
|
24
27
|
### Arguments
|
|
25
|
-
|
|
28
|
+
|
|
29
|
+
- **`[topic]`**: The question or technology to investigate.
|
|
26
30
|
|
|
27
31
|
### Flags
|
|
28
|
-
|
|
29
|
-
-
|
|
32
|
+
|
|
33
|
+
- **`--depth [quick|standard|deep]`**: (Default: `standard`).
|
|
34
|
+
- **`--domain [url]`**: Restrict search to specific site (e.g., `github.com`).
|
|
30
35
|
|
|
31
36
|
## 4. Behavioral Flow (Orchestration)
|
|
32
37
|
|
|
33
38
|
### Phase 1: Parsing
|
|
34
|
-
|
|
35
|
-
|
|
39
|
+
|
|
40
|
+
1. **Decompose**: Break query into keywords.
|
|
41
|
+
2. **Select**: Choose tool (`tavily` for web, `context7` for docs).
|
|
36
42
|
|
|
37
43
|
### Phase 2: Execution (The Hunt)
|
|
38
|
-
|
|
39
|
-
-
|
|
40
|
-
-
|
|
44
|
+
|
|
45
|
+
- **Broad Search**: Find candidate URLs.
|
|
46
|
+
- **Deep Read**: Scrape content.
|
|
47
|
+
- **Synthesize**: Cross-reference facts to find consensus.
|
|
41
48
|
|
|
42
49
|
### Phase 3: Reporting
|
|
43
|
-
|
|
44
|
-
-
|
|
50
|
+
|
|
51
|
+
- Construct "Review of Literature."
|
|
52
|
+
- Flag conflicting info ("Source A says X, Source B says Y").
|
|
45
53
|
|
|
46
54
|
## 5. Output Guidelines (The Contract)
|
|
47
55
|
|
|
48
56
|
### Research Report
|
|
57
|
+
|
|
49
58
|
```markdown
|
|
50
59
|
## Research: [Topic]
|
|
51
60
|
|
|
@@ -64,7 +73,9 @@ const x = new Library();
|
|
|
64
73
|
```
|
|
65
74
|
|
|
66
75
|
### Conflicting Info
|
|
67
|
-
|
|
76
|
+
|
|
77
|
+
- StackOverflow suggests X, but Official Docs say Y (Deprecated).
|
|
78
|
+
|
|
68
79
|
```
|
|
69
80
|
|
|
70
81
|
## 6. Examples
|
|
@@ -73,33 +84,45 @@ const x = new Library();
|
|
|
73
84
|
```bash
|
|
74
85
|
/soc-research "Best React form library 2025" --depth deep
|
|
75
86
|
```
|
|
87
|
+
|
|
76
88
|
*Effect:* Compares React Hook Form vs TanStack Form based on bundle size and weekly downloads.
|
|
77
89
|
|
|
78
90
|
### B. Bug Hunting
|
|
91
|
+
|
|
79
92
|
```bash
|
|
80
93
|
/soc-research "Prisma error P2002" --domain github.com
|
|
81
94
|
```
|
|
95
|
+
|
|
82
96
|
*Effect:* Finds specific GitHub issues related to Unique Constraint violations.
|
|
83
97
|
|
|
84
98
|
## 7. Dependencies & Capabilities
|
|
85
99
|
|
|
86
100
|
### Agents
|
|
87
|
-
|
|
101
|
+
|
|
102
|
+
- **Researcher**: `@[.opencode/agents/researcher.md]` - Primary persona.
|
|
88
103
|
|
|
89
104
|
### Skills
|
|
90
|
-
|
|
105
|
+
|
|
106
|
+
- **Sequential Thinking**: `@[.opencode/skills/sequential-thinking/SKILL.md]` - For resolving conflicts.
|
|
91
107
|
|
|
92
108
|
### MCP Integration
|
|
93
|
-
|
|
94
|
-
-
|
|
109
|
+
|
|
110
|
+
- **`tavily`**: Real-time web search.
|
|
111
|
+
- **`context7`**: Documentation retrieval.
|
|
95
112
|
|
|
96
113
|
## 8. Boundaries
|
|
97
114
|
|
|
98
115
|
**Will:**
|
|
99
|
-
|
|
100
|
-
-
|
|
101
|
-
-
|
|
116
|
+
|
|
117
|
+
- Find official documentation.
|
|
118
|
+
- Summarize community consensus.
|
|
119
|
+
- Provide direct links.
|
|
102
120
|
|
|
103
121
|
**Will Not:**
|
|
104
|
-
|
|
105
|
-
-
|
|
122
|
+
|
|
123
|
+
- **Execute Info**: It finds the code, but does not run it.
|
|
124
|
+
- **Make Decisions**: It informs decisions, but `architect` decides.
|
|
125
|
+
|
|
126
|
+
## User Instruction
|
|
127
|
+
|
|
128
|
+
The user have executed the `/soc-research` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the researcher agent to investigate the specified topic, selecting the appropriate research depth (quick, standard, or deep) and tools (tavily for web search, context7 for documentation) based on flags and topic type, decompose the query into searchable keywords, gather information from multiple sources while cross-referencing facts to find consensus, and synthesize findings into a comprehensive research report with cited sources, key findings, code patterns, and flagging of any conflicting information.
|
|
@@ -5,9 +5,11 @@ description: Code review and quality assessment
|
|
|
5
5
|
# /soc-review
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
The `/soc-review` command is the "Critic." It acts as a second pair of eyes before code is merged. It checks for logic errors, security vulnerabilities (OWASP), and adherence to the "Intentional Minimalism" design philosophy.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command routes to specialized reviewers.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Focus |
|
|
@@ -17,35 +19,42 @@ The command routes to specialized reviewers.
|
|
|
17
19
|
| **Style/Lint** | `--quick` | `[reviewer]` | Formatting, Naming |
|
|
18
20
|
|
|
19
21
|
## 3. Usage & Arguments
|
|
22
|
+
|
|
20
23
|
```bash
|
|
21
24
|
/soc-review [target] [flags]
|
|
22
25
|
```
|
|
23
26
|
|
|
24
27
|
### Arguments
|
|
25
|
-
|
|
28
|
+
|
|
29
|
+
- **`[target]`**: File, directory, or Pull Request ID to review.
|
|
26
30
|
|
|
27
31
|
### Flags
|
|
28
|
-
|
|
29
|
-
-
|
|
32
|
+
|
|
33
|
+
- **`--scope [full|quick]`**: (Default: `full`).
|
|
34
|
+
- **`--security`**: Triggers explicit security scan protocol.
|
|
30
35
|
|
|
31
36
|
## 4. Behavioral Flow (Orchestration)
|
|
32
37
|
|
|
33
38
|
### Phase 1: Context Loading
|
|
34
|
-
|
|
35
|
-
|
|
39
|
+
|
|
40
|
+
1. **Read**: Load the target code.
|
|
41
|
+
2. **Context**: Load `implementation_plan.md` (to see what was intended).
|
|
36
42
|
|
|
37
43
|
### Phase 2: Analysis (The Audit)
|
|
38
|
-
|
|
39
|
-
-
|
|
40
|
-
-
|
|
44
|
+
|
|
45
|
+
- **Static Analysis**: Grep for "smells" (`any`, `eval`, `console.log`).
|
|
46
|
+
- **Logic Check**: Trace variable data flow.
|
|
47
|
+
- **Design Check**: Does it match the Project Persona (Minimalism)?
|
|
41
48
|
|
|
42
49
|
### Phase 3: Reporting
|
|
43
|
-
|
|
44
|
-
-
|
|
50
|
+
|
|
51
|
+
- Categorize findings by Severity (Critical, Warning, Info).
|
|
52
|
+
- Reject if Critical issues exist.
|
|
45
53
|
|
|
46
54
|
## 5. Output Guidelines (The Contract)
|
|
47
55
|
|
|
48
56
|
### Code Review
|
|
57
|
+
|
|
49
58
|
```markdown
|
|
50
59
|
## Review: [Target]
|
|
51
60
|
|
|
@@ -70,33 +79,45 @@ Solid logic, but the SQL injection must be fixed before merge.
|
|
|
70
79
|
## 6. Examples
|
|
71
80
|
|
|
72
81
|
### A. Pre-Merge Review
|
|
82
|
+
|
|
73
83
|
```bash
|
|
74
84
|
/soc-review src/features/payments --security
|
|
75
85
|
```
|
|
86
|
+
|
|
76
87
|
*Effect:* Triggers `security` agent to specifically look for PCI compliance issues and raw secrets.
|
|
77
88
|
|
|
78
89
|
### B. Quick Sanity Check
|
|
90
|
+
|
|
79
91
|
```bash
|
|
80
92
|
/soc-review --quick
|
|
81
93
|
```
|
|
94
|
+
|
|
82
95
|
*Effect:* Scans changed files for obvious errors (lint, types) before commit.
|
|
83
96
|
|
|
84
97
|
## 7. Dependencies & Capabilities
|
|
85
98
|
|
|
86
99
|
### Agents
|
|
87
|
-
|
|
88
|
-
-
|
|
100
|
+
|
|
101
|
+
- **Reviewer**: `@[.opencode/agents/reviewer.md]` - General code quality.
|
|
102
|
+
- **Security**: `@[.opencode/agents/security.md]` - Vulnerability scanning.
|
|
89
103
|
|
|
90
104
|
### Skills
|
|
91
|
-
|
|
105
|
+
|
|
106
|
+
- **Security Audit**: `@[.opencode/skills/security-audit/SKILL.md]` - Automated checking.
|
|
92
107
|
|
|
93
108
|
## 8. Boundaries
|
|
94
109
|
|
|
95
110
|
**Will:**
|
|
96
|
-
|
|
97
|
-
-
|
|
98
|
-
-
|
|
111
|
+
|
|
112
|
+
- Point out specific lines of code.
|
|
113
|
+
- Suggest concrete fixes.
|
|
114
|
+
- Block "unsafe" code.
|
|
99
115
|
|
|
100
116
|
**Will Not:**
|
|
101
|
-
|
|
102
|
-
-
|
|
117
|
+
|
|
118
|
+
- **Fix the code**: It only comments. Use `/soc-improve` to fix.
|
|
119
|
+
- **Judge Aesthetics**: Unless it violates "Intentional Minimalism."
|
|
120
|
+
|
|
121
|
+
## User Instruction
|
|
122
|
+
|
|
123
|
+
The user have executed the `/soc-review` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate reviewer agent based on the specified scope and security flag, load the target code and associated context (such as implementation_plan.md), perform static analysis to identify code smells, trace variable data flow for logic verification, check for security vulnerabilities when `--security` is specified, categorize findings by severity (Critical, Warning, Info), provide specific line-by-line feedback with concrete fix suggestions, generate a comprehensive review report with verdict and summary, and block merges if critical issues are detected.
|
|
@@ -5,9 +5,11 @@ description: Test generation and execution
|
|
|
5
5
|
# /soc-test
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
The `/soc-test` command is the "Quality Gatekeeper." It generates, runs, and reports on tests. It ensures that no code is shipped without verification. It triggers the `quality` agent to write unit, integration, or E2E tests and uses the `reviewer` agent to analyze coverage.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command determines the scope and tool based on the arguments.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Tool Used |
|
|
@@ -18,39 +20,46 @@ The command determines the scope and tool based on the arguments.
|
|
|
18
20
|
| **Coverage Check**| `--coverage` | `[reviewer]` | Istanbul/C8 |
|
|
19
21
|
|
|
20
22
|
## 3. Usage & Arguments
|
|
23
|
+
|
|
21
24
|
```bash
|
|
22
25
|
/soc-test [target] [flags]
|
|
23
26
|
```
|
|
24
27
|
|
|
25
28
|
### Arguments
|
|
26
|
-
|
|
29
|
+
|
|
30
|
+
- **`[target]`**: File or directory to test (e.g., `src/utils/math.ts`).
|
|
27
31
|
|
|
28
32
|
### Flags
|
|
29
|
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
33
|
+
|
|
34
|
+
- **`--type [unit|integration|e2e]`**: (Optional) Default: `unit`.
|
|
35
|
+
- **`--coverage`**: Generates a coverage report.
|
|
36
|
+
- **`--watch`**: Runs in watch mode (interactive).
|
|
32
37
|
|
|
33
38
|
## 4. Behavioral Flow (Orchestration)
|
|
34
39
|
|
|
35
40
|
### Phase 1: Context & Gap Analysis
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
41
|
+
|
|
42
|
+
1. **Read**: Analyzes the source code in `[target]`.
|
|
43
|
+
2. **Scan**: Checks for existing `.test.ts` or `_test.py` files.
|
|
44
|
+
3. **Plan**: Identifies missing test cases (Edge cases, Error states, Happy path).
|
|
39
45
|
|
|
40
46
|
### Phase 2: Generation (The Writer)
|
|
47
|
+
|
|
41
48
|
The command prompts the `quality` agent:
|
|
42
49
|
> "Generate **[Type]** tests for **[Target]**.
|
|
43
50
|
> Ensure **[Coverage]**.
|
|
44
51
|
> Mock dependencies: **[External Services]**."
|
|
45
52
|
|
|
46
53
|
### Phase 3: Execution (The Runner)
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
54
|
+
|
|
55
|
+
1. **Run**: Executes the test command (e.g., `npm test`).
|
|
56
|
+
2. **Report**: Captures `stdout/stderr`.
|
|
57
|
+
3. **Reflect**: If tests fail, it suggests fixes (or fixes them if in `implement` mode).
|
|
50
58
|
|
|
51
59
|
## 5. Output Guidelines (The Contract)
|
|
52
60
|
|
|
53
61
|
### Test Execution Report
|
|
62
|
+
|
|
54
63
|
```markdown
|
|
55
64
|
## Test Report: [Target]
|
|
56
65
|
|
|
@@ -72,38 +81,51 @@ The command prompts the `quality` agent:
|
|
|
72
81
|
## 6. Examples
|
|
73
82
|
|
|
74
83
|
### A. Unit Test Generation
|
|
84
|
+
|
|
75
85
|
```bash
|
|
76
86
|
/soc-test src/utils/currency.ts --type unit
|
|
77
87
|
```
|
|
88
|
+
|
|
78
89
|
*Effect:* Generates `src/utils/currency.test.ts` covering rounding logic and currency codes.
|
|
79
90
|
|
|
80
91
|
### B. Integration Test
|
|
92
|
+
|
|
81
93
|
```bash
|
|
82
94
|
/soc-test src/api/auth --type integration
|
|
83
95
|
```
|
|
96
|
+
|
|
84
97
|
*Effect:* Sets up a mock database and tests the `/login` flow including DB persistence.
|
|
85
98
|
|
|
86
99
|
## 7. Dependencies & Capabilities
|
|
87
100
|
|
|
88
101
|
### Agents
|
|
89
|
-
|
|
90
|
-
-
|
|
102
|
+
|
|
103
|
+
- **Quality Assurance**: `@[.opencode/agents/quality.md]` - Primary agent for test generation.
|
|
104
|
+
- **Reviewer**: `@[.opencode/agents/reviewer.md]` - For evaluating test coverage and effectiveness.
|
|
91
105
|
|
|
92
106
|
### Skills
|
|
93
|
-
|
|
94
|
-
-
|
|
107
|
+
|
|
108
|
+
- **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Verifying test results against requirements.
|
|
109
|
+
- **Debug Protocol**: `@[.opencode/skills/debug-protocol/SKILL.md]` - Analyzing test failures.
|
|
95
110
|
|
|
96
111
|
### MCP Integration
|
|
97
|
-
|
|
98
|
-
-
|
|
112
|
+
|
|
113
|
+
- **`run_command`**: Executing test runners (Jest, Vitest, Pytest).
|
|
114
|
+
- **`filesystem`**: processing integration test artifacts or coverage reports.
|
|
99
115
|
|
|
100
116
|
## 8. Boundaries
|
|
101
117
|
|
|
102
118
|
**Will:**
|
|
103
|
-
|
|
104
|
-
-
|
|
105
|
-
-
|
|
119
|
+
|
|
120
|
+
- Generate standard test files using the project's framework.
|
|
121
|
+
- Run tests and parse output.
|
|
122
|
+
- Mock external dependencies (S3, Stripe) to prevent flake.
|
|
106
123
|
|
|
107
124
|
**Will Not:**
|
|
108
|
-
|
|
109
|
-
-
|
|
125
|
+
|
|
126
|
+
- **Guarantee 100% Logic Coverage**: It covers code paths, not necessarily business intent.
|
|
127
|
+
- **Debug Production**: Tests run in `test` environment only.
|
|
128
|
+
|
|
129
|
+
## User Instruction
|
|
130
|
+
|
|
131
|
+
The user have executed the `/soc-test` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the quality agent to generate and run tests for the specified target, analyze the source code to understand what needs testing and check for existing test files, determine the test type (unit, integration, or e2e) based on flags or code context, generate comprehensive test cases covering happy paths, edge cases, and error states, mock external dependencies to prevent test flakiness, execute the test runner and capture output, analyze any test failures using the debug protocol skill, generate a coverage report when `--coverage` is specified, and provide a comprehensive test execution report showing status, failures with diagnosis, and coverage metrics.
|