DEV Community: Thryx

How to Use Subagents in Claude Code

Thryx — Thu, 16 Jul 2026 19:00:03 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

Long Claude Code sessions die the same way every time: the context window fills up with search results, file dumps, and dead-end exploration, and the model gets dumber right when you need it sharp. Subagents are the built-in fix — separate workers that do the messy digging in their own context and hand back only the conclusion. Here's how to actually use them.

What a subagent actually is

A subagent is a separate agent instance that Claude Code spins up with its own context window. It gets a task, works it — reading files, grepping, reasoning — and returns a single result message to the main conversation. All the intermediate noise stays in the subagent's context and dies with it.

That buys you three things:

A clean main context. The subagent burns its own tokens exploring; your main conversation only receives the conclusion. Fifty file reads on its side show up as one summary on yours.
Parallel work. Multiple subagents can run at once. Three independent questions, three workers, answered simultaneously instead of serially.
Specialization. A custom subagent carries its own system prompt and its own tool restrictions, so it behaves like a focused specialist instead of a generalist with your whole session on its mind.

Triggering one: automatic vs explicit

You don't have to configure anything to start. Claude decides to delegate on its own when a task looks like broad search or research — "find everywhere we handle auth" is the kind of thing it will hand to a subagent without being asked.

When you want control, ask explicitly:

use a subagent to find every place we construct SQL queries by hand

spawn an agent to research how the payment webhook flow works, then summarize it

Plain language is the interface. Say "subagent" or "spawn an agent" and describe the task; Claude handles the rest.

One thing to know about the plumbing: subagent results come back to the main agent, not directly to you. The main agent reads the result and summarizes it in its reply. You're always talking to the coordinator, never the worker.

Building a custom subagent

The real power move is defining your own. A custom subagent is one Markdown file with YAML frontmatter, and it lives in one of two places:

.claude/agents/ in your repo — project-level. Commit it and your whole team gets the same specialist.
~/.claude/agents/ — personal, available in every project you open.

Here's a read-only code reviewer:

---
name: code-reviewer
description: "Use this agent when code has just been written or modified and needs review. Checks for bugs, security issues, and convention violations before anything ships."
tools: Read, Grep, Glob
---

You are a senior code reviewer. Review the changes you're pointed at
for correctness bugs first, then security issues, then convention
violations. Be specific: file and line, what's wrong, why it matters.
Do not suggest rewrites of code that works. Report findings ranked
by severity, worst first.

Four frontmatter fields matter:

name — kebab-case identifier.
description — when Claude should use it. This is the routing signal; more on it below, because it's where most subagents fail.
tools — optional allowlist. Everything not listed is off the table.
model — optional; pin the model this subagent runs on.

Everything below the frontmatter is the subagent's system prompt. If you've read how to write a system prompt for an AI agent, all of it applies here — concrete rules, explicit output shape, no vibes.

Don't want to hand-write the file? Run /agents inside Claude Code — it opens an interactive manager for creating and editing subagents.

The description is the routing signal — write it like a trigger

Claude reads the description field to decide when to delegate. That makes it the single most important line in the file. Write it as a trigger condition:

# Weak — Claude has no idea when to reach for this
description: A helpful agent for code quality.

# Strong — reads like a rule Claude can match against
description: Use this agent when code has just been written or modified and needs review.

"Use this agent when…" followed by concrete situations is the pattern that works. If your subagent never fires automatically, fix the description before you touch anything else.

Restrict tools — it's a safety feature, not a nicety

The tools allowlist is what makes specialists trustworthy. A reviewer with only Read, Grep, Glob cannot accidentally edit a file, no matter how confused it gets. That's a guarantee, not a hope.

Good candidates for the specialist treatment, each with tools scoped to the job:

Code reviewer — read-only.
Test runner/fixer — needs to run commands and edit test files.
Docs writer — read plus write, no shell.
Security auditor — read-only, again.
Read-only explorer — for "map this codebase" jobs where you want zero chance of side effects.

One structural limit to design around: a subagent cannot spawn further subagents. Delegation goes one level deep, so the main agent is always the coordinator fanning work out — build your workflows with that shape in mind.

The honest trade-off

Subagents are not free. Each one spins up its own instance, which means added latency before you see anything, and its exploration burns tokens even though they never land in your context. For a single quick file lookup, direct search is flat-out better — don't spawn a worker to answer a one-line grep.

The rule of thumb: delegate when the search is broad or the task is self-contained. Keep it direct when the answer is one known location away.

The token side is worth planning around too, since subagents burn tokens even though those tokens never land in your context. If cost is a concern, one option is pointing Claude Code at a cheaper backend — the GLM Coding Plan is one, and I walk through that setup in how to set up Claude Code with the GLM API. When the exploring is cheap, "spawn three workers" feels like a shrug instead of a bill.

Broke to Built is one broke human + AI agents building real software with no budget, writing down every step. This site's tools run on free GLM — z.ai's Coding Plan is the referral that funds our compute (disclosed affiliate).

How to Validate a SaaS Idea With No Money

Thryx — Wed, 15 Jul 2026 19:00:02 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

The usual way a SaaS idea dies is after months of building — when one week of checking would have killed it for free. That order is backwards, and fixing it costs nothing. Validation isn't a budget problem — every tool you need has a free tier. It's a courage problem: you have to show the idea to strangers before it's real, and accept what they do (not what they say) as the verdict.

Here's the whole playbook at $0, in the order I'd run it.

What validation actually means

Validation is evidence that strangers want the thing enough to give you something: an email, a slot on their calendar, or money. Not your friends. Not people being polite. Strangers, giving something up.

Y Combinator's motto is "make something people want" — and the only way to know people want it is to watch what they do when you put the promise in front of them. Everything below is a way of generating that behavior cheaply.

Two rules before anything else:

Compliments are not data. "That's a cool idea" costs the speaker nothing and predicts nothing.
You are not the customer. Even if you have the problem yourself, you're testing whether other people have it badly enough to act.

The ladder of evidence

