Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

code-review

Estrelas1

Forks0

Atualizado3 de julho de 2026 às 10:53

Runs a security and quality review checklist over a diff or named files in an isolated forked subagent. Covers injection, secrets, authz/authn, error handling, resource leaks, concurrency, compatibility, test coverage, and hardcoded config. Returns severity-ranked findings with file:line and a blocking/non-blocking/clean verdict. Read-only - never edits code or proposes inline fixes.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

ianshank

ianshank/Agents

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Analistas de garantia de qualidade de software e testadoresInformática e Matemática·SOC 15-1253

Explorador de arquivos

2 arquivos

SKILL.md

readonly

name	code-review
description	Runs a security and quality review checklist over a diff or named files in an isolated forked subagent. Covers injection, secrets, authz/authn, error handling, resource leaks, concurrency, compatibility, test coverage, and hardcoded config. Returns severity-ranked findings with file:line and a blocking/non-blocking/clean verdict. Read-only - never edits code or proposes inline fixes.
when_to_use	Use when the user asks to review changes, audit a diff or PR, or check code for security or quality issues before merge. Not for writing new code or fixing issues.
context	fork
allowed-tools	Read, Grep, Glob

Code Review (Forked, Read-Only)

Review the given diff or files against the checklist below. This skill runs in an isolated fork with read-only tools: do not edit files, do not propose inline patches, do not run commands. Return findings only.

Procedure

Identify the review target: the provided diff, the named files, or (if neither) the files the caller describes. Read each changed file in full, not just hunks — context outside the diff often invalidates or confirms a finding.
Evaluate every item on the checklist against the changed code:
- Injection / input validation: SQL, shell, path, template, deserialization; untrusted input reaching a sink without sanitization.
- Secrets / credentials: keys, tokens, passwords, connection strings committed in code or test fixtures.
- Authz / authn changes: new endpoints or paths that bypass existing checks; weakened permission logic.
- Error handling: swallowed exceptions, fail-open behavior where fail-closed is required (and vice versa), missing error paths.
- Resource leaks: unclosed files, sockets, connections, subscriptions; missing finally/defer/with equivalents.
- Concurrency: shared mutable state, race conditions, missing locks or atomics, deadlock-prone lock ordering.
- Backwards compatibility: changes to public function signatures, wire formats, schemas, CLI flags, or config keys that break existing callers.
- Test coverage: changed behavior with no corresponding test change; tests deleted or weakened.
- Hardcoded values: literals (URLs, ports, timeouts, limits, paths) that belong in config or environment.
For each finding, record: severity (critical / high / medium / low), file:line, a one-sentence defect statement, and a concrete failure scenario (the input or sequence of events that makes it go wrong). No finding without a scenario.
Discard findings you cannot tie to a specific line and scenario. Do not pad the report with style nits unless nothing else was found, and label them as such.

Output

Findings ranked by severity, highest first, in the format: [SEVERITY] file:line — defect statement. Scenario: ...
End with exactly one verdict line:
- Verdict: blocking — at least one critical or high finding.
- Verdict: non-blocking — only medium/low findings.
- Verdict: clean — no findings.
Never include patches, rewritten code, or fix suggestions beyond naming the defect; the caller decides remediation outside the fork.

Mais deste repositório

mesmo repositório

architecture-drift-guard

ianshank/Agents

Detect and block architecture drift in CI by comparing a codebase's actual Python import graph against a declared C4 component model. Use this whenever the user wants to enforce architecture in CI/CD, fail builds on undocumented dependencies, keep C4/Mermaid diagrams in sync with code, set up architecture tests or fitness functions, prevent layering violations, or guard/lint/gate their architecture — even if they don't name C4 or Mermaid explicitly. Also use it to bootstrap an architecture manifest from an existing repo or to remediate a failing drift check.

2026-07-071

eval-corpus-forge

ianshank/Agents

