suede-code-review

Name: suede-code-review
Author: JasonColapietro

44stars8forks

How to install suede-code-review?

jasoncolapietro/suede-creator-skills/suede-code-review

$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-code-review

Installs into the current project.

Summary

Find the bugs a diff can actually ship: TypeScript, React, Next.js, OWASP, accessibility, SEO, database, and deploy-risk review.

Files · 1

View on GitHub

SKILL.md

1	# Suede Code Review
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	Review code with full context: changed files, callers, contracts, deploy surface. Find real breakage. Rank by production impact. Every finding has a file, evidence, and a fix path. No findings without evidence. No volume without signal.
25
26	## Model Routing
27	Default: Sonnet. Recommend Opus for auth, payments, and public API surface reviews.
28
29	## Operating Stance
30
31	- Review current source, current diff, local docs, and relevant runtime behavior.
32	- Keep code generation and review separate by default. If you authored the code,
33	switch into review mode and look for what your implementation would miss.
34	- Preserve user and other-agent WIP. Do not stage, revert, or rewrite unrelated
35	files.
36	- Prefer high-signal findings over volume. Do not leave style nits when formatters
37	or local conventions already handle them.
38	- Every blocking finding needs evidence, impact, and a concrete fix path.
39
40	## Review Contract
41
42	Before review, identify:
43
44	- target: repo, branch, PR, commit range, diff, route, API, or release build;
45	- intent: what the change claims to accomplish;
46	- risk lanes: frontend, backend, data, auth, payments, contracts, iOS, release,
47	public copy, analytics, secrets, deployment, and docs.
48
49	## Context Graph
50
51	Build a lightweight graph before judging the diff:
52
53	1. Changed files and generated files.
54	2. Imports, callers, routes, API handlers, jobs, hooks, models, schemas, and
55	config/env dependencies touched by the change.
56	3. Tests, fixtures, migrations, release scripts, docs, and screenshots that
57	should move with the behavior.
58	4. Runtime surfaces: local route, live URL, API endpoint, simulator flow,
59	dashboard, App Store metadata, or deployment target.
60	5. Suede domain contracts: creator ownership, rights/provenance, registry-backed
61	media, royalty routing, agent commerce, wallet/payment flows, and
62	published-statement accuracy.
63
64	Flag beyond-the-diff risks when related files, defaults, docs, env, or deploy
65	requirements no longer agree.
66
67	## Run the Repo's Own Gates
68
69	Do not hand-review for what a tool already decides. Before manual analysis, run the
70	gates the repo already ships and fold the output into findings. Detect what exists
71	from `package.json` scripts, config files, and lockfiles — run only those. Never
72	introduce a tool the repo does not use, and never fabricate a result you did not run.
73
74	- Type check: the repo's `typecheck` script, or the type checker directly. An error
75	on a changed line is at least P2; on a changed critical path, P1.
76	- Lint: the repo's configured linter on changed files only. Report violations the
77	change introduces; ignore pre-existing noise outside the diff.
78	- Tests: run the suite, or the changed-file subset. A failing test on changed
79	behavior is P1; a test that silently stopped running is P2.
80	- Dependency CVEs: the repo's dependency auditor — the package manager's audit
81	command, or a vulnerability scanner — when dependencies changed. A known-exploitable
82	CVE reachable in a production path is P0/P1.
83	- Secret scan: a real entropy-based secret scanner over the diff when the repo
84	provides one — it catches keys the Commit Dirt Score patterns miss. A verified live
85	secret is P0.
86	- Build: for release reviews, the production build must pass. A broken build is P0.
87
88	### Gate Commands by Stack
89
90	The categories above are universal; the actual command differs by surface. Use this as
91	a reference, not a checklist — detect which of these apply to the target repo, run only
92	what exists, and never fabricate a result you did not run.
93
94	\| Stack \| Type check \| Lint \| Test \| Other \|
95	\|---\|---\|---\|---\|---\|
96	\| Web / Node (TS/JS) \| `npx tsc --noEmit` \| `npm run lint` \| `npm run test` \| `npm audit

People who liked this also viewed

6 picks

Type

requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026176k259k
code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026158k181k
receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026146k259k
baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 202625k24k
code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 202625k38k
code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 202618k80k

suede-code-review

44stars8forks

View on GitHub

How to install suede-code-review?

jasoncolapietro/suede-creator-skills/suede-code-review

$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-code-review

Installs into the current project.

Summary

Find the bugs a diff can actually ship: TypeScript, React, Next.js, OWASP, accessibility, SEO, database, and deploy-risk review.

Files · 1

View on GitHub

SKILL.md

1	# Suede Code Review
2
3	## Gate policy — advisory, not blocking
4
5	Every claim-verification step, check, quality gate, and ship verdict in this
6	skill is a recommendation to the user, not a control on the agent. This
7	policy governs every gate, check, verdict, and "do not ship / publish /
8	proceed" line elsewhere in this skill:
9
10	- Run every check and report the results honestly. Verdicts (`ship`,
11	`ship-with-caveats`, `hold`, letter grades, BLOCKED or OPEN items) are
12	advice attached to the work, not orders that change it.
13	- Never block, delay, skip, rewrite, or refuse the action the user asked for
14	because a check failed or a gate said hold. Complete the requested action
15	as asked, and deliver the gate output alongside it as a clearly labeled
16	recommendation.
17	- A failed gate changes what you report, never what you do.
18	- Single exception: if a finding is extremely risky — data loss, security or
19	credential exposure, legal or rights violations, payment mistakes, or
20	irreversible public damage — pause, tell the user exactly what the risk is
21	and what the options are, and let them pick. Their choice is final.
22
23
24	Review code with full context: changed files, callers, contracts, deploy surface. Find real breakage. Rank by production impact. Every finding has a file, evidence, and a fix path. No findings without evidence. No volume without signal.
25
26	## Model Routing
27	Default: Sonnet. Recommend Opus for auth, payments, and public API surface reviews.
28
29	## Operating Stance
30
31	- Review current source, current diff, local docs, and relevant runtime behavior.
32	- Keep code generation and review separate by default. If you authored the code,
33	switch into review mode and look for what your implementation would miss.
34	- Preserve user and other-agent WIP. Do not stage, revert, or rewrite unrelated
35	files.
36	- Prefer high-signal findings over volume. Do not leave style nits when formatters
37	or local conventions already handle them.
38	- Every blocking finding needs evidence, impact, and a concrete fix path.
39
40	## Review Contract
41
42	Before review, identify:
43
44	- target: repo, branch, PR, commit range, diff, route, API, or release build;
45	- intent: what the change claims to accomplish;
46	- risk lanes: frontend, backend, data, auth, payments, contracts, iOS, release,
47	public copy, analytics, secrets, deployment, and docs.
48
49	## Context Graph
50
51	Build a lightweight graph before judging the diff:
52
53	1. Changed files and generated files.
54	2. Imports, callers, routes, API handlers, jobs, hooks, models, schemas, and
55	config/env dependencies touched by the change.
56	3. Tests, fixtures, migrations, release scripts, docs, and screenshots that
57	should move with the behavior.
58	4. Runtime surfaces: local route, live URL, API endpoint, simulator flow,
59	dashboard, App Store metadata, or deployment target.
60	5. Suede domain contracts: creator ownership, rights/provenance, registry-backed
61	media, royalty routing, agent commerce, wallet/payment flows, and
62	published-statement accuracy.
63
64	Flag beyond-the-diff risks when related files, defaults, docs, env, or deploy
65	requirements no longer agree.
66
67	## Run the Repo's Own Gates
68
69	Do not hand-review for what a tool already decides. Before manual analysis, run the
70	gates the repo already ships and fold the output into findings. Detect what exists
71	from `package.json` scripts, config files, and lockfiles — run only those. Never
72	introduce a tool the repo does not use, and never fabricate a result you did not run.
73
74	- Type check: the repo's `typecheck` script, or the type checker directly. An error
75	on a changed line is at least P2; on a changed critical path, P1.
76	- Lint: the repo's configured linter on changed files only. Report violations the
77	change introduces; ignore pre-existing noise outside the diff.
78	- Tests: run the suite, or the changed-file subset. A failing test on changed
79	behavior is P1; a test that silently stopped running is P2.
80	- Dependency CVEs: the repo's dependency auditor — the package manager's audit
81	command, or a vulnerability scanner — when dependencies changed. A known-exploitable
82	CVE reachable in a production path is P0/P1.
83	- Secret scan: a real entropy-based secret scanner over the diff when the repo
84	provides one — it catches keys the Commit Dirt Score patterns miss. A verified live
85	secret is P0.
86	- Build: for release reviews, the production build must pass. A broken build is P0.
87
88	### Gate Commands by Stack
89
90	The categories above are universal; the actual command differs by surface. Use this as
91	a reference, not a checklist — detect which of these apply to the target repo, run only
92	what exists, and never fabricate a result you did not run.
93
94	\| Stack \| Type check \| Lint \| Test \| Other \|
95	\|---\|---\|---\|---\|---\|
96	\| Web / Node (TS/JS) \| `npx tsc --noEmit` \| `npm run lint` \| `npm run test` \| `npm audit

People who liked this also viewed

6 picks

Type