brycewatson.com / goals

My goals, and the work behind them.

The goals below are the outcomes I'm driving toward, grouped by area, each with the verified work behind it. Most of the work runs through Command, an autonomous operator I built on Claude Code: I hand it a goal, it plans the work, and once I approve, it files issues for my projects to implement.

29 goals across 4 areas · updated 27 Jul 2026

Each goal carries what done looks like, why it matters, and how the work actually gets done, grounded in real sessions or, where there is no history yet, a plain forward plan.

autonomous operator

One operator that runs my standing goals across every project. 11 goals

The operator I run everything through. Command watches all my projects, ranks what needs my attention, and manages my standing goals across the whole fleet. For each goal it researches and plans the work, then files those plans as issues for the project that owns the code to carry out. It also experiments with improvements to how each project is set up, proving every change moved a real number before it counts. All of it runs on plans I approve, stopping only at the calls that truly need me.

why

It is the multiplier on the rest of my work. Build the operator once and every project inherits it, so my time goes to the decisions only I can make.

how · the 11 goals below

Build an always-aware autonomous operator that runs my standing goals with minimal hand-holding

ongoing active

One operator, Command, watches every project at once, holds my standing goals, and drives each one forward on its own: it ranks what needs me, plans the work, and acts within fixed limits, stopping only at the few moves that genuinely need a human. Each goal carries its own autonomy level, so routine work runs freely while anything risky waits for me.

why
It is the parent every other goal here is built on. Get the operator right once and every project inherits its planning, safety, and proof, so my time goes to the calls that genuinely need me instead of re-deciding the same things project by project.

how
Real sessions this week built the pieces: a proof loop that applies a fix, measures it, then keeps or rolls it back; machine-checkable directives that carry a proven change to other projects only after it holds on one or two first; and an inventory that promoted strong project skills into my global set. Four limits stay fixed throughout, on spending, publishing, contacting new people, and anything irreversible.
62 entries behind this
Build a signal engine that turns my own chat history into targeted improvements

milestone resting

A working engine that reads my own chat logs, git, and pull requests across every project, merges them into one ranked, continuously updated list of recurring friction, and turns the top of that list into per-project fixes I can approve. It observes and proposes; the project that owns the code makes the change.

why
It turns my own chat logs, commits, and pull requests into ranked, provable improvements, so the operator gets better from real evidence instead of my guesses. No single project sees all of my history at once, so this cross-project view is the one job only Command can do.

how
I built it in phases, from an evaluation harness and the first ingest-and-rank engine, through a remediation-and-proof loop, fleet directives, and a continuous metric feed. A sealed A/B test on real-site clones showed a proposed rule changed a real agent's behavior, at about Fisher p=0.001.
7 entries behind this
Operate that signal engine and measurably cut my own recurring friction

ongoing active

The signal engine runs as a standing loop, not a one-time build: it keeps surfacing real friction across my projects and proposing fixes, and it is judged on one thing, whether the measured trend of that friction actually falls over time. Success is a number going down, not a feature shipped.

why
This is where the operator has to prove it was worth building. An engine that never shows it cut anything is unproven, so this is the goal that makes the work on every other project pay off instead of just piling up.

how
The engine itself is built through its metric-feed phase, and the proof machinery already runs: a metric floor recorded before any fix, and a sealed behavioral test that showed a proposed rule measurably steered a real agent. What is left is the part that proves the whole goal: define the baseline, then track the trend across real weeks.
4 entries behind this
Make my operator's behavior reliably evolvable through skills and durable rules

ongoing active

My operator's evolvable behavior lives in editable skill files and durable rules, not buried in code, and my corrections route automatically to the right place: a persona, a skill, or the charter. Changing how it works means editing a rule, not rewriting a program.

why
A fix made once in a shared skill or rule applies to every project I run, instead of being re-solved from scratch each time the same problem shows up. That is what makes the rest of the operator worth maintaining.

