suede-code

Name: suede-code
Author: JasonColapietro

44stars8forks

How to install suede-code?

jasoncolapietro/suede-creator-skills/suede-code

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

Installs into the current project.

Summary

Review and grade code in one pass: real findings, A-F ship verdict, auth/payment risk, OWASP checks, deploy safety, and fix briefs.

Files · 1

View on GitHub

SKILL.md

1	# Suede Code
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	One pass for code: a deep, evidence-based review and a blunt A-F ship grade, together by default. Findings tell you what is wrong; the grade tells you whether it ships. Every finding has a file, evidence, and a fix path. No findings without evidence. No volume without signal.
25
26	Runs only when asked. This skill never auto-fires on a diff, a save, or a commit. Invoke it explicitly (review this, grade this, security-check this, is this safe to ship). Do not run it as a side effect of other work.
27
28	## Model Routing
29
30	Default: Sonnet. Recommend Opus for auth, payments, and public API surface reviews.
31
32	## Operating Stance
33
34	- Review current source, current diff, local docs, and relevant runtime behavior.
35	- Keep code generation and review separate. If you authored the code, switch into review mode and look for what your implementation would miss.
36	- Preserve user and other-agent WIP. Do not stage, revert, or rewrite unrelated files.
37	- Prefer high-signal findings over volume. Do not leave style nits when formatters 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 reviewing, 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, public copy, analytics, secrets, deployment, docs.
47
48	## Context Graph
49
50	Build a lightweight graph before judging the diff:
51
52	1. Changed files and generated files.
53	2. Imports, callers, routes, API handlers, jobs, hooks, models, schemas, and config/env dependencies touched by the change.
54	3. Tests, fixtures, migrations, release scripts, docs, and screenshots that should move with the behavior.
55	4. Runtime surfaces: local route, live URL, API endpoint, simulator flow, dashboard, App Store metadata, or deployment target.
56	5. Domain contracts: creator ownership, rights/provenance, registry-backed media, royalty routing, agent commerce, wallet/payment flows, and published-statement accuracy.
57
58	Flag beyond-the-diff risks when related files, defaults, docs, env, or deploy requirements no longer agree.
59
60	## Run Gates and Honor Project Rules
61
62	Before manual analysis, run the gates the repo already ships and fold results in — typecheck, the configured linter on changed files, the test suite, the dependency auditor when deps changed, and a real secret scanner over the diff. Detect what exists; run only that; never fabricate a result you did not run, and note in Verification when a gate could not run. Then read the repo's own conventions — `CLAUDE.md`, `AGENTS.md`, linter/formatter config, nearest-ancestor rules — and treat them as binding: do not flag what a rule permits, do flag what it forbids, and do not re-raise a pattern the user already accepted.
63
64	## Review Modes
65
66	- Fast diff review: small change, narrow blast radius, focused findings.
67	- Deep PR review: multi-file behavior, public surface, data/auth/payment, release, or cross-repo risk.
68	- Plan review: implementation has not started; inspect scope, sequencing, acceptance criteria, test mapping, missing decisions.
69	- Fix verification: review after fixes; rescan changed files and confirm the original finding is gone.
70	- Release review: validate build, secrets, env, public copy, screenshots, metadata, deployment, and live/API readback.
71
72	### Depth Levels
73
74	Add a `--depth` modifier:
75
76	- `--quick` (~2 min): pattern scan — obvious bugs, hardcoded secrets, missing null checks, injection patterns, broken error handling. No cross-file analysis.
77	- `--standard` (default, ~10 min): per-file correctness on cha

People who liked this also viewed

6 picks

Type

