opencodekit 0.23.2 → 0.23.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -14
- package/dist/index.js +1 -1
- package/dist/template/.opencode/AGENTS.md +92 -19
- package/dist/template/.opencode/README.md +43 -6
- package/dist/template/.opencode/artifacts/harness-workflows/plan.md +317 -0
- package/dist/template/.opencode/command/audit.md +65 -0
- package/dist/template/.opencode/command/init.md +19 -2
- package/dist/template/.opencode/command/research.md +67 -16
- package/dist/template/.opencode/command/ship.md +55 -5
- package/dist/template/.opencode/command/verify.md +5 -5
- package/dist/template/.opencode/opencode.json +12 -0
- package/dist/template/.opencode/plugin/README.md +0 -6
- package/dist/template/.opencode/plugin/codesearch.ts +730 -0
- package/dist/template/.opencode/plugin/memory/tools.ts +6 -6
- package/dist/template/.opencode/plugin/session-summary.ts +0 -2
- package/dist/template/.opencode/plugin/srcwalk.ts +22 -157
- package/dist/template/.opencode/skill/code-review-and-quality/SKILL.md +1 -1
- package/dist/template/.opencode/skill/debugging-and-error-recovery/SKILL.md +1 -1
- package/dist/template/.opencode/skill/deep-module-design/SKILL.md +1 -1
- package/dist/template/.opencode/skill/defense-in-depth/SKILL.md +0 -2
- package/dist/template/.opencode/skill/development-lifecycle/SKILL.md +11 -9
- package/dist/template/.opencode/skill/manifest.json +77 -0
- package/dist/template/.opencode/skill/planning-and-task-breakdown/SKILL.md +1 -1
- package/dist/template/.opencode/skill/srcwalk/SKILL.md +10 -13
- package/dist/template/.opencode/tool/grepsearch.ts +92 -103
- package/dist/template/.opencode/workflows/audit-pattern.md +51 -0
- package/dist/template/.opencode/workflows/batch-implement.md +82 -0
- package/dist/template/.opencode/workflows/deep-research.md +58 -0
- package/dist/template/.opencode/workflows/development-lifecycle-workflow.md +129 -0
- package/package.json +1 -1
- package/dist/template/.opencode/command/clarify.md +0 -46
- package/dist/template/.opencode/command/commit.md +0 -53
- package/dist/template/.opencode/command/design.md +0 -129
- package/dist/template/.opencode/command/explore.md +0 -169
- package/dist/template/.opencode/command/improve-architecture.md +0 -55
- package/dist/template/.opencode/command/pr.md +0 -148
- package/dist/template/.opencode/command/refactor.md +0 -65
- package/dist/template/.opencode/command/review-codebase.md +0 -128
- package/dist/template/.opencode/command/test.md +0 -66
- package/dist/template/.opencode/command/ui-review.md +0 -109
- package/dist/template/.opencode/opencodex-fast.jsonc +0 -3
- package/dist/template/.opencode/plugin/rtk.ts +0 -43
- package/dist/template/.opencode/skill/agent-teams/SKILL.md +0 -268
- package/dist/template/.opencode/skill/code-navigation/SKILL.md +0 -142
- package/dist/template/.opencode/skill/condition-based-waiting/SKILL.md +0 -135
- package/dist/template/.opencode/skill/condition-based-waiting/example.ts +0 -171
- package/dist/template/.opencode/skill/context-engineering/SKILL.md +0 -176
- package/dist/template/.opencode/skill/memory-system/SKILL.md +0 -147
- package/dist/template/.opencode/skill/structured-edit/SKILL.md +0 -191
- package/dist/template/.opencode/skill/ubiquitous-language/SKILL.md +0 -184
- package/dist/template/.opencode/skill/v0/SKILL.md +0 -158
|
@@ -3,19 +3,19 @@ import { tool } from "@opencode-ai/plugin";
|
|
|
3
3
|
const GREP_APP_API = "https://grep.app/api/search";
|
|
4
4
|
|
|
5
5
|
interface SearchResult {
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
6
|
+
repo: string;
|
|
7
|
+
path: string;
|
|
8
|
+
content: { snippet: string };
|
|
9
|
+
total_matches: string;
|
|
10
10
|
}
|
|
11
11
|
|
|
12
12
|
interface GrepResponse {
|
|
13
|
-
|
|
14
|
-
|
|
13
|
+
hits: { hits: SearchResult[] };
|
|
14
|
+
time: number;
|
|
15
15
|
}
|
|
16
16
|
|
|
17
17
|
export default tool({
|
|
18
|
-
|
|
18
|
+
description: `Search real-world code examples from GitHub repositories via grep.app. Replaces asking "how do others use X?" — use this for finding production patterns and real-world API usage.
|
|
19
19
|
|
|
20
20
|
WHEN: Implementing unfamiliar APIs, looking for production patterns, understanding library integrations.
|
|
21
21
|
SKIP: Searching your own codebase (use grep/srcwalk), looking up docs (use context7), general research (use websearch).
|
|
@@ -31,113 +31,102 @@ Use when:
|
|
|
31
31
|
- Understanding library integrations - see how things work together
|
|
32
32
|
|
|
33
33
|
IMPORTANT: Search for **literal code patterns**, not keywords:
|
|
34
|
-
|
|
35
|
-
❌ Bad: "react tutorial", "best practices", "how to use"
|
|
34
|
+
Good: "useState(", "import React from", "async function"
|
|
36
35
|
|
|
36
|
+
Bad: "react tutorial", "best practices", "how to use"
|
|
37
37
|
Examples:
|
|
38
38
|
grepsearch({ query: "getServerSession", language: "TypeScript" })
|
|
39
39
|
grepsearch({ query: "CORS(", language: "Python", repo: "flask" })
|
|
40
40
|
grepsearch({ query: "export async function POST", path: "route.ts" })
|
|
41
41
|
`,
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
|
|
46
|
-
|
|
47
|
-
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
.replace(/<[^>]*>/g, "") // Remove HTML tags
|
|
119
|
-
.replace(/</g, "<")
|
|
120
|
-
.replace(/>/g, ">")
|
|
121
|
-
.replace(/&/g, "&")
|
|
122
|
-
.replace(/"/g, '"')
|
|
123
|
-
.split("\n")
|
|
124
|
-
.slice(0, 8)
|
|
125
|
-
.join("\n")
|
|
126
|
-
.trim();
|
|
127
|
-
|
|
128
|
-
return `## ${i + 1}. ${repoName}
|
|
42
|
+
args: {
|
|
43
|
+
query: tool.schema.string().describe("Code pattern to search for (literal text)"),
|
|
44
|
+
language: tool.schema
|
|
45
|
+
.string()
|
|
46
|
+
.optional()
|
|
47
|
+
.describe("Filter by language: TypeScript, TSX, Python, Go, Rust, etc."),
|
|
48
|
+
repo: tool.schema.string().optional().describe("Filter by repo: 'owner/repo' or partial match"),
|
|
49
|
+
path: tool.schema.string().optional().describe("Filter by file path: 'src/', '.test.ts', etc."),
|
|
50
|
+
limit: tool.schema.number().optional().describe("Max results to return (default: 10, max: 20)"),
|
|
51
|
+
},
|
|
52
|
+
execute: async (args) => {
|
|
53
|
+
const { query, language, repo, path, limit = 10 } = args;
|
|
54
|
+
|
|
55
|
+
if (!query || query.trim() === "") {
|
|
56
|
+
return "Error: query is required";
|
|
57
|
+
}
|
|
58
|
+
|
|
59
|
+
// Build URL with proper filter parameters
|
|
60
|
+
// grep.app uses filter[lang][0]=TypeScript format, NOT inline lang:TypeScript
|
|
61
|
+
const url = new URL(GREP_APP_API);
|
|
62
|
+
url.searchParams.set("q", query);
|
|
63
|
+
|
|
64
|
+
// Add language filter (grep.app uses filter[lang][0] format)
|
|
65
|
+
if (language) {
|
|
66
|
+
url.searchParams.set("filter[lang][0]", language);
|
|
67
|
+
}
|
|
68
|
+
|
|
69
|
+
// Add repo filter
|
|
70
|
+
if (repo) {
|
|
71
|
+
url.searchParams.set("filter[repo][0]", repo);
|
|
72
|
+
}
|
|
73
|
+
|
|
74
|
+
// Add path filter
|
|
75
|
+
if (path) {
|
|
76
|
+
url.searchParams.set("filter[path][0]", path);
|
|
77
|
+
}
|
|
78
|
+
|
|
79
|
+
try {
|
|
80
|
+
const response = await fetch(url.toString(), {
|
|
81
|
+
headers: {
|
|
82
|
+
Accept: "application/json",
|
|
83
|
+
"User-Agent": "OpenCode/1.0",
|
|
84
|
+
},
|
|
85
|
+
});
|
|
86
|
+
|
|
87
|
+
if (!response.ok) {
|
|
88
|
+
return `Error: grep.app API returned ${response.status}`;
|
|
89
|
+
}
|
|
90
|
+
|
|
91
|
+
const data = (await response.json()) as GrepResponse;
|
|
92
|
+
|
|
93
|
+
if (!data.hits?.hits?.length) {
|
|
94
|
+
return `No results found for: ${query}${language ? ` (${language})` : ""}`;
|
|
95
|
+
}
|
|
96
|
+
|
|
97
|
+
const maxResults = Math.min(limit, 20);
|
|
98
|
+
const results = data.hits.hits.slice(0, maxResults);
|
|
99
|
+
|
|
100
|
+
const formatted = results.map((hit, i) => {
|
|
101
|
+
const repoName = hit.repo || "unknown";
|
|
102
|
+
const filePath = hit.path || "unknown";
|
|
103
|
+
const snippet = hit.content?.snippet || "";
|
|
104
|
+
|
|
105
|
+
// Clean up HTML from snippet and extract text
|
|
106
|
+
const cleanCode = snippet
|
|
107
|
+
.replace(/<[^>]*>/g, "") // Remove HTML tags
|
|
108
|
+
.replace(/</g, "<")
|
|
109
|
+
.replace(/>/g, ">")
|
|
110
|
+
.replace(/&/g, "&")
|
|
111
|
+
.replace(/"/g, '"')
|
|
112
|
+
.split("\n")
|
|
113
|
+
.slice(0, 8)
|
|
114
|
+
.join("\n")
|
|
115
|
+
.trim();
|
|
116
|
+
|
|
117
|
+
return `## ${i + 1}. ${repoName}
|
|
129
118
|
**File**: ${filePath}
|
|
130
119
|
\`\`\`
|
|
131
120
|
${cleanCode}
|
|
132
121
|
\`\`\``;
|
|
133
|
-
|
|
122
|
+
});
|
|
134
123
|
|
|
135
|
-
|
|
124
|
+
return `Found ${data.hits.hits.length} results (showing ${results.length}) in ${data.time}ms:
|
|
136
125
|
|
|
137
126
|
${formatted.join("\n\n")}`;
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
|
|
127
|
+
} catch (error: unknown) {
|
|
128
|
+
const message = error instanceof Error ? error.message : String(error);
|
|
129
|
+
return `Error searching grep.app: ${message}`;
|
|
130
|
+
}
|
|
131
|
+
},
|
|
143
132
|
});
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# audit-pattern
|
|
2
|
+
|
|
3
|
+
Find all occurrences of a code pattern in the codebase, review each match for correctness/security/edge-cases, and produce prioritized remediation recommendations. Use for cross-cutting concerns like auth checks, error handling, or API patterns.
|
|
4
|
+
|
|
5
|
+
## Args
|
|
6
|
+
|
|
7
|
+
- `pattern` (required) — The code pattern to search for
|
|
8
|
+
|
|
9
|
+
## Phases
|
|
10
|
+
|
|
11
|
+
### Phase 1: discover
|
|
12
|
+
|
|
13
|
+
- **Agent:** @explore
|
|
14
|
+
- **Concurrency:** 1
|
|
15
|
+
- **Prompt:**
|
|
16
|
+
|
|
17
|
+
Search the codebase for the pattern: {pattern}. Use grep or csearch to find every occurrence. List each file with line numbers, grouped by subdirectory. If the pattern has common variations, include those too. Return results in this format:
|
|
18
|
+
|
|
19
|
+
## Directory: [path]
|
|
20
|
+
- `file.ts:42` — [brief context]
|
|
21
|
+
- `file.ts:87` — [brief context]
|
|
22
|
+
|
|
23
|
+
Keep each entry under 50 words.
|
|
24
|
+
|
|
25
|
+
### Phase 2: audit
|
|
26
|
+
|
|
27
|
+
- **Depends on:** Phase 1
|
|
28
|
+
- **Agent:** @review
|
|
29
|
+
- **Concurrency:** Dynamic (estimate ~10 occurrences per agent, min 2, max 15)
|
|
30
|
+
- **Prompt:**
|
|
31
|
+
|
|
32
|
+
Review the following files for the pattern '{pattern}': {phase_1_output}. For each occurrence check: correctness, edge cases, security implications, error handling, and adherence to project conventions. Return findings in this format:
|
|
33
|
+
|
|
34
|
+
## File: [path:line]
|
|
35
|
+
- **Severity:** [critical/important/minor]
|
|
36
|
+
- **Issue:** [description]
|
|
37
|
+
- **Recommendation:** [fix suggestion]
|
|
38
|
+
|
|
39
|
+
Keep each finding under 100 words.
|
|
40
|
+
|
|
41
|
+
## Final Synthesis (Main Agent)
|
|
42
|
+
|
|
43
|
+
After Phase 2 completes, synthesize the audit findings directly from {phase_2_output}.
|
|
44
|
+
|
|
45
|
+
Produce:
|
|
46
|
+
1. **Issues ranked by severity** — Critical, important, minor with file:line references
|
|
47
|
+
2. **Affected scope** — Count of files and occurrences
|
|
48
|
+
3. **Recommended fixes** — Specific fix suggestions per issue
|
|
49
|
+
4. **Correct patterns** — Patterns that are already correct and should be preserved
|
|
50
|
+
|
|
51
|
+
Group findings by subdirectory. Keep the report under 1500 words.
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# batch-implement
|
|
2
|
+
|
|
3
|
+
Take a plan with independent tasks and dispatch one subagent per task in parallel. Each task result is reviewed, then merged. Use for multi-file feature implementation where tasks don't share file dependencies.
|
|
4
|
+
|
|
5
|
+
## Args
|
|
6
|
+
|
|
7
|
+
- `plan` (required) — The implementation plan or PRD
|
|
8
|
+
|
|
9
|
+
## Phases
|
|
10
|
+
|
|
11
|
+
### Phase 1: plan-review
|
|
12
|
+
|
|
13
|
+
- **Agent:** @review
|
|
14
|
+
- **Concurrency:** 1
|
|
15
|
+
- **Prompt:**
|
|
16
|
+
|
|
17
|
+
Review this implementation plan for task independence: {plan}. Verify that the tasks don't edit the same files. If any tasks have overlapping file dependencies, flag them as conflicts. Return the list of tasks grouped by dependency in this format:
|
|
18
|
+
|
|
19
|
+
## Independent Tasks (can run in parallel)
|
|
20
|
+
- **Task 1:** [description]
|
|
21
|
+
- Files: [list]
|
|
22
|
+
- **Task 2:** [description]
|
|
23
|
+
- Files: [list]
|
|
24
|
+
|
|
25
|
+
## Dependent Tasks (must run sequentially)
|
|
26
|
+
- **Task 3:** [description]
|
|
27
|
+
- Depends on: [task names]
|
|
28
|
+
- Files: [list]
|
|
29
|
+
|
|
30
|
+
Keep each task description under 100 words.
|
|
31
|
+
|
|
32
|
+
### Phase 2: implement
|
|
33
|
+
|
|
34
|
+
- **Depends on:** Phase 1
|
|
35
|
+
- **Agent:** @general
|
|
36
|
+
- **Concurrency:** Dynamic (1 agent per task, min 2, max 10)
|
|
37
|
+
- **Prompt:**
|
|
38
|
+
|
|
39
|
+
Implement the following task from the plan: {phase_1_output}. Write production-quality code following project conventions. Include type definitions, error handling, and unit tests. Keep changes scoped to the task — do not refactor unrelated code. Return a summary in this format:
|
|
40
|
+
|
|
41
|
+
## Task: [name]
|
|
42
|
+
- **Files modified:** [list]
|
|
43
|
+
- **Tests added:** [list]
|
|
44
|
+
- **Key changes:** [brief summary]
|
|
45
|
+
|
|
46
|
+
Keep the summary under 200 words.
|
|
47
|
+
|
|
48
|
+
### Phase 3: verify
|
|
49
|
+
|
|
50
|
+
- **Depends on:** Phase 2
|
|
51
|
+
- **Agent:** @review
|
|
52
|
+
- **Concurrency:** Dynamic (~3 implementations per agent, min 2, max 8)
|
|
53
|
+
- **Prompt:**
|
|
54
|
+
|
|
55
|
+
Review this implementation: {phase_2_output}. Check: correctness against the task requirements, test coverage, edge case handling, type safety, and lint compliance. Return findings in this format:
|
|
56
|
+
|
|
57
|
+
## Task: [name]
|
|
58
|
+
- **Status:** [pass/fail]
|
|
59
|
+
- **Issues:** [list with file:line refs]
|
|
60
|
+
- **Recommendations:** [list]
|
|
61
|
+
|
|
62
|
+
Keep each finding under 100 words.
|
|
63
|
+
|
|
64
|
+
## Final Merge (Main Agent)
|
|
65
|
+
|
|
66
|
+
After Phase 3 completes, merge the verified implementations directly from {phase_3_output}.
|
|
67
|
+
|
|
68
|
+
Ensure:
|
|
69
|
+
- No duplicate imports
|
|
70
|
+
- Consistent naming conventions
|
|
71
|
+
- Proper module boundaries
|
|
72
|
+
- No broken imports between modules
|
|
73
|
+
|
|
74
|
+
Report any merge conflicts or integration issues. Return a summary:
|
|
75
|
+
|
|
76
|
+
## Merge Summary
|
|
77
|
+
- **Tasks merged:** [count]
|
|
78
|
+
- **Files modified:** [list]
|
|
79
|
+
- **Integration issues:** [list or 'none']
|
|
80
|
+
- **Next steps:** [list]
|
|
81
|
+
|
|
82
|
+
Keep the summary under 500 words.
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# deep-research
|
|
2
|
+
|
|
3
|
+
Fan out web searches across multiple angles on a question, cross-check sources for contradictions, and produce a cited report with confidence levels. Use when you need multi-source verification or current-events coverage.
|
|
4
|
+
|
|
5
|
+
## Args
|
|
6
|
+
|
|
7
|
+
- `question` (required) — The research question or topic
|
|
8
|
+
|
|
9
|
+
## Phases
|
|
10
|
+
|
|
11
|
+
### Phase 1: research
|
|
12
|
+
|
|
13
|
+
- **Agent:** @scout
|
|
14
|
+
- **Concurrency:** Dynamic (1 agent per distinct angle, min 3, max 10)
|
|
15
|
+
- **Prompt:**
|
|
16
|
+
|
|
17
|
+
Search for different perspectives on the question: {question}. Cover opposing viewpoints, authoritative sources, and recent developments. For each finding, include the URL and publication date. Return findings grouped by angle in this format:
|
|
18
|
+
|
|
19
|
+
## Angle: [angle name]
|
|
20
|
+
- **Finding:** [summary]
|
|
21
|
+
- **Source:** [URL]
|
|
22
|
+
- **Date:** [publication date]
|
|
23
|
+
- **Confidence:** [high/medium/low]
|
|
24
|
+
|
|
25
|
+
Keep each finding under 200 words.
|
|
26
|
+
|
|
27
|
+
### Phase 2: cross-check
|
|
28
|
+
|
|
29
|
+
- **Depends on:** Phase 1
|
|
30
|
+
- **Agent:** @review
|
|
31
|
+
- **Concurrency:** Dynamic (estimate ~5 findings per agent, min 2, max 10)
|
|
32
|
+
- **Prompt:**
|
|
33
|
+
|
|
34
|
+
Cross-check these findings: {phase_1_output}. Flag contradictions between sources, identify confirmable facts with supporting citations, and note where sources disagree or lack evidence. Return a verified fact set in this format:
|
|
35
|
+
|
|
36
|
+
## Verified Facts
|
|
37
|
+
- **Fact:** [statement]
|
|
38
|
+
- **Confidence:** [high/medium/low]
|
|
39
|
+
- **Supporting sources:** [list of URLs]
|
|
40
|
+
|
|
41
|
+
## Contradictions
|
|
42
|
+
- **Claim A:** [statement]
|
|
43
|
+
- **Claim B:** [contradicting statement]
|
|
44
|
+
- **Resolution:** [which is more credible and why]
|
|
45
|
+
|
|
46
|
+
Keep each item under 150 words.
|
|
47
|
+
|
|
48
|
+
## Final Synthesis (Main Agent)
|
|
49
|
+
|
|
50
|
+
After Phase 2 completes, synthesize the final report directly from {phase_2_output}.
|
|
51
|
+
|
|
52
|
+
Write a final cited report using markdown with sections:
|
|
53
|
+
1. **Executive Summary** — Brief overview of key findings
|
|
54
|
+
2. **Key Findings** — Detailed findings with inline citations
|
|
55
|
+
3. **Contradictions & Uncertainties** — Areas of disagreement or low confidence
|
|
56
|
+
4. **Sources** — Complete list of all sources consulted
|
|
57
|
+
|
|
58
|
+
Annotate each claim with confidence level (high/medium/low). Keep the report under 2000 words.
|
|
@@ -0,0 +1,129 @@
|
|
|
1
|
+
# development-lifecycle-workflow
|
|
2
|
+
|
|
3
|
+
Multi-agent workflow that chains the development lifecycle phases with parallelism. Uses specialized agents (scouts, reviewers, planners) and composes with the batch-implement workflow for parallel implementation.
|
|
4
|
+
|
|
5
|
+
## Args
|
|
6
|
+
|
|
7
|
+
- `feature` (required) — The feature or change to implement
|
|
8
|
+
|
|
9
|
+
## Phases
|
|
10
|
+
|
|
11
|
+
### Phase 1: Research Approaches
|
|
12
|
+
|
|
13
|
+
- **Agent:** @scout
|
|
14
|
+
- **Concurrency:** Dynamic (1 agent per approach, min 2, max 5)
|
|
15
|
+
- **Prompt:**
|
|
16
|
+
|
|
17
|
+
Research different approaches to implementing: {feature}. For each approach, analyze:
|
|
18
|
+
1. Technical feasibility
|
|
19
|
+
2. Trade-offs and risks
|
|
20
|
+
3. Implementation complexity
|
|
21
|
+
4. Dependencies and constraints
|
|
22
|
+
|
|
23
|
+
Return findings in this format:
|
|
24
|
+
|
|
25
|
+
## Approach 1: [name]
|
|
26
|
+
- **Description:** [summary]
|
|
27
|
+
- **Pros:** [list]
|
|
28
|
+
- **Cons:** [list]
|
|
29
|
+
- **Complexity:** [low/medium/high]
|
|
30
|
+
- **Risks:** [list]
|
|
31
|
+
|
|
32
|
+
Keep each approach under 300 words.
|
|
33
|
+
|
|
34
|
+
### Phase 2: Validate Requirements
|
|
35
|
+
|
|
36
|
+
- **Depends on:** Phase 1
|
|
37
|
+
- **Agent:** @review
|
|
38
|
+
- **Concurrency:** Dynamic (1 agent per approach, min 1, max 5)
|
|
39
|
+
- **Prompt:**
|
|
40
|
+
|
|
41
|
+
Review these approaches: {phase_1_output}. Validate the requirements and constraints for each approach. Check for:
|
|
42
|
+
1. Technical accuracy
|
|
43
|
+
2. Feasibility given project constraints
|
|
44
|
+
3. Alignment with existing patterns
|
|
45
|
+
4. Missing considerations
|
|
46
|
+
|
|
47
|
+
Return validated requirements in this format:
|
|
48
|
+
|
|
49
|
+
## Validated Requirements
|
|
50
|
+
- **Approach 1:** [validated requirements]
|
|
51
|
+
- **Approach 2:** [validated requirements]
|
|
52
|
+
- **Approach 3:** [validated requirements]
|
|
53
|
+
|
|
54
|
+
## Recommendations
|
|
55
|
+
- **Recommended approach:** [which approach and why]
|
|
56
|
+
- **Critical constraints:** [list]
|
|
57
|
+
|
|
58
|
+
Keep each section under 200 words.
|
|
59
|
+
|
|
60
|
+
### Phase 3: Create Implementation Plan
|
|
61
|
+
|
|
62
|
+
- **Depends on:** Phase 2
|
|
63
|
+
- **Agent:** @plan
|
|
64
|
+
- **Concurrency:** 1
|
|
65
|
+
- **Prompt:**
|
|
66
|
+
|
|
67
|
+
Based on the validated requirements: {phase_2_output}, create a detailed implementation plan for the recommended approach. Break down into independent tasks that can be implemented in parallel.
|
|
68
|
+
|
|
69
|
+
Return the plan in this format:
|
|
70
|
+
|
|
71
|
+
## Implementation Plan
|
|
72
|
+
|
|
73
|
+
### Overview
|
|
74
|
+
[Brief description of the approach]
|
|
75
|
+
|
|
76
|
+
### Tasks
|
|
77
|
+
- **Task 1:** [description]
|
|
78
|
+
- Files: [list]
|
|
79
|
+
- Dependencies: [none or task names]
|
|
80
|
+
- **Task 2:** [description]
|
|
81
|
+
- Files: [list]
|
|
82
|
+
- Dependencies: [none or task names]
|
|
83
|
+
|
|
84
|
+
Keep each task description under 100 words.
|
|
85
|
+
|
|
86
|
+
### Phase 4: Parallel Implementation
|
|
87
|
+
|
|
88
|
+
- **Depends on:** Phase 3
|
|
89
|
+
- **Workflow:** batch-implement
|
|
90
|
+
- **Args:** plan from Phase 3
|
|
91
|
+
|
|
92
|
+
Execute the batch-implement workflow with the implementation plan from Phase 3. This will:
|
|
93
|
+
1. Review the plan for task independence
|
|
94
|
+
2. Implement tasks in parallel
|
|
95
|
+
3. Verify each implementation
|
|
96
|
+
4. Merge the results
|
|
97
|
+
|
|
98
|
+
### Phase 5: Verify Different Aspects
|
|
99
|
+
|
|
100
|
+
- **Depends on:** Phase 4
|
|
101
|
+
- **Agent:** @review
|
|
102
|
+
- **Concurrency:** 3 (one per aspect: correctness, code-quality, performance-security)
|
|
103
|
+
- **Prompt:**
|
|
104
|
+
|
|
105
|
+
Verify the implementation from different aspects: {phase_4_output}. Each reviewer should focus on a different aspect:
|
|
106
|
+
|
|
107
|
+
**Reviewer 1: Correctness**
|
|
108
|
+
- Verify all requirements are met
|
|
109
|
+
- Check for logic errors
|
|
110
|
+
- Validate edge cases
|
|
111
|
+
|
|
112
|
+
**Reviewer 2: Code Quality**
|
|
113
|
+
- Check for code style and patterns
|
|
114
|
+
- Identify code smells
|
|
115
|
+
- Verify test coverage
|
|
116
|
+
|
|
117
|
+
**Reviewer 3: Performance & Security**
|
|
118
|
+
- Check for performance bottlenecks
|
|
119
|
+
- Identify security vulnerabilities
|
|
120
|
+
- Validate error handling
|
|
121
|
+
|
|
122
|
+
Return findings in this format:
|
|
123
|
+
|
|
124
|
+
## Aspect: [correctness/code-quality/performance-security]
|
|
125
|
+
- **Status:** [pass/fail]
|
|
126
|
+
- **Issues:** [list with file:line refs]
|
|
127
|
+
- **Recommendations:** [list]
|
|
128
|
+
|
|
129
|
+
Keep each finding under 150 words.
|
package/package.json
CHANGED
|
@@ -1,46 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Reduce ambiguity before planning or implementation
|
|
3
|
-
argument-hint: "<request> [--quick|--deep]"
|
|
4
|
-
agent: build
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Clarify: $ARGUMENTS
|
|
8
|
-
|
|
9
|
-
Reduce ambiguity before planning or implementation. Use when the request is real but still fuzzy.
|
|
10
|
-
|
|
11
|
-
## Load Skills
|
|
12
|
-
|
|
13
|
-
```typescript
|
|
14
|
-
skill({ name: "brainstorming" });
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
## Parse Arguments
|
|
18
|
-
|
|
19
|
-
| Argument | Default | Description |
|
|
20
|
-
|---|---|---|
|
|
21
|
-
| `<request>` | required | Freeform request text |
|
|
22
|
-
| `--quick` | false | Minimize to 1-3 high-leverage questions |
|
|
23
|
-
| `--deep` | false | Cover non-goals, risks, interfaces, success criteria |
|
|
24
|
-
|
|
25
|
-
**Mode rules:** Default → make next command obvious. `--quick` → 1-3 questions. `--deep` → exhaustive. `--deep` wins if both appear.
|
|
26
|
-
|
|
27
|
-
## When to Use / Not Use
|
|
28
|
-
|
|
29
|
-
**Use:** Request is fuzzy, scope unclear, multiple interpretations of "done," `/plan` would be premature because main decision is unresolved.
|
|
30
|
-
**Skip:** Request is specific enough to plan directly, task is mechanical, ambiguity is only about codebase facts you can inspect.
|
|
31
|
-
|
|
32
|
-
## Core Rules
|
|
33
|
-
|
|
34
|
-
- **Inspect first, ask second** — never ask for codebase facts you can discover directly
|
|
35
|
-
- **One question at a time** — each must reduce a real ambiguity
|
|
36
|
-
- **Prefer structured choices** (multiple choice, yes/no)
|
|
37
|
-
- **Surface non-goals explicitly** — what should *not* change is as important as what should
|
|
38
|
-
- **Stop once the next command is obvious**
|
|
39
|
-
|
|
40
|
-
## Process
|
|
41
|
-
|
|
42
|
-
1. Read request, identify unknowns blocking execution
|
|
43
|
-
2. Search memory, check existing patterns
|
|
44
|
-
3. Ask questions one at a time, resolve before next
|
|
45
|
-
4. Surface non-goals and constraints
|
|
46
|
-
5. Recommend next command: `/plan`, `/create`, `/ship`, or `/design`
|
|
@@ -1,53 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
description: Create a well-structured conventional commit from staged or unstaged changes
|
|
3
|
-
argument-hint: "[--all] [--amend] [message override]"
|
|
4
|
-
agent: build
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Commit: $ARGUMENTS
|
|
8
|
-
|
|
9
|
-
Create a well-structured conventional commit from current changes.
|
|
10
|
-
|
|
11
|
-
## Load Skills
|
|
12
|
-
|
|
13
|
-
```typescript
|
|
14
|
-
skill({ name: "verification-before-completion" });
|
|
15
|
-
```
|
|
16
|
-
|
|
17
|
-
## Process
|
|
18
|
-
|
|
19
|
-
### Phase 1: Inspect Changes
|
|
20
|
-
|
|
21
|
-
```bash
|
|
22
|
-
git status --short
|
|
23
|
-
git diff --cached --stat # if staged
|
|
24
|
-
git diff --stat # if unstaged
|
|
25
|
-
```
|
|
26
|
-
|
|
27
|
-
### Phase 2: Review Diffs
|
|
28
|
-
|
|
29
|
-
Read each changed file. Look for:
|
|
30
|
-
- Debug code, console.log, TODOs that should be resolved
|
|
31
|
-
- Accidental changes outside scope
|
|
32
|
-
- Missing error handling or edge cases
|
|
33
|
-
|
|
34
|
-
### Phase 3: Construct Commit
|
|
35
|
-
|
|
36
|
-
Format: `type(scope): description`
|
|
37
|
-
|
|
38
|
-
Types: `feat` (feature), `fix` (bug), `test` (test-only), `refactor` (no behavior change), `chore` (config/tooling), `docs`, `style`, `perf`.
|
|
39
|
-
|
|
40
|
-
### Phase 4: Commit
|
|
41
|
-
|
|
42
|
-
```bash
|
|
43
|
-
git add <files> # stage specific files — never git add .
|
|
44
|
-
git commit -m "type(scope): description
|
|
45
|
-
|
|
46
|
-
- bullet points of key changes"
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
### Phase 5: Verify
|
|
50
|
-
|
|
51
|
-
```bash
|
|
52
|
-
git log --oneline -3
|
|
53
|
-
```
|