@nano-step/skill-manager 5.6.1 → 5.6.2

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.
Files changed (30) hide show
  1. package/package.json +1 -1
  2. package/private-catalog.json +5 -0
  3. package/skills/deep-design/SKILL.md +402 -0
  4. package/skills/deep-design/evals/evals.json +23 -0
  5. package/skills/deep-design/skill.json +7 -0
  6. package/skills/feature-analysis/SKILL.md +290 -0
  7. package/skills/feature-analysis/skill.json +15 -0
  8. package/skills/nano-brain/skill.json +7 -0
  9. package/skills/pr-code-reviewer/CHANGELOG.md +287 -0
  10. package/skills/pr-code-reviewer/RESEARCH.md +60 -0
  11. package/skills/pr-code-reviewer/SKILL.md +530 -0
  12. package/skills/pr-code-reviewer/assets/config.json +47 -0
  13. package/skills/pr-code-reviewer/checklists/backend-express.md +357 -0
  14. package/skills/pr-code-reviewer/checklists/ci-cd.md +428 -0
  15. package/skills/pr-code-reviewer/checklists/consumer-search-matrix.md +339 -0
  16. package/skills/pr-code-reviewer/checklists/database.md +382 -0
  17. package/skills/pr-code-reviewer/checklists/frontend-vue-nuxt.md +426 -0
  18. package/skills/pr-code-reviewer/checklists/review-checklist.md +116 -0
  19. package/skills/pr-code-reviewer/references/framework-rules/express.md +39 -0
  20. package/skills/pr-code-reviewer/references/framework-rules/nestjs.md +41 -0
  21. package/skills/pr-code-reviewer/references/framework-rules/typeorm.md +52 -0
  22. package/skills/pr-code-reviewer/references/framework-rules/typescript.md +50 -0
  23. package/skills/pr-code-reviewer/references/framework-rules/vue-nuxt.md +53 -0
  24. package/skills/pr-code-reviewer/references/nano-brain-integration.md +61 -0
  25. package/skills/pr-code-reviewer/references/performance-patterns.md +26 -0
  26. package/skills/pr-code-reviewer/references/quality-patterns.md +25 -0
  27. package/skills/pr-code-reviewer/references/report-template.md +167 -0
  28. package/skills/pr-code-reviewer/references/security-patterns.md +31 -0
  29. package/skills/pr-code-reviewer/references/subagent-prompts.md +323 -0
  30. package/skills/pr-code-reviewer/skill.json +15 -0
