[
  {
    "id": "tip-01-ci-feedback-loop",
    "title": "Close the CI feedback loop: let the agent trigger CI and read failed logs itself",
    "start_seconds": 113,
    "end_seconds": 194,
    "speaker": "Sponsor segment (Blacksmith), read by Theo",
    "evidence_type": "sponsor-ad-framing (sponsor performance claims unverified)",
    "source_claim_paraphrase": "The segment describes the common loop: agents make changes, a PR goes up, CI fails with an error not seen locally, the human digs the error out of the logs, pastes it to the agent, the agent pushes again, and the human waits again. The sponsor's pitch is that a CI provider whose CLI lets the agent trigger the run, pull the logs, and fix things itself removes that waiting.",
    "how_to_apply": "Regardless of vendor, wire the agent's environment so it can (a) trigger CI on demand, and (b) fetch only the failing portion of a run's logs itself — e.g. `gh run view RUN_ID --log-failed` or `gh run view RUN_ID --json headSha,status,conclusion,url` per GitHub CLI docs. The reusable lesson is to give the agent a self-serve path around every human copy-paste hop in your check loop.",
    "when_useful": "Any repo where agents open PRs and CI results gate them, especially when humans currently relay errors by hand.",
    "caveat": "This is a paid advertisement. Blacksmith's claims of being faster and cheaper, the ~3,000 jobs in 7 days figure, and falling failure rates are sponsor claims, not independently verified. Do not adopt the vendor from the ad; the portable idea is the loop shape, not the product.",
    "suggested_skill": "agent-feedback-engineering"
  },
  {
    "id": "tip-02-two-browser-e2e",
    "title": "Design tiny two-actor end-to-end tests that catch whole classes of failure",
    "start_seconds": 226,
    "end_seconds": 275,
    "speaker": "Theo (recounting his time at Twitch)",
    "evidence_type": "theo-anecdote",
    "source_claim_paraphrase": "Theo's favorite example from Twitch: one end-to-end test spun up two Playwright browser instances with cookies for two bot accounts pre-signed in; one bot sent a message in a Twitch chat channel, the other verified the message appeared and rendered. It was simple but caught failures earlier than almost anything else.",
    "how_to_apply": "Find the smallest two-actor path through your most complex surface (e.g. producer/consumer, sender/receiver, writer/reader) and encode it as one E2E test with authenticated browser contexts. Prefer one honest cross-system assertion over many shallow unit checks when a class of regressions keeps slipping through.",
    "when_useful": "Distributed or multi-party features (chat, notifications, sync, webhooks) where component tests pass but integration breaks.",
    "caveat": "This is Theo's recollection of a past employer's test, not a checked-in implementation here. Playwright specifics (video/trace retention, retries) are documented separately in Playwright's docs, not proven by the video.",
    "suggested_skill": "agent-feedback-engineering"
  },
  {
    "id": "tip-03-automation-multiplies-agents",
    "title": "Infra and DX automation now speeds up every agent, not just you",
    "start_seconds": 287,
    "end_seconds": 306,
    "speaker": "Boris (as quoted by Theo), endorsed by Theo",
    "evidence_type": "quoted-post-via-theo",
    "source_claim_paraphrase": "Boris's post argues automations have become more important because infra and developer-experience automation speed you up, and if you run many agents, each agent is sped up too — more automation means more output per unit of time. Theo agrees, noting he used to get pushback for pushing fast provisioning and preview environments.",
    "how_to_apply": "Treat build/test/provisioning time as a multiplier over agent count. Before scaling the number of parallel agents, profile the slow shared steps (env setup, test suites, CI wait) and fix those first.",
    "when_useful": "When deciding where to invest tooling effort on a team running multiple concurrent agent sessions.",
    "caveat": "The direction of the claim is plausible but the magnitude (more output per unit of time) is asserted, not measured in the video.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-04-preview-environments",
    "title": "Preview environments matter more now that code is built outside your machine",
    "start_seconds": 306,
    "end_seconds": 352,
    "speaker": "Theo",
    "evidence_type": "theo-opinion",
    "source_claim_paraphrase": "Theo says people used to tell him nobody needs preview environments since everyone builds locally. Now code is built by agents in cloud sandboxes, background tabs, worktrees, or other machines on your network, so a good preview-environment experience is valuable — including ways for agents to test those previews, find bugs, and post evidence of the results.",
    "how_to_apply": "Give every agent workspace a URL it can reach and verify against: a per-branch preview deployment, plus a scripted check (screenshot, key flow, console-error capture) the agent can run and attach to the PR.",
    "when_useful": "Any agent workflow where the human cannot or should not run the app locally to review each change.",
    "caveat": "Opinion/argument, not a measured result. Setting up previews may involve deployments, which stays outside this task's authorization.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-05-custom-file-upload-skill",
    "title": "Build small tool adapters for things the CLI cannot do (video/asset uploads to PRs)",
    "start_seconds": 352,
    "end_seconds": 390,
    "speaker": "Theo",
    "evidence_type": "theo-anecdote",
    "source_claim_paraphrase": "Theo noticed his agents could not attach video files to pull requests: the GitHub UI accepts drag-and-drop uploads, but the CLI and programmatic PR tools have no equivalent. He built a custom file-upload skill backed by his own small service on Cloudflare (files.tslop.org) with a key deployed across his machines, so machines can upload a file and post the link as a line in the PR.",
    "how_to_apply": "Establish the missing operation against current tooling. Reuse an authorized transport before building a narrow adapter, document its contract as a skill, and verify the actual agent can use it. Posting the resulting link requires applicable authorization.",
    "when_useful": "Recurring agent tasks blocked by a missing API surface: media attachments, screenshots, signed artifacts, anything possible by hand but not by tooling.",
    "caveat": "A file-upload SKILL.md is visible on screen at 06:23. Full-resolution visual inspection found it names `FILE_HOST_TOKEN`, uses `curl --fail-with-body` over HTTP PUT, and specifies the public URL from the response body. That evidence describes the file's contents only; it does not prove a real upload succeeded, and it does not establish the service's endpoints or security model beyond that. Theo's service involves an access key on a fleet — any equivalent needs its own key-handling review, and nothing here authorizes deploying a service.",
    "suggested_skill": "agent-tool-adapters"
  },
  {
    "id": "tip-06-skill-authoring-reward",
    "title": "Authoring and testing a small skill has a tight, low-stakes feedback loop",
    "start_seconds": 390,
    "end_seconds": 418,
    "speaker": "Theo",
    "evidence_type": "theo-opinion",
    "source_claim_paraphrase": "Theo reports that building these one-off pieces is more fun than expected: assembling a few parts, figuring out what works, writing it up as a skill, and watching the agent use it is rewarding like setting up an environment for a team — but with a much tighter feedback loop and smaller cost when things break.",
    "how_to_apply": "When a manual workaround recurs, budget a short iteration: implement the smallest working tool, document it as a skill, run it once through the agent, and refine. Keep each iteration reversible and small so failures are cheap.",
    "when_useful": "Individual contributors hesitating to invest in tooling because it used to be high-effort, low-recognition work.",
    "caveat": "Subjective experience report, not a productivity measurement.",
    "suggested_skill": "agent-tool-adapters"
  },
  {
    "id": "tip-07-team-buy-in",
    "title": "Teams are now more willing to fund tooling time — use it",
    "start_seconds": 448,
    "end_seconds": 480,
    "speaker": "Theo",
    "evidence_type": "theo-opinion",
    "source_claim_paraphrase": "Theo says most teams are more willing to let you spend time on environment and automation work now; three days on a Vim config used to draw concern from bosses and teammates. He encourages his own team to spend more time on it because they had internalized that it was not worthwhile.",
    "how_to_apply": "Propose time-boxed agent-tooling work explicitly (e.g. a recurring tooling block) and frame it as team-leverage: each improvement applies to every teammate's agents. Show one concrete win before asking for more time.",
    "when_useful": "Engineers who assume management still treats deep tooling as slacking.",
    "caveat": "Anecdotal claim about team attitudes; nothing in the video establishes your team's tolerance — ask, don't assume.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-08-fix-class-loops",
    "title": "Move recurring fixes from per-occurrence agent corrections into executable checks (lint rule, CI step, routine)",
    "start_seconds": 480,
    "end_seconds": 510,
    "speaker": "Boris (as quoted by Theo)",
    "evidence_type": "quoted-post-via-theo",
    "source_claim_paraphrase": "From 08:02, Boris's post argues that moving things into code improves efficiency: an agent can fix an issue every time it sees it, but that spends tokens and may miss cases. If Claude instead writes a lint rule, a CI step, or a routine, the whole class of issue can be automated permanently. Boris ties this to what people mean by loops: automating entire types of busywork rather than solving instances one at a time. Theo notes the idea is not new.",
    "how_to_apply": "When an agent (or you) has corrected the same class of issue more than once, stop fixing occurrences and add an executable check that catches the class: a custom lint rule, a CI gate, or a small script. Write the check once, let it run on every change.",
    "when_useful": "Any recurring correction — style, safety, architecture — that is currently handled by repeated review comments or repeated agent fixes.",
    "caveat": "Argument, not a measured result. A wrong or over-broad check silently blocks good changes, so review executable checks like any other code.",
    "suggested_skill": "agent-feedback-engineering"
  },
  {
    "id": "tip-19-custom-lint-economics",
    "title": "Custom lint rules became economical: agents lower the cost of the code and its tests",
    "start_seconds": 510,
    "end_seconds": 566,
    "speaker": "Theo",
    "evidence_type": "theo-opinion",
    "source_claim_paraphrase": "From 08:30, Theo elaborates on the economics: certain checks would be useful but were never worth the extra effort — for example a custom lint rule needing around 400 lines to verify very specific oddities. Those checks would have stayed as manual code review indefinitely. Now that writing the code and the tests verifying it are much cheaper, building custom automations and actions per project makes sense, especially because agents hit these problems far more often than people did.",
    "how_to_apply": "Re-price formerly dismissed checks: if writing the rule plus its verifying tests is now cheap, build it instead of leaving it to manual review. ESLint supports custom rules per its docs; have the agent write the accompanying tests.",
    "when_useful": "Teams with a backlog of issues always caught by eye that were never worth the engineering cost.",
    "caveat": "Economic argument, not measured. Custom rules still need maintenance; a wrong rule silently blocks good code, so review it like any other code.",
    "suggested_skill": "agent-feedback-engineering"
  },
  {
    "id": "tip-09-domain-knowledge-as-infra",
    "title": "Encode domain knowledge as infrastructure so newcomers' agents get steered too",
    "start_seconds": 596,
    "end_seconds": 631,
    "speaker": "Boris (as quoted by Theo), partially endorsed by Theo",
    "evidence_type": "quoted-post-via-theo",
    "source_claim_paraphrase": "Boris argues the blocker for day-one contributions is domain knowledge living in people's heads; agents let that knowledge be encoded as infrastructure beyond what lint rules, types, and tests express — code comments, skills, Claude.md rules, memories. He frames a rejected PR from an unknown framework, or an off-pattern design, as a failure of automation. Theo likes the idea — engineers who know good codebases should build systems that keep the codebase good — but says Boris goes further than he would.",
    "how_to_apply": "Audit recurring onboarding corrections and move each one into a durable artifact: a lint rule, a type, an architectural structure, or a written steering file. Aim the artifact at everyone's agents, not just yours.",
    "when_useful": "Codebases where the same contextual rules are re-taught verbally to every new engineer.",
    "caveat": "Theo explicitly calls parts of this a reach, especially the claim that non-engineers can contribute as effectively as engineers (he says not as effectively). Treat the strong version as Boris's claim, not established fact.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-10-newcomer-questions-signal",
    "title": "Treat newcomer questions as a signal for onboarding gaps (Theo's dumb-questions practice)",
    "start_seconds": 674,
    "end_seconds": 709,
    "speaker": "Theo",
    "evidence_type": "theo-practice",
    "source_claim_paraphrase": "Theo describes a practice from his teams: new teammates were asked to ask at least one dumb question per day. Beyond unblocking them, the questions reveal what is and is not working for people discovering the codebase — insight you only get while someone is still a beginner — and inform making the codebase more approachable and preventing regressions.",
    "how_to_apply": "Make newcomer questions a blameless artifact and triage them periodically: answer the person, then fix the cause — better naming, a missing doc, a lint rule, or a steering-file entry — so the next newcomer (and their agent) never hits it.",
    "when_useful": "Any team onboarding engineers, and equally for agents: an agent's repeated confusion is the same signal.",
    "caveat": "This is a cultural practice Theo describes for his own teams. It is source material, not a workspace rule — no daily question quota is adopted or required here. It depends on psychological safety and does not by itself fix the underlying gaps.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-11-own-your-instructions",
    "title": "Write your CLAUDE.md / AGENTS.md yourself; watch agent behavior and adjust",
    "start_seconds": 749,
    "end_seconds": 783,
    "speaker": "Theo",
    "evidence_type": "theo-directive",
    "source_claim_paraphrase": "Theo's advice: do not let your agents write your Claude.md or agents.md file — that is where the extra human effort is worth it, because it is how you learn what leads to different agent behaviors. Watch what your agents do, then adjust the files, the tooling, and the setup to steer the model where you want.",
    "how_to_apply": "Author instruction files by hand from observed agent behavior. Keep a short log of misbehaviors and the edit that addressed each; if an agent offers to rewrite the file for you, decline and write the change yourself.",
    "when_useful": "Anyone whose agent instructions were generated once and never deliberately revised.",
    "caveat": "Theo's strong personal rule for his own instruction files. Current user instructions and workspace rules take precedence over anything in this video; this tip records source material, not workspace authority.",
    "suggested_skill": "agent-context-calibration"
  },
  {
    "id": "tip-12-steering-pushback",
    "title": "Use steering files to make the agent say no (and to get fast feedback when things go wrong)",
    "start_seconds": 783,
    "end_seconds": 829,
    "speaker": "Theo",
    "evidence_type": "theo-practice",
    "source_claim_paraphrase": "The goal is not to stuff everything agents should know into context, but to give feedback when they do things wrong — for the agent and for human contributors. Steering files can encode pushback: if people keep requesting a feature that does not belong, add a rule to agents.md telling the agent to stop and decline, and it will.",
    "how_to_apply": "When a request pattern repeats that you always reject, write the rejection rule into the steering file with the reason and the expected response. Chain rules together where that makes outputs more consistent and reliable.",
    "when_useful": "Projects that attract repeated out-of-scope requests from users, teammates, or agents.",
    "caveat": "A steering rule only nudges; it does not enforce, and adversarial or novel phrasings can get around it. Keep real enforcement in lints, types, and CI.",
    "suggested_skill": "agent-context-calibration"
  },
  {
    "id": "tip-13-type-safe-composition",
    "title": "Compose layers so type safety runs end to end — and expect that click more often now",
    "start_seconds": 831,
    "end_seconds": 869,
    "speaker": "Theo",
    "evidence_type": "theo-anecdote",
    "source_claim_paraphrase": "Theo compares well-chained steering to the feeling of building the T3 stack: Prisma turns the database into typed functions, tRPC exposes them over an RPC layer, and type safety reaches from the UI hook/component all the way to the database. He says such compositions used to happen once every few years; now he gets them almost daily.",
    "how_to_apply": "Design toolchains so guarantees compose: if one layer produces types, make the next layer consume them rather than re-declaring shapes. Look for the same composition opportunity in agent setups (schema → tool → test → doc all deriving from one source).",
    "when_useful": "Any stack where hand-written duplicates of a single source of truth drift apart.",
    "caveat": "Specifics (Prisma, tRPC, T3) are Theo's stack, not a general requirement; the transferable idea is single-source typed composition. The almost-daily cadence is anecdotal.",
    "suggested_skill": "agent-tool-adapters"
  },
  {
    "id": "tip-14-zero-context-docs",
    "title": "Write Claude.mds, review.mds, skills, and docs so agents work with zero prompting context",
    "start_seconds": 873,
    "end_seconds": 925,
    "speaker": "Boris (as quoted by Theo), endorsed by Theo",
    "evidence_type": "quoted-post-via-theo",
    "source_claim_paraphrase": "Boris's wrap-up: every team should write the Claude.mds, review.mds, skills, and docs that let agents work productively in the codebase with zero additional context from the prompter; as models and harnesses improve this gets easier, and meanwhile it is on every team to convert domain knowledge into infra so Claude writes better code, review catches more, and the next person contributes more easily. Theo jokes that his own preferences are public information so telling the agent to build it the way he would works, and notes small changes in these files meaningfully change behavior — citing a developer who dumped context from favorite books to tune model tone.",
    "how_to_apply": "Test onboarding by handing a fresh agent (or new hire) only the repo: if they fail on something the repo could have said, write it into the repo's instruction/doc layer rather than the prompt. Keep review guidance in a review file so code review encodes standards automatically.",
    "when_useful": "Any shared codebase; the test is whether a stranger's first prompt succeeds.",
    "caveat": "The claim that non-engineers contribute as effectively as engineers, made around this section, is Boris's and Theo calls it a reach. Prompt-tuning anecdotes (book dumps, name-dropping) are illustrative, not a recommended technique, and public-preference name-dropping relies on Theo's specific visibility.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-15-minimal-context-calibration",
    "title": "Calibrate from a cold start: run minimal prompts first, add context only where it fails",
    "start_seconds": 962,
    "end_seconds": 998,
    "speaker": "Theo",
    "evidence_type": "theo-directive",
    "source_claim_paraphrase": "Theo explicitly warns against installing every skill and plugin up front and forcing the team to match: use the tools as preconfigured, and build a solution when you find an actual problem. Do not touch the instruction files until after the first few prompts show what goes wrong — and send those prompts with as little context as possible to see whether that is enough, and if not, what belongs in the files.",
    "how_to_apply": "Start a new repo or agent setup with default configuration and a minimal prompt. Record each failure, then add the minimum fix: a file entry, a rule, a tool. Repeat; never pre-install speculatively. Keep standing instructions, admitted tools and runtime safeguards; minimize only extra project explanation.",
    "when_useful": "New projects, newly agent-enabled repos, and any team tempted by large plugin lists.",
    "caveat": "Applies to steering files and plugin adoption; it does not restrict authorized skill authoring, which is a separate activity governed by current workspace rules.",
    "suggested_skill": "agent-context-calibration"
  },
  {
    "id": "tip-16-steer-not-map",
    "title": "Instruction files should steer toward success, not list where things are",
    "start_seconds": 998,
    "end_seconds": 1008,
    "speaker": "Theo",
    "evidence_type": "theo-directive",
    "source_claim_paraphrase": "If your Claude.md or agents.md is just a list of where things are in the codebase, that is not a good guide; those files should steer the model toward success, not toward specific lines of code.",
    "how_to_apply": "Replace inventory-style entries (the API lives in src/api) with behavior-shaping guidance: conventions, invariants, what to do when uncertain, how to verify. Let the agent find files itself; spend the file's budget on judgment.",
    "when_useful": "Auditing any existing instruction file that reads like a directory listing.",
    "caveat": "Heuristic, not absolute — a brief orientation line can help; the point is not to make maps the whole file.",
    "suggested_skill": "agent-context-calibration"
  },
  {
    "id": "tip-17-career-leverage",
    "title": "Building environments where code lands well is a career-level skill (with a grain of salt)",
    "start_seconds": 1014,
    "end_seconds": 1080,
    "speaker": "Theo (self-flagged as speculative)",
    "evidence_type": "theo-opinion",
    "source_claim_paraphrase": "Theo flags this as possibly a reach: these skills are how you become a senior developer and level up your impact, because moving from great individual contributor to team-forward requires work that elevates how others contribute, not just you or the product. You can learn it solo with your own multi-agent projects or at a company. He believes making environments where code lands most effectively is a bigger skill than landing the code yourself, but says this was always the best path to staff engineer — building structures and systems, not just landing more code — and now it can be done solo.",
    "how_to_apply": "Budget deliberate time to improving the shared surface: instruction files, lint rules, CI, preview checks. Document these contributions so their leverage is visible in reviews, since the payoff accrues to the team rather than your commit count.",
    "when_useful": "ICs aiming at senior/staff scope, and teams deciding what to recognize and promote.",
    "caveat": "Theo himself says to take it with a grain of salt; it is career argument, not evidence. Whether a given employer rewards it varies.",
    "suggested_skill": "agent-ready-workspaces"
  },
  {
    "id": "tip-18-solo-onboarding",
    "title": "Solo projects now exceed your own comprehension — build systems so you and your agents don't get lost",
    "start_seconds": 1080,
    "end_seconds": 1116,
    "speaker": "Theo",
    "evidence_type": "theo-anecdote",
    "source_claim_paraphrase": "Theo notes that past solo projects stayed fully in his head, so he never experienced what contributing to them felt like. With agents, even his solo projects go beyond his own comprehension, so he must build systems that keep his agents — and his own attention — from getting lost, which is how he keeps leveling up.",
    "how_to_apply": "Treat your own solo repo like a team repo: write the steering files, runnable checks, and preview verification as if a stranger (human or agent) will onboard tomorrow. Re-onboard yourself periodically with a cold, minimal-context prompt to find what only lived in your head.",
    "when_useful": "Solo developers and small projects where all context is tacit and agent-generated code outpaces personal recall.",
    "caveat": "Personal experience; the beyond-my-comprehension claim is Theo's self-description, not a general measurement.",
    "suggested_skill": "agent-ready-workspaces"
  }
]