agentleFS
Sign inStart free
PowerShellPowerShell/DSC/.github/skills/code-review/SKILL.md

code-review

Skill540 starsChanged 12 months agoMITView on GitHub

Repository-specific code review guidance for DSC (Rust, PowerShell/Pester, JSON)

We split this skill into the rules it gives an agent

10 rules. 0 are common, 7 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 184 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use the path-based mapping below to determine which area instructions apply to the files under review.

    line 12
  2. Distinctive:

    Intentional design decisions: When maintainers explicitly label behavior as "intentional", do not re-flag.

    line 45
  3. Distinctive:

    Extract repetitive code into helper functions: When the same logic appears in multiple places, flag it and suggest extracting a shared …

    line 46
  4. Distinctive:

    Accurate comments: If code behavior changes, update comments to match.

    line 50
  5. Distinctive:

    Doc comments matching implementation: Update when described behavior doesn't match reality.

    line 52
  6. Very specific:

    Remove debug print statements: Do not use println! for debugging -- use debug!/trace!

    line 53
  7. Very specific:

    Use rust-i18n with the t! macro: All user-facing strings in Rust code must use the t!

    line 58
  8. Distinctive:

    Locale key accuracy: Verify key names match the keyword/function they describe.

    line 60
  9. Distinctive:

    No dead locale strings: Do not add i18n keys that are never referenced in code.

    line 61
  10. Very specific:

    Check control flow, not just syntax: Verify if: always(), continue-on-error, and needs/stage dependencies match stated failure behavior.

    line 67

“Common” is measured: kept by at least 6 in 10 of the 184 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

Code Review Instructions for DSC Repository

These instructions guide Copilot when performing code reviews on pull requests in this repository. Focus on high-confidence, actionable findings. Do not comment on style, formatting, or trivial issues.

Detailed review guidance is split by contribution area in .github/skills/code-review/. Use the path-based mapping below to determine which area instructions apply to the files under review.

Area Routing

Paths in this table are relative to the root of the repo, not this SKILL.md file.

AreaPathsInstruction File
Enginelib/dsc-lib/src/configure/, lib/dsc-lib/src/discovery/, lib/dsc-lib/src/dscresources/, lib/dsc-lib/src/functions/, lib/dsc-lib/src/settings/skills/code-review/engine.instructions.md
Resourcesresources/skills/code-review/resource.instructions.md
Adaptersadapters/skills/code-review/adapter.instructions.md
Extensionsextensions/, lib/dsc-lib/src/extensions/skills/code-review/extension.instructions.md
CLIdsc/src/skills/code-review/cli.instructions.md
Tests**/*.tests.ps1, **/tests/, **/test/, **/Tests/skills/code-review/tests.instructions.md
Librarieslib/skills/code-review/library.instructions.md
Securitylib/dsc-lib/src/util.rs, lib/dsc-lib-security_context/, lib/dsc-lib-registry/, resources/registry/, resources/windows_firewall/, resources/windows_service/, resources/dism_dsc/skills/code-review/security.instructions.md
PerformanceAny *.rs file in hot pathsskills/code-review/performance.instructions.md
Windowsresources/windows_*, resources/dism_dsc/, resources/registry/, lib/dsc-lib-registry/, lib/dsc-lib-pal/skills/code-review/windows.instructions.md
Linux/macOSresources/apt/, resources/sshdconfig/, resources/brew/, lib/dsc-lib-pal/skills/code-review/linux.instructions.md

Multiple areas may apply to a single file. For example, resources/windows_firewall/ triggers both the Resource, Windows, and Security instructions.

General Principles (False-Positive Avoidance)

These apply to ALL areas:

  • Do not claim code will not compile unless you can cite a specific rule violation: Avoid speculative "this won't compile" claims about Rust ownership/borrowing. Only flag compile errors when you can point to a concrete language rule being violated.
  • Test resources are not production code: Code in tools/dsctest/ is for testing only and is never user-facing. Do not require production-grade error handling in test harnesses unless panics would hide regressions.
  • Automatically-generated files: Files like lib/dsc-lib-jsonschema/.versions.json are updated by build automation. Do not flag version bumps as unintentional.
  • Do not demand large abstractions in small PRs: Suggest extracting a helper function. Do not block a focused PR by requesting trait/framework redesigns -- that is follow-up work.
  • Table output is not a stable API: JSON/YAML are canonical machine-readable outputs. Table layout changes are not breaking.
  • Separate input/output structs can be intentional: Resources often distinguish desired state from observed state. Do not assume duplicate structs are accidental.
  • Intentional design decisions: When maintainers explicitly label behavior as "intentional", do not re-flag.
  • Extract repetitive code into helper functions: When the same logic appears in multiple places, flag it and suggest extracting a shared helper function to reduce duplication and improve maintainability.

Documentation and Logging (All Areas)

  • Accurate comments: If code behavior changes, update comments to match.
  • Log level appropriateness: Full PATH contents at trace!, not debug!. Never log secrets.
  • Doc comments matching implementation: Update when described behavior doesn't match reality.
  • Remove debug print statements: Do not use println! for debugging -- use debug!/trace! macros. Note that println! is acceptable for intentional CLI user-facing output.
  • Prefer scan-friendly wording: Log/error strings should be concise for readability in diagnostics.

Internationalization (All Rust Code)

  • Use rust-i18n with the t! macro: All user-facing strings in Rust code must use the t! macro from the rust-i18n crate. Do not hard-code English strings in source files.
  • Strings go in en-us.toml: Localized text must be defined in the en-us.toml locale file, not inline in Rust source.
  • Locale key accuracy: Verify key names match the keyword/function they describe.
  • No dead locale strings: Do not add i18n keys that are never referenced in code.

CI/CD (All Areas)

  • Fork permission limitations: Steps posting PR comments should gate on same-repo PRs or use continue-on-error: true.
  • Conditional tool installation: Install expensive tools only after determining the PR needs them.
  • Check control flow, not just syntax: Verify if: always(), continue-on-error, and needs/stage dependencies match stated failure behavior.
  • Preserve downstream artifact contracts: Flag changes to artifact names/paths when downstream jobs expect the old layout.
  • PowerShell conventions: Singular function names (Test-RustProject). Build failures should throw.

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/learn-claude-code★ 80ksame name
    7. shareAI-lab/analysis_claude_code★ 78ksame 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 repository3 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.

Reviews can't be read right now.

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