@@ -0,0 +1,323 @@
1
+ # Subagent Prompt Templates
2
+
3
+ Launch ALL 4 subagents simultaneously with `run_in_background: true`.
4
+
5
+ **IMPORTANT**: Include the PR Summary in each subagent's context so they understand the overall change.
6
+
7
+ **IMPORTANT**: If project memory results were gathered in Phase 1, include them as a `## NANO-BRAIN MEMORY` section in each subagent's prompt.
8
+
9
+ **IMPORTANT**: Include `$REVIEW_DIR` (the temp clone path from Phase 0) in each subagent's prompt. All file reads, grep searches, and LSP operations MUST target this path — NOT the original workspace repo. This ensures subagents see the actual PR branch code.
10
+
11
+ **IMPORTANT**: If Phase 2 produced cross-repo tracing results or a Premise Check (for DELETION changes), include them as `## CROSS-REPO TRACING` and `## PREMISE CHECK` sections in each subagent's prompt.
12
+
13
+ ```
14
+ ## REVIEW DIRECTORY
15
+ All file reads and searches MUST use this path (temp clone of PR branch):
16
+ ${REVIEW_DIR}
17
+ Do NOT read from the original workspace repo — it may be on a different branch.
18
+ ```
19
+
20
+ ## Filtering Rules (Include in ALL subagent prompts)
21
+
22
+ Every subagent MUST apply these rules before returning findings:
23
+
24
+ ```
25
+ ## FILTERING RULES (MANDATORY)
26
+ - ONLY report findings that would make a senior engineer stop and think
27
+ - SKIP anything a linter/formatter would catch (let tools handle those)
28
+ - SKIP style nits that don't affect readability or correctness
29
+ - SKIP obvious comments like "add JSDoc to this function" unless it's a public API
30
+ - For each finding, ask: "Would I block a PR for this?" If no → downgrade or drop
31
+ - Severity guide:
32
+ - critical: Blocks merge. Security hole, data loss, crash, logic bug
33
+ - warning: Should fix before merge. Edge case, missing validation, race condition
34
+ - improvement: Code works but can be better. Cleaner, faster, more idiomatic
35
+ - suggestion: Nice-to-have. Won't block, won't even flag strongly
36
+
37
+ ## EVIDENCE REQUIREMENT (MANDATORY for critical/warning)
38
+ - Every finding with severity `critical` or `warning` MUST include an `evidence` field
39
+ - Evidence MUST cite specific file paths and line numbers you actually read
40
+ - Findings with severity `critical` or `warning` that lack evidence will be AUTO-DOWNGRADED to `suggestion` by the orchestrator
41
+ - `improvement` and `suggestion` findings do NOT require evidence (field can be empty)
42
+
43
+ ## VERIFICATION PROTOCOL (MANDATORY for critical/warning)
44
+
45
+ Before reporting any finding with severity `critical` or `warning`, complete these 4 steps:
46
+
47
+ ### Step 1: IDENTIFY
48
+ What looks wrong? State the specific concern.
49
+
50
+ ### Step 2: TRACE
51
+ Read the surrounding context beyond the changed file. For each concern type:
52
+ - **Error handling**: Trace the throw/error path UP to the HTTP boundary (controller/route handler). Check for try-catch at EVERY layer between the throw and the controller.
53
+ - **Null safety**: Trace the data DOWN to its source (SQL query, API contract, constructor). Check if the source guarantees non-null (e.g., DB primary key, NOT NULL column, JOIN constraint).
54
+ - **Framework patterns**: Check if the specific usage context makes the pattern safe (e.g., Pinia singleton backing a composable, client-only component, intentionally non-reactive value).
55
+ - **Logic errors**: Construct a CONCRETE triggering scenario with specific input values that would cause the bug.
56
+
57
+ ### Step 3: VERIFY
58
+ Can you PROVE this is a real problem? You need ONE of:
59
+ - A concrete execution path that reaches the bug (with specific inputs)
60
+ - A missing handler at the HTTP boundary (cite the controller file:line where the catch SHOULD be but ISN'T)
61
+ - A data source that can actually produce the problematic value (cite the query/API that returns nullable data)
62
+
63
+ If you cannot construct concrete proof after tracing → DROP the finding silently.
64
+
65
+ ### Step 4: DECIDE
66
+ - **Verified** → Report with `evidence` field containing your proof (file:line references)
67
+ - **Unverifiable** (too many layers, external system) → Report as `suggestion` with `evidence: "unverified: {reason}"`
68
+ - **Disproven** (e.g., try-catch exists at boundary, data source is non-null) → DROP silently. Do NOT report.
69
+
70
+ ## EVIDENCE EXAMPLES
71
+
72
+ GOOD evidence (concrete, traceable):
73
+ - "Throw at `openSearchService.js:870` propagates through `insightService.js:939` (no catch) → `metaService.js:158` (no catch) → controller `meta.js:28` has NO try-catch. Error reaches HTTP boundary unhandled."
74
+ - "`.id` comes from `fetchItemMetaImages` SQL query at `metaRepo.js:332` using LEFT JOIN — `imiu.item_id` can be NULL when no image row exists."
75
+ - "AbortController is non-reactive by design — backed by Pinia singleton store at `useTradeSimilarItemsStore.js:3`, composable creates one closure per component lifecycle."
76
+
77
+ BAD evidence (will be auto-downgraded by orchestrator):
78
+ - "This could throw an error" (no trace to boundary)
79
+ - "This might be null" (no trace to data source)
80
+ - "This violates best practices" (no concrete impact)
81
+ - "Missing error handling" (didn't check if caller handles it)
82
+ ```
83
+
84
+ ## Subagent 1: EXPLORE — Code Quality & Patterns
85
+
86
+ ```javascript
87
+ delegate_task({
88
+ subagent_type: "explore",
89
+ load_skills: [],
90
+ run_in_background: true,
91
+ prompt: `
92
+ ## REVIEW DIRECTORY
93
+ All file reads and searches MUST use this path (temp clone of PR branch):
94
+ ${REVIEW_DIR}
95
+ Do NOT read from the original workspace repo — it may be on a different branch.
96
+
97
+ ## PR SUMMARY
98
+ ${prSummary}
99
+
100
+ ## CHANGED FILES
101
+ ${changedFilesWithDiff}
102
+
103
+ ## TRACED DEPENDENCIES
104
+ ${tracedDependencies}
105
+
106
+ ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
107
+ ${projectMemory || "No nano-brain memory available for this workspace"}
108
+
109
+ ## LINEAR TICKET CONTEXT (from linked Linear ticket)
110
+ ${linearTicketContext || "No Linear ticket linked to this PR"}
111
+
112
+ ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
113
+ ${crossRepoTracing || "No cross-repo tracing performed"}
114
+
115
+ ## PREMISE CHECK (for DELETION changes — why the code existed)
116
+ ${premiseCheck || "Not a DELETION change — no premise check needed"}
117
+
118
+ ${FILTERING_RULES}
119
+
120
+ ## TASK
121
+ Analyze code quality, patterns, and improvement opportunities
122
+
123
+ ## CHECK
124
+ 1. Error handling patterns — missing catches, swallowed errors, generic catches
125
+ 2. Type safety — any casts, missing null checks, unsafe assertions
126
+ 3. Code duplication — repeated logic that should be extracted
127
+ 4. Complexity — deep nesting, long functions, god objects
128
+ 5. **Code improvements** — cleaner alternatives, better abstractions, simpler logic
129
+ 6. **Dead code from deletions** — if code was removed, check if related code (exports, i18n keys, config) is now orphaned
130
+
131
+ DO NOT report: naming nits, formatting, import order, missing comments on obvious code
132
+
133
+ ## RETURN FORMAT
134
+ JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
135
+ severity: "critical" | "warning" | "improvement" | "suggestion"
136
+ evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
137
+ confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
138
+ trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
139
+ `
140
+ });
141
+ ```
142
+
143
+ ## Subagent 2: ORACLE — Security & Logic
144
+
145
+ ```javascript
146
+ delegate_task({
147
+ subagent_type: "oracle",
148
+ load_skills: [],
149
+ run_in_background: true,
150
+ prompt: `
151
+ ## REVIEW DIRECTORY
152
+ All file reads and searches MUST use this path (temp clone of PR branch):
153
+ ${REVIEW_DIR}
154
+ Do NOT read from the original workspace repo — it may be on a different branch.
155
+
156
+ ## PR SUMMARY
157
+ ${prSummary}
158
+
159
+ ## CHANGED FILES
160
+ ${changedFilesWithDiff}
161
+
162
+ ## TRACED DEPENDENCIES
163
+ ${tracedDependencies}
164
+
165
+ ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
166
+ ${projectMemory || "No nano-brain memory available for this workspace"}
167
+
168
+ ## LINEAR TICKET CONTEXT (from linked Linear ticket)
169
+ ${linearTicketContext || "No Linear ticket linked to this PR"}
170
+
171
+ ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
172
+ ${crossRepoTracing || "No cross-repo tracing performed"}
173
+
174
+ ## PREMISE CHECK (for DELETION changes — why the code existed)
175
+ ${premiseCheck || "Not a DELETION change — no premise check needed"}
176
+
177
+ ${FILTERING_RULES}
178
+
179
+ ## TASK
180
+ Deep security, logic analysis, and logic improvement opportunities
181
+
182
+ ## CHECK
183
+ 1. OWASP Top 10 vulnerabilities
184
+ 2. Logic correctness (especially for LOGIC-type changes)
185
+ 3. Edge cases and boundary conditions
186
+ 4. Race conditions and state management
187
+ 5. Input validation gaps
188
+ 6. Authentication/authorization holes
189
+ 7. **Logic improvements** — simpler conditionals, better error paths, clearer state machines
190
+ 8. **Ticket alignment** — do the code changes match the acceptance criteria from the Linear ticket?
191
+ 9. **Cross-repo data consistency** — if the code consumes API data, do frontend assumptions match backend behavior? Are there hardcoded values that should come from backend config?
192
+ 10. **Deletion premise validation** — if code was deleted: Was the code there for a valid reason? Is removal the right fix, or should the logic be corrected instead? Does the deletion hide a problem rather than solve it?
193
+
194
+ CRITICAL: For any if-else or conditional changes, trace ALL code paths affected.
195
+ CRITICAL: For DELETION changes, you MUST evaluate whether removal is correct or whether the code should be FIXED instead. Challenge the PR's premise — don't assume deletion is the right approach.
196
+ CRITICAL: For any data consumed from an API, verify the frontend's interpretation matches the backend's actual behavior. Flag hardcoded values that correspond to backend config.
197
+
198
+ DO NOT report: theoretical vulnerabilities with no realistic attack vector in this context
199
+
200
+ ## RETURN FORMAT
201
+ JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
202
+ severity: "critical" | "warning" | "improvement" | "suggestion"
203
+ evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
204
+ confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
205
+ trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
206
+ `
207
+ });
208
+ ```
209
+
210
+ ## Subagent 3: LIBRARIAN — Documentation & Best Practices
211
+
212
+ ```javascript
213
+ delegate_task({
214
+ subagent_type: "librarian",
215
+ load_skills: [],
216
+ run_in_background: true,
217
+ prompt: `
218
+ ## REVIEW DIRECTORY
219
+ All file reads and searches MUST use this path (temp clone of PR branch):
220
+ ${REVIEW_DIR}
221
+ Do NOT read from the original workspace repo — it may be on a different branch.
222
+
223
+ ## PR SUMMARY
224
+ ${prSummary}
225
+
226
+ ## CHANGED FILES
227
+ ${changedFilesWithDiff}
228
+
229
+ ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
230
+ ${projectMemory || "No nano-brain memory available for this workspace"}
231
+
232
+ ## LINEAR TICKET CONTEXT (from linked Linear ticket)
233
+ ${linearTicketContext || "No Linear ticket linked to this PR"}
234
+
235
+ ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
236
+ ${crossRepoTracing || "No cross-repo tracing performed"}
237
+
238
+ ## PREMISE CHECK (for DELETION changes — why the code existed)
239
+ ${premiseCheck || "Not a DELETION change — no premise check needed"}
240
+
241
+ ${FILTERING_RULES}
242
+
243
+ ## TASK
244
+ Best practices review and idiomatic improvement opportunities
245
+
246
+ ## CHECK
247
+ 1. Framework anti-patterns (Next.js, React, Express, etc.)
248
+ 2. Library misuse — using APIs incorrectly or suboptimally
249
+ 3. **Idiomatic improvements** — more idiomatic usage of language/framework features
250
+ 4. Missing docs ONLY on public APIs or complex algorithms
251
+ 5. **Orphaned resources** — if code was deleted, check for orphaned i18n keys, unused imports, dead CSS classes, abandoned config entries
252
+
253
+ DO NOT report: missing JSDoc on internal functions, obvious code, or private helpers
254
+
255
+ ## RETURN FORMAT
256
+ JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
257
+ severity: "critical" | "warning" | "improvement" | "suggestion"
258
+ evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
259
+ confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
260
+ trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
261
+ `
262
+ });
263
+ ```
264
+
265
+ ## Subagent 4: GENERAL — Tests & Integration
266
+
267
+ ```javascript
268
+ delegate_task({
269
+ subagent_type: "general",
270
+ load_skills: [],
271
+ run_in_background: true,
272
+ prompt: `
273
+ ## REVIEW DIRECTORY
274
+ All file reads and searches MUST use this path (temp clone of PR branch):
275
+ ${REVIEW_DIR}
276
+ Do NOT read from the original workspace repo — it may be on a different branch.
277
+
278
+ ## PR SUMMARY
279
+ ${prSummary}
280
+
281
+ ## CHANGED FILES
282
+ ${changedFilesWithDiff}
283
+
284
+ ## TRACED TEST FILES
285
+ ${tracedTestFiles}
286
+
287
+ ## NANO-BRAIN MEMORY (past sessions, reviews, decisions)
288
+ ${projectMemory || "No nano-brain memory available for this workspace"}
289
+
290
+ ## LINEAR TICKET CONTEXT (from linked Linear ticket)
291
+ ${linearTicketContext || "No Linear ticket linked to this PR"}
292
+
293
+ ## CROSS-REPO TRACING (from Phase 2 — backend data flow analysis)
294
+ ${crossRepoTracing || "No cross-repo tracing performed"}
295
+
296
+ ## PREMISE CHECK (for DELETION changes — why the code existed)
297
+ ${premiseCheck || "Not a DELETION change — no premise check needed"}
298
+
299
+ ${FILTERING_RULES}
300
+
301
+ ## TASK
302
+ Test coverage, integration analysis, and performance improvement opportunities
303
+
304
+ ## CHECK
305
+ 1. Untested critical code paths (logic branches, error handlers)
306
+ 2. Edge cases not covered by tests
307
+ 3. Broken contracts — do changes break existing integrations?
308
+ 4. **Performance improvements** — unnecessary allocations, N+1 queries, missing caching
309
+ 5. Historical regressions — have similar changes caused issues before?
310
+ 6. **Acceptance criteria coverage** — are all acceptance criteria from the ticket addressed by code + tests?
311
+ 7. **Cross-repo contract integrity** — if frontend code was changed/deleted, does it break assumptions the backend relies on? Does the backend expect the frontend to display certain data?
312
+
313
+ DO NOT report: missing tests for trivial getters/setters, style-only changes, or config files
314
+
315
+ ## RETURN FORMAT
316
+ JSON: {findings: [{file, line, severity, category, message, suggestion, code_suggestion?, evidence, confidence, trace_path?}]}
317
+ severity: "critical" | "warning" | "improvement" | "suggestion"
318
+ evidence: REQUIRED for critical/warning — concrete proof with file:line references. Empty string for improvement/suggestion.
319
+ confidence: "high" (traced 2+ layers, concrete proof) | "medium" (traced 1 layer) | "low" (pattern-based, no trace)
320
+ trace_path: Optional array of "file:line" strings showing the verification trace (e.g., ["service.js:870", "controller.js:28"])
321
+ `
322
+ });
323
+ ```
@@ -0,0 +1,15 @@
1
+ {
2
+ "name": "pr-code-reviewer",
3
+ "version": "3.1.0",
4
+ "description": "Comprehensive code review with 4 parallel subagents, smart tracing, iterative refinement, workspace-aware configuration, and GitHub Copilot-style PR summaries.",
5
+ "compatibility": "OpenCode with nano-brain",
6
+ "agent": null,
7
+ "commands": [],
8
+ "tags": [
9
+ "code-review",
10
+ "pr",
11
+ "security",
12
+ "quality",
13
+ "subagents"
14
+ ]
15
+ }