Works with the AI tools you already use
Claude Code
Cursor
Codex CLI
Muse
Dots+22 moreClaude CodeCursorCodex CLIMuseDots
OpenClaw
Manus
Grok
Grok Bot+18 agentsQuality Control Checklist Builder
Describe a process and what has gone wrong; get a pass/fail QC checklist where every check traces to a real failure.
Free
Quality Control Checklist Builder
Example session with this skill installed
Build a QC checklist for how we publish customer-facing release notes. Right now quality depends entirely on who writes them.
Our process: the PM collects merged tickets tagged "customer-facing" from Jira at the end of each sprint. They write a draft in Google Docs grouped into New, Improved, and Fixed. Engineering lead reviews for technical accuracy. Marketing edits for tone. Then the PM pastes it into our help center and also emails it to customers through our newsletter tool.
Things that have gone wrong in the last six months: we announced a feature that was behind a feature flag and not actually released to most customers; a release note mentioned an internal codename ("Project Falcon") instead of the product name; one email went out with broken links because the help-center article was published after the email; we forgot to mention a breaking API change that affected integrations; and twice a fix was listed that had actually been reverted before the release.
- Read your context and instructions
- Compiled the quality control checklist
I've written the checklist: 9 critical checks and 8 routine ones across four gates, each placed where its failure gets in. All five failures you listed would be caught before the email goes out.
The main finding. Two of your five failures (the flagged feature and the twice-listed reverted fix) come from the same gap. The draft is built from Jira, and Jira only shows what was merged, not what customers actually received. So the checklist has the engineering lead check the actual release contents and flag states. The PM then rechecks both within 24 hours of sending, because things can change between the end-of-sprint review and send day.
How each past failure is caught:
| Failure | Check | When |
|---|---|---|
| Feature announced while still behind a flag | C3: flag on for 100% of eligible customers, or the note states the limit ("Enterprise plans only"). C7 rechecks on send day | Eng review, publish day |
| "Project Falcon" in the text | C5: search for every name on a codename list, plus ticket numbers and internal web addresses. Run after Marketing's last edit and again on the pasted versions | Tone edit, publish day |
| Broken links in the email | C8: help-center article must be live, checked in a logged-out browser, before the email is scheduled. C9: click every link in a test send | Publish day |
| Breaking API change left out | C1: a second Jira search for API and breaking changes that ignores the "customer-facing" tag. C4: the eng lead answers yes/no in writing, and any breaking change gets a required section at the top | Collection, eng review |
| Reverted fix listed | C2: check the release's code history for each ticket and confirm it wasn't reverted. C7 rechecks on send day | Eng review, publish day |
Two process changes it asks for:
- Marketing edits in Suggesting mode, and the eng lead approves any suggestion that changes a claim (C6). Right now Marketing edits after the technical review, so the last edit is never checked for accuracy. This one isn't from your list; it's a gap in the current order of steps.
- The help-center article goes live before the email is scheduled. That's a fixed order now, not a habit.
When a critical check fails: wrong items get
removed so the send still goes out. A missing breaking change or a broken link
holds the send, because a breaking change can't just be dropped from the notes. The doc also covers what to do if an error gets out anyway, and has a results table to add to each release's Google Doc.
What I couldn't do: I didn't have a real recent release note, so I could only test the checklist against the failures you described. Before you adopt it, run last sprint's doc through it. Part 6 explains what to look for.
Three assumptions for you to confirm (Part 5):
- "Released" means flagged on for 100% of eligible customers.
- The Head of Product decides go/no-go when a breaking change is unclear.
- The send-day recheck happens within 24 hours of sending.
One-time setup: a new Jira saved search, a codename list the PM maintains (names added when a project starts), and read access to the feature-flag tool for the PM.
File
| Path | Last modified | Includes |
|---|---|---|
release-notes-qc-checklist.md (in your working folder) | 2026-10-01 | v1.0: failure list, checks by gate, escalation, record templates, setup, failure trace, 90-day review on 2026-12-30 |
Connects securely to your tools. The creator never sees your data.
About this skill
For operations leads, PMs, and team leads whose output quality depends on who did the work. Describe the process and, most importantly, what has actually gone wrong before. You get a checklist anyone can run, where every check exists to catch a named failure.
What you get
- A failure-mode inventory: for each step, what can go wrong, why it is missed today, and what it costs.
- Two tiers of checks. Critical checks stop the line and are never skipped; routine checks tolerate an occasional miss.
- Binary, observable checks with the evidence to look at, such as "invoice total matches PO total", never "check invoice".
- An operating shell: when each check runs, who signs off, where results are recorded, and what happens when a critical check fails.
- A trace table showing which check catches each of your past failures, plus a 90-day review date.
What it refuses to do
- Add a check that does not trace to a failure mode. A check that catches nothing is process theater.
- Use vague acceptance criteria like "appropriate", "sufficient", or "high quality".
- Ship a wall of checks nobody completes. Past about 15 per tier, it splits the list by role or stage.
- Claim it was tested on real work when it was not. Without a recent real work product, it says so and tells you how to dry-run it.
What's in the zip
SKILL.md: the skill.references/recipe.md: the full step-by-step recipe with examples and variations.evals/: test cases you can run to check its behavior.
The demo below shows the summary Claude gives in chat. The full checklist it wrote to a file is about 14 KB. From the open-source Claude Code Recipes collection.
How to install
Works the same in every agent - Claude, Cursor, Codex, Copilot and 20+ more.
- 1
Download the ZIP
Free skills download straight away. Paid skills unlock right after purchase.
- 2
Unzip into your skills folder
Every agent reads skills from one folder on your machine. Drop the unzipped folder in there.
- 3
Ask your agent to use it
Restart the agent if it was already running. It picks the skill up automatically - no config needed.
Skills folder by agent
Click the path to copy it. Create the folder if it does not exist yet.
Reviews
No reviews yet
Be one of the first to try it. Every listed skill passes our trust checks below.
Security scanned
Passed our 8-point scan before listing
Fresh listing
Recently published to Agensi
Free forever
No account required to browse
Trust & safety
Security scanned
Verified clean 1 day ago
- Free to download with an account
Needs access to
Github