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 skill
1---2name: process-quality-checker3description: process-quality-checker4---5# process-quality-checker67## Purpose8Assess whether the development process supports quality through reviews, testing, traceability, versioning, and release discipline.910## Trigger this skill when11- You need a focused software-quality analysis or artifact rather than a broad generic review.12- Quality claims, tradeoffs, or risks are currently vague or implicit.13- You need a reusable output another reviewer, developer, or agent can extend safely.1415## Expected inputs16- system or component context17- quality goals or stakeholder expectations18- available evidence19- constraints and known risks2021## Deliverables22- structured findings23- quality-focused artifact24- assumptions and evidence gaps25- recommended next skill2627## Operating procedure281. Clarify which quality concern is in scope and why it matters to the system or stakeholder.292. Separate explicit evidence from assumptions, missing data, or inference.303. Convert vague quality language into concrete attributes, criteria, or review findings.314. Produce a compact artifact that supports decision-making, follow-up analysis, or governance.325. Recommend the next most useful quality, verification, or remediation step.3334## Quality gates35- Do not make strong quality claims without evidence or confidence notes.36- Make tradeoffs, assumptions, and blind spots explicit.37- Prefer actionable findings tied to consequence over generic “improve quality” advice.38- Keep the artifact compact, structured, and reusable.3940## Handoff targets41- product-vs-process-quality-splitter42- quality-risk-register-builder43- quality-evidence-summarizer4445## Output style46- Be explicit about evidence quality and uncertainty.47- Prefer structured findings over narrative filler.48- Tie recommendations to quality impact, operational consequence, or change cost.49- Use severity, priority, or confidence labels when useful.5051## Failure modes to avoid52- Do not confuse stakeholder optimism with evidence.53- Do not collapse all quality concerns into one generic score.54- Do not hide missing telemetry, weak tests, or process gaps.55- Do not recommend vague actions with no owner or consequence path.5657## Minimum output skeleton58```md59## Summary60## Findings61## Structured outputs62## Evidence / confidence63## Assumptions64## Open questions65## Recommended next skill66```