Philosophy first: why discipline beats raw capability

This course is a tour through the workflows and skills packed into scott-cc, a Claude Code plugin built up over dozens of real engineering sessions. Most of what's in there is self-explanatory — a persona agent named frontend-architect does roughly what it sounds like, a doc-lookup skill named context7 does roughly what it sounds like. This course skips those. What it covers instead is the smaller set of skills and agents that encode a genuinely non-obvious judgment call — the kind of decision a competent engineer might still get wrong by default, because the wrong version looks reasonable right up until it isn't.

It starts here, with philosophy, on purpose. Every mechanism in the later lessons — the review panel's validation gates, the epic planner's checkpoint files, the mutation-testing pipeline — is an implementation of a small set of convictions about what makes an AI coding agent trustworthy instead of merely fast. If you don't understand the convictions first, the mechanisms read as arbitrary process. Understand the convictions, and the mechanisms read as the obvious consequence of taking them seriously.

This lesson pulls that philosophy directly from two sources: scott-cc's own root CLAUDE.md, which states its priorities in plain language, and the karpathy-guidelines skill, which operationalizes them as a behavioral floor every other skill sits on top of.

Plausible is not the same as correct

Left to its own defaults, an AI coding agent optimizes for producing code that looks like it satisfies the request. That's not a criticism of any particular model — it's a structural fact about the task. Generating a plausible-looking diff is fast and cheap; confirming that diff actually does what was asked is slower and requires more deliberate effort. Without an explicit counter-pressure, the fast and cheap option wins by default, every time, because nothing in the interaction forces the slower option to happen instead.

scott-cc's CLAUDE.md names this directly by stating an explicit priority order: quality, simplicity, robustness, scalability, and long-term maintainability — over development cost. Read that list carefully and notice what it's actually claiming. It isn't saying quality is free. It's saying quality is worth paying for, even when the payment is slower iteration and more back-and-forth than a quality-blind approach would need. That's a real tradeoff, stated as a tradeoff, not dressed up as a win-win.

The practical effect is a standing instruction to resist the fast/plausible shortcut wherever it shows up — and it shows up constantly, in dozens of small decisions per session: whether to actually run the failing test or just reason about why it should now pass, whether to open the rendered UI or just trust that the CSS change looks right, whether to trace an error to its root cause or pattern-match a fix from the stack trace. Every lesson after this one is a specific mechanism for winning one of those small decisions on purpose, instead of by accident.

The single clearest tactical rule

If the whole philosophy had to compress into one instruction, it would be this: reproduce bugs end-to-end before attempting a fix. That ordering matters more than it looks like it should. Reproducing a bug first means you've watched the actual failure happen, in front of you, with the actual inputs that trigger it. Fixing based on a stack trace alone means you've inferred a plausible cause and are betting the fix addresses it — which is exactly the fast/plausible shortcut the default failure mode describes, just wearing a debugging costume instead of a feature-implementation one.

The same discipline extends past bug fixes into ordinary maintenance: lint and test issues encountered mid-task get fixed even when they're unrelated to the task at hand, rather than stepped around. And for UI work specifically, the standard is "obsessed with pixel perfection" — meaning visual review against the actual rendered output, not a mental simulation of what the CSS change should produce. All three rules share the same shape: don't let a plausible mental model substitute for looking at the real thing.

A layer everything else stands on

karpathy-guidelines is the foundational behavioral-principles skill that everything else in scott-cc sits on top of: think before coding, make minimal and surgical changes, execute against a stated goal rather than a vague sense of the task. None of those instructions are individually novel — you've heard some version of "think before you code" before. What's notable is where this skill sits architecturally, not what it says.

The context-file-optimizer skill, covered in the next lesson, references karpathy-guidelines by name in its own "Principle Hierarchy" — specifically as the layer a project's CLAUDE.md doesn't need to restate, because the behavioral floor is already loaded by the skill itself. That's a deliberate layering decision: put durable, project-independent behavioral principles in one shared skill, load it once, and let every project-level context file skip re-explaining what's already covered. It's a small design choice with a large payoff, and it's the first hint of a theme this whole course keeps returning to — where you put a piece of guidance changes what it costs you every time an agent starts a session.

Preferences that are actually protections

scott-cc's CLI tool-preference table — rg over grep, fd over find, bat over cat — reads, at first glance, like ordinary style preference. So does the direnv-only rule for secrets, the Makefile-only rule for service lifecycle, the ban on default ports, and the uv-only rule for Python dependencies. It's tempting to file all of this under "one engineer's taste" and relax it when it's inconvenient.

That reading misses the point. Each of these rules closes off a specific, concrete way an agent can degrade a shared environment. Direnv-only secrets storage means an API key never ends up committed to git history or leaked into shell history through an inline export. Makefile-only service lifecycle means services stay properly detached and don't silently block a terminal an agent needs back. Non-default ports mean a dev server started for one project doesn't collide with a dev server already running for another, on a machine where several projects run at once. Uv-only dependency management means a project never drifts into the specific, hard-to-diagnose failure mode where pip and poetry and conda have each partially installed a different version of the same package.

Reframed that way, the table isn't a taste preference at all — it's a list of failure modes with a rule attached to each one. That reframe is the actual skill: reading a guideline and asking what specific problem it prevents, not just what it asks you to do differently.

The why, before the how

Everything in this lesson traces back to one conviction: an AI coding agent's default behavior optimizes for looking done, not for being right, and closing that gap takes deliberate, named countermeasures rather than vague encouragement to "be careful." scott-cc states its priorities explicitly, gives a concrete ordering rule for bug fixes, layers a shared behavioral floor underneath every project, and reframes its tool preferences as guardrails against specific failures rather than taste.

Every lesson from here forward is this same conviction, expressed as an actual mechanism instead of a stated principle — a skill, an agent, an orchestration pattern you can point to and inspect. This lesson was the why. The rest of the course is the how, starting with the most basic mechanism of all: what actually ends up loaded into an agent's context window, and when.