Every validation signal sits on a rung. Weakest to strongest:

People say it's interesting. Nearly worthless. Everyone says this about everything.
People give an email for a waitlist. A small real cost. Worth something.
People book and show up to a 15-minute call. Time is expensive. This is serious interest.
People pre-order or sign a letter of intent. Money or a signature. This is the top.

The whole game is climbing this ladder before you write code. Distrust the bottom rung completely, treat the second rung as a hint, and don't commit months of your life to anything that hasn't touched rung three or four.

Step 1: Find the complaint before you pitch the cure ($0)

Before you talk to anyone, go read what people already say when nobody's pitching them. Search Reddit and niche forums for the problem — not your product, the problem. Look for phrases like "how do you deal with," "is there a tool for," "I'm so sick of."

You're reading, not posting. Do not spam communities with your idea — that burns the channel you'll need later. What you want from this step:

The exact words people use to describe the pain (this becomes your landing page headline).
What they currently do about it — spreadsheets, duct-taped tools, paying a VA, nothing.
Whether the complaint shows up repeatedly or you had to dig for one thread from three years ago.

If you can't find anyone complaining, that's your first data point, and it's not a good one.

Step 2: Run 5-10 problem interviews

Find 5-10 people who plausibly have the problem and get them talking. The one rule that makes or breaks this: ask about their current behavior and past attempts, never about your idea.

"Would you use a tool that does X?" gets you a polite yes and zero information. People say yes to be nice. Instead:

"Walk me through the last time this happened."
"What did you do about it?"
"What have you tried before? What did you pay for it?"
"What happened after that?"

Past behavior is evidence. If they've never tried to solve the problem — never searched for a tool, never hacked a spreadsheet, never paid anyone — the pain probably isn't real enough to sustain a product, no matter how enthusiastically they nod.

Reaching out cold is the uncomfortable part, and it's also free. A short, honest message — "I'm researching how people handle X, can I ask you three questions?" — outperforms anything clever. If writing that outreach note is what's stopping you, the same structure I use in the professional email prompt guide works for this: context, one clear ask, easy out.

Step 3: Put up a landing page and a waitlist ($0)

Now turn the language from steps 1 and 2 into a one-page test:

One sentence stating the promise. Use the words your interviewees used, not your clever positioning.
One CTA. Join the waitlist. That's it — no nav, no feature grid, no pricing page.
Total transparency. Say it's upcoming. No fake "Buy now" button that takes card details for a product that doesn't exist. You're measuring pull, not tricking people.

The free stack: Carrd has a free tier that handles a one-page site fine, or throw plain HTML on any free subdomain you already have access to. For the form, Google Forms is free forever, and Tally's free tier embeds cleanly if you want it to look less like a survey. Wire the CTA to the form, and you have a functioning validation machine for exactly $0.

Step 4: Drive small, genuine traffic and measure

A landing page with no visitors measures nothing. But you don't need an ad budget — you need a handful of real humans from communities you actually belong to. Share it where you already participate, framed honestly: "I'm exploring this, does it resonate?" A few dozen genuine visitors tell you more than a thousand bought clicks, because you know exactly who they are and why they came.

Watch one number: signup rate — emails collected per real visitor. Don't obsess over the absolute count; obsess over whether people who have the problem convert when they see the promise stated in their own words.

Then climb. Email the waitlist and ask for a 15-minute call (rung three). On the calls, if the pain is real, ask the money question: "If I build this, would you pre-pay for the first month?" or, for anything B2B-shaped, "would you sign a letter of intent?" (rung four). Every rung people climb willingly is evidence. Every rung they refuse is also evidence.

Set your kill criteria before you start

This is the step everyone skips, and it's the one that protects the only capital you actually have: your time.

Before you run any of the above, write down what result means "drop it." For example: if after a week of genuine effort I can't find 10 people who care enough to give an email or take a call, this idea is dead. Whatever your line is, set it while you're still objective — because after two weeks of effort, sunk cost will happily move the goalposts for you.

A killed idea after one week is a win. The same idea killed after six months of building is the disaster this whole process exists to prevent.

The broke-builder edge: let AI do the grunt work

Here's what's changed about this playbook: the mechanical parts now take minutes instead of days. An AI agent will draft your landing page copy, your survey questions, your outreach messages, and five headline variants to test — faster than you can make coffee. If you're setting up agents to do that kind of drafting reliably, the structure matters more than the model; that's exactly what how to write a system prompt for an AI agent covers. And the quality of what comes back tracks the quality of what you feed in — Meta-Prompt Architect is the tool I built for turning a rough "draft my landing copy" into a reusable, high-signal instruction, so the agent's first pass is usable instead of generic.

I run my own drafting and build agents through Claude Code pointed at the GLM Coding Plan, which keeps the token bill near zero — the setup is in how to set up Claude Code with the GLM API.

But be clear-eyed about what AI does and doesn't buy you here. It compresses the cheap parts. The scarce input in validation was never the code or the copy — it's honest contact with strangers. No agent can sit through a problem interview for you, and no model can make a stranger hand over an email they don't want to give. That part is still yours, and it's the part that counts.

Where this fits

The whole sequence — complaints → interviews → landing page → traffic → calls → money — runs on Google Forms, Carrd or a free subdomain, Tally, Reddit search, and your own nerve. Zero dollars, one to two weeks, and at the end you either have strangers' emails and booked calls, or you have a clean kill and your next idea.

Since the building itself is nearly free now too (cheap tokens, see the GLM setup guide), the temptation is to skip validation entirely because "I can just build it in a weekend." Resist that. Cheap building makes validation more valuable, not less: when everyone can ship, the only edge left is knowing what's worth shipping. Climb the ladder first.

How to Use Claude Code Plugins (Install from a Marketplace or Build Your Own)

Thryx — Tue, 14 Jul 2026 19:00:09 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

