archetype-review-base
について
これは、すべてのドメイン固有レビュアーが一貫した構造、重大度評価、および判定フォーマットを確保するために実装しなければならない基礎的なレビューフレームワークです。これにより、18種類の異なるレビュアープロンプト間での重複を排除しつつ、ドメイン固有のヒューリスティックと汎用チェックの境界を定義します。このスキルは、リストされているドメイン固有レビュアーを呼び出す際に使用してください。ただし、一般的なクロスドメイン・セキュリティレビューには使用しないでください。
クイックインストール
Claude Code
推奨npx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/archetype-review-baseこのコマンドをClaude Codeにコピー&ペーストしてスキルをインストールします
ドキュメント
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: APPROVEDis allowed only when ALL Critical and ALL High findings have remediation in the bd backlog. (Usebd ready --label {your-archetype}to check.)VERDICT: BLOCKEDis 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 payments | pci-reviewer |
| Oracle staleness, MEV, contract upgradeability | oracle-reviewer |
| PHI flows, BAA chain, FHIR/HL7 | healthcare-reviewer |
| Generic XSS, SQLi, weak hashing, secrets in source | security-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.
GitHub リポジトリ
関連スキル
llamaguard
その他LlamaGuardは、暴力やヘイトスピーチなど6つの安全性カテゴリーにおいて、LLMの入力と出力をモデレートするMetaの70-80億パラメータモデルです。94〜95%の精度を提供し、vLLM、Hugging Face、Amazon SageMakerを使用してデプロイ可能です。このスキルを使用して、AIアプリケーションにコンテンツフィルタリングと安全策を簡単に統合できます。
cost-optimization
その他このClaudeスキルは、リソースの適正サイジング、タグ付け戦略、支出分析を通じて、開発者がクラウドコストを最適化することを支援します。AWS、Azure、GCPにわたるクラウド支出の削減とコストガバナンスの実施のためのフレームワークを提供します。インフラコストの分析、リソースの適正サイジング、または予算制約への対応が必要な際にご利用ください。
quantizing-models-bitsandbytes
その他このスキルは、bitsandbytesを使用してLLMを8ビットまたは4ビット精度に量子化し、精度の低下を最小限に抑えつつ50〜75%のメモリ削減を実現します。限られたGPUメモリでより大規模なモデルを実行したり、推論を高速化するのに理想的で、INT8、NF4、FP4などのフォーマットをサポートしています。HuggingFace Transformersと統合され、QLoRAトレーニングや8ビットオプティマイザーを可能にします。
dispatching-parallel-agents
その他このClaudeスキルは、複数のエージェントを配備し、3つ以上の独立した問題を並行して調査・修正します。共有状態や依存関係がなく解決可能な、無関係な障害が発生するシナリオ向けに設計されています。中核となる機能は並列問題解決であり、効率を最大化するために独立した問題領域ごとに1つのエージェントを割り当てます。
