I made Claude smarter by writing it a letter

Tech/process summary (what the video is about)

The creator describes a workflow for “making Claude/agents smarter” by maintaining and tuning custom agent instructions (e.g., agents.md / Claude.md) along with skill prompts that control agent behavior across many development machines and tooling “harnesses.”

The central theme is that the biggest productivity gain isn’t raw coding ability—it’s improved communication quality: clear PRs, better plans, correct tool usage, less “slop,” and safer multi-machine execution.

They also demonstrate supporting infrastructure and automation patterns, including:

• Review-bot aware PR monitoring
• Fleet synchronization across machines
• Model-history auditing to detect failure modes
• Skills for generating/storing HTML artifacts and uploading files for PR embedding

---

Key product/features & workflow concepts

1) Multi-machine dev orchestration (“fleet”)

• Uses T3 Code to run work across multiple machines and manage diffs / task placement (which machine executes what).
• Maintains a fleet repo consisting of markdown files plus a forked vibe-proxy to adjust the CLI proxy API for personal needs.
• Defines machine-specific “skills” visibility via metadata (e.g., core agents, machine leader skill, universal skills).

Goal: avoid buggy custom systems; leverage T3 Code’s multi-machine support + markdown-driven configuration.

---

2) Tuning global agents.md / Claude.md (behavior control)

They compare an older agents.md / Claude.md to a newer version and explain that these instructions strongly influence agent outcomes across models.

Major instruction themes include:

• Type safety & TypeScript quality
  • Avoid “Python-like” TypeScript
  • Avoid unsafe casting one-liners
  • Prefer “good TS” conventions
• Verification-first
  • Run targeted lint/typecheck before broader builds/tests
• Safety controls (“blast radius”)
  • Prefer targeted actions
  • Avoid destructive steps unless explicitly requested
• Tests discipline
  • Use good regression/feature tests
  • Avoid expensive “endless smoke tests”
• Less chatter / fewer unnecessary code changes
  • Add lines that reduce over-proactivity in certain models
  • Treat questions as read-only
• Agent orchestration rules
  • Don’t spawn multi-agent panels or sub-agents for single-pass tasks
  • State file ownership up front to prevent colliding edits

---

3) Skills as modular tools (PRs, monitoring, file uploads, HTML docs)

They maintain multiple skills that agents can “trigger” via keywords embedded in the skill description.

Core principle: skill “description” is a trigger, not an explanation

They emphasize that the skill description should contain magic trigger keywords for when a model should pull in the skill—rather than trying to describe everything the skill does.

---

PR-related skills

1. file/open/create a PR skill

   • Trigger: “file/open/create a PR.”
   • Split from “babysitting” to improve trigger accuracy.
   • Includes guidance for good PR titles/descriptions:
     • Avoid nonsense titles
     • Include a clear problem summary + solution
     • Avoid implementation inventories
   • Instructs: no draft PRs, because review bots won’t run on drafts.

2. babysit PR skill (review-bot aware monitoring loop)

   • Purpose: keep PRs fresh by handling rebases/updates, reacting to comments, and looping until the PR is green.
   • “Review bot hygiene” rules:
     • Use PR checks/tools (if available) to monitor comment arrival
     • Only act on newer comments/checks after the latest push
     • Verify findings against source before changing code
     • Distinguish repo failures vs infra flakes; provide written reasons when dismissing false positives
     • If an “overriding PR” makes the PR obsolete, stop monitoring and ask before closing
     • Reply formatting: send responses “on Theo’s behalf” including model/harness context

---

File upload skill (R2 hosting + PR embedding)

• Custom skill uploads arbitrary local files (screenshots, recordings, logs, artifacts) to a public file host and returns a URL.
• Includes:
  • Authentication via token requirements
  • Slugified naming + random suffixing
  • Guidance for embedding URLs in PRs so agents don’t use hacky video-attachment approaches
• Real benefit: improves communication by letting the agent provide clickable recordings the user can access.

---

HTML communication skill (PostPlan / readable artifacts)

Creates an HTML communication skill so agents produce human-readable HTML documents (plans/specs/reports/UI mocks) and upload them to a service (PostPlan).

Key behavior constraints:

• Don’t open HTML in a browser; instead fetch with shell after upload succeeds
• Enforce a single capped HTML file size limit
• Use “read-only” prompt mapping:
  • avoid conflating product HTML vs communication HTML

Later, they plan to split the overloaded HTML skill into:

• postplan read (trigger when the user provides a PostPlan URL)
• HTML communication (trigger when the user asks for HTML writeups)

---

Model auditing & failure-mode analysis (how they “made it smarter”)

A major technical section focuses on learning from history:

• They run audits across multiple models/harnesses (e.g., “Opus 5”, “Fable”, etc.) and generate stats such as:
  • corrections per 100 user messages
  • frequency of PR hygiene issues (e.g., filing drafts)
  • process-killing mistakes (killing the wrong processes)
  • tool misuse categories
  • stopping-early vs regression vs overbuild behavior
  • bash error rates

Observed failure patterns include:

• Some models were over-aggressive, causing environment damage (e.g., wrong process kills, tool misuse).
• Some models repeatedly filed draft PRs.
• Some models triggered expensive overbuild / unnecessary checks.
• Some models made unasked edits to global files; auditing revealed this and led to guardrails.

Outcome: update agent instructions and skills to steer away from the worst failure modes.

---

Engineering “cross-surface” correctness (web/desktop/mobile)

They add repo-specific contribution rules for T3 Code contributors:

• Common defect: changes applied only to the surface the contributor tested.
• They emphasize a checklist mindset:
  • before finishing, walk through entry points for each client:
    • web UI
    • desktop
    • mobile
    • shared package vs provider adapters
    • docs updates
• They stress separation of concerns:
  • complexity belongs in the adapter boundary
  • orchestration stays pure
  • UI stays dumb

They also call out architectural packages (conceptually), including:

• contracts: defines data/messages crossing the websocket/HTTP boundary; changes may fail to reflect if not kept in sync—so they add instructions to maintain alignment.

Also included: instructions to avoid doc leakage.

• Split user docs vs maintainer/internal docs, because models sometimes include internal details in user-facing docs.

---

Review of communication quality (not just code quality)

The creator explicitly states the purpose of the work:

Not to “make the model better at writing code,” but to make it better at communicating with them and other maintainers.

The skills and PR-description templates help generate:

• clearer updates
• useful context for humans
• fewer PRs that balloon in size or become unreadable

---

Mentions of sponsors / external platforms

• Work OS: agent platform/admin features (SSO/SAML/AD integrations; agents building on behalf of users; admin portal setup burden)
• Convex: backend/product platform for T3 Chat; includes benefits like syncing data, preview PRs, access controls, described as a “cloud code plugin”

(These are sponsor inserts and not core to the creator’s agent configuration system.)

---

Main speakers / sources

• Main speaker: the YouTuber/creator (speaking in first person)
• Referenced external people/teams:
  • Theo (used as an identity in agent instructions / “Theo’s behalf” in PR formatting)
  • Julius (mentioned as writing T3 Code skills / contributor context)
  • Anthropic (referenced regarding Claude; also “Thor” as the person who provided/introduced the HTML planning skill)
  • Opus/Codex (mentioned as harness/model behavior sources)
  • Work OS and Convex (sponsors)