My Claude Code setup took months to accrete: a review command here, a formatting hook there, an MCP server for the database, a subagent for QA. Then I started a second project and discovered the setup didn't come with me — it was smeared across four config surfaces in the first repo, and "install my tooling" meant a twenty-minute archaeology dig through my own dotfiles. Plugins are Claude Code's answer to exactly that problem: one directory that bundles all of it, installable with one command.

What a plugin actually is

A plugin is a folder with a manifest. Inside it, the same primitives you can already wire up by hand, packaged to travel together:

Skills and commands — the prompt templates behind /name invocations, the same format as a custom slash command
Agents — subagent definitions that show up in /agents
Hooks — lifecycle event handlers, same schema as Claude Code hooks in your settings, just living in hooks/hooks.json
MCP servers — a bundled .mcp.json, so installing the plugin connects the tools without anyone running claude mcp add

Plugins can also carry LSP servers for code intelligence, background monitors, and executables — but the four above are the ones you'll actually package first.

The one behavioral difference from hand-wired pieces: namespacing. A skill named hello in a plugin named my-plugin is invoked as /my-plugin:hello, not /hello. That's deliberate — two plugins can both ship a deploy skill without colliding. Your own standalone .claude/ files keep their short names.

Install one from a marketplace in two minutes

A marketplace is a catalog — a repo or URL that lists plugins and where to fetch them. Using one is a two-step deal: add the catalog, then install individual plugins from it. Think app store: adding the store installs nothing.

Anthropic's official marketplace (claude-plugins-official) is registered automatically. Run /plugin inside a session and you get a tabbed manager — Discover, Installed, Marketplaces, Errors, cycled with Tab. Browse Discover, hit Enter on a plugin, and the details pane shows what it contains, its context cost in tokens, and a "Will install" inventory before you commit.

Or skip the browsing and install directly:

/plugin install github@claude-plugins-official

For third-party catalogs, add the marketplace first. The community marketplace — where reviewed third-party submissions land, each pinned to a specific commit — is the obvious second stop:

/plugin marketplace add anthropics/claude-plugins-community
/plugin install some-plugin@claude-community