how
I relocated every skill to a single live source so there is one place to edit, added a path that routes an "always do X" correction into a persona, skill, or charter home, and made every review leave a commit-pinned trail, so the reasoning behind each change stays on record.
15 entries behind this
Make my operator's actions context-aware instead of one-size-fits-all

ongoing active

Every action my operator proposes is a prompt built from that project's real current state and editable by me before it runs, not a generic template stamped onto every project. It runs several of these at once, since I usually have around five projects in flight.

why
A generic prompt makes the model guess at context, so the work is only as good as the default template. Composing each prompt from real project state is what should make the operator worth using across the projects I run in parallel, instead of a wrapper that sends the same instructions everywhere.

how
I built a per-action composer that shapes each prompt from live project state, with the plain template kept as the fallback. The current focus is proving the composed prompt beats the template, one surface at a time, before I rely on it everywhere.
9 entries behind this
Keep an accurate, self-researched profile of how I actually work

ongoing resting

A profile of how I actually work, built from my own chat logs rather than my self-description, that I can read and correct and that updates over time as my habits change. It also captures my writing voice, so anything drafted in my name sounds like me.

why
A correct model of how I work makes the tooling's decisions better, both what it proposes to me and how it phrases things in my name. Most of my tooling reads this profile, so when it is accurate, everything that depends on it gets more accurate too.

how
I built profile generation from chat history, then carried a single operator profile into Command with a store and a reviewable document I can edit. Recurring corrections route back into it, so it stays current with how I actually work instead of going stale.
2 entries behind this
- Closed the desktop packaging experiment jul 11
- Scoped an onboarding wizard for the operator jul 10
Mine my own chat history for the methods that actually improve results

ongoing active

My own Claude transcripts are a record of which workflows measurably help, so I can fold the winners back into my configuration. The question it answers is concrete: which of my methods actually move results, judged on outcomes rather than impression.

why
Every correction I mine becomes a rule, skill, or memory, so the next session starts better off than the last. It is the cheapest way I have to keep getting better, because the evidence is already sitting in my own history.

how
It started as an open-source tool I built to mine corrections from my transcripts and patch my global config. That project is shelved now, but the practice runs fleet-wide through four shipped skills that search my history, run retrospectives, and turn cross-project friction into proposed fixes I review before they ship.
17 entries behind this
Keep a live status picture across all my projects

ongoing active

At any moment I can see every active project's git status, CI, open pull requests, and stale work in one place, without re-checking each repo by hand. It is read-only by design: it tells me what is true, it does not change anything.

why
Everything else the operator does sits on top of this. Safe autonomous work can only be proposed from an accurate, current picture of what is actually happening everywhere.

how
A free always-on watcher records git, CI, and session state across my projects, so the operator reads that instead of re-deriving it each time. On top of it, a read-only team inspects my active projects, and a skill summarizes any single one on demand.
24 entries behind this
Hold everything I publish to a hard quality and honesty bar

ongoing active

Nothing I publish reaches the public unless it reads cleanly, stands on its own research, and every claim in it is literally true. Private references are stripped before anything ships.

why
It is the basis for trusting an operator that publishes on my behalf. If anything it ships can be invented, sloppy, or leak something private, then none of it is worth reading.

how
Before anything publishes I run a fact-check pass and an adversarial review that sends each claim back to its source to try to break it, and an anonymization scan that strips private names and details. The next step is turning this from a routine I run into an automatic gate every publish has to pass.
9 entries behind this
Measure my operator's agents on valid-plan rate, tool-call accuracy, and steps and cost against a human baseline

milestone new goal not started

Command's agents get judged on metrics I do not formally track today: how often a plan is valid, how often a tool call is correct in each category, and how many steps and how much cost a run takes against a human doing the same work. The point is a scoreboard, so a change to the operator can be shown to help or hurt rather than argued about.

why
Today I judge the operator's agents by how their work reads to me, which cannot tell me whether a change made them better or only different. The human baseline is the part that makes the numbers mean something, because it answers whether the agent is worth running at all.

