process-quality-checker
Skill3 starsChanged 8 months agoMITView on GitHub
In this repository21 other files it gives its agents.
- maintainability-reviewerSkill
- process-quality-checkerSkill
- product-vs-process-quality-splitterSkill
- quality-attribute-model-builderSkill
- quality-evidence-summarizerSkill
- quality-goal-scorerSkill
- quality-risk-register-builderSkill
- quality-weighting-reviewerSkill
- reliability-quality-reviewerSkill
- technical-debt-auditorSkill
- usability-quality-reviewerSkill
- maintainability-reviewerSkill
- product-vs-process-quality-splitterSkill
- quality-attribute-model-builderSkill
- quality-evidence-summarizerSkill
- quality-goal-scorerSkill
- quality-risk-register-builderSkill
- quality-weighting-reviewerSkill
- reliability-quality-reviewerSkill
- technical-debt-auditorSkill
- usability-quality-reviewerSkill
The file
We split this skill into the rules it gives an agent
9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 39
Do not make strong quality claims without evidence or confidence notes.
- Distinctive: line 41
Prefer actionable findings tied to consequence over generic “improve quality” advice.
- Distinctive: line 42
Keep the artifact compact, structured, and reusable.
- Distinctive: line 51
Prefer structured findings over narrative filler.
- Distinctive: line 53
Use severity, priority, or confidence labels when useful.
- Distinctive: line 56
Do not confuse stakeholder optimism with evidence.
- Distinctive: line 57
Do not collapse all quality concerns into one generic score.
- Distinctive: line 58
Do not hide missing telemetry, weak tests, or process gaps.
- Distinctive: line 59
Do not recommend vague actions with no owner or consequence path.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
process-quality-checker
Purpose
Assess whether the development process supports quality through reviews, testing, traceability, versioning, and release discipline.
Trigger this skill when
- You need a focused software-quality analysis or artifact rather than a broad generic review.
- Quality claims, tradeoffs, or risks are currently vague or implicit.
- You need a reusable output another reviewer, developer, or agent can extend safely.
Expected inputs
- system or component context
- quality goals or stakeholder expectations
- available evidence
- constraints and known risks
Deliverables
- structured findings
- quality-focused artifact
- assumptions and evidence gaps
- recommended next skill
Operating procedure
- Clarify which quality concern is in scope and why it matters to the system or stakeholder.
- Separate explicit evidence from assumptions, missing data, or inference.
- Convert vague quality language into concrete attributes, criteria, or review findings.
- Produce a compact artifact that supports decision-making, follow-up analysis, or governance.
- Recommend the next most useful quality, verification, or remediation step.
Quality gates
- Do not make strong quality claims without evidence or confidence notes.
- Make tradeoffs, assumptions, and blind spots explicit.
- Prefer actionable findings tied to consequence over generic “improve quality” advice.
- Keep the artifact compact, structured, and reusable.
Handoff targets
- product-vs-process-quality-splitter
- quality-risk-register-builder
- quality-evidence-summarizer
Output style
- Be explicit about evidence quality and uncertainty.
- Prefer structured findings over narrative filler.
- Tie recommendations to quality impact, operational consequence, or change cost.
- Use severity, priority, or confidence labels when useful.
Failure modes to avoid
- Do not confuse stakeholder optimism with evidence.
- Do not collapse all quality concerns into one generic score.
- Do not hide missing telemetry, weak tests, or process gaps.
- Do not recommend vague actions with no owner or consequence path.
Minimum output skeleton
## Summary
## Findings
## Structured outputs
## Evidence / confidence
## Assumptions
## Open questions
## Recommended next skillDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