/plugin marketplace add accepts a GitHub owner/repo shorthand, a full git URL (include the https:// and the .git), a local directory, or a direct URL to a hosted marketplace.json.

Installing prompts you for a scope:

user — you, across all projects (the default)
project — written to .claude/settings.json, so everyone who clones the repo gets it
local — this repo only, gitignored

Then activate without restarting:

/reload-plugins

That's the full loop. The plugin's skills now show up under their namespace — install commit-commands from Anthropic's demo marketplace and you get /commit-commands:commit.

Managing what you've installed

The day-to-day commands:

/plugin list                                # what's installed, grouped by scope
/plugin disable plugin-name@marketplace-name  # turn off without uninstalling
/plugin enable plugin-name@marketplace-name
/plugin uninstall plugin-name@marketplace-name
/plugin update plugin-name@marketplace-name   # pull a plugin update
/plugin marketplace update marketplace-name   # refresh a catalog

Everything also exists as a shell command (claude plugin install formatter@my-marketplace --scope project) for scripts and CI. Two things worth knowing before you accumulate a pile: removing a marketplace uninstalls every plugin you got from it, and every enabled plugin adds tokens to every session — claude plugin details <name> shows the projected cost, split into always-on and on-invoke. Audit occasionally; the Installed tab literally flags plugins you haven't touched in weeks.

When a plugin beats hand-wiring each piece

Honest answer: not always. The decision is about distribution, not capability — a plugin can't do anything the standalone pieces can't.

Hand-wire when it's one project, it's just you, and you're still iterating. Files in .claude/ are faster to edit, need no manifest, and keep short names. Every plugin in my own setup started life as a loose skill or hook I was still fiddling with.

Package a plugin when:

Someone else needs your setup. The alternative is a README that says "create these four files, paste this JSON, run these three commands." A plugin turns that into one install — and the MCP servers, hooks, and agents arrive pre-wired to each other.
You need it in more than one repo. User-scope install once beats copying .claude/ folders around and watching them drift.
You want versioned updates. Bump the version field, users get the update; your copied-folder users get nothing, forever.
The pieces only make sense together. A deploy skill that calls a deploy MCP server guarded by a deploy hook is one product, not three configs. Shipping them separately invites the broken half-install.

The tell is the second consumer. The moment a setup has one — a teammate, your own second machine, a future you — packaging pays for itself.

Build your own: the anatomy

A minimal plugin is two files. The manifest lives at .claude-plugin/plugin.json:

{
  "name": "my-first-plugin",
  "description": "A greeting plugin to learn the basics",
  "version": "1.0.0"
}

name is the only required field — it becomes the namespace prefix. version is optional but load-bearing: set it and users only get updates when you bump it; omit it and the git commit SHA is the version, so every push ships. Set it for stable releases, omit it while iterating.

Components sit at the plugin root, not inside .claude-plugin/ — the number-one structural mistake, per Anthropic's own docs. Only plugin.json goes in there:

my-plugin/
├── .claude-plugin/
│   └── plugin.json       # only the manifest lives here
├── skills/
│   └── hello/
│       └── SKILL.md      # becomes /my-plugin:hello
├── commands/             # flat .md files, same format as custom slash commands
├── agents/               # subagent definitions
├── hooks/
│   └── hooks.json        # same schema as hooks in settings.json
└── .mcp.json             # bundled MCP servers

skills/ is the recommended layout for new plugins (each skill a folder with a SKILL.md); commands/ holds flat Markdown files in the older style. If you already have working pieces in a project's .claude/ directory, migration is mostly cp -r — copy commands/, agents/, skills/ across, and move your hooks object out of settings.json into hooks/hooks.json, same shape.

One rule saves you a debugging afternoon: use ${CLAUDE_PLUGIN_ROOT} for every internal path in hook commands and MCP configs. Installed plugins are copied into a cache at ~/.claude/plugins/cache, not run from where the user cloned them — so relative paths that reach outside the plugin directory (../shared-utils) simply don't exist after install. The variable always resolves to wherever the plugin actually landed.

Test locally, then validate

Point Claude Code at the directory — no marketplace, no install:

claude --plugin-dir ./my-plugin

Invoke your skill (/my-plugin:hello), check /agents for your agents, trigger your hooks. As you edit, /reload-plugins picks up changes mid-session. Before shipping, lint the whole structure:

claude plugin validate ./my-plugin

It checks plugin.json, skill and agent frontmatter, and hooks/hooks.json for schema errors — the same check Anthropic's review pipeline runs on community submissions. There's also claude plugin init my-tool, which scaffolds a manifest and starter skill under ~/.claude/skills/ that loads automatically next session — the fastest path from nothing to a working plugin skeleton.

Distribute it: a marketplace is one JSON file

To share, you publish a catalog. A marketplace is a repo with a .claude-plugin/marketplace.json listing your plugins:

{
  "name": "my-plugins",
  "owner": { "name": "Your Name" },
  "plugins": [
    {
      "name": "quality-review-plugin",
      "source": "./plugins/quality-review-plugin",
      "description": "Adds a quality-review skill for quick code reviews"
    }
  ]
}

source can be a relative path inside the same repo (the simple case: one repo, plugins/ folder, catalog at the root) or an object pointing at another GitHub repo, so one catalog can index plugins living anywhere. Test the whole flow locally before pushing:

/plugin marketplace add ./my-marketplace
/plugin install quality-review-plugin@my-plugins

Then push to GitHub and your users run /plugin marketplace add your-name/your-repo. For a team, go one step further: add the marketplace to the project's .claude/settings.json under extraKnownMarketplaces, and Claude Code prompts every collaborator who trusts the repo to install the team plugins. That plus a committed CLAUDE.md file is the whole "onboard a new dev's AI tooling" problem, solved in two files.

The security paragraph you shouldn't skip

A plugin is code execution with your user privileges — hooks run shell commands, MCP servers are processes, and installing from a marketplace means trusting whoever controls that repo, including their future pushes. Anthropic verifies none of it for third-party sources. The same rules as any dependency: read the component inventory before installing, prefer pinned catalogs like the community marketplace, and be pickier about marketplaces than about plugins — the catalog decides what an update contains.

Where this fits

Plugins are the distribution layer for everything else in this cluster: the slash commands you templatize, the hooks that enforce your rules, the MCP servers that feed Claude real data, the subagents that parallelize the work. Once your setup is a plugin, it follows you to every project — which means the economics of running it everywhere start to matter. I keep the heavy drafting lanes on the z.ai GLM Coding Plan — that's a referral link, it helps fund our compute, and the plan costs the same with or without it; setup walkthrough in how to set up Claude Code with the GLM API.

And the honest limit of packaging: a plugin makes instructions installable, not good. A bad prompt shipped to five repos is a bad prompt five times. The skill and agent bodies inside your plugin are system prompts, and writing those tight is its own craft — Meta-Prompt + System Prompt Architect ($8.99, one-time) is the skill I use to turn rough intent into the kind of precise, reusable, failure-aware instructions that are actually worth namespacing and shipping. Package the wiring with a plugin; make what's inside worth installing.

How to Use Claude Code in VS Code

Thryx — Mon, 13 Jul 2026 19:00:55 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

Most people's first Claude Code session is a terminal squinting contest: a multi-file diff scrolls past as text, you approve it half-read, and then you alt-tab into your editor to find out what actually changed. VS Code integration fixes exactly that. Here's how to wire it up, what you actually get, and when the plain terminal is still the right call.

The mental model first: it's the same agent

Get this straight before touching setup, because it saves you a bunch of confusion: Claude Code in VS Code is not a different product. The extension is a window into the same agent you run in a terminal. Your CLAUDE.md loads exactly the same. Your hooks fire. Your MCP servers connect. Your skills and slash commands all work. Nothing you've configured gets redone or duplicated — the IDE just gives that same agent better ways to show you things and better context about what you're looking at.

Prerequisite: a working CLI

You need the Claude Code CLI installed and authenticated before any of this matters. If you haven't done that yet — or you have, and the token meter is scaring you — the budget path is running it against the GLM models: full walkthrough in how to set up Claude Code with the GLM API. The plan I use for that is the z.ai GLM Coding Plan — disclosure up front: https://z.ai/subscribe?ic=BWTG6TRYYQ is a referral link, it helps fund our compute, and it's the same plan you'd get without it.

Once claude runs in any terminal, you're ready.

Setup: run claude in the integrated terminal

Here's the whole install process:

Open your project in VS Code.
Open the integrated terminal.
Run claude.

That's it. Claude Code auto-detects that it's running inside VS Code, and the official extension typically auto-installs on its own the first time you do this. No marketplace hunting, no config file. (The extension does live on the VS Code marketplace if you'd rather install it directly — same result.)

The one detail that matters: the auto-detect and auto-install happen in the integrated terminal. If your session didn't connect on its own, /ide (next section) is the fix.

If it didn't connect: /ide

Sometimes a terminal-launched session doesn't hook into the IDE automatically. There's a slash command for exactly that. Inside your Claude Code session, run:

/ide

That connects the running session to VS Code. It's the first thing to try any time the integration features listed below aren't showing up.

What you actually get

Four concrete upgrades over a plain terminal, roughly in order of how much they'll change your day:

Native diff review. When Claude proposes changes, they open in VS Code's diff viewer instead of rendering as terminal text. This is the headline feature. A three-file refactor as side-by-side diffs you can scan properly is a different experience from the same refactor as a wall of +/- lines — you catch the wrong-but-plausible edit before accepting it, not after.

Your selection is context. Whatever you've selected, and whichever file is active, gets shared with Claude automatically. Highlight a gnarly function and ask "why does this leak?" — no pasting, no describing where the code lives.

Shared diagnostics. The lint and type errors VS Code already knows about are shared with Claude. So "fix the type errors in this file" works off the same red squiggles you're staring at, instead of Claude re-deriving the problems from scratch.

A quick-launch shortcut. Ctrl+Esc on Windows/Linux, Cmd+Esc on Mac — opens Claude Code focused on your current file. It turns "I'll ask Claude about this" from a context switch into a keystroke.

Feeding it context

Two habits worth building once you're in the editor. You can @-mention files in your prompt to pull them in as context references, and you can drag files straight into the prompt for the same effect. Between those, the auto-shared selection, and the shared diagnostics, most of the "let me explain where everything is" preamble from terminal-only sessions just disappears.

This is also where your standing setup compounds. The IDE hands Claude situational context — what you're looking at right now. Your CLAUDE.md hands it standing context — the commands, conventions, and do-NOTs that apply every session. And anything you've wired via MCP servers is available here too, because — same agent. The three layers stack.

The honest trade-off: when plain terminal wins

The extension is not a mandatory upgrade, and some good workflows skip it deliberately. If you live in tmux, you already have your own pane and session management and the IDE window is just in the way. If you're working over SSH on a remote box, the plain CLI is the natural fit. Plenty of people run Claude Code as a pure terminal tool forever and lose nothing that matters to them.

Where the extension earns its keep is visual review: the moment Claude starts proposing multi-file changes you actually want to read before accepting, the native diff viewer stops being a nicety and starts being the reason you catch mistakes. If your sessions are mostly one-file edits and quick questions, the terminal alone is fine.

Cursor and Windsurf

Both are VS Code forks, and the same extension mechanism works in them — run the CLI in the integrated terminal, connect the same way. If your editor of choice is one of those, everything above carries over.

Where this fits

Editor integration is the visibility layer. The other half of getting real work out of the agent in your editor is what you feed it — and that's economics plus instructions.

Economics: IDE workflows make it easy to hand Claude more context and bigger tasks, which burns more tokens. I keep the meter sane by running against the GLM Coding Plan — again, https://z.ai/subscribe?ic=BWTG6TRYYQ is our disclosed referral link, and the setup is in the GLM API guide.

Instructions: a better window into the agent doesn't fix vague prompts. For the repeated stuff, can your workflows into a custom slash command so one keystroke plus one command runs the whole routine. And for writing instructions that actually steer — reusable, high-signal, testable — Meta-Prompt Architect is the pack I use so every token, cheap or not, does real work.

Wire it up, hit Ctrl+Esc, and stop approving diffs you haven't read.

How to Use Claude Code Hooks (Turn Rules Into Guarantees)

Thryx — Sun, 12 Jul 2026 19:00:55 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

You put "always run prettier after editing" in your CLAUDE.md. Claude does it... most of the time. Then one long session it edits nine files, formats six, and you find the mess in the diff. That gap — between a rule the model usually follows and a rule that always runs — is exactly what hooks close.

What Claude Code hooks actually are

Hooks are shell commands you define that Claude Code runs automatically at lifecycle events — before a tool call, after one succeeds, when you submit a prompt, when a session starts, when Claude finishes responding.

The key word is deterministic. Instructions in a CLAUDE.md file are suggestions the model reads and usually honors — but it can overlook one mid-task. A hook isn't read by the model at all. The harness executes it, every time the event fires, no judgment involved. Rules become guarantees.

That's the whole mental model: CLAUDE.md for judgment calls, hooks for laws.

Where hooks live

Hook config goes in your settings JSON, and there are three layers:

~/.claude/settings.json — user-level, follows you across every project.
.claude/settings.json — project-level, committed to the repo so your whole team gets the same guardrails.
.claude/settings.local.json — project-level but personal; gitignored.

Don't want to hand-edit JSON? Run /hooks inside a Claude Code session and it walks you through setting them up interactively. I'd still learn the raw shape, though, because that's what you'll be debugging later.

The config shape

Here's a working starting template — a hook that auto-formats any file Claude edits:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$(jq -r '.tool_input.file_path')\""
          }
        ]
      }
    ]
  }
}

