MCP HubMCP Hub
Retour aux compétences

archetype-review-base

avelikiy
Mis à jour 2 days ago
3 vues
30
6
30
Voir sur GitHub
Autreai

À propos

Il s'agit d'un cadre d'examen fondamental que tous les examinateurs spécifiques à un domaine doivent mettre en œuvre pour garantir une structure cohérente, des évaluations de sévérité uniformes et un formatage des verdicts standardisé. Il définit la frontière entre les heuristiques spécifiques au domaine et les vérifications génériques, éliminant ainsi les doublons parmi les 18 invites d'examen différentes. Utilisez cette compétence chaque fois que vous invoquez un examinateur de domaine listé, mais pas pour les revues de sécurité générales inter-domaines.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add avelikiy/great_cto -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/avelikiy/great_cto
Git CloneAlternatif
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/archetype-review-base

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

Archetype-review-base — shared review framework

Every domain reviewer follows this skeleton. Each reviewer's own SKILL.md adds the domain heuristics on top. This skill defines the parts that must be IDENTICAL across all reviewers.

Mandatory report sections

A domain review report is a markdown file at docs/reviews/REVIEW-{slug}-{reviewer}.md. It MUST contain these sections in this exact order:

# REVIEW-{slug} — {reviewer name}

Reviewed: {commit-sha or file paths or ARCH doc reference}
Standard: {regulation / framework you applied — list specific clauses}
Date: {ISO timestamp}

## Scope

2-3 sentences. What did you look at? What's intentionally out of scope?

## Findings

For each finding, use this exact format:

- **[Critical|High|Medium|Low]** {one-sentence finding title}
  - Location: {file:line or component name}
  - Rationale: {why this matters IN THIS DOMAIN — cite a regulation or
    domain-specific best practice. Generic "could be a problem" is
    rejected.}
  - Remediation: {specific fix — code change, config change, or
    architectural change. NOT "consider adding X" — write the exact change.}
  - References: {URL or document section}

Order findings: Critical → High → Medium → Low.
If no findings at a tier, write: "_None at {tier} severity._"

## Verdict

VERDICT: {APPROVED|BLOCKED} reason="{specific reason}"

Severity scale (DOMAIN-anchored)

Severity is graded against THIS DOMAIN's regulatory or correctness baseline, not generic STRIDE severity. Examples:

  • A PCI reviewer rating an unencrypted PAN at REST = Critical (PCI scope violation; immediate regulatory exposure)
  • An oracle reviewer rating a Chainlink staleness < 1h = High (likely OK now, MEV vulnerable in stress)
  • A gov reviewer rating Section 508 a11y gaps = High (federal contract risk; not Critical because not an immediate breach)

Cite the standard in Rationale. If you can't, the finding is probably generic and should be reduced one severity tier (the security-officer agent handles generic concerns).

Verdict rules

  • VERDICT: APPROVED is allowed only when ALL Critical and ALL High findings have remediation in the bd backlog. (Use bd ready --label {your-archetype} to check.)
  • VERDICT: BLOCKED is required when even one Critical or High has no remediation, OR when discovery surfaced an unknown that you couldn't resolve.
  • Medium and Low findings do NOT block. Note them; pipeline continues.

Domain heuristic vs generic check

You are the SPECIALIST. Your job is the domain-specific stuff that generic STRIDE / OWASP misses. Decision rule:

The check is about…Belongs to
Card data, PCI scope, idempotency in paymentspci-reviewer
Oracle staleness, MEV, contract upgradeabilityoracle-reviewer
PHI flows, BAA chain, FHIR/HL7healthcare-reviewer
Generic XSS, SQLi, weak hashing, secrets in sourcesecurity-officer (NOT you)
Generic "needs error handling"senior-dev / code-reviewer (NOT you)

If a finding is generic, mention it briefly but DON'T inflate severity. Defer to the appropriate generic reviewer.

Apply skeptical-triage

