You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .agents/skills/rsh-review/SKILL.md
+5-1Lines changed: 5 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -36,7 +36,8 @@ Review code changes with a bug-finding mindset. Prioritize correctness, regressi
36
36
4. Challenge assumptions around error paths, cancellation, timeouts, cleanup, concurrency, config precedence, and backward compatibility.
37
37
5. Check whether tests cover intended behavior and important failure modes.
38
38
6. Check whether `site/` docs or `docs/design/` should change.
39
-
7. Report findings first, ordered by severity. Keep summaries brief.
39
+
7. Keep the review scoped to the current PR unless the user asks for a broader audit. Distinguish required fixes from optional hardening or follow-on cleanup.
40
+
8. Report findings first, ordered by severity. Keep summaries brief.
40
41
41
42
## Output Expectations
42
43
@@ -47,6 +48,7 @@ Review code changes with a bug-finding mindset. Prioritize correctness, regressi
47
48
- If no findings are present, say so explicitly and call out any residual risk or untested areas.
48
49
- Do not pad the review with praise or low-value nits unless the user asks for them.
49
50
- Do not report speculative issues unless there is a plausible failure mode in the changed code.
51
+
- Do not turn a scoped PR review into general codebase cleanup. If you notice unrelated risks, list them as out-of-scope follow-ups only when they are important.
50
52
- Treat missing coverage as a test gap unless the diff shows a confirmed bug.
51
53
52
54
## Severity Guide
@@ -105,6 +107,8 @@ Intentional formatter changes should usually come with targeted regression cover
105
107
106
108
Changes in these areas often regress behavior only in realistic end-to-end paths. Review interactions, not just isolated helpers.
107
109
110
+
For auth, redaction, and cache metadata changes, check both positive behavior and negative leakage boundaries: where credentials are applied, where they must not be applied, what gets persisted, and what appears in errors or traces. Keep findings tied to the PR's changed paths.
111
+
108
112
### Test buffer races
109
113
110
114
Tests that share a `bytes.Buffer` across concurrent writers can hide data races, especially when subprocess stderr/stdout is wired into test buffers.
Copy file name to clipboardExpand all lines: .agents/skills/rsh-simplify/SKILL.md
+13Lines changed: 13 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,6 +27,19 @@ Identify and eliminate unnecessary complexity in the Restish codebase. Fewer lin
27
27
28
28
User experience comes first. Developer experience comes second. Simplifications that improve both are highest value. Simplifications that improve only developer experience at some user cost are not acceptable.
29
29
30
+
## Post-Review Shrink Pass
31
+
32
+
After a PR has gone through review/fix loops, do a focused simplification pass before final handoff when the diff has grown substantially. Compare `git diff --stat` or `git diff --shortstat` before and after. Target duplicated test setup, repeated assertions, over-large inline fixtures, and helper code that obscures the behavior under test. Prefer deleting ceremony over deleting coverage.
33
+
34
+
Good shrink-pass moves:
35
+
36
+
- Table-drive cases that share setup and assertion shape.
37
+
- Add small helpers for repeated config/cache/server setup when they make tests read more directly.
38
+
- Share behavioral assertions that are repeated verbatim.
39
+
- Keep edge-case tests for auth, redaction, redirects, cache metadata, migrations, and subprocess behavior when those edge cases are the point of the PR.
40
+
41
+
Avoid code golf. A shorter diff that is harder to audit, especially around security/auth/cache behavior, is not a simplification.
Copy file name to clipboardExpand all lines: .agents/skills/rsh-test/SKILL.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,6 +59,9 @@ Prefer plain Go tests with a small Restish-specific helper vocabulary over Gherk
59
59
60
60
- One test should usually cover one behavior from input through observable result.
61
61
- Combine cases when they differ only by inputs and expected outputs. Split cases when setup or failure meaning differs.
62
+
- For review-driven edge cases, first preserve the behavioral boundary, then reduce scaffolding. Table-drive repeated redirect, redaction, cache, migration, or auth-origin cases only when the setup and assertion shape truly match.
63
+
- Use focused helpers for repeated config/cache/server setup, but keep the request, persisted state, error, or output assertion visible in the test.
64
+
- When covering credential handling, assert both where credentials are applied and where they are not applied, plus what gets persisted and what appears in diagnostics.
62
65
- Avoid asserting private call sequences unless ordering is the contract.
63
66
- Avoid mocks for HTTP, files, and CLI I/O when standard library fakes or temp resources are clearer.
64
67
- Keep fixtures tiny but believable: real OpenAPI fragments, real response headers, real shorthand, real config snippets.
Copy file name to clipboardExpand all lines: AGENTS.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,6 +48,10 @@ The core design is a `CLI` struct in `internal/cli/cli.go` that owns all state
48
48
49
49
`TODO.md` and `review.md` are local working files for planning, code reviews, and in-progress implementation notes only. They must never be committed to git history. Keep them ignored/untracked, and if they are accidentally staged, unstage them before committing.
50
50
51
+
## PR Review and Cleanup Discipline
52
+
53
+
Keep review and fix loops scoped to the current PR's behavioral surface unless the user explicitly asks for broader cleanup. After substantial review loops, do a simplification pass before final handoff: reduce repeated scaffolding, table-drive genuinely similar cases, and consolidate helpers where that preserves readability. Do not shrink a PR by deleting important coverage or making security/auth/cache behavior harder to audit.
54
+
51
55
## Commit Messages
52
56
53
57
Use [Conventional Commits](https://www.conventionalcommits.org/) for all commits:
0 commit comments