Three parts to understand:

The event (PostToolUse) — when this fires. The main ones: PreToolUse (before a tool call — this one can block it), PostToolUse (after a tool call succeeds), UserPromptSubmit (when you submit a prompt), SessionStart, Stop (when Claude finishes responding), Notification, PreCompact, and SubagentStop.
The matcher ("Edit") — which tool triggers it, for the tool events. Tool names like Edit or Bash, patterns like "Edit|Write" to catch both, or an empty matcher to fire on every tool.
The hooks list — { "type": "command", "command": "..." } entries, the actual shell commands to run.

How a hook sees what's happening

Every hook receives the event's data as JSON on stdin. For tool events that includes the tool name and its input — the file path being edited, the bash command about to run. jq is the standard way to pull fields out:

jq -r '.tool_input.file_path'   # the file an Edit is touching
jq -r '.tool_input.command'     # the command a Bash call is running

That's what the template above is doing — reading the edited file's path off stdin and handing it to prettier.

Exit codes: the control channel

Your hook talks back to Claude Code through its exit code:

Exit 0 — continue normally. For UserPromptSubmit and SessionStart hooks, whatever the hook prints to stdout gets added into Claude's context — which means a hook can inject information at the top of a session.
Exit 2 — block the action. The tool call doesn't happen, and whatever you printed to stderr is fed back to Claude so it knows why and can adjust course instead of retrying blindly.

Exit 2 is the power move. It's the difference between "please don't touch that folder" and a bouncer at the door.

Four recipes worth stealing

1. Auto-format after every edit. The template above. Swap prettier for black, gofmt, whatever your stack formats with. You'll never review an unformatted diff again.

2. Block edits to protected paths. A PreToolUse hook with matcher "Edit|Write" that reads the file path from stdin and exits 2 if it matches something sacred:

#!/bin/bash
path=$(jq -r '.tool_input.file_path')
if echo "$path" | grep -qE '\.env|migrations/'; then
  echo "Blocked: $path is protected. Edit the source template instead." >&2
  exit 2
fi
exit 0

Save that as a script, point the hook's command at it. The stderr message matters — Claude reads it and reroutes instead of slamming into the wall repeatedly.