Before emitting VERDICT: BLOCKED, apply the skeptical-triage skill (3 rounds of self-challenge). False-positive BLOCKED at gate:plan wastes CTO time. Only block when 3/3 rounds confirm.

Verdict log line

After writing your report, append ONE line to your verdict log:

{ISO-ts} {APPROVED|BLOCKED} feature={slug} review=docs/reviews/REVIEW-{slug}-{reviewer}.md criticals={N} highs={M} mediums={K} cost=${USD}

The board's readVerdicts() parser anchors on the leading timestamp. Format MUST be space-separated; pipe-separated form parses as verdict='|' and breaks the pipeline status display.

Prose rules — apply skill prose-style

  • No hedge words ("generally", "somewhat", "maybe")
  • Lead with the conclusion
  • Concrete evidence (file:line) over adjectives
  • No filler openings ("In this review, we will...")
  • Verdict line on the LAST line of the report

When to escalate vs review

Escalate to security-officer (not just BLOCK) when:

  • The finding crosses your domain boundary (e.g. PCI reviewer hits a generic SQLi — that's security-officer's job)
  • A regulatory question is ambiguous (e.g. "is this BA or sub-processor under HIPAA?")
  • The user has provided conflicting requirements (BLOCKED on contradictions, not on your domain expertise)

Escalation: create a bd task with label security-officer and blocks your review verdict.

Self-test before sign-off

Before writing your verdict line, grep your draft for:

  • \b(generally|somewhat|fairly|mostly|possibly|perhaps|maybe)\b — rewrite
  • Any finding without a Location line — fix
  • Any finding without Remediation as a SPECIFIC change — fix
  • Any Critical/High without remediation-in-bd — flip to BLOCKED

If any check fires in a non-quoted block, fix before signing off.

Dépôt GitHub

avelikiy/great_cto
Chemin: skills/archetype-review-base
0
agentic-codingclaude-code-pluginclaude-code-skillsclaude-code-subagentscode-reviewcto

Compétences associées

llamaguard

Autre

LlamaGuard est le modèle de Meta, doté de 7 à 8 milliards de paramètres, conçu pour modérer les entrées et sorties des LLM selon six catégories de sécurité comme la violence et les discours haineux. Il offre une précision de 94 à 95 % et peut être déployé avec vLLM, Hugging Face ou Amazon SageMaker. Utilisez cette compétence pour intégrer facilement le filtrage de contenu et des garde-fous de sécurité dans vos applications d'IA.

Voir la compétence

cost-optimization

Autre

Cette compétence de Claude aide les développeurs à optimiser les coûts du cloud grâce au redimensionnement des ressources, aux stratégies d'étiquetage et à l'analyse des dépenses. Elle fournit un cadre pour réduire les dépenses cloud et mettre en œuvre une gouvernance des coûts sur AWS, Azure et GCP. Utilisez-la lorsque vous devez analyser les coûts d'infrastructure, redimensionner les ressources ou respecter des contraintes budgétaires.

Voir la compétence

quantizing-models-bitsandbytes

Autre

Cette compétence quantifie les LLMs en précision 8 bits ou 4 bits à l'aide de bitsandbytes, permettant une réduction de 50 à 75 % de la mémoire utilisée avec une perte de précision minime. Elle est idéale pour exécuter des modèles plus volumineux sur une mémoire GPU limitée ou pour accélérer l'inférence, prenant en charge des formats comme INT8, NF4 et FP4. La compétence s'intègre à HuggingFace Transformers et permet l'entraînement QLoRA ainsi que l'utilisation d'optimiseurs en 8 bits.

Voir la compétence

dispatching-parallel-agents

Autre

Cette compétence Claude déploie plusieurs agents pour enquêter et résoudre simultanément 3 problèmes indépendants ou plus. Elle est conçue pour des scénarios impliquant des défaillances non liées qui peuvent être résolues sans état partagé ni dépendances. La capacité fondamentale est la résolution de problèmes en parallèle, en assignant un agent par domaine problématique indépendant afin de maximiser l'efficacité.

Voir la compétence