how
Nothing is built yet. This came out of holding my own systems up against a book on AI engineering, which named the agent metrics I had skipped. The first step is deciding what each metric means and what Command has to start recording to compute it, since the run records it keeps today do not carry steps, cost, or tool-call outcomes. Then I fix the human baseline before changing anything, so it cannot be drawn after the fact to flatter a result.
Harden the tools that send and publish against prompt injection

milestone new goal not started

Every tool that can send or publish something is hardened against instructions smuggled in through the content it reads, across ShopForge and Command. The scope is deliberately the write actions, the ones whose mistakes reach other people.

why
A read-only mistake costs me a wasted run, but a send or publish mistake reaches someone else and cannot be taken back. These systems read listings, pages, and replies I did not write, so that content has to be treated as untrusted input rather than as instruction.

how
Not started. The plan is to inventory every write-action tool in both systems first, since I cannot harden what I have not listed, then treat fetched content as data at each of those boundaries and test each one against real injection attempts before calling it done.

this site

brycewatson.com, kept honest and current. 6 goals

brycewatson.com itself: my public, honest record of how I actually work, kept current and accurate as the first thing anyone deciding whether to hire me sees. It carries the writing, the project pages, the reading list, and an auto-updating weekly work log. The goals in this area are the standing commitments that keep it honest, from the writing bar to a clean lint gate.

why

It is where the claims I make elsewhere get backed up by something checkable. Recent, dated, verifiable work is more convincing than a pitch, and this site is where people find it and decide to reach out.

how · the 6 goals below

Ship an auto-updating weekly work log as honest proof of recent work

ongoing active

A live weekly work-log page that shows every interactive coding session from the past week, each one written up in plain language, with private and personal work redacted by an explicit rule rather than quietly dropped. The numbers are re-derived from git, not asserted.

why
Instead of describing my work, it shows it: a recent, dated record anyone deciding whether to hire me can check. The numbers come from git, so there is nothing to take on faith.

how
It is shipped and live. A script pulls each week's work from my session handoffs and git, I write up the items, and a redaction gate fails the build if anything private slips through. Every Sunday a skill opens a review pull request; nothing publishes until I merge it.
34 entries behind this
Ship the next most valuable blog post each week, fact-checked

ongoing active

A steady weekly cadence where each new post is the most valuable thing I have to write about, drafted in my own voice and shipped only after it survives review. Some weeks there is nothing worth posting, and that is fine; I will not post filler to keep a streak.

why
A regular, fact-checked posting habit is the evidence that I am doing the work, and it gives people who might hire me something concrete to read. Each post adds to the public record.

how
I mine my own conversation history and existing posts to pick the next post worth writing, draft it in my voice, then run a review pipeline of parallel subagents covering technical accuracy, fact-checking, editing, and visual checks, fixing what they flag and looping until the reviews come back clean.
7 entries behind this
Raise the writing bar on this site against engineers I admire

ongoing resting

Every post here is held to one bar: does it read like an engineer I respect wrote it, clear and plain and in my own voice, with no filler. The bar is a real comparison, not a vague aspiration.

why
My writing is the main thing visitors judge me on. If it is weak, the work behind it gets discounted, so this stays an ongoing standard rather than a one-time cleanup.

how
I benchmark my voice against engineers whose writing I admire, turn what I notice into concrete, checkable guidelines, then re-edit existing posts against them. A recent post went through a full improvement pass and a register fix, with a from-first-principles rewrite still ahead.
1 entry behind this
- Fact-checked the public AI engineering argument jul 8
Keep this site clean, accurate, and current

ongoing active

I keep the site from going stale, wrong, or half-finished: links, project pages, and claims stay current, private client references stay anonymized, and the working tree never sits dirty with stray files.

why
The site's whole value is that it is accurate, so a single stale claim or leaked private name makes every other claim here suspect. This upkeep is what keeps the rest of these goals credible.

how
I fix what has drifted as part of regular upkeep. Recently I retired a project page after its hosted service shut down, built a new one, ran a dark-mode and consistency pass across the whole site, and added a working-tree-hygiene rule so finished work is never left uncommitted.
11 entries behind this
Keep this site's lint gate green

milestone resting

