suede-release-linter
starsforks
How to install suede-release-linter?
jasoncolapietro/suede-creator-skills/suede-release-linter
$npx -y skills add JasonColapietro/suede-creator-skills --skill suede-release-linterAudit creative release folders before handoff: metadata, file structure, artwork, lyrics, stems, rights blockers, and platform readiness.
SKILL.md
| 1 | # Release Metadata Linter |
| 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 | ## Overview |
| 25 | |
| 26 | Audit a music or media project folder and produce a practical release-readiness report. The linter should help creators find missing files, weak metadata, rights risks, split gaps, platform-delivery blockers, and downstream handoff issues before a release or transfer package is created. |
| 27 | |
| 28 | **Core principle:** report what is present, missing, or unknown. Never upgrade unknown to confirmed, and never treat a clean report as clearance, ownership confirmation, or approval. |
| 29 | |
| 30 | Public v1 is offline-first: inspect local files and supplied metadata, do not upload files, write to a registry, call distribution APIs, request private keys, or claim legal clearance. |
| 31 | |
| 32 | ## Workflow |
| 33 | |
| 34 | 1. Identify the source folder or supplied files. |
| 35 | 2. Ask for the output location if it is not obvious. |
| 36 | 3. Read `references/lint-rules.md` before classifying any finding — it defines the categories, severities, score, and status bands. Do not assign severities from memory. |
| 37 | 4. If working on a local folder, run `scripts/lint_release.py` to generate `release-lint-report.md` and `release-lint-report.json`. |
| 38 | 5. Read `references/fix-guidance.md` when turning findings into specific next actions. |
| 39 | 6. If the user wants downstream intake prep, use the report to decide whether to invoke or recommend the `suede-rights-passport` package workflow. |
| 40 | 7. Do not invent release metadata. Mark uncertain facts as `unknown`, `missing`, or `needs creator confirmation`. Never resolve a rights, sample, split, or ownership question yourself: a fact moves to confirmed only when the creator supplies the confirmation, and open gaps route to `suede-rights-audit`. |
| 41 | 8. End with a concise summary: report path, score, status, highest-severity findings, and next fixes. |
| 42 | |
| 43 | ## Quick Start |
| 44 | |
| 45 | ```bash |
| 46 | python3 /path/to/suede-release-linter/scripts/lint_release.py \ |
| 47 | /path/to/music-project \ |
| 48 | --output /path/to/release-lint-output |
| 49 | ``` |
| 50 | |
| 51 | If the source folder contains a metadata file, pass it explicitly: |
| 52 | |
| 53 | ```bash |
| 54 | python3 /path/to/suede-release-linter/scripts/lint_release.py \ |
| 55 | /path/to/music-project \ |
| 56 | --metadata /path/to/music-project/metadata.json \ |
| 57 | --output /path/to/release-lint-output |
| 58 | ``` |
| 59 | |
| 60 | Accepted metadata formats are JSON, YAML/YML when PyYAML is installed, and |
| 61 | public-safe key=value text files. Do not point metadata at real `.env`, |
| 62 | credential, wallet, or deployment config files. |
| 63 | |
| 64 | Safety defaults: |
| 65 | |
| 66 | - Hidden files, dependency folders, build outputs, caches, and secret-like files are skipped by default. |
| 67 | - Unrecognized file types are skipped unless `--include-other` is passed. |
| 68 | - Absolute local paths are redacted to share-safer names unless `--include-absolute-paths` is passed. |
| 69 | - Existing generated report files are not overwritten unless `--force` is passed. |
| 70 | - The output folder cannot be the same folder as the source or live inside it. |
| 71 | - YAML metadata requires PyYAML: `python3 -m pip install PyYAML`. |
| 72 | |
| 73 | ## What To Check |
| 74 | |
| 75 | Read each bundled reference at the moment it is needed, not up front: |
| 76 | |
| 77 | - `references/lint-rules.md`: before classifying findings, or when hand-linting without the script — categories, severity levels, score, and status bands. |
| 78 | - `references/metadata-fields.md`: when metadata is missing, malformed, or being authored — recommended fields, accepted aliases, and confirmation values. |
| 79 | - `references/fix-guidance.md`: when turning findings into next actions or a fix plan. |
| 80 | - `references/passport-context.md`: when the user asks how the lint report relates to Suede review or the Suede Creator Passport. |
| 81 | |
| 82 | The script writes: |
| 83 | |
| 84 | - `release-lint-report.md`: human-readable report. |
| 85 | - `release-lint-report.json`: machine-readable findings. |
| 86 | |
| 87 | Use the bundled assets when repairing or hand-writi |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
