← back to Bcherny Scout

SKILL.md

123 lines

---
name: bcherny-scout
description: Scout what Boris Cherny (@bcherny on X, creator of Claude Code) is posting — workflow doctrine, Claude Code features, agent best practices — then verify each claim against how Claude Code actually behaves, dedupe against Steve's existing rules/skills, and draft gated codify memos for the keepers. Also carries his "automation doctrine" (2026-07-15 seed post) as an on-demand audit — find repeat-fix busywork in a repo or session and propose converting it to a lint rule, canary, hook, skill, or CLAUDE.md rule. Use when Steve says "bcherny scout", "/bcherny-scout", "what is Boris Cherny posting", "any new claude code doctrine from boris", "run the automation audit", "second-fix audit", or drops an x.com/bcherny link and asks what it says and whether to adopt it. Completes the scout trio with tiktok-architect (rules) and gurisingh-scout (tools) — this one covers the primary source.
---

# Bcherny Scout

## Overview

Boris Cherny created Claude Code, so his feed is the closest thing to primary
doctrine about how to run agents well. This skill does two things:

1. **Scout mode** — retrieve his recent posts (or one specific post), treat
   each claim as a hypothesis to VERIFY, dedupe against what Steve already
   has, and draft gated memos to codify the good ones into MEMORY.md /
   CLAUDE.md / a skill.
2. **Audit mode** — apply his automation doctrine (see
   `references/seed-automation-doctrine.md`) to a repo or recent session:
   find issue classes that got fixed more than once by hand or by agent, and
   propose the automation (lint rule / CI step / canary / hook / skill /
   CLAUDE.md rule) that kills each class permanently.

Never a hype relay: posts are claims, not facts, and nothing is codified or
installed without Steve's sign-off.

## Scout mode

### 1. Retrieve ($0)

For a specific post:

```bash
node scripts/hydrate-tweet.js <tweet-id-or-url>
```

Check the output flags — `longform: true` means the full note-tweet text was
recovered; `truncated: true` means only ~280 chars came back, so do NOT quote
or analyze it as complete (see `references/retrieval.md` for fallbacks). For
a discovery sweep of recent posts, follow the fan-out in
`references/retrieval.md` (Exa + WebSearch + HN mirror), then hydrate each
candidate id.

### 2. Filter and classify

Keep posts that are: workflow doctrine, Claude Code feature announcements or
tips, agent/skill/CLAUDE.md patterns, or org-level practices for agentic
teams. Drop personal chatter. Classify each keeper: `doctrine` | `feature` |
`tip` | `pattern`.

### 3. Verify before relaying

Even the creator's posts get verified — features ship after posts, behavior
differs by version, and doctrine may not fit Steve's stack:

- Feature claims → check against the installed Claude Code version
  (`claude --version`, changelog, or the claude-code-guide agent).
- Behavior/workflow claims → test in-session where cheap, or mark UNVERIFIED.
- Doctrine → assess against Steve's actual operating patterns; note where it
  conflicts with a standing rule (the standing rule wins until Steve says
  otherwise).

### 4. Dedupe against the existing stack

```bash
grep -ril "<keyword>" ~/.claude/skills/*/SKILL.md 2>/dev/null
grep -il "<keyword>" ~/.claude/projects/-Users-macstudio3/memory/*.md
grep -i "<keyword>" ~/.claude/CLAUDE.md
```

If an equivalent rule/skill exists, the useful output is a **diff** (what the
post adds or contradicts), not a redundant recommendation. Note: /checkup is
already adapted from his /checkup — precedent for adapting rather than
copying verbatim.

### 5. Score and draft gated memos

Score each keeper 1–5 on fit (matches Steve's stack), leverage (multiplies
across sessions/agents), and confidence (verified vs unverified). For
anything averaging ≥ 4 on fit+leverage, draft a codify memo to
`~/.claude/yolo-queue/pending-approval/` naming: the claim, verification
result, the exact target (MEMORY.md entry / CLAUDE.md rule / skill edit),
and the proposed text. Steve approves; the scout never self-codifies.

## Audit mode (the automation doctrine, applied)

Trigger: "run the automation audit", "second-fix audit", or scoped to a repo
("audit <project> for busywork"). Procedure:

1. Read `references/seed-automation-doctrine.md` (the five distilled rules).
2. Gather evidence of repeat fixes: `git log --oneline` for recurring
   fix-verb commits on the same files, MEMORY.md entries describing recurring
   gotchas, canary FAIL history, and recent session transcripts if in scope.
3. For each issue class fixed ≥ 2 times, propose ONE automation in the
   cheapest durable form, preference order: lint rule → CI/pre-commit hook →
   canary → skill → CLAUDE.md/MEMORY.md rule (prose is the fallback, code is
   the goal).
4. Apply the zero-additional-context test to the repo: could an agent with no
   prompt context contribute? List what tribal knowledge is missing from
   CLAUDE.md/skills.
5. Output a ranked table (class, times fixed, proposed automation, effort).
   Reversible local automations may be built directly; anything touching
   prod, CI on live repos, or settings.json drafts to pending-approval.

## Hard rails

- Propose-only for codification and installs — memos to pending-approval,
  Steve decides.
- Never quote a `truncated: true` hydration as the full post.
- Posts are claims; show verification status (VERIFIED / UNVERIFIED /
  CONFLICTS) next to every relayed claim.
- $0 retrieval by default; metered fallbacks (Exa) show cost per Steve's
  always-show-costs rule, and log it exactly like this (the key lives under
  `apis` in pricing.json — don't grep top-level keys):

  ```bash
  node ~/.claude/skills/cost-tracker/scripts/log.js \
    --api exa_search --units <n>:search --app bcherny-scout --note "sweep <date>"
  ```

- For THREADS, hydrate-tweet.js returns only tweet 1 — pull the full thread
  from the unrollnow mirror (see `references/retrieval.md` §3) before
  analyzing.