Linting passes clean on this site, down from 208 errors. The piece still ahead is a continuous-integration check to hold that line so the gate cannot quietly drift back.

why
A green lint gate keeps every later change building on clean ground. Before this, 208 errors had piled up with nothing enforcing the gate, and that kind of quiet drift compounds fast.

how
I cleared the backlog from 208 errors to zero, then widened linting to cover the automation scripts and hooks so new code is checked too, not just the app. The one piece still open is a CI step that runs the lint on every change; today the pipeline only runs the build.
1 entry behind this
- Drove the repo's lint gate back to zero errors jun 18
Keep the public reading list current as a signal of practical learning

ongoing underway

The reading page stays current: what I am reading now, on top of the full list of what I have already finished. My recent picks lean toward practical books on AI, agents, and going to market; the finished list is broader, running from hard science fiction to engineering and psychology. Everything on it is a book I actually read, not one I mean to get to.

why
It is an honest signal of how I keep learning, the practical picks most of all. It is worth keeping because every entry is a book I actually read, so it shows what I have really worked through rather than what I wish I had.

how
I move books between currently-reading and finished as I read them, and pull each cover automatically through a Google Books script instead of sourcing them by hand.

open source

Tooling and contributions, in the open. 4 goals

My best tooling and contributions, put where anyone can read and run them: an MIT-licensed library of the Claude Code skills and hooks I use every day, a complete and tested reference MCP server, fixes sent upstream into the official MCP SDK, and a reusable SEO index-validation skill. These are working artifacts, not write-ups about them.

why

Open, forkable work is the most honest proof of how I build, because anyone can check it. And sharpening a shared tool once compounds across every project I run, so the open work and my own work improve together.

how · the 4 goals below

Maintain and grow an open-source library of Claude skills and hooks

ongoing active

A public, MIT-licensed repository of my Claude Code skills and hooks that anyone can clone and run with nothing but Python and Node. My machine runs a live copy deployed straight from this repo, so the repo is the one place my global tooling actually lives.

why
When I improve a skill once, every project I run gets the better version. Open-sourcing it also lets anyone read exactly how I build instead of taking my word for it.

how
I publish the repo and grow it commit by commit: a multi-agent review loop, session end and resume, chat-history search, transcript retrospectives, and image generation, plus contributor docs, a skill spec, and a security model. A sync engine keeps the repo and my live machine in step, and when a project-specific skill proves out, I generalize it into a global one.
9 entries behind this
Get a contribution accepted into the official MCP Python SDK

milestone underway

A change of mine is accepted into the official Model Context Protocol Python SDK, the one I build on daily. The bar is a merge into the real project, not a fork of my own.

why
A change in a project I depend on is proof anyone can open and check: the pull request, its tests, and its passing checks are all public. It carries weight because the fix is already written and under review upstream, not hypothetical.

how
I forked the repo and opened pull request #2041 to fix issue #1671: exposing the progress callback in the server-session methods that make long-running calls, the sampling and elicitation calls, so they can report progress, with new tests covering it. The pull request is open and awaiting maintainer review.
Build a polished, fully-tested MCP server demo as public portfolio proof

milestone underway

A complete MCP server demo, live and public: a forkable starter kit with a working reference implementation, a documentation site, and a green test suite. It is meant to be read, cloned, and run, not just linked to.

why
It is portfolio proof of MCP engineering, the kind of working artifact a prospect can fork and run instead of taking my word for it. The 74 tests and the live repo make the claim checkable.

how
It is already shipped: a FastMCP starter kit that wraps any REST API as typed, validated MCP tools, with Pydantic v2 models, four reference tools, 74 passing tests, a public repo, and a docs site. The ongoing work is keeping it current as the protocol and the framework move.
Turn SEO index-validation into a reusable skill any site can use

milestone underway

A single global skill that can check crawl and index health on any deployed site, not just mine, and diagnose and fix why specific pages are not getting indexed. I can run it on any project instead of re-solving indexing per site.

