agentic-ai-system-course: Skill for Claude Code

Agentic System Reviewer

Overview

Review the provided docs and code against the course, but only after reconstructing the user's goal, project scope, risk level, and archetype. The review must be course-grounded, scope-aware, and evidence-backed.

Core principle: do not grade a weekend prototype like an enterprise workflow control plane, and do not wave through production autonomy like a toy.

When To Use

Use this skill for:

• PRDs, design docs, implementation plans, or idea files for agentic systems.
• Codebases or diffs implementing agent loops, tools, memory, planning, delegation, connectors, proactive triggers, or self-improvement.
• Requests like "review this against the course", "is this agent design good?", "what chapters does this miss?", "check my PRD/code", or "is this production-ready?"

Do not use this skill for ordinary code review with no agent-system concern. Use the normal code-review workflow for that.

Required Resources

Resolve these paths relative to this SKILL.md. Load only what is needed:

• references/scope-intake.md - mandatory before review.
• references/chapter-rubric.md - mandatory after scope is known; read the relevant chapter rows.
• references/report-template.md - mandatory before writing the final report.
• scripts/suggest-chapters.mjs - optional helper to seed chapter selection from files; never treat it as authoritative.

Review Flow

Follow this order: read provided docs, inspect provided code, write the scope ledger, ask or assume explicitly for material unknowns, select up to 6 primary chapters, open those course files, then write the findings-first report.

Non-Negotiables

1. Read user-provided docs first. If a PRD, plan, README, idea file, issue, transcript, or design note exists, it defines intent until contradicted.
2. If code is provided, read enough of the codebase to understand architecture, boundaries, data flow, and actual behavior. At minimum, inspect the entry point, loop/orchestrator, tool definitions, prompt/context builder, state/memory/persistence files, connectors, and tests/evals when present. If the provided code is under 500 lines, read all of it. Note unread directories or files in the ledger.
3. Establish and record scope before critique. Include project type, users, stakes, archetype, current maturity, and worst plausible mistake.
4. Ask before reviewing when any material unknown touches users, data scope, autonomy, external actions, or production readiness. If the user declines, run an assumption-led review that clearly marks unresolved scope and confidence.
5. Read relevant course chapters before citing them. Naming chapters from memory is not enough.
6. Calibrate rigor. Side projects still need clear loops and tool contracts, but not full multi-tenant ops. Production systems need explicit safety, state, observability, and approval surfaces.
7. Findings must include evidence, course reference, impact, and suggested fix. In the final report, the Findings section precedes Strengths unless there are no issues.
8. If reference systems are cloned under references/ (e.g., OpenCode, Hermes Agent, OpenClaw, Paperclip), use them to ground findings with concrete file:line evidence for the pattern. Do not invent paths for references that are not cloned; describe the pattern from the chapter notes instead.