From formspec-specs
Use when the user asks to review code changes, a PR, a diff, or a patch. Apply a semi-formal review workflow: explore methodically, ground claims in file:line evidence, trace callers/callees and tests, and produce a structured findings-first review.
How this skill is triggered — by the user, by Claude, or both
Slash command
/formspec-specs:semi-formal-code-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill when the user asks for a review of code changes.
Use this skill when the user asks for a review of code changes.
This skill is informed by Agentic Code Reasoning by Shubham Ugare and Satish Chandra (arXiv:2603.01896v2, March 4, 2026), bundled locally as Agentic Code Reasoning - arXiv 2603.01896v2.pdf.
The paper does not publish this exact code-review workflow, but it does support the underlying method: semi-formal, evidence-first reasoning with explicit traces, data flow, semantic properties, and formal conclusions. This skill is a stricter code-review adaptation of that method.
Activate when the user asks for a review of changes against a codebase, for example:
Do not activate for general code questions or implementation help.
Determine what to review from the user request:
git diff <base>...<head>.git diff --cached.git diff.git show <commit> or git diff <commit1>..<commit2>.If the user does not specify a scope, inspect uncommitted changes first.
Use lightweight structured notes while exploring.
Before reading a file:
HYPOTHESIS H[N]: [What you expect to find and why]
EVIDENCE: [What from the diff or previously read files motivates this]
CONFIDENCE: high | medium | low
After reading a file:
OBSERVATIONS from [filename]:
O[N]: [Key observation, with line numbers]
HYPOTHESIS UPDATE:
H[N]: CONFIRMED | REFUTED | REFINED - [explanation]
UNRESOLVED:
- [Remaining questions]
- [Other files/functions to examine]
NEXT ACTION RATIONALE: [Why read another file, or why enough evidence exists]
During exploration:
Produce a structured findings-first review with these sections.
State:
none foundInclude a trace table for every touched or behavior-critical function:
| Function / Method | File:Line | Parameters / Inputs | Return / Output | Verified Behavior |
| --- | --- | --- | --- | --- |
| ... | ... | ... | ... | ... |
For each key variable or state transition introduced or modified by the patch, note:
Also list semantic properties or invariants the patch relies on, with evidence and what would break them.
For each relevant test:
For edge cases, enumerate only concrete scenarios that are plausible from the code or exercised by tests. State:
If no tests cover the changed path, say so explicitly.
Each finding should include:
FINDING [N]:
Severity: BLOCKER | WARNING | NIT | OBSERVATION
Category: correctness | performance | security | maintainability | test-coverage
Location: [file:line]
Description: [concise description]
Evidence chain: [premise/observation/trace that supports the finding]
Suggestion: [concrete fix or next step, if applicable]
Order findings by severity. Prioritize behavioral regressions, correctness bugs, broken assumptions, and missing test coverage over style concerns.
End with:
VERDICT: APPROVE | REQUEST CHANGES | NEEDS DISCUSSION
Justification:
- The patch [does / does not] achieve its stated intent because [evidence]
- Coverage of changed paths: ADEQUATE | INSUFFICIENT
- Confidence: HIGH | MEDIUM | LOW
Use up to 100 tool-use steps. Aim for 20 to 40 on typical reviews, and spend more when patches touch shared utilities, cross module boundaries, or error-handling behavior.
npx claudepluginhub mikewolfd/formspec --plugin formspec-specsProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.