why
Indexing problems are easy to miss: the page exists, but no one can find it because it never got indexed. Generalizing the fix once means I diagnose it once and reuse it on any site, instead of redoing the work each time.

how
It grew out of a real Search Console indexing fix on one of my sites, then got pulled into a reusable global skill: a dependency-free probe script that checks status codes, redirects, soft 404s, and the sitemap, paired with a written playbook for the Search Console side. The remaining step is verifying it across more sites before I call it done.

ventures

Independent products I build on my own. 8 goals

Independent products I am building toward real users and revenue, on my own rather than for a client. I share each goal here in general terms and hold back the specifics (names, niches, numbers) until it is real. The test that matters is the plainest one: do people use it and pay for it.

why

They are my bet on durable income that does not depend on selling my hours. Holding back the details until there is something real to show is how I keep this area honest instead of hype.

how · the 8 goals below

Build a near-autonomous shop that sells print-on-demand art with minimal hands-on time

ongoing active

A system that designs the art, builds and checks the listings, publishes them, and markets the shop, running almost entirely on its own so my part is a short daily review. The goal is a shop that actually sells, not just one that runs.

why
If the system can run a real shop on its own, the work I put in once keeps producing sales without more of my time. That is what I am after: income that grows faster than the hours behind it, and it only counts once it makes real money.

how
I rebuilt it around per-shop branding, automated image checks that catch defects before anything publishes, and listing optimization for search. The honest status is that the hard part is still ahead: turning visits into the first sales.
7 entries behind this
Detect rising category demand before it peaks

ongoing from a split resting

The part of DemandForge that watches a category's search demand and flags what is rising before it saturates, so the content effort goes where attention is heading, not where it already crested.

why
Picking the right rising sub-topics early is most of the battle in organic demand; arriving after the peak means competing for attention that is already leaving.

how
A category-demand trend index plus a plateau detector that scores terms and flags when growth flattens. The honest status is that it surfaces signals; proving they reliably lead to revenue is the next step.
9 entries behind this
Build category-authority content that ranks

ongoing from a split resting

The content engine: pages and pillars that earn category authority and rank, built on a repeatable structure rather than one-off posts.

why
Organic demand needs content that search engines and readers trust; authority is what turns a rising category into traffic the engine owns.

how
A rising-category content pillar, a scored long-tail calendar, and authority signals like real sources and transparency. The part still ahead is converting ranking into an owned audience.
6 entries behind this
Measure organic demand on demand

ongoing from a split active

The instrumentation: pull traffic and search performance for the engine whenever needed, so demand is measured rather than guessed.

why
A demand engine you cannot measure is one you cannot improve or prove; on-demand metrics are what make each iteration honest.

how
A metrics skill that reads traffic and Search Console on demand, plus fixes that keep attribution accurate. The plumbing works; tying the numbers to revenue is the open thread.
10 entries behind this
Turn the demand engine into revenue

milestone from a split resting

The capitalization step: turn the organic demand the engine creates into revenue through own-product, affiliate, or lead paths.

why
Demand only matters if it pays; this is the milestone that decides whether the reusable engine is a business or a demo.

how
Wire the demand to monetization paths and measure first revenue. The honest status is that this is the least-finished stage: the engine is being built before the money is proven.
2 entries behind this
- Activated the venture's business data-inquiry path toward its keep-or-kill gate jul 3
- Diagnosed whether the demand engine was living up to its potential jun 22
Launch and grow PlumageDispatch, the engine's first live vertical

ongoing newly public active

PlumageDispatch is the first live vertical built on the DemandForge engine: a real, public site applying the demand-creation playbook to a single niche from scratch.

why
A reusable engine only proves itself on a live vertical; PlumageDispatch is where the engine meets real traffic, real content, and the first revenue test.

how
Stand up the site, run the content and demand-signal work against the niche, and instrument it. The status is live and growing; the open question is whether it converts to revenue.
4 entries behind this
Stand up evaluation on DemandForge's research output, and decide where vector retrieval earns a place across my systems

milestone new goal not started

