Claude
Skill
code-review
Review PR, branch, commit or working-tree changes for concrete defects and fidelity to intended behavior. Also use when explicitly asked to independently challenge a prepared plan, diagnosis or verification claim.
Virus-scanned
Reviewed automatically before listing.
Download
sgaabdu4-building-flutter-apps-.agents_skills_code-review-c396097.zip · 2 KB
Install
skills CLI
npx skills add https://github.com/sgaabdu4/building-flutter-apps/tree/main/.agents/skills/code-review
Claude Code
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install sgaabdu4-building-flutter-apps@llmmart
Git
git clone https://github.com/sgaabdu4/building-flutter-apps.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole sgaabdu4/building-flutter-apps collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Code Review
Load the review method; load the independent-challenge branch only when requested.
flowchart LR R[references/review.md] -->|Independent / adversarial review requested| C[references/challenge.md] click R "references/review.md" click C "references/challenge.md"
Files (building-flutter-apps)
-
agents
-
openai.yaml 265 B
interface: display_name: "Code Review" short_description: "Review diffs against standards and behavior" default_prompt: "Use $code-review to review these changes against their intended behavior and repository rules." policy: allow_implicit_invocation: true
-
-
references
-
challenge.md 1.3 KB
# Independent challenge Apply only to an explicitly requested independent/adversarial review. Use an available separate reviewer within existing authorization; no fixed provider, model or custom runner. If independence cannot be provided, report that limit rather than label a self-review independent. - Brief = accepted outcome + exact artifact/revision + constraints + owner/caller pointers + actual proof + unknowns. Provide enough context to test claims; omit author identity, previous verdicts and rebuttals that could bias the reviewer. - Assignment = inspect without editing; reconstruct the intended outcome and try to disprove material claims. Seek a competing cause, missed caller, boundary/retry failure, weak test or simpler existing owner where relevant. Use the shared finding format; no mandatory checklist of unrelated concerns. - Host = verify returned findings against source and, where useful, the cheapest discriminating check. Reviewer confidence and consensus are not proof. Only verified findings enter the defect list; preserve consequential unknowns as verification gaps. ```mermaid flowchart LR F[Reviewer finding] --> V{Host evidence} V -->|Proves failure| K[Keep finding] V -->|Disproves failure| D[Discard finding] V -->|Insufficient| U[State missing evidence + next check] ``` -
review.md 1.7 KB
# Review method - Target = identify the requested artifact + comparison base. Use the supplied PR/base; otherwise resolve the branch's intended target from repository evidence. Upstream tracking alone may identify the same branch, not its merge target. Unclear scope → state the gap before drawing conclusions. - Diff = read full hunks + affected owners/callers. Branch/PR → cumulative diff against its merge-base; commit → requested patch; working tree → staged + unstaged + in-scope untracked files. Include local changes in a branch review only when in scope. Empty diff → no changes to review, not a failed review. - Intent = compare against the user's request and supplied/linked requirements. Check missing behavior, changed contracts + unsupported additions. Missing requirements → state that limit; do not infer intent from the implementation itself. - Claims = trace the failure scenario through actual data, state, permissions, ordering or callers. For plans/diagnoses/proof, separate proposed behavior from implemented behavior and claimed results from observed results. - Tests = apply [Test design + quality](../../he/references/testing.md) to affected tests and claimed proof. Passing gates do not establish requirement coverage, realistic UI behavior or deployed success. - Finding = precise location + code/evidence fact + triggering condition + concrete impact + smallest useful correction. Rank by impact and likelihood. Remove preference-only, duplicate, speculative and already-disproved candidates; an unresolved question is not a confirmed defect. - Result = actionable findings first, then material coverage limits + unverified checks. No findings → say so without implying unperformed verification or approval of unknown behavior.
-
-
SKILL.md 551 B
--- name: code-review description: Review PR, branch, commit or working-tree changes for concrete defects and fidelity to intended behavior. Also use when explicitly asked to independently challenge a prepared plan, diagnosis or verification claim. --- # Code Review Load the review method; load the independent-challenge branch only when requested. ```mermaid flowchart LR R[references/review.md] -->|Independent / adversarial review requested| C[references/challenge.md] click R "references/review.md" click C "references/challenge.md" ```
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.