skills/software-engineering/standards-review/SKILL.md
Review a saved standards document via a one-standard-at-a-time interview. Prompts the user for the file path, parses individual standards, then presents each one for evaluation with concrete options (Accept / Revise / Reject / Defer). Produces a summary report at the end.
npx skillsauth add pantheon-org/tekhne standards-reviewInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Review a set of project standards through a structured, one-at-a-time interview. Each standard is presented individually with actionable options; the user picks one and moves on. Ends with a confirmed recap and a written report.
Every standard should be clear, enforceable, and necessary. If it's not all three, it needs work.
The interview is a triage loop — for each standard, present it, get the user's action, and move on. Do not over-analyse a single standard or extend the interview beyond the user's stated scope.
RULES.md, CONTRIBUTING.md, or similar) and wants to audit themAsk the user for the path to their standards file. Use a single question tool call with the file path as the only question.
Expected file formats, in priority order:
| Format | Parsing rule |
|--------|-------------|
| Markdown (*.md) | Each ## / ### / #### heading block is one standard. If no headings exist, each bullet list item (- / *) is one standard. |
| Plain text | Each non-empty line is one standard. |
Read the file with the Read tool. Parse it into individual standard entries.
If the file has no detectable structure, ask the user how standards are delimited before continuing.
Tell the user how many standards were found and ask if they want to review all of them. If the count is 0, report that no standards were detected and offer to re-parse with a user-specified delimiter.
For each standard, use the question tool to present exactly one question. Never bundle multiple standards or multiple questions into a single call.
Each question must:
question tool).The default option set, which applies to every standard unless the user explicitly requests different criteria:
Collect the answer silently. Do not discuss or debate the user's assessment. Store it internally for the summary.
When the user picks "Other", capture what they said as their desired action. If their free-text answer matches one of the curated options (e.g. "I think we should remove this"), map it to the closest curated label for the summary.
After the last standard has been answered, stop asking questions immediately. Do not ask follow-ups about individual answers, and do not offer to revisit standards unless the user explicitly requests it.
Present a summary table of all standards reviewed:
| # | Standard | Action | Notes |
|---|----------|--------|-------|
| 1 | First standard title... | Accept | |
| 2 | Second standard title... | Revise | needs examples |
| 3 | Third standard title... | Reject | duplicates rule X |
Use a single question call: "Does this recap look right? Any changes before I write the report?" with options:
If the user wants changes, apply them, then re-recap once. Do not loop indefinitely.
After confirmation, produce a review output. Default to writing a .context/findings/ file named standards-review-{file-stem}-{date}.md. If .context/findings/ does not exist, write to .context/ instead, or ask the user where to put it.
The report must include:
# Standards Review: {filename}
**Reviewed:** {date}
**File:** {path}
**Standards found:** {N}
**Actions:** Accept: {X}, Revise: {Y}, Reject: {Z}, Other/Deferred: {W}
## Summary
{One-paragraph overview — key themes, what's healthy, what needs work}
## Detail
### 1. {Standard title or first N chars}
**Text:** {full standard text}
**Action:** {Accept | Revise | Reject | Defer}
**Notes:** {if the user added any}
## Next Steps
- {X} standards to keep — no action needed
- {Y} standards to revise — {list them}
- {Z} standards to reject — {list them, with rationale}
- {W} to discuss further — {list them}
NEVER present more than one standard per question turn. This is the core constraint of the skill — one standard, one question, one turn.
NEVER skip the recap and confirmation. Without it, the user has no chance to correct misinterpretations before the report is written.
NEVER make up assessment criteria that the user didn't agree to. The default option set (Accept/Revise/Reject/Other) applies; if the user wants different criteria, they will use the free-text path.
NEVER debate the user's assessment. The review captures their judgement, not the agent's opinion. If a standard is plainly contradictory or impossible, you may note it in the report's summary section, but do not argue during the interview.
NEVER ask about the same standard twice. Once assessed, that standard is closed.
NEVER bundle an evaluation question with a follow-up (e.g., "Accept or Revise, and also tell me why"). Let the user answer the action question first; if they volunteer notes in their answer, capture them. If not, move on.
tools
A skill that produces warnings but no errors.
testing
A well-formed example skill for testing the validator.
development
A skill with code blocks and imperative instructions for testing content and contamination analysis.
tools