Build, validate, and package reusable evaluation datasets for agent and LLM systems from prompts, traces, tool-call logs, metadata, and expected outcomes. Use this when the user asks to gather eval data, create benchmark datasets, normalize traces, define reusable ground truth, bootstrap eval suites, or produce retrieval, tool-invocation, response, or end-to-end evaluation artifacts.

2026-07-071

model-bench

ianshank/Agents

Benchmark and A/B-test multiple LLMs or systems-under-test on one evaluation dataset. Use this whenever the user wants to compare models side by side, rank candidates by a score, run a multi-model comparison, set up a persistent A/B eval campaign, decide whether a new model is significantly better than a baseline, or produce a comparative HTML/JSON benchmark report.

2026-07-071

openai-judge

ianshank/Agents

LLM-as-a-judge evaluations over OpenAI-compatible APIs (including NVIDIA Nemotron & LM Studio). Use whenever evaluating output quality, correctness, or scoring responses using standard rubrics.

2026-07-071

c4-docs

ianshank/Agents

Generates or updates C4 architecture documentation as Mermaid diagrams in the host repo (docs/architecture/ by default, or the repo's existing docs location). Produces Level 1 context and Level 2 container diagrams, plus Level 3 components only for the subsystem being changed. Updates existing diagrams in place and flags drift between diagrams and code instead of silently rewriting them.

2026-07-031

plan

ianshank/Agents

Instantiates a constraint-programming planning template for a new task, producing a single markdown plan with five sections - objective function, feasible region, permission architecture, feedback loop, and context persistence. All success criteria must be mechanically verifiable (commands, not vibes).

2026-07-031

name	code-review
description	Runs a security and quality review checklist over a diff or named files in an isolated forked subagent. Covers injection, secrets, authz/authn, error handling, resource leaks, concurrency, compatibility, test coverage, and hardcoded config. Returns severity-ranked findings with file:line and a blocking/non-blocking/clean verdict. Read-only - never edits code or proposes inline fixes.
when_to_use	Use when the user asks to review changes, audit a diff or PR, or check code for security or quality issues before merge. Not for writing new code or fixing issues.
context	fork
allowed-tools	Read, Grep, Glob

Code Review (Forked, Read-Only)

Procedure

Identify the review target: the provided diff, the named files, or (if neither) the files the caller describes. Read each changed file in full, not just hunks — context outside the diff often invalidates or confirms a finding.
Evaluate every item on the checklist against the changed code:
- Injection / input validation: SQL, shell, path, template, deserialization; untrusted input reaching a sink without sanitization.
- Secrets / credentials: keys, tokens, passwords, connection strings committed in code or test fixtures.
- Authz / authn changes: new endpoints or paths that bypass existing checks; weakened permission logic.
- Error handling: swallowed exceptions, fail-open behavior where fail-closed is required (and vice versa), missing error paths.
- Resource leaks: unclosed files, sockets, connections, subscriptions; missing finally/defer/with equivalents.
- Concurrency: shared mutable state, race conditions, missing locks or atomics, deadlock-prone lock ordering.
- Backwards compatibility: changes to public function signatures, wire formats, schemas, CLI flags, or config keys that break existing callers.
- Test coverage: changed behavior with no corresponding test change; tests deleted or weakened.
- Hardcoded values: literals (URLs, ports, timeouts, limits, paths) that belong in config or environment.
For each finding, record: severity (critical / high / medium / low), file:line, a one-sentence defect statement, and a concrete failure scenario (the input or sequence of events that makes it go wrong). No finding without a scenario.
Discard findings you cannot tie to a specific line and scenario. Do not pad the report with style nits unless nothing else was found, and label them as such.

Output

Findings ranked by severity, highest first, in the format: [SEVERITY] file:line — defect statement. Scenario: ...
End with exactly one verdict line:
- Verdict: blocking — at least one critical or high finding.
- Verdict: non-blocking — only medium/low findings.
- Verdict: clean — no findings.
Never include patches, rewritten code, or fix suggestions beyond naming the defect; the caller decides remediation outside the fork.