hyperframes-cliUse the HyperFrames CLI development loop: init, add, catalog, capture, lint, check, snapshot, compare, grade-compare, preview, play, present, beats, keyframes, single or batch render, publish, cloud, SkillsJul 2026262k37k
request-refactor-planSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026165k181k
analyze-projectRigor Analyze / Rigor Audit read-only skill for deep learning research repositories. Use when the user wants to read and understand a repository, inspect model structure and training or inference entrSkillsMay 2026161k507
explore-codeRigor Improve implementation leaf skill for auditable candidate implementation in deep learning research repositories. Use when the researcher explicitly authorizes exploratory work on an isolated braSkillsMay 2026161k507
ubiquitous-languageSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026160k181k
scaffold-exercisesSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026149k181k

suede-code

44stars8forks

View on GitHub

How to install suede-code?

jasoncolapietro/suede-creator-skills/suede-code

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

Installs into the current project.

Summary

Review and grade code in one pass: real findings, A-F ship verdict, auth/payment risk, OWASP checks, deploy safety, and fix briefs.

Files · 1

View on GitHub

SKILL.md

1	# Suede Code
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	One pass for code: a deep, evidence-based review and a blunt A-F ship grade, together by default. Findings tell you what is wrong; the grade tells you whether it ships. Every finding has a file, evidence, and a fix path. No findings without evidence. No volume without signal.
25
26	Runs only when asked. This skill never auto-fires on a diff, a save, or a commit. Invoke it explicitly (review this, grade this, security-check this, is this safe to ship). Do not run it as a side effect of other work.
27
28	## Model Routing
29
30	Default: Sonnet. Recommend Opus for auth, payments, and public API surface reviews.
31
32	## Operating Stance
33
34	- Review current source, current diff, local docs, and relevant runtime behavior.
35	- Keep code generation and review separate. If you authored the code, switch into review mode and look for what your implementation would miss.
36	- Preserve user and other-agent WIP. Do not stage, revert, or rewrite unrelated files.
37	- Prefer high-signal findings over volume. Do not leave style nits when formatters 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 reviewing, 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, public copy, analytics, secrets, deployment, docs.
47
48	## Context Graph
49
50	Build a lightweight graph before judging the diff:
51
52	1. Changed files and generated files.
53	2. Imports, callers, routes, API handlers, jobs, hooks, models, schemas, and config/env dependencies touched by the change.
54	3. Tests, fixtures, migrations, release scripts, docs, and screenshots that should move with the behavior.
55	4. Runtime surfaces: local route, live URL, API endpoint, simulator flow, dashboard, App Store metadata, or deployment target.
56	5. Domain contracts: creator ownership, rights/provenance, registry-backed media, royalty routing, agent commerce, wallet/payment flows, and published-statement accuracy.
57
58	Flag beyond-the-diff risks when related files, defaults, docs, env, or deploy requirements no longer agree.
59
60	## Run Gates and Honor Project Rules
61
62	Before manual analysis, run the gates the repo already ships and fold results in — typecheck, the configured linter on changed files, the test suite, the dependency auditor when deps changed, and a real secret scanner over the diff. Detect what exists; run only that; never fabricate a result you did not run, and note in Verification when a gate could not run. Then read the repo's own conventions — `CLAUDE.md`, `AGENTS.md`, linter/formatter config, nearest-ancestor rules — and treat them as binding: do not flag what a rule permits, do flag what it forbids, and do not re-raise a pattern the user already accepted.
63
64	## Review Modes
65
66	- Fast diff review: small change, narrow blast radius, focused findings.
67	- Deep PR review: multi-file behavior, public surface, data/auth/payment, release, or cross-repo risk.
68	- Plan review: implementation has not started; inspect scope, sequencing, acceptance criteria, test mapping, missing decisions.
69	- Fix verification: review after fixes; rescan changed files and confirm the original finding is gone.
70	- Release review: validate build, secrets, env, public copy, screenshots, metadata, deployment, and live/API readback.
71
72	### Depth Levels
73
74	Add a `--depth` modifier:
75
76	- `--quick` (~2 min): pattern scan — obvious bugs, hardcoded secrets, missing null checks, injection patterns, broken error handling. No cross-file analysis.
77	- `--standard` (default, ~10 min): per-file correctness on cha

People who liked this also viewed

6 picks

Type