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.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download sgaabdu4-building-flutter-apps-.agents_skills_code-review-c396097.zip · 2 KB
Part of sgaabdu4/building-flutter-apps — 14 skills

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.

No comments yet.

Reviews (0)

No reviews yet.

Related