agentleFS
Sign inStart free
nitinjain999nitinjain999/platform-skills/.github/skills/code-review/SKILL.md

code-review

Skill71 starsChanged 8 days agoApache-2.0View on GitHub

Review pull requests to this repo (a Claude Code / Copilot / Cursor platform-engineering skill plugin) for technical accuracy, security posture, structural consistency with existing domains, and completeness. Use this for any PR touching commands/, references/, examples/, skills/platform-skills/SKILL.md, or the plugin catalog files (plugin.json, marketplace.json, COMMANDS.md, HOW_IT_WORKS.md, GETTING_STARTED.md).

We split this skill into the rules it gives an agent

3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 185 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    No wildcard IAM actions ("*") or wildcard resources (Resource: "*") without an explicit justification comment.

    line 16
  2. Very specific:

    Don't recreate a pattern that already has a home elsewhere in this repo (e.g.

    line 28
  3. Distinctive:

    Only after the above are clean: check for premature abstraction, unnecessary refactors of unrelated code, comments that explain *what* …

    line 38

“Common” is measured: kept by at least 6 in 10 of the 185 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

This repo teaches platform engineering patterns (Kubernetes, Terraform, GitHub Actions, AWS, Azure, GitOps, secrets management, and related domains) as slash commands, reference guides, and worked examples. Review every PR against the priorities below, in order — correctness and security outrank style every time.

1. Correctness first

  • Don't take a vendor API, SDK method, config schema, or CLI flag on faith — verify it against the vendor's actual current docs before approving a claim about it. A wrong schema in this repo doesn't just break a build once; every user who copies the example inherits the bug. If the PR can't be independently verified from the diff alone, say so explicitly rather than approving on trust.
  • If a PR claims a behavior ("fails open", "fails closed", "denies", "logs X") for a script or workflow, trace the actual code path rather than trusting the prose describing it. Doc drift between what code does and what a comment/reference says it does is a common, real defect class here — flag it as a correctness issue, not a nitpick.
  • Flag deprecated APIs, deprecated action versions, and end-of-life tool versions by name.

2. Security

  • No wildcard IAM actions ("*") or wildcard resources (Resource: "*") without an explicit justification comment. Push for scoped ARNs and explicit action lists.
  • GitHub Actions: uses: steps pinned to a full commit SHA (not a floating tag) unless the PR explicitly documents why not yet (e.g. "pin before use" on a new example). Least-privilege permissions: blocks — flag a job-level write scope that only one step needs.
  • Any workflow step that interpolates ${{ github.* }} directly into a run: shell block is a template-injection risk — it must be bound to an env: var first and referenced as a quoted shell variable.
  • Secrets: no hardcoded credentials, no logging of raw secret values, and any new audit/log-writing code must state what it excludes (raw command text, tokens, etc.) — silence on this point is a gap, not a default-safe assumption.

3. Structural consistency with this repo's own conventions

New content must match the shape of existing sibling content, not invent a new one:

  • A new commands/<name>.md needs front-matter matching existing commands (name, description, argument-hint, title, sidebar_label, custom_edit_url) and the Q1/Q2 interactive-wizard pattern already used elsewhere.
  • A new command must be registered everywhere the catalog expects it, not just in skills/platform-skills/SKILL.md: .claude-plugin/plugin.json (commands array + keywords), root SKILL.md (must stay byte-identical to skills/platform-skills/SKILL.md), COMMANDS.md, HOW_IT_WORKS.md, GETTING_STARTED.md, and any repo-wide command-count reference (README badge/prose, EDITOR_INTEGRATIONS.md, marketplace.json). Run bash tests/validate-skill.sh and bash tests/handbook-consistency.sh and confirm both are clean before approving — a PR that adds a command but skips this registration sweep is incomplete, not just stylistically off. (This is not a hypothetical: a real PR to this repo shipped a fully-working command that failed exactly this check, caught only by a whole-diff review, not the per-file diff.)
  • A new examples/<domain>/ directory needs a README.md starting with a Status: <Stable|Beta> line, matching sibling example READMEs.
  • Don't recreate a pattern that already has a home elsewhere in this repo (e.g. don't add ad-hoc IAM least-privilege prose inside an unrelated command when references/aws.md/references/azure.md or the IAM section of the top-level CLAUDE.md already own that guidance) — cross-reference it instead.