3. Audit-log every Bash command. A hook matching Bash that appends jq -r '.tool_input.command' to a log file. When you're running Claude with broad permissions, that trail is how you sleep at night.

4. Desktop notification when Claude needs you. A Notification event hook that fires your OS's notifier. You stop babysitting the terminal and go do something else until it pings you.

Two warnings before you go hook-happy

Hooks run with your user's full permissions. The harness executes your command as you — a buggy hook can do real damage, same as any shell script with your keys. Keep commands simple, and test every hook standalone in a terminal before wiring it into settings.

Hooks add latency on every matching event. An empty matcher on PreToolUse means your script runs before every single tool call. Keep hooks fast and scoped to the tools they actually care about.

Why this matters more on cheap models

Here's the un-obvious payoff. Deterministic enforcement matters most when the model is weakest. I run a lot of sessions against GLM models to keep costs near zero — setup is in how to set up Claude Code with the GLM API — and a lighter model drifts from soft instructions more than a frontier one does. Hooks don't care. The formatter runs, the protected path stays blocked, the audit log fills up, regardless of what the model remembered. The plan I use for that is the z.ai GLM Coding Plan — full disclosure, https://z.ai/subscribe?ic=BWTG6TRYYQ is a referral link that helps fund our compute; same plan either way, just through our link.

Hooks plus a cheap backend is the combo: the guardrails are free and mechanical, so the tokens only pay for actual thinking.

Where this fits

Hooks are the enforcement layer of a Claude Code setup, and they slot alongside the other layers. Your CLAUDE.md holds the judgment-call rules and project facts; custom slash commands turn your repeated workflows into one-word triggers; hooks make the non-negotiables actually non-negotiable. Wire the three together and the tool stops needing supervision.

The remaining variable is instruction quality — hooks enforce the hard rules, but everything else still rides on how well you prompt. Meta-Prompt Architect is the pack I use to turn rough intent into reusable, high-signal instructions, so the tokens I'm paying for (referral-funded or not) do real work instead of thrashing.

How to Schedule Claude Code to Run Daily in the Cloud (Routines)

Thryx — Sat, 11 Jul 2026 19:00:46 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

Everything I run, I eventually want to run without me. A daily content job, a nightly dependency check, a weekly report — the moment a task is worth doing on a schedule, the machine executing it shouldn't be a Windows tower that somebody has to leave on. Claude Code's answer is routines: scheduled cloud agents that fire on a cron, do real work in an isolated cloud session, and leave before you wake up. I set my first ones up today; here's the honest walkthrough.

What a routine actually is

A routine is a stored job: a prompt, a GitHub repo, a model, and a schedule. When the cron fires, Anthropic's cloud spins up a fresh sandboxed session — its own clone of your repo, its own tools (shell, file read/write, search), optionally your claude.ai MCP connectors — and hands your prompt to the agent as if you'd typed it. The agent works until the job is done, and the whole session is saved so you can read exactly what it did at claude.ai/code/routines.

Two properties define the shape of everything you build with them:

Isolation. The session starts with zero context. It hasn't read your chat history, doesn't know your conventions, and can't see your machine. The prompt has to carry everything.
A repo is the world. The git checkout is the filesystem the agent lives in — and also its best output channel, because the agent can commit and push. A routine that writes its results into the repo builds a ledger; the next run reads it and continues.

Creating one with /schedule

Inside Claude Code, type /schedule and describe the job in plain language. It will walk you through the pieces:

The task. What the agent should do each run, and what "done" looks like.
The repo. Which GitHub repository gets cloned into the session.
The schedule. A 5-field cron expression, always in UTC, minimum interval one hour. Say a local time and it converts — but double-check the conversion; a "9am daily" job that quietly runs at 9am UTC is a classic.
The model. Defaults to Sonnet, which is right for most scheduled work — save the heavier models for jobs where judgment is the product.

For a one-shot instead of a recurring job ("run this once tomorrow at 6am"), the same flow takes a single future timestamp; the routine fires once and disables itself. That one-shot mode is quietly the best feasibility tool in the product — before committing to a daily job, I fire a single probe run whose only task is "try the pipeline and report what breaks." Today's probe told me in one run whether a cloud sandbox could render video with native canvas and ffmpeg. Twenty minutes of cloud time answered what could have been a day of guessing.

The prompt is a system prompt — write it like one

Because the session starts cold, routine prompts are a different genre from chat messages. Mine follow a fixed skeleton:

Identity and mission — one paragraph, including what the deliverable is.
Numbered steps — where things live in the repo, which scripts to run, in what order.
Failure policy — diagnose briefly, try one workaround, then record the blocker instead of thrashing.
The deliverable's exact shape — if I want JSON, I show the JSON.

This is the same discipline as writing a CLAUDE.md file or a custom subagent: instruction quality is the product. An unattended agent amplifies whatever you wrote — precision compounds, vagueness compounds faster.

The secrets problem (and the pattern that solves it)

Here's the constraint that shapes real automations: the cloud session cannot access your local environment variables or files. Whatever credential your job needs — an upload token, an API key — has to reach the routine some other way, and committing it to the repo is not that way. Ever.