Two things: a harness that scores the research DemandForge produces, so its quality is measured rather than eyeballed, and a settled answer on where vector retrieval belongs across my systems, reached by evaluation instead of preference.

why
The demand engine's research is the input everything downstream depends on, so if it is wrong the content built on it is wrong too, and today nothing scores it systematically. The retrieval question matters because my systems currently load context just in time instead, and I want that choice tested rather than assumed.

how
Not started. The order is the harness first, because the retrieval decision needs a scoring method before it can be decided on evidence. Without one I would just be picking the architecture I already prefer.
Add cost tracking to ShopForge and replace one felt model choice with a measured leaderboard

milestone new goal not started

ShopForge reports what each run costs, and one model choice I currently make on feel gets replaced by a small private leaderboard that scores the candidates on my own tasks. One choice, measured, not a general benchmarking project.

why
A shop meant to run on its own has to earn more than it spends, and I cannot tell whether it does without knowing what a run costs. The single model choice is scoped small on purpose, so I find out whether measuring beats guessing before spending effort on the rest.

how
Not started. Cost tracking comes first because the leaderboard needs a cost number to score against, then I take the one model decision with the most riding on it and run the candidates on my own tasks rather than on public benchmarks.

What changed

How the goal set itself has shifted this week. 1 update

Added · week of jul 24

Published four goals from the next steps in my AI engineering post. Three come from its sequenced plan: evaluation on the demand engine's research alongside the vector-retrieval decision, injection-hardening for the tools that send and publish, and cost tracking with one measured model choice. The fourth, the agent-evaluation metrics, is the next step its agents section named.

Measure my operator's agents on valid-plan rate, tool-call accuracy, and steps and cost against a human baseline
Harden the tools that send and publish against prompt injection
Stand up evaluation on DemandForge's research output, and decide where vector retrieval earns a place across my systems
Add cost tracking to ShopForge and replace one felt model choice with a measured leaderboard

earlier changes (1)

Split · week of jun 22 - 28

Split one broad demand-engine goal into four specific sub-goals, and published the engine's first live vertical.

retired Build a reusable engine that creates organic demand for a niche from scratch

Detect rising category demand before it peaks
Build category-authority content that ranks
Measure organic demand on demand
Turn the demand engine into revenue
published Launch and grow PlumageDispatch, the engine's first live vertical

recently shipped

all verified work, by week

weekly work log By project, with the receipts archive Every weekly report, by week

My goals, and the work behind them.

autonomous operator

Build an always-aware autonomous operator that runs my standing goals with minimal hand-holding

Build a signal engine that turns my own chat history into targeted improvements

Operate that signal engine and measurably cut my own recurring friction

Make my operator's behavior reliably evolvable through skills and durable rules

Make my operator's actions context-aware instead of one-size-fits-all

Keep an accurate, self-researched profile of how I actually work

Mine my own chat history for the methods that actually improve results

Keep a live status picture across all my projects

Hold everything I publish to a hard quality and honesty bar

Measure my operator's agents on valid-plan rate, tool-call accuracy, and steps and cost against a human baseline

Harden the tools that send and publish against prompt injection

this site

Ship an auto-updating weekly work log as honest proof of recent work

Ship the next most valuable blog post each week, fact-checked

Raise the writing bar on this site against engineers I admire

Keep this site clean, accurate, and current

Keep this site's lint gate green

Keep the public reading list current as a signal of practical learning

open source

Maintain and grow an open-source library of Claude skills and hooks

Get a contribution accepted into the official MCP Python SDK

Build a polished, fully-tested MCP server demo as public portfolio proof

Turn SEO index-validation into a reusable skill any site can use

ventures

Build a near-autonomous shop that sells print-on-demand art with minimal hands-on time

Detect rising category demand before it peaks

Build category-authority content that ranks

Measure organic demand on demand

Turn the demand engine into revenue

Launch and grow PlumageDispatch, the engine's first live vertical

Stand up evaluation on DemandForge's research output, and decide where vector retrieval earns a place across my systems

Add cost tracking to ShopForge and replace one felt model choice with a measured leaderboard

What changed