brycewatson.com / goals

Goals and the work behind them

The goals below record the outcomes I'm working toward and the logged work behind them. The September 11 Command account describes a shared kit of rules, skills and guard hooks being tried in project sessions, with the earlier dispatcher off. That account records the start of the trial, not its result.

23 goals across 4 areas · generated goal data: 5 Oct 2026

Area explanations reviewed September 12, 2026. The generated goal data and individual change dates below have their own dates.

Each goal says what done looks like, why it matters, and how the work gets done, backed by session history where there is any and a plan where there isn't.

Want the projects themselves? They're on the Work page. Have a defined engineering problem? See Direct Consulting.

autonomous operator

One kit every project session inherits, and the goals they work toward. 11 goals

Command's September 11, 2026 account describes a shared kit of rules, skills and guard hooks inherited by project sessions. It records day one of a seven-day trial with the earlier dispatcher off. The sessions take responsibility for their own work and background workers; the trial tests whether that needs less separate coordination.

why

I want to find out whether the useful rules and tools can travel with each project session, leaving me more attention for the project itself. The dated account explains the comparison and what the trial must show; it does not yet report a result.

how · the 11 goals below

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

ongoing active

Command, the kit every Claude Code session on my projects inherits: the rules that decide what a session may do without me, the skills that carry work from research to a merged pull request, and the goals file they work toward. Anything risky still waits for my word. The kit is Command's fifth shape since May 2026, grown out of a standalone operator, and its seven-day trial runs to 17 September.

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.
98 entries behind this
Build a signal engine that turns my own chat history into targeted improvements

milestone active

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.
20 entries behind this
Operate that signal engine and measurably cut my own recurring friction

ongoing resting

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.
6 entries behind this
Make my operator's behavior reliably evolvable through skills and durable rules

ongoing resting

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.
40 entries behind this
Make my operator's actions context-aware instead of one-size-fits-all

ongoing resting

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.
14 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 resting

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.
24 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.
61 entries behind this
Hold everything I publish to a hard quality and honesty bar

ongoing resting

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.
14 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, a public record of my work. 6 goals

This site carries my writing, project accounts, reading list and published work-log snapshots. I want someone deciding whether to work with me to find specific evidence and understand when it was checked. The goals here describe that aim; they are not a claim that every page or weekly report is current.

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.
44 entries behind this
Ship the next most valuable blog post each week, fact-checked

ongoing resting

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.
14 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.
2 entries behind this
- Made a post declare its genre before it is written, and fail the build if it does not aug 16
- 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.
41 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 resting

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.
14 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. 2 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 2 goals below

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

ongoing resting

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
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

The latest structural updates to the public goal set. 1 latest update

Retired · effective aug 7

Retired DemandForge and its live vertical after the venture's evidence no longer supported continuing the investment.

retired Detect rising category demand before it peaks

retired Build category-authority content that ranks

retired Measure organic demand on demand

retired Turn the demand engine into revenue

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

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

earlier changes (2)

Added · effective 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
later retired 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

Split · effective jun 22

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

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

recently shipped

all published work, by week

latest published week An activity summary by project archive Every weekly report, by week

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

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

What changed