The pattern I use: a keyed relay. The real credential lives server-side as a secret in a tiny hosted service (a Cloudflare Worker's free tier does this for $0), and the service exposes one narrow endpoint gated by a random key. The routine's prompt carries only that key. My video pipeline works exactly like this: the Worker holds the YouTube OAuth token as a Worker secret; the routine renders the video in the sandbox and POSTs the file to the relay; the relay does the upload. If the routine's key ever leaked, the blast radius is "someone could post a video to my channel" — not "someone owns my Google account." Scope the key to the action, keep the credential where nobody's prompt can see it.

OAuth'd MCP connectors attached to the routine solve the same problem for supported services (mail, drives, and similar) without any hosting at all.

What runs well on a schedule

The jobs that have earned a cron in my setup, all on the theme of building while you sleep:

Content generation — a nightly drafter that stocks a queue for a human-or-stronger-model gate to review in the morning. Nothing auto-publishes ungated; the routine removes the blank-page step, not the judgment step.
Feasibility probes — one-shot runs that answer "can this environment do X" with facts.
Repo hygiene — dependency bumps, dead-link checks, stale-issue triage, committed as a report or a PR.
Ledger updates — pull yesterday's numbers from an API, append to a data file, push.

Cost note, disclosed as always: routine runs consume your plan's usage like any session, so the economics of daily automation depend on what your tokens cost. I keep the heavy drafting lanes on the z.ai GLM Coding Plan — that's a referral link, it helps fund our compute, and the plan costs the same with or without it; the setup is in how to set up Claude Code with the GLM API. Cheap tokens for the bulk lanes, scheduled cloud runs for the judgment lanes.

Where this fits

Routines are the last piece of a stack where each layer removes one manual step. CLAUDE.md encodes your standing rules, hooks enforce them mechanically, subagents parallelize the work — and a routine removes the final human act of showing up to start it. What's left is the part that was always the real job: writing instructions good enough to run unattended. That's the exact muscle Meta-Prompt Architect trains — turning rough intent into the tight, reusable, failure-aware instructions that a 6am cloud session with zero context and nobody watching can actually execute. On the GLM plan (referral above, disclosed) or any backend: the prompt is the program now. Write it like one.

How to Post to LinkedIn from a Script: the 15-Minute OAuth Walkthrough (2026)

Thryx — Fri, 10 Jul 2026 19:00:49 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

Every scheduled-posting tool for LinkedIn wants a subscription for what is, underneath, four HTTP requests. I assumed the DIY route was gated behind a partner-program application and weeks of waiting — that's the reputation. Then I actually did it today, and the whole thing — app creation to a verified working token — took about fifteen minutes, because the two products a personal posting script needs are instant self-serve checkboxes. Here's the exact walkthrough, including the one place LinkedIn tried to trip me.

Step 1: Create the app (you need a company page)

Go to linkedin.com/developers/apps and create an app. The one real prerequisite: LinkedIn requires a company page to verify the app against. If the page is yours, this is a non-event — you approve the verification request as the page admin and it's verified instantly.

Don't let the company-page requirement confuse you about what you're building: the app is verified against the page, but with the scopes below you'll be posting as yourself, to your own member feed.

Step 2: Request the two instant products

On the app's Products tab, request:

Share on LinkedIn — this is what grants the w_member_social scope, the permission to create posts as a member.
Sign In with LinkedIn using OpenID Connect — this grants openid profile email, which you need to fetch your own member id.

Both are instant self-serve grants: tick the checkbox, accept the LinkedIn API Terms, done. No review queue, no application essay.

One boundary I hit while poking around: the Community Management API — the product that lets you post as an organization/page rather than as yourself — cannot share an app with other products. It demands its own dedicated app. So if page-posting is in your future, plan on a second app; don't try to bolt it onto this one.

Step 3: Add a redirect URL (it can literally 404)

On the Auth tab, add an authorized redirect URL. Here's the part that saves you from standing up a server: any https URL on a domain you control works — even one that returns a 404.

Why: LinkedIn's OAuth flow ends by redirecting your browser to that URL with ?code=... appended. For a one-time personal-token setup, you don't need the page to do anything — you just need to read the code parameter out of the address bar after the redirect lands. A dead path on a domain you own is a perfectly valid OAuth redirect target for this purpose.

While you're on the Auth tab, note your Client ID and Client Secret — and keep the secret out of your repo. Same rule as giving credentials to a scheduled cloud agent: secrets live in environment variables or server-side stores, never in git.

Step 4: The consent URL

Build this URL (one line) and open it in a browser where you're logged in to LinkedIn:

https://www.linkedin.com/oauth/v2/authorization
  ?response_type=code
  &client_id=YOUR_CLIENT_ID
  &redirect_uri=YOUR_REDIRECT_URL
  &scope=openid%20profile%20email%20w_member_social
  &state=SOME_RANDOM_STRING

Approve the consent screen, and LinkedIn bounces you to your redirect URL with ?code=... in the query string. Copy that code — it's single-use and short-lived, so move straight to the exchange.

The gotcha that got me: LinkedIn may interrupt the consent flow with a security checkpoint asking you to verify your email if the login looks unusual to it. It's not a bug in your setup — complete the verification and the flow resumes.

Step 5: Exchange the code for a token

Form-encoded POST:

curl -X POST https://www.linkedin.com/oauth/v2/accessToken \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d grant_type=authorization_code \
  -d code=THE_CODE_FROM_THE_REDIRECT \
  -d redirect_uri=YOUR_REDIRECT_URL \
  -d client_id=YOUR_CLIENT_ID \
  -d client_secret=YOUR_CLIENT_SECRET

The response gives you access_token, expires_in: 5184000, an id_token, and the granted scope. That expires_in is the quiet headline: 5,184,000 seconds is two months. For a personal script, that means re-doing this dance six times a year, not building refresh-token plumbing on day one.

Step 6: Verify the token and get your member id

curl https://api.linkedin.com/v2/userinfo \
  -H "Authorization: Bearer <your-access-token>"

This returns your name plus a sub field — your member id. Your author URN for posting is urn:li:person:<sub>. If this call returns your own name, the OAuth leg is done and verified.

Step 7: The post call (per LinkedIn's docs)

Honesty checkpoint: everything above this line I ran today and watched succeed, through the userinfo verification. The post call itself I'm giving you as documented by LinkedIn — I validated the token and URN, not an actual published post yet.

Per the docs, posting is:

curl -X POST https://api.linkedin.com/rest/posts \
  -H "Authorization: Bearer <your-access-token>" \
  -H "X-Restli-Protocol-Version: 2.0.0" \
  -H "LinkedIn-Version: YYYYMM" \
  -H "Content-Type: application/json" \
  -d '{
    "author": "urn:li:person:YOUR_SUB",
    "commentary": "Posted from a script.",
    "visibility": "PUBLIC",
    "distribution": { "feedDistribution": "MAIN_FEED" },
    "lifecycleState": "PUBLISHED"
  }'

Two headers people miss: X-Restli-Protocol-Version: 2.0.0 is required, and LinkedIn-Version must be a valid YYYYMM API version string — check LinkedIn's versioning docs for the current active version and substitute it for the placeholder above.

Where this goes next

A two-month token plus a four-request flow is exactly the shape of thing you hand to an agent. Mine drafts in a cheap lane — I run bulk generation on the z.ai GLM Coding Plan (that's a referral link, it helps fund our compute, and the plan costs the same with or without it; setup in how to set up Claude Code with the GLM API) — and the posting step is just this walkthrough's step 7 wearing a cron. If you want the whole loop hands-off, the same pattern as scheduling Claude Code to run daily in the cloud applies: keep the LinkedIn token server-side, let the scheduled job call a narrow relay. And if the script needs richer context than "write a post" — your voice, your topics, your rules — that's a job for a proper instruction stack, the kind you build once with something like an MCP server feeding your agent real data and a prompt written like it has to survive unattended. Meta-Prompt Architect is my tool for exactly that last part: turning "post good stuff to LinkedIn" into instructions precise enough that the 2-month token is the only thing you ever have to touch.

How to Create a Skill in Claude Code

Thryx — Thu, 09 Jul 2026 21:19:15 +0000

This is a cross-post — the original (and any updates) live at broke2builtai.com.

The first time I watched Claude Code reach for a skill I hadn't told it to use — read a folder, run the script inside it, and hand back the finished thing — the difference from a slash command finally landed. A slash command waits for you to type it. A skill waits for the situation. Claude decides. That one shift is the whole feature, and building one takes about five minutes once you know where the file goes.

Here's the entire thing end to end, including the one gotcha that decides whether your skill ever actually fires.

What a Skill actually is

A Skill is a folder with a SKILL.md file inside it. The Markdown holds instructions; the YAML frontmatter at the top holds a name and a description. That description is doing the most important job in the whole file: Claude reads it to decide, on its own, whether the current task warrants invoking the skill. Nothing else you write matters if the description doesn't get you picked.

That's the mental model to hold onto: a custom slash command is a prompt you trigger by typing /name; a skill is a procedure Claude triggers when the context matches. Same reusable-instructions idea, opposite trigger.

Where the file goes

Two locations register, exactly like commands and subagents:

Project skill — .claude/skills/<skill-name>/SKILL.md inside the repo. Committed, so your whole team gets it.
Personal skill — ~/.claude/skills/<skill-name>/SKILL.md in your home directory. Follows you across every project on your machine.

Each skill is its own folder, and the folder name should match the name in the frontmatter. A loose SKILL.md sitting somewhere else won't be picked up.

The minimum viable skill

Create the folder and the file:

.claude/skills/pytest-runner/SKILL.md

Then write the two-part file — frontmatter, then body:

---
name: pytest-runner
description: "Run, generate, or debug pytest tests for this project. Use when the user asks to run the test suite, add tests for a function, or figure out why a test is failing."
---

When invoked:

1. Run the suite with `python -m pytest -q` and read the output.
2. If tests fail, show the failing test names and the assertion, then propose the smallest fix.
3. When asked to add tests, match the existing style in `tests/` — same fixtures, same naming.
4. Never mark work done until the suite is green; paste the passing summary line.

That's a working skill. No install step, no registration file — Claude Code discovers it from the folder. Next time you ask something that matches the description, Claude reaches for it.

The one gotcha: the description IS the trigger

If your skill never fires, the description is almost always why. Claude selects a skill by matching the task against the description text, so a vague description: helps with tests competes badly against everything else in context and usually loses.

Write the description like a trigger list, not a summary. Name the concrete situations, the verbs, and the file types:

Weak: description: Testing helper.
Strong: description: Run, generate, or debug pytest tests. Use when the user asks to run the suite, add tests for a function/module, or diagnose a failing test.

The body can be as long and detailed as you want — that content only loads once the skill is invoked. The description is the part that's always competing for selection, so that's where the precision has to live. This is the same discipline behind writing a good system prompt for an agent: be explicit about when, not just what.

Bundling scripts, references, and templates

The reason a skill beats a slash command for real workflows is that the folder can hold more than instructions. Anything you drop in the skill directory is available to Claude when the skill runs:

.claude/skills/release-notes/
├── SKILL.md
├── template.md          # the format to fill in
└── changelog-parse.py   # a helper the skill runs

Reference them from SKILL.md by relative path — "fill in template.md", "run changelog-parse.py on the git log" — and Claude reads or executes them as part of following the skill. That's how a skill packages an entire procedure (a format + a script + the rules for using them), not just a paragraph of prompt. If the script needs a tool that prompts for permission, the same permission and hooks rules apply as anywhere else in Claude Code.

Skill vs. slash command vs. CLAUDE.md — which to reach for

Three ways to give Claude Code reusable instructions, and they're not interchangeable:

CLAUDE.md — always-on. Loaded every session. Use it for standing facts about the project (here's how to write one). The cost is context: everything in it is paid for on every turn.
Slash command — you-triggered, on demand. Use it when you decide the moment (/review, /deploy).
Skill — model-triggered, on demand. Use it when you want Claude to notice the situation and reach for the procedure itself.

The practical rule: standing context goes in CLAUDE.md; a procedure you invoke yourself is a slash command; a procedure Claude should invoke when it sees the trigger is a skill. Getting that split right is what keeps your everyday context lean while still having deep procedures on tap.

The honest workflow

Build the skill small, then watch whether it fires. Ask something that should trigger it and see if Claude reaches for it — if it doesn't, tighten the description and try again. That loop takes a couple of minutes and is the only real test that matters, because a skill that never gets invoked is just a Markdown file nobody reads.

This site runs its own automation on Claude Code and free-tier AI. If you're wiring up cheap models to do real work, we run everything on GLM's free tier through the z.ai Coding Plan (referral link — it funds our compute); a tight SKILL.md is exactly the kind of harness that keeps a cheaper model on rails.