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: "Systematically clean up code, remove dead code, and optimize proje
|
|
|
5
5
|
# /soc-cleanup
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
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
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command routes cleanup tasks based on the `--type` flag.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Tool Used |
|
|
@@ -18,38 +20,45 @@ The command routes cleanup tasks based on the `--type` flag.
|
|
|
18
20
|
| **Deep Clean** | `--type all` | `[quality]` | All tools |
|
|
19
21
|
|
|
20
22
|
## 3. Usage & Arguments
|
|
23
|
+
|
|
21
24
|
```bash
|
|
22
25
|
/soc-cleanup [target] [flags]
|
|
23
26
|
```
|
|
24
27
|
|
|
25
28
|
### Arguments
|
|
26
|
-
|
|
29
|
+
|
|
30
|
+
- **`[target]`**: Directory or file to clean (default: current context).
|
|
27
31
|
|
|
28
32
|
### Flags
|
|
29
|
-
|
|
30
|
-
-
|
|
31
|
-
-
|
|
32
|
-
-
|
|
33
|
+
|
|
34
|
+
- **`--type [code|imports|files|all]`**: **MANDATORY**.
|
|
35
|
+
- **`--safe`**: (Default) Only removes code with 0 references.
|
|
36
|
+
- **`--aggressive`**: Removes code with indirect/suspect references (requires confirmation).
|
|
37
|
+
- **`--preview`**: Lists changes without applying them (Dry Run).
|
|
33
38
|
|
|
34
39
|
## 4. Behavioral Flow (Orchestration)
|
|
35
40
|
|
|
36
41
|
### Phase 1: Analysis (The Scanner)
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
42
|
+
|
|
43
|
+
1. **Map**: Scans `[target]` for exports and imports.
|
|
44
|
+
2. **Trace**: Builds a dependency graph.
|
|
45
|
+
3. **Flag**: Identifies "orphan" nodes (code with no incoming edges).
|
|
40
46
|
|
|
41
47
|
### Phase 2: Plan (The Stratagem)
|
|
42
|
-
|
|
43
|
-
-
|
|
48
|
+
|
|
49
|
+
- If `safe`: Select only orphans with 0 references.
|
|
50
|
+
- If `aggressive`: Select orphans + "soft" references (comments, test-only usage).
|
|
44
51
|
|
|
45
52
|
### Phase 3: Execution (The Broom)
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
53
|
+
|
|
54
|
+
1. **Backup**: (Implicit) Relies on Git.
|
|
55
|
+
2. **Remove**: Deletes lines/files.
|
|
56
|
+
3. **Verify**: Runs build/tests. If fail -> Revert.
|
|
49
57
|
|
|
50
58
|
## 5. Output Guidelines (The Contract)
|
|
51
59
|
|
|
52
60
|
### Cleanup Report
|
|
61
|
+
|
|
53
62
|
```markdown
|
|
54
63
|
## Cleanup Report: [Target]
|
|
55
64
|
|
|
@@ -69,39 +78,52 @@ The command routes cleanup tasks based on the `--type` flag.
|
|
|
69
78
|
## 6. Examples
|
|
70
79
|
|
|
71
80
|
### A. Safe Import Cleanup
|
|
81
|
+
|
|
72
82
|
```bash
|
|
73
83
|
/soc-cleanup src/ --type imports --safe
|
|
74
84
|
```
|
|
85
|
+
|
|
75
86
|
*Effect:* Removes unused `import` statements and sorts remaining ones.
|
|
76
87
|
|
|
77
88
|
### B. Dead Code Preview
|
|
89
|
+
|
|
78
90
|
```bash
|
|
79
91
|
/soc-cleanup --type code --preview
|
|
80
92
|
```
|
|
93
|
+
|
|
81
94
|
*Effect:* Lists all exported functions that are never imported, but does not delete them.
|
|
82
95
|
|
|
83
96
|
## 7. Dependencies & Capabilities
|
|
84
97
|
|
|
85
98
|
### Agents
|
|
86
|
-
|
|
87
|
-
-
|
|
99
|
+
|
|
100
|
+
- **Quality**: `@[.opencode/agents/quality.md]` - Primary agent for code analysis.
|
|
101
|
+
- **Architect**: `@[.opencode/agents/architect.md]` - For structural cleanup.
|
|
88
102
|
|
|
89
103
|
### Skills
|
|
90
|
-
|
|
91
|
-
-
|
|
104
|
+
|
|
105
|
+
- **Safety Check**: `@[.opencode/skills/security-audit/SKILL.md]` - ensuring cleanup doesn't remove security gates.
|
|
106
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - Recovering if cleanup breaks the build.
|
|
92
107
|
|
|
93
108
|
### MCP Integration
|
|
94
|
-
|
|
95
|
-
-
|
|
109
|
+
|
|
110
|
+
- **`context7`**: Verifying if "unused" code is actually a framework entry point (e.g., Next.js pages).
|
|
111
|
+
- **`filesystem`**: Moving and deleting files.
|
|
96
112
|
|
|
97
113
|
## 8. Boundaries
|
|
98
114
|
|
|
99
115
|
**Will:**
|
|
100
|
-
|
|
101
|
-
-
|
|
102
|
-
-
|
|
116
|
+
|
|
117
|
+
- Remove unused imports.
|
|
118
|
+
- Delete files with 0 references (in `aggressive` mode).
|
|
119
|
+
- Consolidate duplicate logic (if explicitly identified).
|
|
103
120
|
|
|
104
121
|
**Will Not:**
|
|
105
|
-
|
|
106
|
-
-
|
|
107
|
-
-
|
|
122
|
+
|
|
123
|
+
- **Delete "Commented Out" Code**: Unless explicitly told to.
|
|
124
|
+
- **Touch Config Files**: (e.g., `tsconfig.json`) without explicit intent.
|
|
125
|
+
- **Break Public APIs**: Will not remove exports from `index.ts` files in libraries.
|
|
126
|
+
|
|
127
|
+
## User Instruction
|
|
128
|
+
|
|
129
|
+
The user have executed the `/soc-cleanup` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate agent based on the extracted `--type` flag (code, imports, files, or all), scan the specified target (or current directory if none specified) to build a dependency graph and identify orphan code, apply the selected safety mode (`--safe` for zero-reference removal only or `--aggressive` for broader cleanup including soft references), generate a preview of changes if `--preview` is specified, and execute the cleanup while verifying that tests and builds still pass.
|
|
@@ -0,0 +1,271 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Deployment orchestration, release management, and infrastructure provisioning"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-deploy
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
|
|
9
|
+
The `/soc-deploy` command is the "Release Commander." It orchestrates the entire deployment pipeline—from environment provisioning to production release. It ensures deployments are repeatable, safe, and observable. It integrates CI/CD workflows, infrastructure as code, and rollback procedures to minimize deployment risk.
|
|
10
|
+
|
|
11
|
+
## 2. Triggers & Routing
|
|
12
|
+
|
|
13
|
+
The command activates deployment modes based on target environment and strategy.
|
|
14
|
+
|
|
15
|
+
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
16
|
+
| :--- | :--- | :--- | :--- |
|
|
17
|
+
| **Environment Setup** | `--action provision` | `[devops-agent]` | Cloud Provider, Regions, Resources |
|
|
18
|
+
| **CI/CD Pipeline** | `--action pipeline` | `[devops-agent]` | Build Steps, Tests, Gates |
|
|
19
|
+
| **Production Deploy** | `--action deploy` | `[devops-agent]` + `[security]` | Release Checklist, Rollback Plan |
|
|
20
|
+
| **Rollback** | `--action rollback` | `[devops-agent]` | Previous Stable Version |
|
|
21
|
+
| **Monitoring Setup** | `--action monitor` | `[devops-agent]` | Alerts, Dashboards, SLOs |
|
|
22
|
+
|
|
23
|
+
## 3. Usage & Arguments
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
/soc-deploy [target] [flags]
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
### Arguments
|
|
30
|
+
|
|
31
|
+
- **`[target]`**: Deployment target (e.g., "staging", "production", "v2.1.0", "infrastructure").
|
|
32
|
+
|
|
33
|
+
### Flags
|
|
34
|
+
|
|
35
|
+
- **`--action [provision|pipeline|deploy|rollback|monitor]`**: **MANDATORY**. Specifies deployment phase.
|
|
36
|
+
- **`--environment [dev|staging|prod]`**: Target environment (required for deploy/rollback).
|
|
37
|
+
- **`--strategy [blue-green|canary|rolling|recreate]`**: Deployment strategy (default: rolling).
|
|
38
|
+
- **`--version [semver]`**: Version tag to deploy (e.g., "v2.1.0").
|
|
39
|
+
- **`--dry-run`**: Simulate deployment without executing (validate configuration).
|
|
40
|
+
- **`--skip-tests`**: Skip test execution in pipeline (emergency use only).
|
|
41
|
+
- **`--auto-rollback`**: Automatically rollback on health check failure.
|
|
42
|
+
|
|
43
|
+
## 4. Behavioral Flow (Orchestration)
|
|
44
|
+
|
|
45
|
+
### Phase 1: Pre-Flight Checks
|
|
46
|
+
|
|
47
|
+
1. **Validate**: Check all required flags and configurations.
|
|
48
|
+
2. **Health Check**: Verify current environment status.
|
|
49
|
+
3. **Permission Check**: Ensure deployment credentials are valid.
|
|
50
|
+
4. **Gate Check**: Verify all pre-deployment requirements met (tests passed, approvals granted).
|
|
51
|
+
|
|
52
|
+
### Phase 2: Deployment Execution
|
|
53
|
+
|
|
54
|
+
#### Environment Provisioning (`--action provision`):
|
|
55
|
+
- Generate Terraform/CloudFormation configs.
|
|
56
|
+
- Create resource groups/VPCs.
|
|
57
|
+
- Set up databases, caches, queues.
|
|
58
|
+
- Configure networking and security groups.
|
|
59
|
+
- Output infrastructure state files.
|
|
60
|
+
|
|
61
|
+
#### Pipeline Configuration (`--action pipeline`):
|
|
62
|
+
- Define build stages (lint → test → build → scan).
|
|
63
|
+
- Configure artifact storage.
|
|
64
|
+
- Set up deployment gates (manual approval for prod).
|
|
65
|
+
- Integrate security scanning (SAST, dependency check).
|
|
66
|
+
- Configure notifications (Slack, email).
|
|
67
|
+
|
|
68
|
+
#### Production Deploy (`--action deploy`):
|
|
69
|
+
- **Blue-Green**: Deploy to new environment, run smoke tests, switch traffic.
|
|
70
|
+
- **Canary**: Deploy to 5% of traffic, monitor metrics, gradually increase.
|
|
71
|
+
- **Rolling**: Replace instances one by one with health checks.
|
|
72
|
+
- **Recreate**: Stop old version, start new version (downtime acceptable).
|
|
73
|
+
|
|
74
|
+
#### Rollback (`--action rollback`):
|
|
75
|
+
- Identify previous stable version.
|
|
76
|
+
- Execute rollback strategy (reverse of deployment).
|
|
77
|
+
- Verify system health post-rollback.
|
|
78
|
+
- Generate incident report.
|
|
79
|
+
|
|
80
|
+
### Phase 3: Post-Deployment
|
|
81
|
+
|
|
82
|
+
- **Verification**: Run smoke tests and health checks.
|
|
83
|
+
- **Monitoring**: Activate alerts and dashboards.
|
|
84
|
+
- **Notification**: Notify team of deployment status.
|
|
85
|
+
- **Documentation**: Update deployment log and runbooks.
|
|
86
|
+
|
|
87
|
+
## 5. Output Guidelines (The Contract)
|
|
88
|
+
|
|
89
|
+
### Deployment Report Template
|
|
90
|
+
|
|
91
|
+
```markdown
|
|
92
|
+
# Deployment Report: [Version] → [Environment]
|
|
93
|
+
|
|
94
|
+
## Summary
|
|
95
|
+
**Action**: Production Deploy
|
|
96
|
+
**Version**: v2.1.0
|
|
97
|
+
**Strategy**: Blue-Green
|
|
98
|
+
**Status**: ✅ SUCCESS / ❌ FAILED / ⚠️ ROLLBACK
|
|
99
|
+
**Duration**: 12 minutes
|
|
100
|
+
**Started**: 2026-01-30 14:30 UTC
|
|
101
|
+
**Completed**: 2026-01-30 14:42 UTC
|
|
102
|
+
|
|
103
|
+
## Pre-Deployment Checklist
|
|
104
|
+
- [x] All tests passing (CI/CD green)
|
|
105
|
+
- [x] Security scan passed (0 critical, 2 medium)
|
|
106
|
+
- [x] Database migrations reviewed
|
|
107
|
+
- [x] Rollback plan documented
|
|
108
|
+
- [x] On-call engineer notified
|
|
109
|
+
|
|
110
|
+
## Deployment Steps
|
|
111
|
+
|
|
112
|
+
| Step | Action | Status | Duration |
|
|
113
|
+
|:-----|:-------|:------:|:--------:|
|
|
114
|
+
| 1 | Provision green environment | ✅ | 3m |
|
|
115
|
+
| 2 | Deploy v2.1.0 to green | ✅ | 2m |
|
|
116
|
+
| 3 | Run smoke tests | ✅ | 2m |
|
|
117
|
+
| 4 | Database migration | ✅ | 1m |
|
|
118
|
+
| 5 | Switch traffic (blue→green) | ✅ | 30s |
|
|
119
|
+
| 6 | Verify production health | ✅ | 3m |
|
|
120
|
+
| 7 | Decommission blue | ✅ | 1m |
|
|
121
|
+
|
|
122
|
+
## Health Checks
|
|
123
|
+
|
|
124
|
+
| Check | Target | Actual | Status |
|
|
125
|
+
|:------|:-------|:-------|:------:|
|
|
126
|
+
| Response Time | <200ms | 145ms | ✅ |
|
|
127
|
+
| Error Rate | <0.1% | 0.02% | ✅ |
|
|
128
|
+
| CPU Usage | <70% | 45% | ✅ |
|
|
129
|
+
| Memory Usage | <80% | 62% | ✅ |
|
|
130
|
+
|
|
131
|
+
## Rollback Information
|
|
132
|
+
**Previous Version**: v2.0.8
|
|
133
|
+
**Rollback Command**: `/soc-deploy rollback --environment prod --version v2.0.8`
|
|
134
|
+
**Estimated Rollback Time**: 5 minutes
|
|
135
|
+
**Rollback Triggered**: No
|
|
136
|
+
|
|
137
|
+
## Post-Deployment Actions
|
|
138
|
+
- [x] Monitoring dashboards verified
|
|
139
|
+
- [x] Error logs checked (no anomalies)
|
|
140
|
+
- [x] Team notified in #deployments
|
|
141
|
+
- [x] Runbooks updated
|
|
142
|
+
- [ ] Post-deploy review scheduled (24h)
|
|
143
|
+
|
|
144
|
+
## Issues & Notes
|
|
145
|
+
- Minor: 2 medium-severity dependency warnings (non-blocking)
|
|
146
|
+
- Note: Database migration required brief read-only mode (45s)
|
|
147
|
+
```
|
|
148
|
+
|
|
149
|
+
### Pipeline Configuration Output
|
|
150
|
+
|
|
151
|
+
```yaml
|
|
152
|
+
# .github/workflows/deploy.yml (Generated)
|
|
153
|
+
name: Deploy Pipeline
|
|
154
|
+
|
|
155
|
+
on:
|
|
156
|
+
push:
|
|
157
|
+
tags: ['v*']
|
|
158
|
+
|
|
159
|
+
jobs:
|
|
160
|
+
validate:
|
|
161
|
+
runs-on: ubuntu-latest
|
|
162
|
+
steps:
|
|
163
|
+
- uses: actions/checkout@v4
|
|
164
|
+
- name: Lint
|
|
165
|
+
run: npm run lint
|
|
166
|
+
- name: Type Check
|
|
167
|
+
run: npm run typecheck
|
|
168
|
+
|
|
169
|
+
test:
|
|
170
|
+
runs-on: ubuntu-latest
|
|
171
|
+
needs: validate
|
|
172
|
+
steps:
|
|
173
|
+
- name: Unit Tests
|
|
174
|
+
run: npm test
|
|
175
|
+
- name: Coverage
|
|
176
|
+
run: npm run test:coverage
|
|
177
|
+
|
|
178
|
+
security:
|
|
179
|
+
runs-on: ubuntu-latest
|
|
180
|
+
needs: validate
|
|
181
|
+
steps:
|
|
182
|
+
- name: SAST Scan
|
|
183
|
+
uses: github/codeql-action@v2
|
|
184
|
+
- name: Dependency Check
|
|
185
|
+
run: npm audit --audit-level moderate
|
|
186
|
+
|
|
187
|
+
deploy:
|
|
188
|
+
runs-on: ubuntu-latest
|
|
189
|
+
needs: [test, security]
|
|
190
|
+
environment: production
|
|
191
|
+
steps:
|
|
192
|
+
- name: Deploy to Production
|
|
193
|
+
run: |
|
|
194
|
+
/soc-deploy prod --action deploy --version ${{ github.ref_name }}
|
|
195
|
+
```
|
|
196
|
+
|
|
197
|
+
## 6. Examples
|
|
198
|
+
|
|
199
|
+
### A. Production Deployment
|
|
200
|
+
|
|
201
|
+
```bash
|
|
202
|
+
/soc-deploy production --action deploy --version v2.1.0 --strategy blue-green --auto-rollback
|
|
203
|
+
```
|
|
204
|
+
|
|
205
|
+
*Effect:* Deploys v2.1.0 to production using blue-green strategy with automatic rollback on health check failure.
|
|
206
|
+
|
|
207
|
+
### B. Infrastructure Provisioning
|
|
208
|
+
|
|
209
|
+
```bash
|
|
210
|
+
/soc-deploy "staging-infrastructure" --action provision --provider aws --region us-east-1
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
*Effect:* Provisions all staging environment infrastructure on AWS us-east-1 (VPC, databases, caches, load balancers).
|
|
214
|
+
|
|
215
|
+
### C. Emergency Rollback
|
|
216
|
+
|
|
217
|
+
```bash
|
|
218
|
+
/soc-deploy production --action rollback --version v2.0.8
|
|
219
|
+
```
|
|
220
|
+
|
|
221
|
+
*Effect:* Immediately rolls back production to v2.0.8, verifies health, and generates incident report.
|
|
222
|
+
|
|
223
|
+
### D. Pipeline Setup
|
|
224
|
+
|
|
225
|
+
```bash
|
|
226
|
+
/soc-deploy "ci-cd" --action pipeline --provider github-actions
|
|
227
|
+
```
|
|
228
|
+
|
|
229
|
+
*Effect:* Generates complete CI/CD pipeline configuration for GitHub Actions with build, test, security, and deploy stages.
|
|
230
|
+
|
|
231
|
+
## 7. Dependencies & Capabilities
|
|
232
|
+
|
|
233
|
+
### Agents
|
|
234
|
+
|
|
235
|
+
- **DevOps Lead**: `[devops-agent]` - Infrastructure provisioning, pipeline setup, deployment execution.
|
|
236
|
+
- **Security Validator**: `[security]` - Pre-deployment security checks and approval.
|
|
237
|
+
- **PM Coordination**: `[pm-agent]` - Deployment scheduling and approval workflows.
|
|
238
|
+
|
|
239
|
+
### Skills
|
|
240
|
+
|
|
241
|
+
- **Security Audit**: `@[.opencode/skills/security-audit/SKILL.md]` - Validates deployment security.
|
|
242
|
+
- **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Pre-deployment verification.
|
|
243
|
+
- **Confidence Check**: `@[.opencode/skills/confidence-check/SKILL.md]` - Validates deployment readiness.
|
|
244
|
+
- **Package Manager**: `@[.opencode/skills/package-manager/SKILL.md]` - Ensures correct package manager for builds.
|
|
245
|
+
|
|
246
|
+
### MCP Integration
|
|
247
|
+
|
|
248
|
+
- **`tavily`**: Research cloud provider best practices and pricing.
|
|
249
|
+
- **`context7`**: Access Terraform, Kubernetes, or cloud provider documentation.
|
|
250
|
+
- **`generate_image`**: Create infrastructure architecture diagrams.
|
|
251
|
+
|
|
252
|
+
## 8. Boundaries
|
|
253
|
+
|
|
254
|
+
**Will:**
|
|
255
|
+
|
|
256
|
+
- Provision infrastructure using IaC (Terraform/CloudFormation).
|
|
257
|
+
- Configure CI/CD pipelines with proper gates and stages.
|
|
258
|
+
- Execute deployments using various strategies (blue-green, canary, rolling).
|
|
259
|
+
- Perform automated rollbacks on failure.
|
|
260
|
+
- Set up monitoring and alerting for deployed services.
|
|
261
|
+
|
|
262
|
+
**Will Not:**
|
|
263
|
+
|
|
264
|
+
- **Execute Without Approval**: Production deployments require explicit approval (unless `--auto-approve` flag used).
|
|
265
|
+
- **Modify Production Directly**: Always uses IaC and pipelines—no manual SSH changes.
|
|
266
|
+
- **Skip Security Scans**: Can override with `--skip-security` but flags as high risk.
|
|
267
|
+
- **Store Secrets**: References secret managers but never logs or stores credentials.
|
|
268
|
+
|
|
269
|
+
## User Instruction
|
|
270
|
+
|
|
271
|
+
The user have executed the `/soc-deploy` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate deployment action (provision, pipeline, deploy, rollback, or monitor), perform pre-flight checks including permissions, health status, and deployment gates, execute the requested deployment phase using infrastructure-as-code principles and the specified strategy, run health checks and verification tests, if deployment fails and `--auto-rollback` is set, execute rollback procedure, generate comprehensive deployment report with all steps, health metrics, and rollback information, and update deployment logs and notify stakeholders of completion status.
|
|
@@ -5,9 +5,11 @@ description: "Design system architecture, APIs, and component interfaces with co
|
|
|
5
5
|
# /soc-design
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
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.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command routes to specialized sub-agents based on the `--type` flag.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
@@ -18,40 +20,47 @@ The command routes to specialized sub-agents based on the `--type` flag.
|
|
|
18
20
|
| **UI Component** | `--type component` | `[frontend]` | Accessibility (WCAG), Design Tokens |
|
|
19
21
|
|
|
20
22
|
## 3. Usage & Arguments
|
|
23
|
+
|
|
21
24
|
```bash
|
|
22
25
|
/soc-design [target] [flags]
|
|
23
26
|
```
|
|
24
27
|
|
|
25
28
|
### Arguments
|
|
26
|
-
|
|
29
|
+
|
|
30
|
+
- **`[target]`**: The feature, system, or component to design (e.g., "User Auth", "Payment Gateway").
|
|
27
31
|
|
|
28
32
|
### Flags
|
|
29
|
-
|
|
30
|
-
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
33
|
+
|
|
34
|
+
- **`--type [type]`**: **MANDATORY**. One of `architecture`, `api`, `database`, `component`.
|
|
35
|
+
- **`--format [format]`**:
|
|
36
|
+
- `spec`: Textual specification with requirements (default).
|
|
37
|
+
- `diagram`: Mermaid or ASCII visualization.
|
|
38
|
+
- `code`: Interface definitions (TypeScript interfaces, SQL DDL).
|
|
34
39
|
|
|
35
40
|
## 4. Behavioral Flow (Orchestration)
|
|
36
41
|
|
|
37
42
|
### Phase 1: Context Analysis
|
|
38
|
-
|
|
39
|
-
|
|
43
|
+
|
|
44
|
+
1. **Read**: Examines existing `task.md`, `README.md`, and any previous brainstorming artifacts.
|
|
45
|
+
2. **Constraint Check**: Identifies tech stack limitations (e.g., "We are using Next.js on Vercel").
|
|
40
46
|
|
|
41
47
|
### Phase 2: Design Generation
|
|
48
|
+
|
|
42
49
|
The command prompts the target agent:
|
|
43
50
|
> "Agent **[Name]**, create a **[Type]** design for **[Target]**.
|
|
44
51
|
> Standard: **Intentional Minimalism**.
|
|
45
52
|
> Output: **[Format]**."
|
|
46
53
|
|
|
47
54
|
### Phase 3: Validation (Reflexion)
|
|
48
|
-
|
|
49
|
-
-
|
|
50
|
-
-
|
|
55
|
+
|
|
56
|
+
- Does the design violate "Zero Trust"?
|
|
57
|
+
- Is the schema normalized?
|
|
58
|
+
- Are the UI components accessible?
|
|
51
59
|
|
|
52
60
|
## 5. Output Guidelines (The Contract)
|
|
53
61
|
|
|
54
62
|
### A. Architecture Decision Record (ADR)
|
|
63
|
+
|
|
55
64
|
```markdown
|
|
56
65
|
# ADR: [Title]
|
|
57
66
|
## Context
|
|
@@ -63,6 +72,7 @@ The command prompts the target agent:
|
|
|
63
72
|
```
|
|
64
73
|
|
|
65
74
|
### B. API Specification
|
|
75
|
+
|
|
66
76
|
```typescript
|
|
67
77
|
interface CreateUserRequest {
|
|
68
78
|
email: string; // @format email
|
|
@@ -71,6 +81,7 @@ interface CreateUserRequest {
|
|
|
71
81
|
```
|
|
72
82
|
|
|
73
83
|
### C. Database Schema (Prisma/SQL)
|
|
84
|
+
|
|
74
85
|
```prisma
|
|
75
86
|
model User {
|
|
76
87
|
id String @id @default(cuid())
|
|
@@ -81,41 +92,55 @@ model User {
|
|
|
81
92
|
## 6. Examples
|
|
82
93
|
|
|
83
94
|
### A. System Architecture
|
|
95
|
+
|
|
84
96
|
```bash
|
|
85
97
|
/soc-design user-management --type architecture --format diagram
|
|
86
98
|
```
|
|
99
|
+
|
|
87
100
|
*Effect:* Triggers `architect` to draw a high-level system diagram including Auth0, Postgres, and Next.js linkage.
|
|
88
101
|
|
|
89
102
|
### B. API Design
|
|
103
|
+
|
|
90
104
|
```bash
|
|
91
105
|
/soc-design payment-api --type api --format spec
|
|
92
106
|
```
|
|
107
|
+
|
|
93
108
|
*Effect:* Triggers `backend` to define `POST /api/payments` with request/response schemas and error codes.
|
|
94
109
|
|
|
95
110
|
## 7. Dependencies & Capabilities
|
|
111
|
+
|
|
96
112
|
### Agents
|
|
97
|
-
|
|
98
|
-
-
|
|
99
|
-
-
|
|
100
|
-
-
|
|
113
|
+
|
|
114
|
+
- **Architecture**: `@[.opencode/agents/architect.md]` - System design and patterns.
|
|
115
|
+
- **API/DB**: `@[.opencode/agents/backend.md]` - Schema and interface definitions.
|
|
116
|
+
- **UI/UX**: `@[.opencode/agents/frontend.md]` - Component and interaction design.
|
|
117
|
+
- **Research**: `@[.opencode/agents/researcher.md]` - Competitive analysis and best practices.
|
|
101
118
|
|
|
102
119
|
### Skills
|
|
103
|
-
|
|
104
|
-
-
|
|
120
|
+
|
|
121
|
+
- **Simplification**: `@[.opencode/skills/simplification/SKILL.md]` - Ensuring designs are not over-engineered.
|
|
122
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - Critiquing design decisions.
|
|
105
123
|
|
|
106
124
|
### MCP Integration
|
|
107
|
-
|
|
108
|
-
-
|
|
109
|
-
-
|
|
125
|
+
|
|
126
|
+
- **`generate_image`**: Used to create UI mockups, architectural diagrams, and visual flows.
|
|
127
|
+
- **`context7`**: Accessing latest documentation for chosen frameworks (e.g., "Next.js App Router patterns").
|
|
128
|
+
- **`tavily`**: Researching industry standards and existing solutions.
|
|
110
129
|
|
|
111
130
|
## 8. Boundaries
|
|
112
131
|
|
|
113
132
|
**Will:**
|
|
114
|
-
|
|
115
|
-
-
|
|
116
|
-
-
|
|
133
|
+
|
|
134
|
+
- Create comprehensive design specifications.
|
|
135
|
+
- Generate interface definitions (contracts).
|
|
136
|
+
- Validate designs against architectural constraints.
|
|
117
137
|
|
|
118
138
|
**Will Not:**
|
|
119
|
-
|
|
120
|
-
-
|
|
121
|
-
-
|
|
139
|
+
|
|
140
|
+
- **Write Implementation Code**: Use `/soc-implement` for that.
|
|
141
|
+
- **Deploy Infrastructure**: Use Terraform/SOC agents for that.
|
|
142
|
+
- **Guess Requirements**: If ambiguous, it will ask for clarification.
|
|
143
|
+
|
|
144
|
+
## User Instruction
|
|
145
|
+
|
|
146
|
+
The user have executed the `/soc-design` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate specialized agent based on the extracted `--type` flag (architecture, api, database, or component), examine existing project context from `task.md`, `README.md`, and brainstorming artifacts to understand constraints, prompt the target agent to create comprehensive design specifications in the requested format (spec, diagram, or code), validate the design against architectural constraints and best practices including the Ultrathink protocol, and generate the appropriate output—whether an Architecture Decision Record (ADR), API specification with TypeScript interfaces, database schema definition, or UI component design with accessibility considerations.
|