super-opencode 1.1.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 +84 -0
- package/.opencode/agents/backend.md +124 -0
- package/.opencode/agents/frontend.md +137 -0
- package/.opencode/agents/optimizer.md +51 -0
- package/.opencode/agents/pm-agent.md +105 -0
- package/.opencode/agents/quality.md +107 -0
- package/.opencode/agents/researcher.md +105 -0
- package/.opencode/agents/reviewer.md +80 -0
- package/.opencode/agents/security.md +107 -0
- package/.opencode/agents/writer.md +136 -0
- package/.opencode/commands/soc-analyze.md +137 -0
- package/.opencode/commands/soc-brainstorm.md +110 -0
- package/.opencode/commands/soc-cleanup.md +107 -0
- package/.opencode/commands/soc-design.md +122 -0
- package/.opencode/commands/soc-explain.md +113 -0
- package/.opencode/commands/soc-git.md +104 -0
- package/.opencode/commands/soc-help.md +94 -0
- package/.opencode/commands/soc-implement.md +112 -0
- package/.opencode/commands/soc-improve.md +105 -0
- package/.opencode/commands/soc-pm.md +99 -0
- package/.opencode/commands/soc-research.md +105 -0
- package/.opencode/commands/soc-review.md +102 -0
- package/.opencode/commands/soc-test.md +109 -0
- package/.opencode/commands/soc-workflow.md +97 -0
- package/.opencode/settings.json +3 -0
- package/.opencode/skills/confidence-check/SKILL.md +97 -0
- package/.opencode/skills/debug-protocol/SKILL.md +83 -0
- package/.opencode/skills/reflexion/SKILL.md +108 -0
- package/.opencode/skills/security-audit/SKILL.md +90 -0
- package/.opencode/skills/self-check/SKILL.md +95 -0
- package/.opencode/skills/simplification/SKILL.md +92 -0
- package/AGENTS.md +175 -0
- package/LICENSE +21 -0
- package/README.md +288 -0
- package/dist/cli.js +403 -0
- package/package.json +45 -0
|
@@ -0,0 +1,107 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Systematically clean up code, remove dead code, and optimize project structure"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-cleanup
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
The `/soc-cleanup` command is the "Janitor" of the codebase. It safely identifies and removes technical debt, unused exports, and dead code. It operates in two modes: `Safe` (conservative) and `Aggressive` (deep cleaning). Its primary directive is "Do No Harm."
|
|
9
|
+
|
|
10
|
+
## 2. Triggers & Routing
|
|
11
|
+
The command routes cleanup tasks based on the `--type` flag.
|
|
12
|
+
|
|
13
|
+
| Trigger Scenario | Flag | Target Agent | Tool Used |
|
|
14
|
+
| :--- | :--- | :--- | :--- |
|
|
15
|
+
| **Dead Code** | `--type code` | `[quality]` | TSPrune, Knip |
|
|
16
|
+
| **Unused Imports** | `--type imports` | `[quality]` | ESLint/Birome |
|
|
17
|
+
| **File Structure** | `--type files` | `[architect]` | Filesystem Analysis |
|
|
18
|
+
| **Deep Clean** | `--type all` | `[quality]` | All tools |
|
|
19
|
+
|
|
20
|
+
## 3. Usage & Arguments
|
|
21
|
+
```bash
|
|
22
|
+
/soc-cleanup [target] [flags]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
### Arguments
|
|
26
|
+
- **`[target]`**: Directory or file to clean (default: current context).
|
|
27
|
+
|
|
28
|
+
### Flags
|
|
29
|
+
- **`--type [code|imports|files|all]`**: **MANDATORY**.
|
|
30
|
+
- **`--safe`**: (Default) Only removes code with 0 references.
|
|
31
|
+
- **`--aggressive`**: Removes code with indirect/suspect references (requires confirmation).
|
|
32
|
+
- **`--preview`**: Lists changes without applying them (Dry Run).
|
|
33
|
+
|
|
34
|
+
## 4. Behavioral Flow (Orchestration)
|
|
35
|
+
|
|
36
|
+
### Phase 1: Analysis (The Scanner)
|
|
37
|
+
1. **Map**: Scans `[target]` for exports and imports.
|
|
38
|
+
2. **Trace**: Builds a dependency graph.
|
|
39
|
+
3. **Flag**: Identifies "orphan" nodes (code with no incoming edges).
|
|
40
|
+
|
|
41
|
+
### Phase 2: Plan (The Stratagem)
|
|
42
|
+
- If `safe`: Select only orphans with 0 references.
|
|
43
|
+
- If `aggressive`: Select orphans + "soft" references (comments, test-only usage).
|
|
44
|
+
|
|
45
|
+
### Phase 3: Execution (The Broom)
|
|
46
|
+
1. **Backup**: (Implicit) Relies on Git.
|
|
47
|
+
2. **Remove**: Deletes lines/files.
|
|
48
|
+
3. **Verify**: Runs build/tests. If fail -> Revert.
|
|
49
|
+
|
|
50
|
+
## 5. Output Guidelines (The Contract)
|
|
51
|
+
|
|
52
|
+
### Cleanup Report
|
|
53
|
+
```markdown
|
|
54
|
+
## Cleanup Report: [Target]
|
|
55
|
+
|
|
56
|
+
### Summary
|
|
57
|
+
- **Removed**: 15 unused exports
|
|
58
|
+
- **Deleted**: 2 dead files
|
|
59
|
+
- **Bytes Saved**: 4.5KB
|
|
60
|
+
|
|
61
|
+
### Actions Taken
|
|
62
|
+
- [x] Removed `oldFunction` from `src/utils.ts` (0 refs).
|
|
63
|
+
- [x] Deleted `src/components/unused-modal.tsx`.
|
|
64
|
+
|
|
65
|
+
### Skipped (Safety Check)
|
|
66
|
+
- [ ] `legacyAuth.ts` (Referenced in TODO comment).
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
## 6. Examples
|
|
70
|
+
|
|
71
|
+
### A. Safe Import Cleanup
|
|
72
|
+
```bash
|
|
73
|
+
/soc-cleanup src/ --type imports --safe
|
|
74
|
+
```
|
|
75
|
+
*Effect:* Removes unused `import` statements and sorts remaining ones.
|
|
76
|
+
|
|
77
|
+
### B. Dead Code Preview
|
|
78
|
+
```bash
|
|
79
|
+
/soc-cleanup --type code --preview
|
|
80
|
+
```
|
|
81
|
+
*Effect:* Lists all exported functions that are never imported, but does not delete them.
|
|
82
|
+
|
|
83
|
+
## 7. Dependencies & Capabilities
|
|
84
|
+
|
|
85
|
+
### Agents
|
|
86
|
+
- **Quality**: `@[.opencode/agents/quality.md]` - Primary agent for code analysis.
|
|
87
|
+
- **Architect**: `@[.opencode/agents/architect.md]` - For structural cleanup.
|
|
88
|
+
|
|
89
|
+
### Skills
|
|
90
|
+
- **Safety Check**: `@[.opencode/skills/security-audit/SKILL.md]` - ensuring cleanup doesn't remove security gates.
|
|
91
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - Recovering if cleanup breaks the build.
|
|
92
|
+
|
|
93
|
+
### MCP Integration
|
|
94
|
+
- **`context7`**: Verifying if "unused" code is actually a framework entry point (e.g., Next.js pages).
|
|
95
|
+
- **`filesystem`**: Moving and deleting files.
|
|
96
|
+
|
|
97
|
+
## 8. Boundaries
|
|
98
|
+
|
|
99
|
+
**Will:**
|
|
100
|
+
- Remove unused imports.
|
|
101
|
+
- Delete files with 0 references (in `aggressive` mode).
|
|
102
|
+
- Consolidate duplicate logic (if explicitly identified).
|
|
103
|
+
|
|
104
|
+
**Will Not:**
|
|
105
|
+
- **Delete "Commented Out" Code**: Unless explicitly told to.
|
|
106
|
+
- **Touch Config Files**: (e.g., `tsconfig.json`) without explicit intent.
|
|
107
|
+
- **Break Public APIs**: Will not remove exports from `index.ts` files in libraries.
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design
|
|
3
|
+
description: "Design system architecture, APIs, and component interfaces with comprehensive specifications"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /soc-design
|
|
7
|
+
|
|
8
|
+
## 1. Command Overview
|
|
9
|
+
The `/soc-design` command orchestrates the creation of technical specifications, architecture diagrams, and API contracts. It transitions a project from "brainstorming" to "blueprint." It delegates specific design tasks to the `architect`, `backend`, or `frontend` agents, ensuring all designs are validated against the "Ultrathink" protocol before any code is written.
|
|
10
|
+
|
|
11
|
+
## 2. Triggers & Routing
|
|
12
|
+
The command routes to specialized sub-agents based on the `--type` flag.
|
|
13
|
+
|
|
14
|
+
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
15
|
+
| :--- | :--- | :--- | :--- |
|
|
16
|
+
| **System Architecture** | `--type architecture` | `[architect]` | Scalability, Cloud Limits, ADR templates |
|
|
17
|
+
| **API Contract** | `--type api` | `[backend]` | REST/GraphQL patterns, Auth headers |
|
|
18
|
+
| **Database Schema** | `--type database` | `[backend]` | Normalization rules, Migration templates |
|
|
19
|
+
| **UI Component** | `--type component` | `[frontend]` | Accessibility (WCAG), Design Tokens |
|
|
20
|
+
|
|
21
|
+
## 3. Usage & Arguments
|
|
22
|
+
```bash
|
|
23
|
+
/soc-design [target] [flags]
|
|
24
|
+
```
|
|
25
|
+
|
|
26
|
+
### Arguments
|
|
27
|
+
- **`[target]`**: The feature, system, or component to design (e.g., "User Auth", "Payment Gateway").
|
|
28
|
+
|
|
29
|
+
### Flags
|
|
30
|
+
- **`--type [type]`**: **MANDATORY**. One of `architecture`, `api`, `database`, `component`.
|
|
31
|
+
- **`--format [format]`**:
|
|
32
|
+
- `spec`: Textual specification with requirements (default).
|
|
33
|
+
- `diagram`: Mermaid or ASCII visualization.
|
|
34
|
+
- `code`: Interface definitions (TypeScript interfaces, SQL DDL).
|
|
35
|
+
|
|
36
|
+
## 4. Behavioral Flow (Orchestration)
|
|
37
|
+
|
|
38
|
+
### Phase 1: Context Analysis
|
|
39
|
+
1. **Read**: Examines existing `task.md`, `README.md`, and any previous brainstorming artifacts.
|
|
40
|
+
2. **Constraint Check**: Identifies tech stack limitations (e.g., "We are using Next.js on Vercel").
|
|
41
|
+
|
|
42
|
+
### Phase 2: Design Generation
|
|
43
|
+
The command prompts the target agent:
|
|
44
|
+
> "Agent **[Name]**, create a **[Type]** design for **[Target]**.
|
|
45
|
+
> Standard: **Intentional Minimalism**.
|
|
46
|
+
> Output: **[Format]**."
|
|
47
|
+
|
|
48
|
+
### Phase 3: Validation (Reflexion)
|
|
49
|
+
- Does the design violate "Zero Trust"?
|
|
50
|
+
- Is the schema normalized?
|
|
51
|
+
- Are the UI components accessible?
|
|
52
|
+
|
|
53
|
+
## 5. Output Guidelines (The Contract)
|
|
54
|
+
|
|
55
|
+
### A. Architecture Decision Record (ADR)
|
|
56
|
+
```markdown
|
|
57
|
+
# ADR: [Title]
|
|
58
|
+
## Context
|
|
59
|
+
[Problem description]
|
|
60
|
+
## Decision
|
|
61
|
+
[Solution chosen]
|
|
62
|
+
## Consequences
|
|
63
|
+
[Trade-offs]
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
### B. API Specification
|
|
67
|
+
```typescript
|
|
68
|
+
interface CreateUserRequest {
|
|
69
|
+
email: string; // @format email
|
|
70
|
+
role?: 'admin' | 'user';
|
|
71
|
+
}
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### C. Database Schema (Prisma/SQL)
|
|
75
|
+
```prisma
|
|
76
|
+
model User {
|
|
77
|
+
id String @id @default(cuid())
|
|
78
|
+
email String @unique
|
|
79
|
+
}
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
## 6. Examples
|
|
83
|
+
|
|
84
|
+
### A. System Architecture
|
|
85
|
+
```bash
|
|
86
|
+
/soc-design user-management --type architecture --format diagram
|
|
87
|
+
```
|
|
88
|
+
*Effect:* Triggers `architect` to draw a high-level system diagram including Auth0, Postgres, and Next.js linkage.
|
|
89
|
+
|
|
90
|
+
### B. API Design
|
|
91
|
+
```bash
|
|
92
|
+
/soc-design payment-api --type api --format spec
|
|
93
|
+
```
|
|
94
|
+
*Effect:* Triggers `backend` to define `POST /api/payments` with request/response schemas and error codes.
|
|
95
|
+
|
|
96
|
+
## 7. Dependencies & Capabilities
|
|
97
|
+
### Agents
|
|
98
|
+
- **Architecture**: `@[.opencode/agents/architect.md]` - System design and patterns.
|
|
99
|
+
- **API/DB**: `@[.opencode/agents/backend.md]` - Schema and interface definitions.
|
|
100
|
+
- **UI/UX**: `@[.opencode/agents/frontend.md]` - Component and interaction design.
|
|
101
|
+
- **Research**: `@[.opencode/agents/researcher.md]` - Competitive analysis and best practices.
|
|
102
|
+
|
|
103
|
+
### Skills
|
|
104
|
+
- **Simplification**: `@[.opencode/skills/simplification/SKILL.md]` - Ensuring designs are not over-engineered.
|
|
105
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - Critiquing design decisions.
|
|
106
|
+
|
|
107
|
+
### MCP Integration
|
|
108
|
+
- **`generate_image`**: Used to create UI mockups, architectural diagrams, and visual flows.
|
|
109
|
+
- **`context7`**: Accessing latest documentation for chosen frameworks (e.g., "Next.js App Router patterns").
|
|
110
|
+
- **`tavily`**: Researching industry standards and existing solutions.
|
|
111
|
+
|
|
112
|
+
## 8. Boundaries
|
|
113
|
+
|
|
114
|
+
**Will:**
|
|
115
|
+
- Create comprehensive design specifications.
|
|
116
|
+
- Generate interface definitions (contracts).
|
|
117
|
+
- Validate designs against architectural constraints.
|
|
118
|
+
|
|
119
|
+
**Will Not:**
|
|
120
|
+
- **Write Implementation Code**: Use `/soc-implement` for that.
|
|
121
|
+
- **Deploy Infrastructure**: Use Terraform/SOC agents for that.
|
|
122
|
+
- **Guess Requirements**: If ambiguous, it will ask for clarification.
|
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Code explanation and understanding
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-explain
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
The `/soc-explain` command is the "Tutor." It translates complex code, errors, or concepts into natural language. It adapts its depth to the user's needs, from simple analogies to expert technical deep-dives. It generates documentation that can be saved.
|
|
9
|
+
|
|
10
|
+
## 2. Triggers & Routing
|
|
11
|
+
The command uses the `writer` agent effectively to synthesize information.
|
|
12
|
+
|
|
13
|
+
| Trigger Scenario | Flag | Target Agent | Style |
|
|
14
|
+
| :--- | :--- | :--- | :--- |
|
|
15
|
+
| **High Level** | `--depth simple` | `[writer]` | Analogies, non-technical |
|
|
16
|
+
| **Standard** | `--depth detailed` | `[writer]` | Code logic, flow, syntax |
|
|
17
|
+
| **Deep Dive** | `--depth expert` | `[architect]` | Memory, performance, edge cases |
|
|
18
|
+
|
|
19
|
+
## 3. Usage & Arguments
|
|
20
|
+
```bash
|
|
21
|
+
/soc-explain [target] [flags]
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
### Arguments
|
|
25
|
+
- **`[target]`**: Code snippet, file path, error message, or concept (e.g., "Dependency Injection").
|
|
26
|
+
|
|
27
|
+
### Flags
|
|
28
|
+
- **`--depth [simple|detailed|expert]`**: (Default: `detailed`).
|
|
29
|
+
- **`--context [file]`**: Add extra context for better explanation.
|
|
30
|
+
|
|
31
|
+
## 4. Behavioral Flow (Orchestration)
|
|
32
|
+
|
|
33
|
+
### Phase 1: Analysis
|
|
34
|
+
1. **Parse**: Is the target a file, a string, or a concept?
|
|
35
|
+
2. **Context**: If it's an error, where did it come from? If it's code, what language?
|
|
36
|
+
|
|
37
|
+
### Phase 2: Synthesis (The Lesson)
|
|
38
|
+
- **Analogy**: "Think of a Promise like a pizza buzzer..."
|
|
39
|
+
- **Technical**: "It wraps the value in a microtask queue..."
|
|
40
|
+
- **Example**: "Here is how you use it:"
|
|
41
|
+
|
|
42
|
+
### Phase 3: Formatting
|
|
43
|
+
- Structure with clear Headers.
|
|
44
|
+
- Use Code Blocks for syntax.
|
|
45
|
+
- Highlight "Key Takeaways."
|
|
46
|
+
|
|
47
|
+
## 5. Output Guidelines (The Contract)
|
|
48
|
+
|
|
49
|
+
### Explanation Document
|
|
50
|
+
```markdown
|
|
51
|
+
## Explanation: [Topic]
|
|
52
|
+
|
|
53
|
+
### Summary
|
|
54
|
+
[1-2 sentences. The TL;DR.]
|
|
55
|
+
|
|
56
|
+
### Conceptual Analogy (If Simple)
|
|
57
|
+
[Mundane comparison]
|
|
58
|
+
|
|
59
|
+
### Technical Breakdown
|
|
60
|
+
- **Component A**: Does X.
|
|
61
|
+
- **Component B**: Does Y.
|
|
62
|
+
|
|
63
|
+
### Code Example
|
|
64
|
+
```javascript
|
|
65
|
+
// Before
|
|
66
|
+
badCode()
|
|
67
|
+
|
|
68
|
+
// After (corrected/explained)
|
|
69
|
+
goodCode()
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
### Key Takeaways
|
|
73
|
+
1. [Point 1]
|
|
74
|
+
2. [Point 2]
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
## 6. Examples
|
|
78
|
+
|
|
79
|
+
### A. Async/Await (Expert)
|
|
80
|
+
```bash
|
|
81
|
+
/soc-explain "How Node Event Loop works" --depth expert
|
|
82
|
+
```
|
|
83
|
+
*Effect:* Explains Phases (Timers, Poll, Check), Microtasks vs Macrotasks, and `process.nextTick`.
|
|
84
|
+
|
|
85
|
+
### B. Error Parsing
|
|
86
|
+
```bash
|
|
87
|
+
/soc-explain "TypeError: Cannot read property 'map' of undefined"
|
|
88
|
+
```
|
|
89
|
+
*Effect:* Explains that the array is missing, helps identify the source variable, suggests Optional Chaining (`?.`).
|
|
90
|
+
|
|
91
|
+
## 7. Dependencies & Capabilities
|
|
92
|
+
|
|
93
|
+
### Agents
|
|
94
|
+
- **Writer**: `@[.opencode/agents/writer.md]` - Primary explainer.
|
|
95
|
+
- **Architect**: `@[.opencode/agents/architect.md]` - For system-level concepts.
|
|
96
|
+
|
|
97
|
+
### Skills
|
|
98
|
+
- **Simplification**: `@[.opencode/skills/simplification/SKILL.md]` - To de-jargonize complex topics.
|
|
99
|
+
|
|
100
|
+
### MCP Integration
|
|
101
|
+
- **`context7`**: Fetching official docs to cite sources.
|
|
102
|
+
- **`read_file`**: Reading the full content of the file being explained.
|
|
103
|
+
|
|
104
|
+
## 8. Boundaries
|
|
105
|
+
|
|
106
|
+
**Will:**
|
|
107
|
+
- Explain *why* code works.
|
|
108
|
+
- Suggest *best practices*.
|
|
109
|
+
- Debug *logic* errors via explanation.
|
|
110
|
+
|
|
111
|
+
**Will Not:**
|
|
112
|
+
- **Write the Fix**: It explains the fix; `/soc-implement` writes it.
|
|
113
|
+
- **Execute Code**: It analyzes static text.
|
|
@@ -0,0 +1,104 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Git operations with intelligent commit messages and workflow optimization"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-git
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
The `/soc-git` command is the "Version Controller." It wraps standard git operations with intelligence. It can analyze diffs to generate Conventional Commit messages, check for accidental secrets before pushing, and manage branching strategies.
|
|
9
|
+
|
|
10
|
+
## 2. Triggers & Routing
|
|
11
|
+
The command routes to the `writer` agent for message generation and `security` for pre-push checks.
|
|
12
|
+
|
|
13
|
+
| Trigger Scenario | Flag | Target Agent | Action |
|
|
14
|
+
| :--- | :--- | :--- | :--- |
|
|
15
|
+
| **Commit Message** | `--smart` | `[writer]` | Generate `feat(scope): desc` |
|
|
16
|
+
| **Pre-Push** | `push` | `[security]` | Scan for secrets |
|
|
17
|
+
| **Branching** | `branch` | `[pm-agent]` | Enforce naming conventions |
|
|
18
|
+
|
|
19
|
+
## 3. Usage & Arguments
|
|
20
|
+
```bash
|
|
21
|
+
/soc-git [operation] [args] [flags]
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
### Arguments
|
|
25
|
+
- **`[operation]`**: `commit`, `push`, `pull`, `branch`, `status`, `diff`.
|
|
26
|
+
|
|
27
|
+
### Flags
|
|
28
|
+
- **`--smart`**: Auto-generate messages/descriptions.
|
|
29
|
+
- **`--force`**: Bypass safety checks (Use with caution).
|
|
30
|
+
|
|
31
|
+
## 4. Behavioral Flow (Orchestration)
|
|
32
|
+
|
|
33
|
+
### Phase 1: Context Analysis
|
|
34
|
+
1. **Status Check**: Run `git status`.
|
|
35
|
+
2. **Diff Analysis**: Run `git diff --staged`.
|
|
36
|
+
3. **Safety Check**: Scan pending changes for keys/env files.
|
|
37
|
+
|
|
38
|
+
### Phase 2: Operations
|
|
39
|
+
- **Commit**:
|
|
40
|
+
- If `--smart`: Feed diff to LLM -> Generate Conventional Commit.
|
|
41
|
+
- If standard: Execute `git commit -m`.
|
|
42
|
+
- **Push**:
|
|
43
|
+
- Check upstream. If missing, auto-set `-u origin`.
|
|
44
|
+
- **Branch**:
|
|
45
|
+
- Normalize name (e.g., `My Feature` -> `feat/my-feature`).
|
|
46
|
+
|
|
47
|
+
### Phase 3: Post-Op
|
|
48
|
+
- Confirm success.
|
|
49
|
+
- Show Next Step (e.g., "Ready to open PR").
|
|
50
|
+
|
|
51
|
+
## 5. Output Guidelines (The Contract)
|
|
52
|
+
|
|
53
|
+
### Git Operation Result
|
|
54
|
+
```markdown
|
|
55
|
+
## Git: [Operation]
|
|
56
|
+
|
|
57
|
+
### Status
|
|
58
|
+
✅ Success / ❌ Failure
|
|
59
|
+
|
|
60
|
+
### Details
|
|
61
|
+
- **Branch**: `feat/user-auth`
|
|
62
|
+
- **Commit**: `a1b2c3d` - "feat(auth): add login route"
|
|
63
|
+
|
|
64
|
+
### Tips
|
|
65
|
+
- [ ] Run `/test` before pushing.
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
## 6. Examples
|
|
69
|
+
|
|
70
|
+
### A. Smart Commit
|
|
71
|
+
```bash
|
|
72
|
+
/soc-git commit --smart
|
|
73
|
+
```
|
|
74
|
+
*Effect:* Analyzes staged files, detects added login logic, commits with: `feat(auth): implement user login flow`.
|
|
75
|
+
|
|
76
|
+
### B. Branch Creation
|
|
77
|
+
```bash
|
|
78
|
+
/soc-git branch "Update README"
|
|
79
|
+
```
|
|
80
|
+
*Effect:* Creates and checks out `docs/update-readme` (auto-categorized).
|
|
81
|
+
|
|
82
|
+
## 7. Dependencies & Capabilities
|
|
83
|
+
|
|
84
|
+
### Agents
|
|
85
|
+
- **Writer**: `@[.opencode/agents/writer.md]` - For commit messages.
|
|
86
|
+
- **Security**: `@[.opencode/agents/security.md]` - For pre-commit hooks.
|
|
87
|
+
|
|
88
|
+
### Skills
|
|
89
|
+
- **Security Audit**: `@[.opencode/skills/security-audit/SKILL.md]` - Scanning staged files.
|
|
90
|
+
|
|
91
|
+
### MCP Integration
|
|
92
|
+
- **`run_command`**: Executing actual git binaries.
|
|
93
|
+
- **`filesystem`**: Reading ignores and config.
|
|
94
|
+
|
|
95
|
+
## 8. Boundaries
|
|
96
|
+
|
|
97
|
+
**Will:**
|
|
98
|
+
- Execute git commands.
|
|
99
|
+
- Generate text for messages.
|
|
100
|
+
- Block commits with secrets (unless `--force`).
|
|
101
|
+
|
|
102
|
+
**Will Not:**
|
|
103
|
+
- **Solve Merge Conflicts**: It will report them, but user must resolve.
|
|
104
|
+
- **Rewrite History**: No `rebase` or `reset --hard` without explicit user confirmation.
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Help and command reference
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-help
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
The `/soc-help` command is the "Librarian." It serves as the primary documentation interface for the agent system. It explains *how* to use the other commands, details what each agent does, and lists available skills. It uses the `researcher` agent to find answers within the system's own documentation.
|
|
9
|
+
|
|
10
|
+
## 2. Triggers & Routing
|
|
11
|
+
The command is self-contained but may use `researcher` for deep queries.
|
|
12
|
+
|
|
13
|
+
| Trigger Scenario | Flag | Target Agent | Action |
|
|
14
|
+
| :--- | :--- | :--- | :--- |
|
|
15
|
+
| **Command Syntax** | `[command]` | `[System]` | Show usage and flags |
|
|
16
|
+
| **Agent Roles** | `[agent]` | `[System]` | Show persona description |
|
|
17
|
+
| **Workflow Guide** | `[topic]` | `[researcher]` | Summarize best practices |
|
|
18
|
+
|
|
19
|
+
## 3. Usage & Arguments
|
|
20
|
+
```bash
|
|
21
|
+
/soc-help [target] [flags]
|
|
22
|
+
```
|
|
23
|
+
|
|
24
|
+
### Arguments
|
|
25
|
+
- **`[target]`**: (Optional) Specific command (`implement`), agent (`backend`), or topic (`workflows`). Default: Shows index.
|
|
26
|
+
|
|
27
|
+
### Flags
|
|
28
|
+
- **`--verbose`**: Show detailed descriptions and hidden flags.
|
|
29
|
+
|
|
30
|
+
## 4. Behavioral Flow (Orchestration)
|
|
31
|
+
|
|
32
|
+
### Phase 1: Lookup
|
|
33
|
+
1. **Index**: Check if target is a known Command, Agent, or Skill.
|
|
34
|
+
2. **Search**: If unknown, grep `.opencode/` documentation for keywords.
|
|
35
|
+
|
|
36
|
+
### Phase 2: Formatting
|
|
37
|
+
- **Structure**: Group by Category (Workflow vs Skill).
|
|
38
|
+
- **Clarity**: Show "Quick Start" snippets.
|
|
39
|
+
|
|
40
|
+
## 5. Output Guidelines (The Contract)
|
|
41
|
+
|
|
42
|
+
### Help Document
|
|
43
|
+
```markdown
|
|
44
|
+
## Help: [Target]
|
|
45
|
+
|
|
46
|
+
### Description
|
|
47
|
+
[Brief summary]
|
|
48
|
+
|
|
49
|
+
### Usage
|
|
50
|
+
`[Command Pattern]`
|
|
51
|
+
|
|
52
|
+
### Key Features
|
|
53
|
+
- Feature 1
|
|
54
|
+
- Feature 2
|
|
55
|
+
|
|
56
|
+
### Related Commands
|
|
57
|
+
- `/related-command`
|
|
58
|
+
```
|
|
59
|
+
|
|
60
|
+
## 6. Examples
|
|
61
|
+
|
|
62
|
+
### A. Command Help
|
|
63
|
+
```bash
|
|
64
|
+
/soc-help implement
|
|
65
|
+
```
|
|
66
|
+
*Effect:* Displays usage for `/soc-implement`, including flags like `--agent` and `--test`.
|
|
67
|
+
|
|
68
|
+
### B. Agent Role
|
|
69
|
+
```bash
|
|
70
|
+
/soc-help backend
|
|
71
|
+
```
|
|
72
|
+
*Effect:* Shows the `backend` agent's persona, including "Prime Directives" and "Restrictions."
|
|
73
|
+
|
|
74
|
+
## 7. Dependencies & Capabilities
|
|
75
|
+
|
|
76
|
+
### Agents
|
|
77
|
+
- **Researcher**: `@[.opencode/agents/researcher.md]` - For finding unstructured help.
|
|
78
|
+
|
|
79
|
+
### Skills
|
|
80
|
+
- **None**: This is a read-only command.
|
|
81
|
+
|
|
82
|
+
### MCP Integration
|
|
83
|
+
- **`filesystem`**: Reading documentation files.
|
|
84
|
+
|
|
85
|
+
## 8. Boundaries
|
|
86
|
+
|
|
87
|
+
**Will:**
|
|
88
|
+
- Explain system capabilities.
|
|
89
|
+
- List available tools.
|
|
90
|
+
- Provide syntax examples.
|
|
91
|
+
|
|
92
|
+
**Will Not:**
|
|
93
|
+
- **Execute Commands**: It only explains them.
|
|
94
|
+
- **Hallucinate Features**: Only lists what exists in `.opencode/`.
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Code implementation with best practices
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-implement
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
The `/soc-implement` command is the execution engine of the agent system. It transforms approved designs and specifications into production-ready code. It enforces strict quality control, testing (TDD), and "self-correction" loops via the `reflexion` skill. It does not plan; it executes.
|
|
9
|
+
|
|
10
|
+
## 2. Triggers & Routing
|
|
11
|
+
The command routes to specialized sub-agents based on the `--agent` flag or file context.
|
|
12
|
+
|
|
13
|
+
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
14
|
+
| :--- | :--- | :--- | :--- |
|
|
15
|
+
| **API/Database Logic** | `--agent backend` | `[backend]` | DB Schemas, Error Handling Middleware |
|
|
16
|
+
| **UI/Components** | `--agent frontend` | `[frontend]` | Design System, A11y Rules, Hooks |
|
|
17
|
+
| **Testing/QA** | `--agent quality` | `[quality]` | Test Runner Config, Coverage Reports |
|
|
18
|
+
| **Refactoring** | `--agent fullstack` | `[backend]` + `[frontend]` | Cross-layer dependencies |
|
|
19
|
+
|
|
20
|
+
## 3. Usage & Arguments
|
|
21
|
+
```bash
|
|
22
|
+
/soc-implement [target] [flags]
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
### Arguments
|
|
26
|
+
- **`[target]`**: The feature or file to implement (e.g., "Login Flow", "src/components/Button.tsx").
|
|
27
|
+
|
|
28
|
+
### Flags
|
|
29
|
+
- **`--agent [backend|frontend|quality]`**: **MANDATORY**. Specifies the executing persona.
|
|
30
|
+
- **`--test`**: (Default: true) Run capabilities tests after implementation.
|
|
31
|
+
- **`--document`**: (Default: true) Update associated documentation/comments.
|
|
32
|
+
|
|
33
|
+
## 4. Behavioral Flow (Orchestration)
|
|
34
|
+
|
|
35
|
+
### Phase 1: Pre-Flight (Confidence Check)
|
|
36
|
+
1. **Read**: Review existing code and referencing `design.md` or `requirements`.
|
|
37
|
+
2. **Verify**: Check for patterns (e.g., "How do existing controllers handle errors?").
|
|
38
|
+
3. **Gate**: If confidence < 80%, ask user/PM for clarification.
|
|
39
|
+
|
|
40
|
+
### Phase 2: Execution (The Loop)
|
|
41
|
+
1. **Test**: Write the test case first (TDD) if applicable.
|
|
42
|
+
2. **Edit**: Apply changes using `replace_file_content` or `write_to_file`.
|
|
43
|
+
3. **Verify**: Run the project's build/test command.
|
|
44
|
+
* *If Fail*: Trigger `reflexion` skill (Why did it fail? -> Fix -> Retry).
|
|
45
|
+
* *Limit*: Max 3 retries before asking for help.
|
|
46
|
+
|
|
47
|
+
### Phase 3: Post-Flight (Self Check)
|
|
48
|
+
- Did I leave any `console.log`?
|
|
49
|
+
- Are inputs sanitized?
|
|
50
|
+
- Did I break the build?
|
|
51
|
+
|
|
52
|
+
## 5. Output Guidelines (The Contract)
|
|
53
|
+
|
|
54
|
+
### Standard Implementation Report
|
|
55
|
+
```markdown
|
|
56
|
+
## Implementation: [Feature Name]
|
|
57
|
+
|
|
58
|
+
### 1. Changes Summary
|
|
59
|
+
- **Created:** `src/features/auth/login.ts`
|
|
60
|
+
- **Modified:** `src/components/navbar.tsx`
|
|
61
|
+
|
|
62
|
+
### 2. Verification
|
|
63
|
+
- ✅ **Build:** Passed
|
|
64
|
+
- ✅ **Tests:** 3 new tests added, all passing.
|
|
65
|
+
- ✅ **Lint:** 0 errors.
|
|
66
|
+
|
|
67
|
+
### 3. Key Decisions
|
|
68
|
+
- Used `zod` for validation to match existing patterns.
|
|
69
|
+
- Extracted `useAuth` hook for reusability.
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## 6. Examples
|
|
73
|
+
|
|
74
|
+
### A. Backend Feature
|
|
75
|
+
```bash
|
|
76
|
+
/soc-implement "User Registration API" --agent backend
|
|
77
|
+
```
|
|
78
|
+
*Effect:* `backend` agent writes `POST /register`, adds `UserSchema` validation, inputs into Postgres, and returns a sanitized User DTO.
|
|
79
|
+
|
|
80
|
+
### B. Frontend Component
|
|
81
|
+
```bash
|
|
82
|
+
/soc-implement "DarkMode Toggle" --agent frontend
|
|
83
|
+
```
|
|
84
|
+
*Effect:* `frontend` agent checks `tailwind.config.js`, creates a toggle component using `Radix UI` primitives (if installed) and handles local storage state.
|
|
85
|
+
|
|
86
|
+
## 7. Dependencies & Capabilities
|
|
87
|
+
|
|
88
|
+
### Agents
|
|
89
|
+
- **Backend**: `@[.opencode/agents/backend.md]`
|
|
90
|
+
- **Frontend**: `@[.opencode/agents/frontend.md]`
|
|
91
|
+
- **Quality**: `@[.opencode/agents/quality.md]` - For TDD and verification.
|
|
92
|
+
|
|
93
|
+
### Skills
|
|
94
|
+
- **Confidence Check**: `@[.opencode/skills/confidence-check/SKILL.md]` - MANDATORY step before starting.
|
|
95
|
+
- **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Validation protocol after changes.
|
|
96
|
+
- **Debug Protocol**: `@[.opencode/skills/debug-protocol/SKILL.md]` - If implementation hits errors.
|
|
97
|
+
|
|
98
|
+
### MCP Integration
|
|
99
|
+
- **`context7`**: For looking up exact syntax and library API usage to prevent hallucinations.
|
|
100
|
+
- **`filesystem`**: For determining current project structure and patterns.
|
|
101
|
+
|
|
102
|
+
## 8. Boundaries
|
|
103
|
+
|
|
104
|
+
**Will:**
|
|
105
|
+
- Write code modules, tests, and documentation.
|
|
106
|
+
- Fix compilation errors it causes.
|
|
107
|
+
- Respect existing linters and formatters.
|
|
108
|
+
|
|
109
|
+
**Will Not:**
|
|
110
|
+
- **Invent Designs**: If no design exists, it will fall back to simple best practices or ask for a design.
|
|
111
|
+
- **Commit Violations**: Will not commit code with secrets or critical bugs.
|
|
112
|
+
- **Touch Forbidden Files**: (e.g., `package-lock.json` manual edits, `.env` manual edits).
|