@cratis/pi 7.78.0 → 7.79.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/package/corpus/agents/code-reviewer.md +3 -18
- package/package/corpus/agents/coordinator.md +1 -2
- package/package/corpus/agents/orchestrator.md +1 -2
- package/package/corpus/agents/performance-reviewer.md +3 -34
- package/package/corpus/agents/planner.md +2 -2
- package/package/corpus/agents/repository-investigation-reviewer.md +8 -1
- package/package/corpus/agents/security-reviewer.md +3 -37
- package/package/corpus/harnesses/copilot/instructions/review-reports.instructions.md +68 -0
- package/package/corpus/harnesses/pi/agents/code-reviewer.md +3 -18
- package/package/corpus/harnesses/pi/agents/coordinator.md +1 -2
- package/package/corpus/harnesses/pi/agents/orchestrator.md +1 -2
- package/package/corpus/harnesses/pi/agents/performance-reviewer.md +3 -34
- package/package/corpus/harnesses/pi/agents/planner.md +2 -2
- package/package/corpus/harnesses/pi/agents/repository-investigation-reviewer.md +8 -1
- package/package/corpus/harnesses/pi/agents/security-reviewer.md +3 -37
- package/package/corpus/prompts/code-review.prompt.md +1 -0
- package/package/corpus/prompts/review-pr.prompt.md +8 -12
- package/package/corpus/prompts/review-skill.prompt.md +3 -3
- package/package/corpus/rules/general.md +1 -0
- package/package/corpus/rules/review-reports.md +67 -0
- package/package/corpus/skills/cratis-code-review/SKILL.md +6 -21
- package/package/corpus/skills/cratis-code-review/verification.json +10 -0
- package/package/corpus/skills/cratis-performance-review/SKILL.md +11 -13
- package/package/corpus/skills/cratis-performance-review/verification.json +12 -0
- package/package/corpus/skills/cratis-security-review/SKILL.md +9 -12
- package/package/corpus/skills/cratis-security-review/verification.json +11 -0
- package/package.json +1 -1
|
@@ -161,21 +161,6 @@ When checking unused code, references, or naming, use semantic navigation if the
|
|
|
161
161
|
|
|
162
162
|
## Output format
|
|
163
163
|
|
|
164
|
-
|
|
165
|
-
|
|
166
|
-
|
|
167
|
-
Then list issues grouped by file:
|
|
168
|
-
|
|
169
|
-
```
|
|
170
|
-
### <file path>
|
|
171
|
-
|
|
172
|
-
**[BLOCKING]** … or **[SUGGESTION]** …
|
|
173
|
-
> Line N: `problematic code`
|
|
174
|
-
> Because: explanation
|
|
175
|
-
> Fix:
|
|
176
|
-
> ```
|
|
177
|
-
> corrected code
|
|
178
|
-
> ```
|
|
179
|
-
```
|
|
180
|
-
|
|
181
|
-
End with a checklist of passed / failed items so the developer knows what was verified.
|
|
164
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
165
|
+
Apply the domain-specific classification in the Report section of
|
|
166
|
+
`.cratis/ai/skills/cratis-code-review/SKILL.md`.
|
|
@@ -143,8 +143,7 @@ For implementation, the applicable changed-lane gates must pass. Mark unrelated
|
|
|
143
143
|
- [ ] `npx tsc -b` — zero TypeScript errors (if frontend present)
|
|
144
144
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
145
145
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
146
|
-
- [ ]
|
|
147
|
-
- [ ] `security-reviewer` finds no vulnerabilities
|
|
146
|
+
- [ ] Code and security reviews approve the scoped change; combine their reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
148
147
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
149
148
|
|
|
150
149
|
---
|
|
@@ -167,8 +167,7 @@ For implementation, the applicable changed-lane gates must pass. Mark unrelated
|
|
|
167
167
|
- [ ] `npx tsc -b` — zero TypeScript errors (if frontend present)
|
|
168
168
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
169
169
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
170
|
-
- [ ]
|
|
171
|
-
- [ ] `security-reviewer` finds no vulnerabilities
|
|
170
|
+
- [ ] Code and security reviews approve the scoped change; combine their reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
172
171
|
- [ ] All documentation is complete and accurate (if required)
|
|
173
172
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
174
173
|
|
|
@@ -71,39 +71,8 @@ Your responsibility is to identify performance problems in changed code before t
|
|
|
71
71
|
|
|
72
72
|
---
|
|
73
73
|
|
|
74
|
-
## Risk classification
|
|
75
|
-
|
|
76
|
-
| Label | Meaning |
|
|
77
|
-
| ------- | --------- |
|
|
78
|
-
| 🔴 High | Will cause measurable degradation at moderate load — must fix before merge |
|
|
79
|
-
| 🟡 Medium | Could degrade under load or at scale — should fix soon |
|
|
80
|
-
| 🟢 Low | Minor inefficiency or style issue — fix when convenient |
|
|
81
|
-
|
|
82
|
-
---
|
|
83
|
-
|
|
84
74
|
## Output format
|
|
85
75
|
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
Group findings by category:
|
|
90
|
-
|
|
91
|
-
```
|
|
92
|
-
### MongoDB / Read Models
|
|
93
|
-
|
|
94
|
-
🟡 **Medium** — `<AppSourceRoot>/Projects/Listing/AllProjects.cs`
|
|
95
|
-
> The query does not specify a sort order or index hint, which will result in a
|
|
96
|
-
> collection scan once the `projects` collection grows.
|
|
97
|
-
> Fix: Add `.SortBy(m => m.Name)` and ensure an index on `Name` exists in the
|
|
98
|
-
> MongoDB collection initialization.
|
|
99
|
-
```
|
|
100
|
-
|
|
101
|
-
End with a summary table:
|
|
102
|
-
|
|
103
|
-
| Category | Status |
|
|
104
|
-
| ---------- | -------- |
|
|
105
|
-
| Chronicle / Event Sourcing | ✅ / ⚠️ / ❌ |
|
|
106
|
-
| MongoDB / Read Models | ✅ / ⚠️ / ❌ |
|
|
107
|
-
| ASP.NET Core / Commands & Queries | ✅ / ⚠️ / ❌ |
|
|
108
|
-
| React / TypeScript | ✅ / ⚠️ / ❌ |
|
|
109
|
-
| General .NET | ✅ / ⚠️ / ❌ |
|
|
76
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
77
|
+
Apply the domain-specific risk mapping in the Report section of
|
|
78
|
+
`.cratis/ai/skills/cratis-performance-review/SKILL.md`.
|
|
@@ -136,9 +136,9 @@ For an implemented application slice, require the applicable changed-lane gates
|
|
|
136
136
|
- [ ] All TypeScript specs pass (`yarn test`) if applicable
|
|
137
137
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
138
138
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
139
|
-
- [ ] Code review by `code-reviewer`
|
|
139
|
+
- [ ] Code review by `code-reviewer` approves the scoped change using `.cratis/ai/rules/review-reports.md`
|
|
140
140
|
- [ ] In an opted-in repository: `.play` changes were reviewed by `screenplay-reviewer`, and no modeled business rule or model-owned behavior exists only in code (infrastructure, client, adapter, code-attachment/handler code and authorized gap-fill governed by the `.play` slice and specs are allowed)
|
|
141
|
-
- [ ] Security review by `security-reviewer`
|
|
141
|
+
- [ ] Security review by `security-reviewer` approves the scoped change; combine the review reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
142
142
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
143
143
|
|
|
144
144
|
---
|
|
@@ -42,4 +42,11 @@ You independently review a completed Cratis repository investigation. Your resul
|
|
|
42
42
|
7. Pre-existing failures are distinguished from failures caused by the investigated behavior.
|
|
43
43
|
8. Failed, missing, or inconclusive evidence remains failed, blocked, or inconclusive.
|
|
44
44
|
|
|
45
|
-
|
|
45
|
+
## Output format
|
|
46
|
+
|
|
47
|
+
Use `.cratis/ai/rules/review-reports.md` for conclusions, including its
|
|
48
|
+
typed-envelope mapping. Return only the requested typed review
|
|
49
|
+
envelope; preserve its schema and blocked or inconclusive states. A material
|
|
50
|
+
unsupported conclusion or inconsistent repository mode prevents acceptance;
|
|
51
|
+
a non-blocking recommendation is advisory. Request a bounded correction when
|
|
52
|
+
a correctable evidence gap exists; otherwise report the exact blocker.
|
|
@@ -79,42 +79,8 @@ Your responsibility is to perform a structured **security review** of all change
|
|
|
79
79
|
|
|
80
80
|
---
|
|
81
81
|
|
|
82
|
-
## Risk classification
|
|
83
|
-
|
|
84
|
-
Assign each finding one of:
|
|
85
|
-
|
|
86
|
-
| Label | Meaning |
|
|
87
|
-
|-------|---------|
|
|
88
|
-
| 🔴 Critical | Must be fixed before merge — exploitable without significant effort |
|
|
89
|
-
| 🟡 Medium | Should be fixed soon — exploitable under specific conditions |
|
|
90
|
-
| 🟢 Low | Improvement or defense-in-depth — fix when convenient |
|
|
91
|
-
|
|
92
|
-
---
|
|
93
|
-
|
|
94
82
|
## Output format
|
|
95
83
|
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
Then list findings grouped by category:
|
|
100
|
-
|
|
101
|
-
```
|
|
102
|
-
### Input Validation & Injection
|
|
103
|
-
|
|
104
|
-
🔴 **Critical** — `Projects/Registration/RegisterProject.cs`
|
|
105
|
-
> Line 14: `var path = Path.Combine(root, command.FileName);`
|
|
106
|
-
> A path traversal attack is possible if `FileName` contains `../` sequences.
|
|
107
|
-
> Fix: Validate that the resolved path stays within the expected root directory.
|
|
108
|
-
```
|
|
109
|
-
|
|
110
|
-
End with a summary table:
|
|
111
|
-
|
|
112
|
-
| Category | Status |
|
|
113
|
-
|----------|--------|
|
|
114
|
-
| Input Validation | ✅ / ⚠️ / ❌ |
|
|
115
|
-
| Auth / Authz | ✅ / ⚠️ / ❌ |
|
|
116
|
-
| Data Exposure | ✅ / ⚠️ / ❌ |
|
|
117
|
-
| Secrets | ✅ / ⚠️ / ❌ |
|
|
118
|
-
| Dependencies | ✅ / ⚠️ / ❌ |
|
|
119
|
-
| Event Sourcing | ✅ / ⚠️ / ❌ |
|
|
120
|
-
| Frontend | ✅ / ⚠️ / ❌ |
|
|
84
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
85
|
+
Apply the domain-specific risk mapping in the Report section of
|
|
86
|
+
`.cratis/ai/skills/cratis-security-review/SKILL.md`.
|
|
@@ -0,0 +1,68 @@
|
|
|
1
|
+
---
|
|
2
|
+
applyTo: ".cratis/ai/skills/cratis-code-review/**,.cratis/ai/skills/cratis-security-review/**,.cratis/ai/skills/cratis-performance-review/**,.cratis/ai/agents/**,.cratis/ai/prompts/**"
|
|
3
|
+
paths:
|
|
4
|
+
- ".cratis/ai/skills/cratis-code-review/**"
|
|
5
|
+
- ".cratis/ai/skills/cratis-security-review/**"
|
|
6
|
+
- ".cratis/ai/skills/cratis-performance-review/**"
|
|
7
|
+
- ".cratis/ai/agents/**"
|
|
8
|
+
- ".cratis/ai/prompts/**"
|
|
9
|
+
---
|
|
10
|
+
<!-- cratis-ai: generated Copilot instructions. Do not edit; rules/ is the source. -->
|
|
11
|
+
|
|
12
|
+
<!-- Copyright (c) Cratis. All rights reserved. -->
|
|
13
|
+
<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
|
|
14
|
+
|
|
15
|
+
# Shared review reports
|
|
16
|
+
|
|
17
|
+
Use this report shape for code, security, performance, and repository-investigation
|
|
18
|
+
reviews. Domain-specific risk labels refine findings, not the report or verdict
|
|
19
|
+
vocabulary. Review the change within the declared scope, not unrelated existing debt.
|
|
20
|
+
|
|
21
|
+
## Report shape
|
|
22
|
+
|
|
23
|
+
Keep these sections in order, writing `None` when a section has no entries:
|
|
24
|
+
|
|
25
|
+
- **Blockers** — findings that must be fixed before merge. Each names a file and
|
|
26
|
+
line or evidence reference, the problem, its concrete consequence, and a proposed
|
|
27
|
+
correction. A blocker names a consequence, not a rule number: "returns HTTP 500
|
|
28
|
+
instead of a validation error" explains harm; "violates rule 4" does not.
|
|
29
|
+
- **Suggestions** — non-blocking improvements, with their benefit and any relevant
|
|
30
|
+
conditions. Do not turn a preference or a hypothetical risk into a merge gate.
|
|
31
|
+
- **Dismissed (with reason)** — candidate findings considered and rejected, each
|
|
32
|
+
with the evidence or reasoning for dismissal so another reviewer need not raise
|
|
33
|
+
it again. Do not invent candidates to populate this section.
|
|
34
|
+
- **Verdict** — one of the values below, scoped to the evidence actually examined.
|
|
35
|
+
|
|
36
|
+
An empty Blockers section is a valid, complete review. Never manufacture a finding
|
|
37
|
+
to make a review look useful. Reserve **[BLOCKING]** exclusively for
|
|
38
|
+
must-fix-before-merge findings; suggestions and dismissed findings never carry it.
|
|
39
|
+
|
|
40
|
+
Every review includes a **Not examined:** line naming the paths, surfaces, checks,
|
|
41
|
+
and axes not examined, including anything that could not be reached. Name what was
|
|
42
|
+
not measured: code-shape inspection is not a benchmark, a build is not behavioral
|
|
43
|
+
proof, and an unexamined surface is not verified. State `None` only when the entire
|
|
44
|
+
declared scope was examined; otherwise give concrete limits and remaining checks.
|
|
45
|
+
|
|
46
|
+
## Verdict vocabulary
|
|
47
|
+
|
|
48
|
+
| Verdict | Meaning |
|
|
49
|
+
| --- | --- |
|
|
50
|
+
| **Approved** | No blockers or suggestions within the examined scope; required review checks are complete. |
|
|
51
|
+
| **Approved with suggestions** | No blockers; non-blocking suggestions remain and required review checks are complete. |
|
|
52
|
+
| **Changes requested** | At least one blocker must be corrected before merge. |
|
|
53
|
+
| **Incomplete** | No confirmed blocker, but missing or inconclusive required evidence prevents approval. |
|
|
54
|
+
|
|
55
|
+
Skipped optional axes belong on the Not examined line and do not alone prevent a
|
|
56
|
+
scoped approval. Missing required evidence does. When blockers and evidence gaps
|
|
57
|
+
coexist, use Changes requested and record the gaps on the Not examined line; never
|
|
58
|
+
reinterpret a failed or blocked gate as passing.
|
|
59
|
+
|
|
60
|
+
When combining reviews, retain one report per reviewer with the shared sections
|
|
61
|
+
and scope line, then give one combined verdict. Any blocker means Changes requested;
|
|
62
|
+
otherwise any Incomplete review means Incomplete; otherwise any remaining suggestion
|
|
63
|
+
means Approved with suggestions; otherwise use Approved. Do not drop dismissals or
|
|
64
|
+
scope limits when combining reports.
|
|
65
|
+
|
|
66
|
+
When a workflow requires a typed review envelope, preserve its schema and express
|
|
67
|
+
these sections, verdict meanings, and scope limits through its existing fields.
|
|
68
|
+
Do not append a competing Markdown report or invent envelope fields.
|
|
@@ -158,21 +158,6 @@ When checking unused code, references, or naming, use semantic navigation if the
|
|
|
158
158
|
|
|
159
159
|
## Output format
|
|
160
160
|
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
Then list issues grouped by file:
|
|
165
|
-
|
|
166
|
-
```
|
|
167
|
-
### <file path>
|
|
168
|
-
|
|
169
|
-
**[BLOCKING]** … or **[SUGGESTION]** …
|
|
170
|
-
> Line N: `problematic code`
|
|
171
|
-
> Because: explanation
|
|
172
|
-
> Fix:
|
|
173
|
-
> ```
|
|
174
|
-
> corrected code
|
|
175
|
-
> ```
|
|
176
|
-
```
|
|
177
|
-
|
|
178
|
-
End with a checklist of passed / failed items so the developer knows what was verified.
|
|
161
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
162
|
+
Apply the domain-specific classification in the Report section of
|
|
163
|
+
`.cratis/ai/skills/cratis-code-review/SKILL.md`.
|
|
@@ -139,8 +139,7 @@ For implementation, the applicable changed-lane gates must pass. Mark unrelated
|
|
|
139
139
|
- [ ] `npx tsc -b` — zero TypeScript errors (if frontend present)
|
|
140
140
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
141
141
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
142
|
-
- [ ]
|
|
143
|
-
- [ ] `security-reviewer` finds no vulnerabilities
|
|
142
|
+
- [ ] Code and security reviews approve the scoped change; combine their reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
144
143
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
145
144
|
|
|
146
145
|
---
|
|
@@ -163,8 +163,7 @@ For implementation, the applicable changed-lane gates must pass. Mark unrelated
|
|
|
163
163
|
- [ ] `npx tsc -b` — zero TypeScript errors (if frontend present)
|
|
164
164
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
165
165
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
166
|
-
- [ ]
|
|
167
|
-
- [ ] `security-reviewer` finds no vulnerabilities
|
|
166
|
+
- [ ] Code and security reviews approve the scoped change; combine their reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
168
167
|
- [ ] All documentation is complete and accurate (if required)
|
|
169
168
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
170
169
|
|
|
@@ -68,39 +68,8 @@ Your responsibility is to identify performance problems in changed code before t
|
|
|
68
68
|
|
|
69
69
|
---
|
|
70
70
|
|
|
71
|
-
## Risk classification
|
|
72
|
-
|
|
73
|
-
| Label | Meaning |
|
|
74
|
-
| ------- | --------- |
|
|
75
|
-
| 🔴 High | Will cause measurable degradation at moderate load — must fix before merge |
|
|
76
|
-
| 🟡 Medium | Could degrade under load or at scale — should fix soon |
|
|
77
|
-
| 🟢 Low | Minor inefficiency or style issue — fix when convenient |
|
|
78
|
-
|
|
79
|
-
---
|
|
80
|
-
|
|
81
71
|
## Output format
|
|
82
72
|
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
Group findings by category:
|
|
87
|
-
|
|
88
|
-
```
|
|
89
|
-
### MongoDB / Read Models
|
|
90
|
-
|
|
91
|
-
🟡 **Medium** — `<AppSourceRoot>/Projects/Listing/AllProjects.cs`
|
|
92
|
-
> The query does not specify a sort order or index hint, which will result in a
|
|
93
|
-
> collection scan once the `projects` collection grows.
|
|
94
|
-
> Fix: Add `.SortBy(m => m.Name)` and ensure an index on `Name` exists in the
|
|
95
|
-
> MongoDB collection initialization.
|
|
96
|
-
```
|
|
97
|
-
|
|
98
|
-
End with a summary table:
|
|
99
|
-
|
|
100
|
-
| Category | Status |
|
|
101
|
-
| ---------- | -------- |
|
|
102
|
-
| Chronicle / Event Sourcing | ✅ / ⚠️ / ❌ |
|
|
103
|
-
| MongoDB / Read Models | ✅ / ⚠️ / ❌ |
|
|
104
|
-
| ASP.NET Core / Commands & Queries | ✅ / ⚠️ / ❌ |
|
|
105
|
-
| React / TypeScript | ✅ / ⚠️ / ❌ |
|
|
106
|
-
| General .NET | ✅ / ⚠️ / ❌ |
|
|
73
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
74
|
+
Apply the domain-specific risk mapping in the Report section of
|
|
75
|
+
`.cratis/ai/skills/cratis-performance-review/SKILL.md`.
|
|
@@ -132,9 +132,9 @@ For an implemented application slice, require the applicable changed-lane gates
|
|
|
132
132
|
- [ ] All TypeScript specs pass (`yarn test`) if applicable
|
|
133
133
|
- [ ] Public-facing changes (clients, SDKs, public APIs) include associated documentation updates
|
|
134
134
|
- [ ] `Documentation/verify-markdown.sh` passes when documentation is added or changed
|
|
135
|
-
- [ ] Code review by `code-reviewer`
|
|
135
|
+
- [ ] Code review by `code-reviewer` approves the scoped change using `.cratis/ai/rules/review-reports.md`
|
|
136
136
|
- [ ] In an opted-in repository: `.play` changes were reviewed by `screenplay-reviewer`, and no modeled business rule or model-owned behavior exists only in code (infrastructure, client, adapter, code-attachment/handler code and authorized gap-fill governed by the `.play` slice and specs are allowed)
|
|
137
|
-
- [ ] Security review by `security-reviewer`
|
|
137
|
+
- [ ] Security review by `security-reviewer` approves the scoped change; combine the review reports using `.cratis/ai/rules/review-reports.md`, preserving each reviewer's findings and scope limits
|
|
138
138
|
- [ ] PR description follows the pull request template and the release-note contract in `pull-requests.md`; test and review notes are in a PR comment
|
|
139
139
|
|
|
140
140
|
---
|
|
@@ -40,4 +40,11 @@ You independently review a completed Cratis repository investigation. Your resul
|
|
|
40
40
|
7. Pre-existing failures are distinguished from failures caused by the investigated behavior.
|
|
41
41
|
8. Failed, missing, or inconclusive evidence remains failed, blocked, or inconclusive.
|
|
42
42
|
|
|
43
|
-
|
|
43
|
+
## Output format
|
|
44
|
+
|
|
45
|
+
Use `.cratis/ai/rules/review-reports.md` for conclusions, including its
|
|
46
|
+
typed-envelope mapping. Return only the requested typed review
|
|
47
|
+
envelope; preserve its schema and blocked or inconclusive states. A material
|
|
48
|
+
unsupported conclusion or inconsistent repository mode prevents acceptance;
|
|
49
|
+
a non-blocking recommendation is advisory. Request a bounded correction when
|
|
50
|
+
a correctable evidence gap exists; otherwise report the exact blocker.
|
|
@@ -76,42 +76,8 @@ Your responsibility is to perform a structured **security review** of all change
|
|
|
76
76
|
|
|
77
77
|
---
|
|
78
78
|
|
|
79
|
-
## Risk classification
|
|
80
|
-
|
|
81
|
-
Assign each finding one of:
|
|
82
|
-
|
|
83
|
-
| Label | Meaning |
|
|
84
|
-
|-------|---------|
|
|
85
|
-
| 🔴 Critical | Must be fixed before merge — exploitable without significant effort |
|
|
86
|
-
| 🟡 Medium | Should be fixed soon — exploitable under specific conditions |
|
|
87
|
-
| 🟢 Low | Improvement or defense-in-depth — fix when convenient |
|
|
88
|
-
|
|
89
|
-
---
|
|
90
|
-
|
|
91
79
|
## Output format
|
|
92
80
|
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
Then list findings grouped by category:
|
|
97
|
-
|
|
98
|
-
```
|
|
99
|
-
### Input Validation & Injection
|
|
100
|
-
|
|
101
|
-
🔴 **Critical** — `Projects/Registration/RegisterProject.cs`
|
|
102
|
-
> Line 14: `var path = Path.Combine(root, command.FileName);`
|
|
103
|
-
> A path traversal attack is possible if `FileName` contains `../` sequences.
|
|
104
|
-
> Fix: Validate that the resolved path stays within the expected root directory.
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
End with a summary table:
|
|
108
|
-
|
|
109
|
-
| Category | Status |
|
|
110
|
-
|----------|--------|
|
|
111
|
-
| Input Validation | ✅ / ⚠️ / ❌ |
|
|
112
|
-
| Auth / Authz | ✅ / ⚠️ / ❌ |
|
|
113
|
-
| Data Exposure | ✅ / ⚠️ / ❌ |
|
|
114
|
-
| Secrets | ✅ / ⚠️ / ❌ |
|
|
115
|
-
| Dependencies | ✅ / ⚠️ / ❌ |
|
|
116
|
-
| Event Sourcing | ✅ / ⚠️ / ❌ |
|
|
117
|
-
| Frontend | ✅ / ⚠️ / ❌ |
|
|
81
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing conclusions.
|
|
82
|
+
Apply the domain-specific risk mapping in the Report section of
|
|
83
|
+
`.cratis/ai/skills/cratis-security-review/SKILL.md`.
|
|
@@ -7,3 +7,4 @@ description: Review a proposed change for correctness, maintainability, and secu
|
|
|
7
7
|
|
|
8
8
|
Review the proposed change for correctness, maintainability, and security.
|
|
9
9
|
Focus on actionable findings and minimize false positives.
|
|
10
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing the report.
|
|
@@ -21,15 +21,11 @@ Produce a structured review of a pull request against all Cratis standards.
|
|
|
21
21
|
|
|
22
22
|
## Output
|
|
23
23
|
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
**Blocking** (violates a MUST): 1. … **Suggestions**: 1. …
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
Be specific — file, line, and corrected code for every blocking issue.
|
|
24
|
+
Read and use `.cratis/ai/rules/review-reports.md` before writing the report.
|
|
25
|
+
Open with the PR number and a short summary. Keep one report per reviewer using
|
|
26
|
+
the shared Blockers / Suggestions / Dismissed (with reason) / Verdict sections
|
|
27
|
+
and Not examined line. Include specification-coverage and documentation checks
|
|
28
|
+
in the relevant reviewer's scope, with any missing evidence made explicit.
|
|
29
|
+
|
|
30
|
+
End with one **Combined verdict** using the shared aggregation rule, preserving
|
|
31
|
+
each reviewer's findings, dismissals, and scope limits.
|
|
@@ -9,6 +9,6 @@ Read [authoring-skills.md](../rules/authoring-skills.md), then apply its section
|
|
|
9
9
|
checklist to the requested skill folder under `.cratis/ai/skills/`. Check routing
|
|
10
10
|
against neighboring skills and workflow correctness against the owning product.
|
|
11
11
|
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
12
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing the report.
|
|
13
|
+
Name any evaluation runs or verification not performed on the scope line.
|
|
14
|
+
Include proposed edits with the findings; do not edit during the review.
|
|
@@ -161,6 +161,7 @@ A claim is only as good as the signal behind it — a build result, a test run,
|
|
|
161
161
|
| Reviewing or explaining a `.play` model | the **cratis-screenplay-model-review** skill |
|
|
162
162
|
| Turning an existing system into a model | the **cratis-screenplay-legacy-extraction** skill |
|
|
163
163
|
| Rendering or gap-filling an accepted model | the **cratis-screenplay-render-and-gap-fill** skill, then **cratis-stage-rendering-and-sandbox** for renderer facts |
|
|
164
|
+
| Code, security, performance and repository-investigation review reports | `review-reports.md` |
|
|
164
165
|
| Authoring or reviewing skills, rules, agents or prompts | `authoring-skills.md` |
|
|
165
166
|
| Step-by-step recipes | `.cratis/ai/skills/` |
|
|
166
167
|
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
applyTo: ".cratis/ai/skills/cratis-code-review/**,.cratis/ai/skills/cratis-security-review/**,.cratis/ai/skills/cratis-performance-review/**,.cratis/ai/agents/**,.cratis/ai/prompts/**"
|
|
3
|
+
paths:
|
|
4
|
+
- ".cratis/ai/skills/cratis-code-review/**"
|
|
5
|
+
- ".cratis/ai/skills/cratis-security-review/**"
|
|
6
|
+
- ".cratis/ai/skills/cratis-performance-review/**"
|
|
7
|
+
- ".cratis/ai/agents/**"
|
|
8
|
+
- ".cratis/ai/prompts/**"
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
<!-- Copyright (c) Cratis. All rights reserved. -->
|
|
12
|
+
<!-- Licensed under the MIT license. See LICENSE file in the project root for full license information. -->
|
|
13
|
+
|
|
14
|
+
# Shared review reports
|
|
15
|
+
|
|
16
|
+
Use this report shape for code, security, performance, and repository-investigation
|
|
17
|
+
reviews. Domain-specific risk labels refine findings, not the report or verdict
|
|
18
|
+
vocabulary. Review the change within the declared scope, not unrelated existing debt.
|
|
19
|
+
|
|
20
|
+
## Report shape
|
|
21
|
+
|
|
22
|
+
Keep these sections in order, writing `None` when a section has no entries:
|
|
23
|
+
|
|
24
|
+
- **Blockers** — findings that must be fixed before merge. Each names a file and
|
|
25
|
+
line or evidence reference, the problem, its concrete consequence, and a proposed
|
|
26
|
+
correction. A blocker names a consequence, not a rule number: "returns HTTP 500
|
|
27
|
+
instead of a validation error" explains harm; "violates rule 4" does not.
|
|
28
|
+
- **Suggestions** — non-blocking improvements, with their benefit and any relevant
|
|
29
|
+
conditions. Do not turn a preference or a hypothetical risk into a merge gate.
|
|
30
|
+
- **Dismissed (with reason)** — candidate findings considered and rejected, each
|
|
31
|
+
with the evidence or reasoning for dismissal so another reviewer need not raise
|
|
32
|
+
it again. Do not invent candidates to populate this section.
|
|
33
|
+
- **Verdict** — one of the values below, scoped to the evidence actually examined.
|
|
34
|
+
|
|
35
|
+
An empty Blockers section is a valid, complete review. Never manufacture a finding
|
|
36
|
+
to make a review look useful. Reserve **[BLOCKING]** exclusively for
|
|
37
|
+
must-fix-before-merge findings; suggestions and dismissed findings never carry it.
|
|
38
|
+
|
|
39
|
+
Every review includes a **Not examined:** line naming the paths, surfaces, checks,
|
|
40
|
+
and axes not examined, including anything that could not be reached. Name what was
|
|
41
|
+
not measured: code-shape inspection is not a benchmark, a build is not behavioral
|
|
42
|
+
proof, and an unexamined surface is not verified. State `None` only when the entire
|
|
43
|
+
declared scope was examined; otherwise give concrete limits and remaining checks.
|
|
44
|
+
|
|
45
|
+
## Verdict vocabulary
|
|
46
|
+
|
|
47
|
+
| Verdict | Meaning |
|
|
48
|
+
| --- | --- |
|
|
49
|
+
| **Approved** | No blockers or suggestions within the examined scope; required review checks are complete. |
|
|
50
|
+
| **Approved with suggestions** | No blockers; non-blocking suggestions remain and required review checks are complete. |
|
|
51
|
+
| **Changes requested** | At least one blocker must be corrected before merge. |
|
|
52
|
+
| **Incomplete** | No confirmed blocker, but missing or inconclusive required evidence prevents approval. |
|
|
53
|
+
|
|
54
|
+
Skipped optional axes belong on the Not examined line and do not alone prevent a
|
|
55
|
+
scoped approval. Missing required evidence does. When blockers and evidence gaps
|
|
56
|
+
coexist, use Changes requested and record the gaps on the Not examined line; never
|
|
57
|
+
reinterpret a failed or blocked gate as passing.
|
|
58
|
+
|
|
59
|
+
When combining reviews, retain one report per reviewer with the shared sections
|
|
60
|
+
and scope line, then give one combined verdict. Any blocker means Changes requested;
|
|
61
|
+
otherwise any Incomplete review means Incomplete; otherwise any remaining suggestion
|
|
62
|
+
means Approved with suggestions; otherwise use Approved. Do not drop dismissals or
|
|
63
|
+
scope limits when combining reports.
|
|
64
|
+
|
|
65
|
+
When a workflow requires a typed review envelope, preserve its schema and express
|
|
66
|
+
these sections, verdict meanings, and scope limits through its existing fields.
|
|
67
|
+
Do not append a competing Markdown report or invent envelope fields.
|
|
@@ -169,28 +169,13 @@ degradations a reviewer can see without measuring:
|
|
|
169
169
|
|
|
170
170
|
## Step 7 — Report
|
|
171
171
|
|
|
172
|
-
|
|
172
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing the report.
|
|
173
173
|
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
178
|
-
|
|
179
|
-
### <file path>
|
|
180
|
-
|
|
181
|
-
**[BLOCKING]** Line N: `problematic code`
|
|
182
|
-
Because: <the consequence, not the rule number>
|
|
183
|
-
Fix:
|
|
184
|
-
<corrected code>
|
|
185
|
-
```
|
|
186
|
-
|
|
187
|
-
Close with what passed and what must change. Two rules make the report usable:
|
|
188
|
-
|
|
189
|
-
- **A blocking finding names a consequence.** "Violates the style guide" is not
|
|
190
|
-
a reason. "Throws on a recoverable path, so the caller sees a 500 instead of a
|
|
191
|
-
validation error" is.
|
|
192
|
-
- **Say what you did not review.** A report listing only findings reads as if
|
|
193
|
-
everything was checked. Name the files, the paths, and the axes you skipped.
|
|
174
|
+
Correctness regressions, broken contracts, and missing specification coverage
|
|
175
|
+
that leaves changed behavior unverified belong in Blockers when they require
|
|
176
|
+
correction before merge. Style preferences and maintainability improvements
|
|
177
|
+
without such a consequence belong in Suggestions. Apply the shared verdict
|
|
178
|
+
vocabulary to those findings.
|
|
194
179
|
|
|
195
180
|
## What breaks
|
|
196
181
|
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
{
|
|
2
|
+
"skill": "cratis-code-review",
|
|
3
|
+
"input": "Report a code review with no blockers and one non-blocking maintainability suggestion.",
|
|
4
|
+
"fixtures": [],
|
|
5
|
+
"assertions": [
|
|
6
|
+
{ "kind": "skill-contains", "value": ".cratis/ai/rules/review-reports.md" },
|
|
7
|
+
{ "kind": "skill-contains", "value": "Correctness regressions, broken contracts" },
|
|
8
|
+
{ "kind": "skill-contains", "value": "Style preferences and maintainability improvements" }
|
|
9
|
+
]
|
|
10
|
+
}
|
|
@@ -121,25 +121,23 @@ behavior this file does not already state.
|
|
|
121
121
|
|
|
122
122
|
## Step 6 — Report
|
|
123
123
|
|
|
124
|
-
|
|
124
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing the report.
|
|
125
|
+
Keep the performance risk label on each finding:
|
|
125
126
|
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
Group findings by the section that produced them, and classify each:
|
|
129
|
-
|
|
130
|
-
| Risk | Meaning |
|
|
127
|
+
| Risk | Shared classification |
|
|
131
128
|
| --- | --- |
|
|
132
|
-
| **High** |
|
|
133
|
-
| **Medium** |
|
|
134
|
-
| **Low** |
|
|
129
|
+
| **High** | Blockers: degradation at moderate load requiring correction before merge |
|
|
130
|
+
| **Medium** | Suggestions: degradation under load or as data grows |
|
|
131
|
+
| **Low** | Suggestions: minor inefficiency |
|
|
135
132
|
|
|
136
|
-
|
|
133
|
+
Use the shared verdict vocabulary, not a separate performance verdict. If a
|
|
134
|
+
scale-dependent degradation must be corrected before merge, classify it as High
|
|
135
|
+
and state the relevant scale rather than leaving a blocker under Medium.
|
|
137
136
|
|
|
138
137
|
**Say what the finding costs and at what scale.** "This is slow" is not
|
|
139
138
|
actionable; "this scans the whole collection on every page load, so it is fine
|
|
140
|
-
at hundreds of rows and not at tens of thousands" is.
|
|
141
|
-
|
|
142
|
-
one overstates the evidence.
|
|
139
|
+
at hundreds of rows and not at tens of thousands" is. Distinguish measured cost
|
|
140
|
+
from code-shape inference; use the shared scope line to name unmeasured behavior.
|
|
143
141
|
|
|
144
142
|
## What breaks
|
|
145
143
|
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
{
|
|
2
|
+
"skill": "cratis-performance-review",
|
|
3
|
+
"input": "Report performance risks from code inspection without presenting unmeasured cost as a benchmark.",
|
|
4
|
+
"fixtures": [],
|
|
5
|
+
"assertions": [
|
|
6
|
+
{ "kind": "skill-contains", "value": ".cratis/ai/rules/review-reports.md" },
|
|
7
|
+
{ "kind": "skill-contains", "value": "**High** | Blockers:" },
|
|
8
|
+
{ "kind": "skill-contains", "value": "**Medium** | Suggestions:" },
|
|
9
|
+
{ "kind": "skill-contains", "value": "**Low** | Suggestions:" },
|
|
10
|
+
{ "kind": "skill-contains", "value": "Distinguish measured cost" }
|
|
11
|
+
]
|
|
12
|
+
}
|
|
@@ -129,21 +129,18 @@ command's properties as well as grepping them.
|
|
|
129
129
|
|
|
130
130
|
## Step 7 — Report
|
|
131
131
|
|
|
132
|
-
|
|
132
|
+
Read and use `.cratis/ai/rules/review-reports.md` when writing the report.
|
|
133
|
+
Keep the security risk label on each finding:
|
|
133
134
|
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
Group findings by the section that produced them, and classify each:
|
|
137
|
-
|
|
138
|
-
| Risk | Meaning |
|
|
135
|
+
| Risk | Shared classification |
|
|
139
136
|
| --- | --- |
|
|
140
|
-
| **Critical** |
|
|
141
|
-
| **Medium** |
|
|
142
|
-
| **Low** |
|
|
137
|
+
| **Critical** | Blockers: exploitable exposure requiring correction before merge |
|
|
138
|
+
| **Medium** | Suggestions: conditional exposure; state what makes it non-critical |
|
|
139
|
+
| **Low** | Suggestions: defense-in-depth improvement |
|
|
143
140
|
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
141
|
+
Use the shared verdict vocabulary, not a separate security verdict. If a
|
|
142
|
+
conditional exposure must be corrected before merge, classify it as Critical
|
|
143
|
+
and explain the exploit conditions rather than leaving a blocker under Medium.
|
|
147
144
|
|
|
148
145
|
## What breaks
|
|
149
146
|
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
{
|
|
2
|
+
"skill": "cratis-security-review",
|
|
3
|
+
"input": "Report security risks using the shared report and distinguish conditional exposure from a merge blocker.",
|
|
4
|
+
"fixtures": [],
|
|
5
|
+
"assertions": [
|
|
6
|
+
{ "kind": "skill-contains", "value": ".cratis/ai/rules/review-reports.md" },
|
|
7
|
+
{ "kind": "skill-contains", "value": "**Critical** | Blockers:" },
|
|
8
|
+
{ "kind": "skill-contains", "value": "**Medium** | Suggestions:" },
|
|
9
|
+
{ "kind": "skill-contains", "value": "**Low** | Suggestions:" }
|
|
10
|
+
]
|
|
11
|
+
}
|