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: Code improvement and optimization
|
|
|
5
5
|
# /soc-improve
|
|
6
6
|
|
|
7
7
|
## 1. Command Overview
|
|
8
|
+
|
|
8
9
|
The `/soc-improve` command is the "Optimizer." Unlike `implement` (which builds new things) or `cleanup` (which removes dead things), `improve` makes existing *working* code *better*. It focuses on performance, readability, security, and quality benchmarks.
|
|
9
10
|
|
|
10
11
|
## 2. Triggers & Routing
|
|
12
|
+
|
|
11
13
|
The command routes to specialized agents based on the `--focus` flag.
|
|
12
14
|
|
|
13
15
|
| Trigger Scenario | Flag | Target Agent | Goal |
|
|
@@ -18,35 +20,42 @@ The command routes to specialized agents based on the `--focus` flag.
|
|
|
18
20
|
| **UX Polish** | `--focus ux` | `[frontend]` | A11y, animations |
|
|
19
21
|
|
|
20
22
|
## 3. Usage & Arguments
|
|
23
|
+
|
|
21
24
|
```bash
|
|
22
25
|
/soc-improve [target] [flags]
|
|
23
26
|
```
|
|
24
27
|
|
|
25
28
|
### Arguments
|
|
26
|
-
|
|
29
|
+
|
|
30
|
+
- **`[target]`**: File or component to optimize.
|
|
27
31
|
|
|
28
32
|
### Flags
|
|
29
|
-
|
|
30
|
-
-
|
|
33
|
+
|
|
34
|
+
- **`--focus [perf|quality|security|ux]`**: **MANDATORY**.
|
|
35
|
+
- **`--metric [target]`**: Optional goal (e.g., `< 100ms`).
|
|
31
36
|
|
|
32
37
|
## 4. Behavioral Flow (Orchestration)
|
|
33
38
|
|
|
34
39
|
### Phase 1: Benchmark (The Baseline)
|
|
35
|
-
|
|
36
|
-
|
|
40
|
+
|
|
41
|
+
1. **Measure**: Analyze current state (LOC, Complexity, or approximate Perf).
|
|
42
|
+
2. **Identify**: Find bottlenecks or anti-patterns.
|
|
37
43
|
|
|
38
44
|
### Phase 2: Plan (The Upgrade)
|
|
39
|
-
|
|
40
|
-
-
|
|
45
|
+
|
|
46
|
+
- Propose specific refactors.
|
|
47
|
+
- Estimate impact (e.g., "Replacing nested loop will reduce O(n^2) to O(n)").
|
|
41
48
|
|
|
42
49
|
### Phase 3: Execute (The Refactor)
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
50
|
+
|
|
51
|
+
1. **Edit**: Apply changes safely.
|
|
52
|
+
2. **Verify**: Ensure tests still pass (Regression Check).
|
|
53
|
+
3. **Compare**: Show Before vs After stats.
|
|
46
54
|
|
|
47
55
|
## 5. Output Guidelines (The Contract)
|
|
48
56
|
|
|
49
57
|
### Improvement Report
|
|
58
|
+
|
|
50
59
|
```markdown
|
|
51
60
|
## Improvement: [Target]
|
|
52
61
|
|
|
@@ -69,37 +78,50 @@ The command routes to specialized agents based on the `--focus` flag.
|
|
|
69
78
|
## 6. Examples
|
|
70
79
|
|
|
71
80
|
### A. Performance Tuning
|
|
81
|
+
|
|
72
82
|
```bash
|
|
73
83
|
/soc-improve src/utils/sort.ts --focus perf
|
|
74
84
|
```
|
|
85
|
+
|
|
75
86
|
*Effect:* Replaces bubble sort with quicksort or uses a native method.
|
|
76
87
|
|
|
77
88
|
### B. Security Hardening
|
|
89
|
+
|
|
78
90
|
```bash
|
|
79
91
|
/soc-improve src/api/user.ts --focus security
|
|
80
92
|
```
|
|
93
|
+
|
|
81
94
|
*Effect:* Adds input validation (Zod) and rate limiting to an existing endpoint.
|
|
82
95
|
|
|
83
96
|
## 7. Dependencies & Capabilities
|
|
84
97
|
|
|
85
98
|
### Agents
|
|
86
|
-
|
|
87
|
-
-
|
|
88
|
-
-
|
|
99
|
+
|
|
100
|
+
- **Architect**: `@[.opencode/agents/architect.md]` - Performance strategy.
|
|
101
|
+
- **Quality**: `@[.opencode/agents/quality.md]` - Code structure.
|
|
102
|
+
- **Security**: `@[.opencode/agents/security.md]` - Hardening.
|
|
89
103
|
|
|
90
104
|
### Skills
|
|
91
|
-
|
|
105
|
+
|
|
106
|
+
- **Reflexion**: `@[.opencode/skills/reflexion/SKILL.md]` - Ensuring improvements don't break logic.
|
|
92
107
|
|
|
93
108
|
### MCP Integration
|
|
94
|
-
|
|
109
|
+
|
|
110
|
+
- **`context7`**: Checking for modern language features (e.g., utilizing new node.js APIs).
|
|
95
111
|
|
|
96
112
|
## 8. Boundaries
|
|
97
113
|
|
|
98
114
|
**Will:**
|
|
99
|
-
|
|
100
|
-
-
|
|
101
|
-
-
|
|
115
|
+
|
|
116
|
+
- Refactor code structure.
|
|
117
|
+
- Optimize algorithms.
|
|
118
|
+
- Add comments/documentation.
|
|
102
119
|
|
|
103
120
|
**Will Not:**
|
|
104
|
-
|
|
105
|
-
-
|
|
121
|
+
|
|
122
|
+
- **Change Behavior**: The external API/output must remain identical (unless fixing a bug).
|
|
123
|
+
- **Delete Features**: Use `/soc-cleanup` for removal.
|
|
124
|
+
|
|
125
|
+
## User Instruction
|
|
126
|
+
|
|
127
|
+
The user have executed the `/soc-improve` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-inference>$ARGUMENTS</user-instruction>`, then route to the appropriate specialized agent based on the extracted `--focus` flag (perf, quality, security, or ux), establish a baseline by measuring current state and identifying bottlenecks or anti-patterns in the specified target, propose specific refactoring or optimization strategies with estimated impact, apply changes safely while ensuring external APIs remain unchanged, verify that tests still pass for regression checking, compare before and after metrics to demonstrate improvement, and generate an improvement report documenting all changes applied and metrics achieved.
|
|
@@ -0,0 +1,329 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Project initialization, tech stack setup, and development environment scaffolding"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-onboard
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
|
|
9
|
+
The `/soc-onboard` command is the "Project Bootstrapper." It transforms an empty repository (or vague idea) into a fully-configured development environment ready for the first commit. It handles repository setup, tech stack selection, development environment configuration, and initial project structure scaffolding. This is always the **first command** for any new project.
|
|
10
|
+
|
|
11
|
+
## 2. Triggers & Routing
|
|
12
|
+
|
|
13
|
+
The command activates onboarding modes based on project type and maturity.
|
|
14
|
+
|
|
15
|
+
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
16
|
+
| :--- | :--- | :--- | :--- |
|
|
17
|
+
| **New Project** | `--type new` | `[architect]` + `[pm-agent]` | Greenfield setup, Tech selection |
|
|
18
|
+
| **Existing Repo** | `--type existing` | `[architect]` | Analysis, Documentation, Setup |
|
|
19
|
+
| **Team Onboarding** | `--type team` | `[pm-agent]` | Developer guides, Standards, Workflows |
|
|
20
|
+
| **Tech Stack Setup** | `--type stack` | `[architect]` + `[backend]` + `[frontend]` | Framework selection, Configuration |
|
|
21
|
+
|
|
22
|
+
## 3. Usage & Arguments
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
/soc-onboard [project-name] [flags]
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### Arguments
|
|
29
|
+
|
|
30
|
+
- **`[project-name]`**: Name of the project (e.g., "my-app", "api-service"). Used for repo naming, package naming, etc.
|
|
31
|
+
|
|
32
|
+
### Flags
|
|
33
|
+
|
|
34
|
+
- **`--type [new|existing|team|stack]`**: **MANDATORY**. Specifies onboarding phase.
|
|
35
|
+
- **`--template [template]`**: Starter template to use (e.g., "nextjs-fullstack", "express-api", "react-native").
|
|
36
|
+
- **`--stack [stack]`**: Tech stack preset (e.g., "typescript-react-node", "python-fastapi", "go-microservices").
|
|
37
|
+
- **`--package-manager [npm|yarn|pnpm|bun]`**: Package manager preference (auto-detected if not specified).
|
|
38
|
+
- **`--git [true|false]`**: Initialize git repository (default: true).
|
|
39
|
+
- **`--install`**: Automatically install dependencies after setup.
|
|
40
|
+
- **`--ci [provider]`**: CI/CD provider setup (e.g., "github-actions", "gitlab-ci").
|
|
41
|
+
|
|
42
|
+
## 4. Behavioral Flow (Orchestration)
|
|
43
|
+
|
|
44
|
+
### Phase 1: Analysis & Planning
|
|
45
|
+
|
|
46
|
+
#### For New Projects (`--type new`):
|
|
47
|
+
1. **Requirements Gathering**: Ask clarifying questions if stack/template not provided.
|
|
48
|
+
2. **Tech Stack Selection**: Recommend stack based on project type.
|
|
49
|
+
3. **Architecture Preview**: Generate high-level folder structure.
|
|
50
|
+
4. **Package Manager Detection**: Analyze environment and recommend best option.
|
|
51
|
+
|
|
52
|
+
#### For Existing Repos (`--type existing`):
|
|
53
|
+
1. **Codebase Analysis**: Parse existing structure, identify patterns.
|
|
54
|
+
2. **Documentation Audit**: Check for README, CONTRIBUTING, docs.
|
|
55
|
+
3. **Setup Verification**: Verify dependencies install, tests run, builds succeed.
|
|
56
|
+
4. **Gap Analysis**: Identify missing configuration files, linting, etc.
|
|
57
|
+
|
|
58
|
+
### Phase 2: Environment Setup
|
|
59
|
+
|
|
60
|
+
#### Repository Initialization:
|
|
61
|
+
- Create directory structure.
|
|
62
|
+
- Initialize git (if `--git true`).
|
|
63
|
+
- Create `.gitignore` appropriate for stack.
|
|
64
|
+
- Set up branch protection rules template.
|
|
65
|
+
|
|
66
|
+
#### Tech Stack Configuration:
|
|
67
|
+
- **Frontend**: React/Next.js/Vue config, Tailwind setup, TypeScript.
|
|
68
|
+
- **Backend**: Express/FastAPI/Gin setup, database config, API structure.
|
|
69
|
+
- **Shared**: ESLint, Prettier, TypeScript, Husky pre-commit hooks.
|
|
70
|
+
- **Testing**: Jest/Vitest/Playwright configuration.
|
|
71
|
+
|
|
72
|
+
#### Package Manager Setup (via `package-manager` skill):
|
|
73
|
+
- Detect available package managers (npm, yarn, pnpm, bun).
|
|
74
|
+
- Check version compatibility.
|
|
75
|
+
- Create lockfile (respecting user's preference).
|
|
76
|
+
- Configure workspace if monorepo detected.
|
|
77
|
+
|
|
78
|
+
### Phase 3: Documentation & Templates
|
|
79
|
+
|
|
80
|
+
- **README.md**: Project description, setup instructions, scripts.
|
|
81
|
+
- **CONTRIBUTING.md**: PR process, coding standards, commit conventions.
|
|
82
|
+
- **AGENTS.md**: OpenCode configuration for the project (this is crucial!).
|
|
83
|
+
- **LICENSE**: Template license file.
|
|
84
|
+
- **.env.example**: Environment variable template.
|
|
85
|
+
|
|
86
|
+
### Phase 4: Verification
|
|
87
|
+
|
|
88
|
+
- Run initial build to verify setup.
|
|
89
|
+
- Run linting to ensure configuration valid.
|
|
90
|
+
- Run tests (should pass with 0 tests initially).
|
|
91
|
+
- Generate onboarding completion report.
|
|
92
|
+
|
|
93
|
+
## 5. Output Guidelines (The Contract)
|
|
94
|
+
|
|
95
|
+
### Project Structure Output
|
|
96
|
+
|
|
97
|
+
```
|
|
98
|
+
my-app/
|
|
99
|
+
├── .github/
|
|
100
|
+
│ └── workflows/
|
|
101
|
+
│ └── ci.yml # CI/CD pipeline
|
|
102
|
+
├── .husky/ # Git hooks
|
|
103
|
+
│ └── pre-commit
|
|
104
|
+
├── .opencode/ # OpenCode configuration
|
|
105
|
+
│ ├── agents/
|
|
106
|
+
│ │ └── custom-agent.md
|
|
107
|
+
│ └── memory/
|
|
108
|
+
│ └── patterns.md
|
|
109
|
+
├── docs/
|
|
110
|
+
│ ├── ADR/ # Architecture Decision Records
|
|
111
|
+
│ ├── api/
|
|
112
|
+
│ └── setup.md
|
|
113
|
+
├── src/
|
|
114
|
+
│ ├── components/ # UI components
|
|
115
|
+
│ ├── lib/ # Utilities, helpers
|
|
116
|
+
│ ├── hooks/ # Custom React hooks
|
|
117
|
+
│ ├── types/ # TypeScript types
|
|
118
|
+
│ └── app/ # App routes/pages
|
|
119
|
+
├── tests/
|
|
120
|
+
│ ├── unit/
|
|
121
|
+
│ └── e2e/
|
|
122
|
+
├── .env.example
|
|
123
|
+
├── .eslintrc.js
|
|
124
|
+
├── .gitignore
|
|
125
|
+
├── .prettierrc
|
|
126
|
+
├── AGENTS.md # OpenCode project guide
|
|
127
|
+
├── CONTRIBUTING.md
|
|
128
|
+
├── LICENSE
|
|
129
|
+
├── package.json
|
|
130
|
+
├── README.md
|
|
131
|
+
├── tsconfig.json
|
|
132
|
+
└── vite.config.ts
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
### Onboarding Report Template
|
|
136
|
+
|
|
137
|
+
```markdown
|
|
138
|
+
# Project Onboarding Report: [Project Name]
|
|
139
|
+
|
|
140
|
+
## Summary
|
|
141
|
+
**Type**: New Project
|
|
142
|
+
**Template**: nextjs-fullstack
|
|
143
|
+
**Stack**: TypeScript + React + Next.js + Node.js
|
|
144
|
+
**Package Manager**: pnpm (v8.15.0)
|
|
145
|
+
**Status**: ✅ COMPLETE
|
|
146
|
+
|
|
147
|
+
## Tech Stack Details
|
|
148
|
+
|
|
149
|
+
### Frontend
|
|
150
|
+
- **Framework**: Next.js 14 (App Router)
|
|
151
|
+
- **Language**: TypeScript 5.3
|
|
152
|
+
- **Styling**: Tailwind CSS + shadcn/ui
|
|
153
|
+
- **State**: Zustand + React Query
|
|
154
|
+
- **Testing**: Vitest + React Testing Library + Playwright
|
|
155
|
+
|
|
156
|
+
### Backend
|
|
157
|
+
- **Runtime**: Node.js 20 LTS
|
|
158
|
+
- **Framework**: Next.js API Routes
|
|
159
|
+
- **Database**: PostgreSQL (Prisma ORM)
|
|
160
|
+
- **Auth**: NextAuth.js
|
|
161
|
+
- **Validation**: Zod
|
|
162
|
+
|
|
163
|
+
### DevOps
|
|
164
|
+
- **CI/CD**: GitHub Actions
|
|
165
|
+
- **Linting**: ESLint + Prettier
|
|
166
|
+
- **Hooks**: Husky + lint-staged
|
|
167
|
+
- **Type Checking**: TypeScript strict mode
|
|
168
|
+
|
|
169
|
+
## Package Manager Selection
|
|
170
|
+
**Selected**: pnpm
|
|
171
|
+
**Rationale**:
|
|
172
|
+
- ✅ Disk space efficient (content-addressable store)
|
|
173
|
+
- ✅ Fast installation (parallelized)
|
|
174
|
+
- ✅ Strict dependency resolution (prevents phantom deps)
|
|
175
|
+
- ✅ Workspace support built-in
|
|
176
|
+
- ✅ Lockfile reliable and deterministic
|
|
177
|
+
|
|
178
|
+
**Alternatives Considered**:
|
|
179
|
+
- npm: Slower, larger node_modules
|
|
180
|
+
- yarn: Good but pnpm preferred for monorepos
|
|
181
|
+
- bun: Fast but newer, less ecosystem maturity
|
|
182
|
+
|
|
183
|
+
## Generated Files
|
|
184
|
+
|
|
185
|
+
### Configuration
|
|
186
|
+
- ✅ package.json (with scripts)
|
|
187
|
+
- ✅ tsconfig.json (strict mode)
|
|
188
|
+
- ✅ tailwind.config.ts
|
|
189
|
+
- ✅ next.config.js
|
|
190
|
+
- ✅ .eslintrc.js (recommended + typescript)
|
|
191
|
+
- ✅ .prettierrc (consistent formatting)
|
|
192
|
+
- ✅ vite.config.ts (for vitest)
|
|
193
|
+
- ✅ playwright.config.ts
|
|
194
|
+
|
|
195
|
+
### Project Structure
|
|
196
|
+
- ✅ src/app/ (Next.js app router)
|
|
197
|
+
- ✅ src/components/ui/ (shadcn base)
|
|
198
|
+
- ✅ src/lib/ (utilities)
|
|
199
|
+
- ✅ src/hooks/ (custom hooks)
|
|
200
|
+
- ✅ src/types/ (global types)
|
|
201
|
+
- ✅ tests/unit/ (Vitest tests)
|
|
202
|
+
- ✅ tests/e2e/ (Playwright tests)
|
|
203
|
+
|
|
204
|
+
### Documentation
|
|
205
|
+
- ✅ README.md (setup, scripts, structure)
|
|
206
|
+
- ✅ CONTRIBUTING.md (PR process, standards)
|
|
207
|
+
- ✅ AGENTS.md (OpenCode configuration)
|
|
208
|
+
- ✅ LICENSE (MIT)
|
|
209
|
+
- ✅ .env.example (environment variables)
|
|
210
|
+
|
|
211
|
+
### OpenCode Integration
|
|
212
|
+
- ✅ .opencode/agents/ (custom agent definitions)
|
|
213
|
+
- ✅ .opencode/memory/ (project patterns)
|
|
214
|
+
|
|
215
|
+
## Verification Results
|
|
216
|
+
|
|
217
|
+
| Check | Command | Status |
|
|
218
|
+
|:------|:--------|:------:|
|
|
219
|
+
| Dependencies Install | pnpm install | ✅ |
|
|
220
|
+
| Type Check | pnpm typecheck | ✅ |
|
|
221
|
+
| Lint | pnpm lint | ✅ |
|
|
222
|
+
| Build | pnpm build | ✅ |
|
|
223
|
+
| Test | pnpm test | ✅ (0 tests) |
|
|
224
|
+
|
|
225
|
+
## Next Steps
|
|
226
|
+
|
|
227
|
+
1. **Configure Environment**: Copy `.env.example` to `.env.local` and fill in values.
|
|
228
|
+
2. **Database Setup**: Run `pnpm db:setup` to initialize PostgreSQL.
|
|
229
|
+
3. **First Feature**: Use `/soc-brainstorm` to plan your first feature.
|
|
230
|
+
4. **Team Onboarding**: Share this repo—team members just run `pnpm install`.
|
|
231
|
+
|
|
232
|
+
## Quick Commands
|
|
233
|
+
|
|
234
|
+
```bash
|
|
235
|
+
# Development
|
|
236
|
+
pnpm dev # Start dev server
|
|
237
|
+
pnpm test # Run unit tests
|
|
238
|
+
pnpm test:e2e # Run E2E tests
|
|
239
|
+
|
|
240
|
+
# Code Quality
|
|
241
|
+
pnpm lint # Run ESLint
|
|
242
|
+
pnpm lint:fix # Fix auto-fixable issues
|
|
243
|
+
pnpm format # Run Prettier
|
|
244
|
+
pnpm typecheck # TypeScript check
|
|
245
|
+
|
|
246
|
+
# Database
|
|
247
|
+
pnpm db:generate # Generate Prisma client
|
|
248
|
+
pnpm db:migrate # Run migrations
|
|
249
|
+
pnpm db:studio # Open Prisma Studio
|
|
250
|
+
```
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
## 6. Examples
|
|
254
|
+
|
|
255
|
+
### A. New Full-Stack Project
|
|
256
|
+
|
|
257
|
+
```bash
|
|
258
|
+
/soc-onboard "my-saas-app" --type new --template nextjs-fullstack --package-manager pnpm --ci github-actions
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
*Effect:* Creates complete Next.js 14 project with TypeScript, Tailwind, Prisma, PostgreSQL, NextAuth, testing setup, CI/CD, and OpenCode configuration.
|
|
262
|
+
|
|
263
|
+
### B. API-Only Project
|
|
264
|
+
|
|
265
|
+
```bash
|
|
266
|
+
/soc-onboard "payment-api" --type new --stack express-typescript --package-manager npm
|
|
267
|
+
```
|
|
268
|
+
|
|
269
|
+
*Effect:* Sets up Express.js API with TypeScript, Zod validation, Prisma ORM, Swagger docs, and testing framework.
|
|
270
|
+
|
|
271
|
+
### C. Existing Repository Analysis
|
|
272
|
+
|
|
273
|
+
```bash
|
|
274
|
+
/soc-onboard "legacy-project" --type existing
|
|
275
|
+
```
|
|
276
|
+
|
|
277
|
+
*Effect:* Analyzes existing codebase, identifies tech stack, verifies setup, and generates missing configuration files and documentation.
|
|
278
|
+
|
|
279
|
+
### D. Team Onboarding Guide
|
|
280
|
+
|
|
281
|
+
```bash
|
|
282
|
+
/soc-onboard "team-setup" --type team
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
*Effect:* Creates comprehensive team onboarding documentation: development standards, PR process, architecture overview, and troubleshooting guides.
|
|
286
|
+
|
|
287
|
+
## 7. Dependencies & Capabilities
|
|
288
|
+
|
|
289
|
+
### Agents
|
|
290
|
+
|
|
291
|
+
- **Architecture Lead**: `[architect]` - Tech stack selection and project structure.
|
|
292
|
+
- **PM Coordinator**: `[pm-agent]` - Documentation standards and team workflows.
|
|
293
|
+
- **Backend Setup**: `[backend]` - Server configuration, database setup.
|
|
294
|
+
- **Frontend Setup**: `[frontend]` - UI framework configuration, styling.
|
|
295
|
+
|
|
296
|
+
### Skills
|
|
297
|
+
|
|
298
|
+
- **Package Manager**: `@[.opencode/skills/package-manager/SKILL.md]` - **MANDATORY** for detecting and configuring the optimal package manager.
|
|
299
|
+
- **Confidence Check**: `@[.opencode/skills/confidence-check/SKILL.md]` - Validates setup choices.
|
|
300
|
+
- **Self Check**: `@[.opencode/skills/self-check/SKILL.md]` - Verifies everything works after setup.
|
|
301
|
+
|
|
302
|
+
### MCP Integration
|
|
303
|
+
|
|
304
|
+
- **`tavily`**: Research latest framework versions and best practices.
|
|
305
|
+
- **`context7`**: Access framework documentation for setup instructions.
|
|
306
|
+
- **`filesystem`**: Create directory structure and files.
|
|
307
|
+
|
|
308
|
+
## 8. Boundaries
|
|
309
|
+
|
|
310
|
+
**Will:**
|
|
311
|
+
|
|
312
|
+
- Initialize new projects with complete tech stack.
|
|
313
|
+
- Analyze and document existing repositories.
|
|
314
|
+
- Set up development environments with proper tooling.
|
|
315
|
+
- Configure package managers (auto-detect or user preference).
|
|
316
|
+
- Generate project documentation (README, CONTRIBUTING, AGENTS.md).
|
|
317
|
+
- Verify setup by running builds and tests.
|
|
318
|
+
|
|
319
|
+
**Will Not:**
|
|
320
|
+
|
|
321
|
+
- **Deploy to Production**: Only sets up local development environment.
|
|
322
|
+
- **Write Business Logic**: Creates scaffolding only—no feature implementation.
|
|
323
|
+
- **Choose Without Consent**: Recommends stack but asks for confirmation.
|
|
324
|
+
- **Override Existing Files**: Warns and backs up before overwriting.
|
|
325
|
+
- **Skip Verification**: Always runs checks to ensure setup works.
|
|
326
|
+
|
|
327
|
+
## User Instruction
|
|
328
|
+
|
|
329
|
+
The user have executed the `/soc-onboard` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate onboarding type (new, existing, team, or stack), for new projects: gather requirements, recommend and confirm tech stack, for existing projects: analyze codebase structure and configuration, use the `package-manager` skill to detect and configure the optimal package manager (never assume npm), create complete directory structure with configuration files, set up linting, testing, and CI/CD tooling, generate all documentation (README, CONTRIBUTING, AGENTS.md), initialize git repository with appropriate .gitignore, verify setup by running install, build, lint, and test commands, and generate comprehensive onboarding report with next steps and quick commands.
|
|
@@ -0,0 +1,215 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: "Sprint planning, roadmap creation, and milestone tracking with dependency mapping"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /soc-plan
|
|
6
|
+
|
|
7
|
+
## 1. Command Overview
|
|
8
|
+
|
|
9
|
+
The `/soc-plan` command bridges the gap between **brainstorming** (ideas) and **design** (architecture). It transforms high-level requirements into actionable sprints, milestones, and dependency trees. It is the "Project Navigator" that ensures the right work happens in the right order.
|
|
10
|
+
|
|
11
|
+
## 2. Triggers & Routing
|
|
12
|
+
|
|
13
|
+
The command activates specific planning modes based on project phase and scope.
|
|
14
|
+
|
|
15
|
+
| Trigger Scenario | Flag | Target Agent | Context Injected |
|
|
16
|
+
| :--- | :--- | :--- | :--- |
|
|
17
|
+
| **Sprint Planning** | `--mode sprint` | `[pm-agent]` | User Stories, Capacity, Velocity |
|
|
18
|
+
| **Roadmap Creation** | `--mode roadmap` | `[pm-agent]` + `[architect]` | Quarterly Goals, Tech Debt |
|
|
19
|
+
| **Milestone Tracking** | `--mode milestone` | `[pm-agent]` | Critical Path, Blockers |
|
|
20
|
+
| **Dependency Analysis** | `--mode dependencies` | `[architect]` | Service Dependencies, APIs |
|
|
21
|
+
|
|
22
|
+
## 3. Usage & Arguments
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
/soc-plan [scope] [flags]
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
### Arguments
|
|
29
|
+
|
|
30
|
+
- **`[scope]`**: The planning scope (e.g., "Q1 2026 Features", "User Auth Epic", "v2.0 Release").
|
|
31
|
+
|
|
32
|
+
### Flags
|
|
33
|
+
|
|
34
|
+
- **`--mode [sprint|roadmap|milestone|dependencies]`**: **MANDATORY**. Specifies the planning granularity.
|
|
35
|
+
- **`--duration [weeks]`**: Sprint/roadmap duration (default: 2 weeks for sprint, 12 weeks for roadmap).
|
|
36
|
+
- **`--capacity [hours]`**: Team capacity in hours for sprint planning.
|
|
37
|
+
- **`--priority [must|should|could]`**: Filters tasks by MoSCoW priority.
|
|
38
|
+
- **`--output [markdown|json|csv]`**: Output format for the plan (default: markdown).
|
|
39
|
+
|
|
40
|
+
## 4. Behavioral Flow (Orchestration)
|
|
41
|
+
|
|
42
|
+
### Phase 1: Context Gathering
|
|
43
|
+
|
|
44
|
+
1. **Read**: Parse existing `requirements.md`, `task_queue.md`, and `project_status.md`.
|
|
45
|
+
2. **Analyze**: Identify completed work, in-progress items, and pending backlog.
|
|
46
|
+
3. **Constraint Check**: Review technical constraints from `architect` ADRs.
|
|
47
|
+
|
|
48
|
+
### Phase 2: Planning Generation
|
|
49
|
+
|
|
50
|
+
#### For Sprint Mode (`--mode sprint`):
|
|
51
|
+
- Break down epics into sprint-sized tasks (≤8 hours each).
|
|
52
|
+
- Assign story points using Fibonacci scale.
|
|
53
|
+
- Calculate velocity based on historical data.
|
|
54
|
+
- Identify dependencies that block sprint completion.
|
|
55
|
+
|
|
56
|
+
#### For Roadmap Mode (`--mode roadmap`):
|
|
57
|
+
- Map epics to quarters/months.
|
|
58
|
+
- Align technical milestones with business goals.
|
|
59
|
+
- Schedule tech debt reduction sprints.
|
|
60
|
+
- Identify hiring/resource needs.
|
|
61
|
+
|
|
62
|
+
#### For Dependency Mode (`--mode dependencies`):
|
|
63
|
+
- Map service-to-service dependencies.
|
|
64
|
+
- Identify circular dependencies and coupling.
|
|
65
|
+
- Create critical path visualization.
|
|
66
|
+
- Flag external API dependencies and SLAs.
|
|
67
|
+
|
|
68
|
+
### Phase 3: Validation & Output
|
|
69
|
+
|
|
70
|
+
- **Validate**: Check for overloaded sprints (>100% capacity).
|
|
71
|
+
- **Export**: Generate `sprint_plan.md` or `roadmap.md`.
|
|
72
|
+
- **Sync**: Update `project_status.md` with new milestones.
|
|
73
|
+
|
|
74
|
+
## 5. Output Guidelines (The Contract)
|
|
75
|
+
|
|
76
|
+
### Sprint Plan Template
|
|
77
|
+
|
|
78
|
+
```markdown
|
|
79
|
+
# Sprint Plan: [Sprint Name]
|
|
80
|
+
|
|
81
|
+
## Overview
|
|
82
|
+
**Duration**: [Start Date] - [End Date]
|
|
83
|
+
**Capacity**: [X] hours
|
|
84
|
+
**Velocity**: [Y] story points
|
|
85
|
+
**Goal**: [One-line sprint objective]
|
|
86
|
+
|
|
87
|
+
## Sprint Backlog
|
|
88
|
+
|
|
89
|
+
### Must Have (MoSCoW)
|
|
90
|
+
| ID | Task | Story Points | Assignee | Dependencies | Status |
|
|
91
|
+
|:---|:-----|:------------:|:--------:|:-------------|:------:|
|
|
92
|
+
| US-001 | Implement OAuth login | 5 | backend | DB Schema | ⬜ |
|
|
93
|
+
| US-002 | Create login UI | 3 | frontend | US-001 API | ⬜ |
|
|
94
|
+
|
|
95
|
+
### Should Have
|
|
96
|
+
| ID | Task | Story Points | Assignee | Dependencies | Status |
|
|
97
|
+
|:---|:-----|:------------:|:--------:|:-------------|:------:|
|
|
98
|
+
| US-003 | Add password reset | 3 | backend | Email Service | ⬜ |
|
|
99
|
+
|
|
100
|
+
### Could Have
|
|
101
|
+
| ID | Task | Story Points | Assignee | Dependencies | Status |
|
|
102
|
+
|:---|:-----|:------------:|:--------:|:-------------|:------:|
|
|
103
|
+
| US-004 | Social login buttons | 2 | frontend | US-002 | ⬜ |
|
|
104
|
+
|
|
105
|
+
## Risks & Blockers
|
|
106
|
+
- ⚠️ **BLOCKER**: Waiting for AWS account setup (affects US-001)
|
|
107
|
+
- 🟡 **RISK**: Email service API rate limits
|
|
108
|
+
|
|
109
|
+
## Definition of Done
|
|
110
|
+
- [ ] All "Must Have" tasks completed
|
|
111
|
+
- [ ] Code reviewed and merged
|
|
112
|
+
- [ ] Tests passing (>80% coverage)
|
|
113
|
+
- [ ] Documentation updated
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
### Roadmap Template
|
|
117
|
+
|
|
118
|
+
```markdown
|
|
119
|
+
# Product Roadmap: [Project Name]
|
|
120
|
+
|
|
121
|
+
## Q1 2026: Foundation
|
|
122
|
+
- **Theme**: Core Platform & Auth
|
|
123
|
+
- **Key Deliverables**:
|
|
124
|
+
- User authentication system
|
|
125
|
+
- Database schema v1
|
|
126
|
+
- CI/CD pipeline
|
|
127
|
+
- **Milestone**: Beta Launch (March 15)
|
|
128
|
+
|
|
129
|
+
## Q2 2026: Growth
|
|
130
|
+
- **Theme**: Features & Scale
|
|
131
|
+
- **Key Deliverables**:
|
|
132
|
+
- Payment integration
|
|
133
|
+
- Admin dashboard
|
|
134
|
+
- Performance optimization
|
|
135
|
+
- **Milestone**: Public Launch (June 1)
|
|
136
|
+
|
|
137
|
+
## Dependencies Map
|
|
138
|
+
```mermaid
|
|
139
|
+
gantt
|
|
140
|
+
title Critical Path
|
|
141
|
+
dateFormat YYYY-MM-DD
|
|
142
|
+
section Backend
|
|
143
|
+
DB Schema :done, db, 2026-01-01, 5d
|
|
144
|
+
API Development :active, api, after db, 10d
|
|
145
|
+
section Frontend
|
|
146
|
+
UI Components :ui, after db, 7d
|
|
147
|
+
Integration :int, after api, 5d
|
|
148
|
+
```
|
|
149
|
+
```
|
|
150
|
+
|
|
151
|
+
## 6. Examples
|
|
152
|
+
|
|
153
|
+
### A. Sprint Planning
|
|
154
|
+
|
|
155
|
+
```bash
|
|
156
|
+
/soc-plan "User Authentication Epic" --mode sprint --duration 2 --capacity 80
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
*Effect:* Creates a 2-week sprint plan with tasks broken down from the auth epic, estimated at 80 hours capacity, with dependency chains identified.
|
|
160
|
+
|
|
161
|
+
### B. Quarterly Roadmap
|
|
162
|
+
|
|
163
|
+
```bash
|
|
164
|
+
/soc-plan "Q1 2026 Product Roadmap" --mode roadmap --duration 12
|
|
165
|
+
```
|
|
166
|
+
|
|
167
|
+
*Effect:* Generates a 12-week roadmap with monthly milestones, resource allocation, and tech debt sprints scheduled.
|
|
168
|
+
|
|
169
|
+
### C. Dependency Analysis
|
|
170
|
+
|
|
171
|
+
```bash
|
|
172
|
+
/soc-plan "Microservices Architecture" --mode dependencies
|
|
173
|
+
```
|
|
174
|
+
|
|
175
|
+
*Effect:* Maps all service dependencies, identifies circular dependencies, and creates a critical path diagram.
|
|
176
|
+
|
|
177
|
+
## 7. Dependencies & Capabilities
|
|
178
|
+
|
|
179
|
+
### Agents
|
|
180
|
+
|
|
181
|
+
- **Orchestrator**: `[pm-agent]` - Sprint breakdown, capacity planning, and milestone tracking.
|
|
182
|
+
- **Technical Consultant**: `[architect]` - Dependency mapping and technical feasibility.
|
|
183
|
+
- **Support**: `[backend]`, `[frontend]` - Effort estimation for implementation tasks.
|
|
184
|
+
|
|
185
|
+
### Skills
|
|
186
|
+
|
|
187
|
+
- **Sequential Thinking**: `@[.opencode/skills/sequential-thinking/SKILL.md]` - For dependency tree analysis and critical path calculation.
|
|
188
|
+
- **Simplification**: `@[.opencode/skills/simplification/SKILL.md]` - Ensures plans are realistic and not over-committed.
|
|
189
|
+
- **Confidence Check**: `@[.opencode/skills/confidence-check/SKILL.md]` - Validates plan feasibility before commitment.
|
|
190
|
+
|
|
191
|
+
### MCP Integration
|
|
192
|
+
|
|
193
|
+
- **`sequential-thinking`**: **MANDATORY** for complex dependency mapping.
|
|
194
|
+
- **`read_file` / `write_file`**: Updates `project_status.md`, `sprint_plan.md`, `roadmap.md`.
|
|
195
|
+
- **`tavily`**: Research industry-standard story point baselines and velocity benchmarks.
|
|
196
|
+
|
|
197
|
+
## 8. Boundaries
|
|
198
|
+
|
|
199
|
+
**Will:**
|
|
200
|
+
|
|
201
|
+
- Create detailed sprint and roadmap documents.
|
|
202
|
+
- Calculate capacity and velocity metrics.
|
|
203
|
+
- Map dependencies and critical paths.
|
|
204
|
+
- Identify risks and blockers.
|
|
205
|
+
|
|
206
|
+
**Will Not:**
|
|
207
|
+
|
|
208
|
+
- **Assign Specific People**: Suggests agent types (backend/frontend) but not individual humans.
|
|
209
|
+
- **Guarantee Delivery Dates**: Provides estimates with confidence intervals, not promises.
|
|
210
|
+
- **Ignore Constraints**: Will flag if requested scope exceeds capacity.
|
|
211
|
+
- **Execute Work**: Planning only—use `/soc-implement` for execution.
|
|
212
|
+
|
|
213
|
+
## User Instruction
|
|
214
|
+
|
|
215
|
+
The user have executed the `/soc-plan` command by parsing the user's arguments provided in `<user-instruction>$ARGUMENTS</user-instruction>`, then route to the appropriate mode (sprint, roadmap, milestone, or dependencies), read existing project context from `requirements.md`, `task_queue.md`, and `project_status.md`, generate a comprehensive plan document with task breakdowns, estimates, and dependency mapping, validate the plan against capacity constraints and technical feasibility, identify risks and blockers, and output the plan in the requested format while updating `project_status.md` with new milestones and timelines.
|