4. Completeness

  • Every risky or destructive operation documented in this repo needs, at minimum: what it affects, how to verify the change worked, and how to roll it back. A PR introducing a new pattern without a rollback note is missing a required section, not offering an optional nice-to-have.
  • Test/validation claims in a PR description must be checked against what actually ran — "tests pass" without a shown command and output is a claim, not evidence. If the PR touches a script with its own test suite (e.g. anything under examples/*/tests/), confirm that suite is wired into tests/handbook-consistency.sh or an equivalent CI gate, not just runnable by hand.
  • If a script or workflow needs to work across environments (this repo's bash code targets bash 3.2 for macOS compatibility; CI runs on Ubuntu), don't assume a technique that works in the review environment (e.g. hiding a binary via a PATH restriction, or relying on globstar) generalizes — ask whether it's been verified on both, or flag it as unverified.

5. Maintainability

Only after the above are clean: check for premature abstraction, unnecessary refactors of unrelated code, comments that explain what instead of why, and scope creep beyond what the PR's stated purpose requires.

Download now (ZIP)

  • Other versions194 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 194

    1. mattpocock/skills★ 309ksame name
    2. TheAlgorithms/Python★ 226ksame name
    3. microsoft/vscode★ 194ksame name
    4. github/spec-kit★ 145ksame name
    5. ggml-org/llama.cpp★ 133ksame name
    6. shareAI-lab/analysis_claude_code★ 80ksame name
    7. shareAI-lab/learn-claude-code★ 80ksame name
    8. vectorize-io/hindsight★ 57ksame name
    9. dbeaver/dbeaver★ 52ksame name
    10. roboflow/supervision★ 51ksame name

    184 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use add-new-model, azsdk-common-sdk-breaking-change and 9 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • PydanticSkill

      add-new-model

      Add support for a newly-released language or image generation model in pydantic-ai (e.g. openai:gpt-5.6, anthropic:claude-sonnet-5, openai:gpt-image-2). Use when a provider ships a new model id and you need to wire literals, profile flags, adapters, and tests to recognize it. Handles SDK-lag, gateway list conventions, capability probing, and direct image-model geometry.

      Also in 9 projects that use this

    • Microsoft AzureSkill

      azsdk-common-sdk-breaking-change

      Detect and mitigate SDK Breaking changes for an SDK package which is generated from TypeSpec. WHEN: "Detect SDK breaking changes for a service", "Detect SDK breaking changes for an SDK package", "Detect and mitigate SDK breaking changes for a service", "Detect and mitigate SDK breaking changes for an SDK package". INVOKES: skill: azsdk-common-generate-sdk-locally; MCP tools: azure-sdk-mcp:azsdk_customized_code_update, azure-sdk-mcp:azsdk_package_detect_breaking_change.

      Also in 4 projects that use this

    • ww-w-aiSkill

      bkend-auth

      bkend.ai authentication guide. Signup, login, JWT tokens, sessions, role-based access control, and password management with bkend.ai BaaS. Triggers: bkend auth, bkend login, bkend signup, JWT, session, RBAC, password, bkend 인증, 로그인, 회원가입, bkend認証, ログイン, 新規登録, bkend认证, 登录, 注册, autenticacion bkend, authentification bkend, bkend-Auth Do NOT use for: data operations (use $bkend-data), file storage (use $bkend-storage).

      Also in 4 projects that use this

    • ww-w-aiSkill

      bkend-cookbook

      bkend.ai cookbook with step-by-step tutorials and example projects. Build a todo app, blog, e-commerce store, and more with bkend.ai BaaS. Triggers: bkend cookbook, bkend tutorial, bkend example, todo app, blog app, bkend 쿡북, bkend 튜토리얼, 예제 프로젝트, bkendクックブック, チュートリアル, bkend教程, 示例项目, tutorial bkend, tutoriel bkend, bkend-Tutorial, ricettario Do NOT use for: initial setup (use $bkend-quickstart), specific features (use $bkend-data/auth/storage).

      Also in 4 projects that use this

    • dzhngSkill

      close-spec

      When a spec under specs/<feature>/ is done shipping (a write-spec build, or any planned task that produced a spec), archive it to specs/done/ and rewrite it from a build-plan into a durable rationale — the why, the principles, the invariants — pointing back to the real code for the how. Use when implementation has landed and the plan no longer matches what shipped, or the user says a feature/spec is finished. Pairs with [write-spec](../write-spec/SKILL.md) (the plan this closes) and [review](../review/SKILL.md) (run before closing).

      Also in 4 projects that use this

    • dzhngSkill

      design-with-images

      Explore UI and visual design with image generation, then iterate the real implementation against the user-selected concept. Use when brainstorming visual directions, offering mockup variants, or implementing an approved generated design; do not stop at the mockups or the first code approximation.

      Also in 4 projects that use this

    • +5 more from ww-w-ai
  • In this repository59 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free