Goals and the work behind them

how · the 11 goals below

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

  ongoing active

  items / wk

  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.

  ▸ 79 entries behind this

  • Autonomous remediation loop ran every firing and reported its top item honestly aug 8
  • Made Command’s knowledge browser something you can act from, not just read aug 7
  • Closed the dispatch blind spots a dropped piece of work exposed aug 7
  • Ran Command as a live control loop, dispatching a fleet of child sessions and merging what came back clean aug 6
  • Derived a replacement demand engine from the traffic that already works, ran the cheapest test first, and it said stop aug 6
  • Audited what control theory is actually buying Command, in plain value terms aug 6
  • Fixed the nightly ops shift so it can do work, and measured whether it did aug 6
  • Fixed the credential self-check so it can tell a dead login from a healthy one aug 4
  • Scheduled scouting and venture reads ran on their own cadence aug 3
  • Autonomous remediation loop ran every firing, and kept meeting blocked work aug 2
  • Tracked the terminal windows interrupting play back to the ops guardian jul 30
  • Diagnosed why the operator's backlog only grew, and built the missing actuator jul 27
  • Pinned the operator's health readout to its real breaker and stopped it scraping logs jul 27
  • Built and scheduled an autonomous controller to drain the work queue, with a reframe pass after three failed attempts jul 26
  • Shipped the morning letter and caught a fix that had been credited but never written jul 26
  • Fixed a false-positive class in the operator's cross-project safety guard jul 25
  • Shipped the Saturday morning letter and landed the held Phase 1 pull requests jul 25
  • Diagnosed a permission-prompt hang in unattended runs and hardened the allow-rules jul 24
  • Evaluated the morning letter and corrected its headline claim about an unattended run jul 24
  • Shipped the first morning letter assembled and merged with nobody at the keyboard jul 24
  • Settled business-formation questions with a fact-checked research pass jul 23
  • Built the compliance upkeep loop for the operator's daily letter jul 23
  • Built the automated morning-letter assembly through the full ship-it chain jul 23
  • Enforced the operator's delegation-of-authority walls and fixed a bug that blocked auto-merge jul 23
  • Morning-letter shift skipped cleanly because the day was already covered jul 23
  • Built the operator's core spine: a leverage-ranked work queue and signature folder jul 22
  • Audited and reconciled the operator's subsystems after the charter reorganization jul 22
  • Landed Phase 1 of the ratified operating charter, including the daily letter task jul 22
  • Designed the operating model that reorganizes every project under one owner jul 21
  • Built the thin-Fable Codex execution layer and recovered the work after a crash jul 20
  • Rescanned open competitions and accelerators for a fit jul 20
  • Ran the weekly PlumageDispatch metrics read jul 20
  • Prepared and verified a Codex task packet for a new operator skill jul 20
  • Nightly knowledge capture found a blind spot in its own preflight jul 15
  • Held a verified nightly knowledge batch at the human review gate jul 14
  • Distilled a night of sessions and ran the review the merge gate requires jul 13
  • Ran the venture's Monday metrics read jul 13
  • Captured the final nightly knowledge changes jul 12
  • Reconciled the knowledge pull requests jul 11
  • Added outcome instrumentation to nightly knowledge capture jul 11
  • Kept a nightly wiki change behind human review jul 11
  • Retrospected a private delivery workflow jul 11
  • Ran a read-only knowledge lint jul 11
  • Started reconciling overlapping knowledge changes jul 11
  • Built the decision deck for the fleet observatory jul 10
  • Stopped nightly knowledge capture from waiting on me jul 10
  • Researched a new demand signal without overstating the evidence jul 10
  • Converted a meeting recap into durable operating context jul 10
  • Turned article commitments into tracked goals jul 10
  • Paused a nightly ingest behind an existing review jul 10
  • Reviewed the day before choosing more work jul 10
  • Reviewed the observatory as one stacked system jul 9
  • Expanded the observatory design across the fleet jul 9
  • Added visible state to unattended merges jul 9
  • Turned the fleet observatory from a sketch into a prototype jul 9
  • Added a flight recorder to the observatory jul 9
  • Turned next steps into a goal registry jul 9
  • Registered the evaluation-harness goal jul 9
  • Built the live fleet observatory pipeline jul 9
  • Added a drift guard to goal selection jul 9
  • Searched past meeting context before acting jul 9
  • Traced an issue discussion back to its source jul 9
  • Started tracing an issue notification jul 9
  • Held a nightly ingest at the review boundary jul 8
  • Nightly knowledge capture hit its runtime limit jul 8
  • Started the fleet observatory concept jul 8
  • Added review flags to autonomous work jul 6
  • Nightly knowledge capture ended before completion jul 6
  • Began a community-participation program to build real distribution jul 5
  • Researched, planned, and began the operator's ground-up redesign jul 1
  • Shipped the redesign's beachhead: a live venture demand instrument jul 1
  • Hardened the operator's backend across reliability, security, and performance jun 22
  • Split the demand-engine goal into its real stages in the operator's registry jun 22
  • Reprioritized the standing objectives toward high-leverage work and aligned them with the site's goals jun 20
  • Fixed an operator backend crash-loop by normalizing objective state at the store boundary jun 19
  • Audited my projects and assets for the highest-leverage place to focus jun 12
  • Scoped a cross-project leverage audit jun 12
  • Fixed stale status docs a repo inventory had flagged jun 11
  • Worked out the cleanest way to keep Claude Code up to date jun 9

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

  milestone resting

  items / wk

  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.

  ▸ 10 entries behind this

  • Weekly knowledge-base lint ran clean; the worktree sweep stayed blocked on an unmerged script aug 1
  • Recovered durable facts the knowledge base had dropped, and corrected its own counts jul 31
  • Stopped the operator's own dispatched work from starving the nightly knowledge digest jul 27
  • Added proof-integrity rules to delegated work jul 9
  • Proved Rung 1 of the signal engine's behavioral finish line jun 16
  • Pre-registered an abort to keep the proof case uncontaminated jun 12
  • Pre-registered the first proof case, and caught the measurer false-proving while validating it jun 11
  • Fused raw signals and made the operator's directives machine-checkable jun 9
  • Wired the signal engine into the live project registry jun 9
  • Added the continuous metric feed the proof loop measures against jun 8

• Operate that signal engine and measurably cut my own recurring friction

  ongoing resting

  items / wk

  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

  • Autonomous remediation tick ran and recorded a clean no-op jul 26
  • Built a self-repair loop that fixes its own detected failures, then retraced two sessions of friction jul 26
  • Remediation tick recorded a second honest no-op against a stale backend jul 26
  • Built the proof loop: apply a fix, measure it, then prove it or roll back jun 8

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

  ongoing active

  items / wk

  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.

  ▸ 18 entries behind this

  • Hardened the machinery Command relies on to merge safely: CI signals, worktrees, and child-repo work aug 6
  • Stopped the test suite from reporting machine load as a code defect aug 6
  • Mapped every operating rule to where it is actually enforced, and guarded against the references going stale aug 4
  • Shipped a startup improvement that always hands back the next best action jul 20
  • Fixed the Codex worker skill's commit contract to match how sandboxed runs behave jul 20
  • Scoped a pilot to push build and review work onto a second agent runtime jul 15
  • Mined an outside knowledge-graph walkthrough for ideas worth adopting jul 13
  • Mapped the next leverage points in harness engineering jul 10
  • Made community participation a reusable skill jul 9
  • Planned the harness-engineering research pass jul 9
  • Worked out where a costlier top-tier model actually earns its place jul 1
  • Implemented the operator's self-improvement backlog against live code jun 30
  • Verified Claude Code's log-retention setting holds, then handed off a post on the default jun 25
  • Audited the operator's goal definitions and added research-first discipline to the delegation skill jun 24
  • Synced the delegation skill to its shipped code and cleared the type errors an adversarial review surfaced jun 18
  • Inventoried my global Claude skills and promoted project ones to the global set jun 14
  • Built the directive surface and the unattended watcher's verdict write jun 10
  • Made directives first-class so a proven fix can roll out across the fleet jun 8

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

  ongoing resting

  items / wk

  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

  • Orchestrated a blog-post pipeline as a thin controller over subagents jul 20
  • Rescanned the competitive wedge jul 13
  • Turned attention constraints into product defaults jul 12
  • Investigated the reflection feature jul 12
  • Built a repeatable pain-mining workflow jul 6
  • Rescanned the competitive wedge jul 6
  • Explored customer-review pain mining jul 6
  • Added an external-client privacy filter and leverage-first objective ranking to the operator jun 20
  • Gave the operator a cross-project-write guard and a delegate-the-what posture jun 18

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

  ongoing resting

  items / wk

  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

  items / wk

  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.

  ▸ 19 entries behind this

  • Studied how Command manages its own child sessions, then shipped the fixes the study named aug 7
  • Recovered the knowledge base’s nightly upkeep after it had silently stopped landing aug 3
  • Ran the nightly wiki digest and corrected its drain-rate reading to zero jul 25
  • Ran the weekly wiki lint and flagged a stale focus snapshot jul 25
  • Ran the nightly wiki digest and kept subagent chatter out of the knowledge base jul 24
  • Unblocked a wiki digest that had been stuck for several nights jul 23
  • Nightly wiki digest skipped a night and escalated a stuck review jul 22
  • Finished a stuck wiki pull request and found a blind spot in its duplicate guard jul 21
  • Ran the nightly wiki digest and distilled the week's sessions into the knowledge base jul 20
  • Planned the next memory consolidation pass jul 11
  • Outlined a duplicate-memory cleanup jul 11
  • Made the model-routing rules explicit jul 10
  • Tightened the long-running coordination session contract jul 10
  • Designed a lower-context operating profile jul 10
  • Reduced the operator's memory burden jul 10
  • Refined the lower-context prompt contract jul 10
  • Split token-efficiency research into bounded tasks jul 9
  • Ran a self-improvement retro grounded in the operator's own session history jun 30
  • Compared two models across my chat history and fed the gaps into my tooling jun 13

• Keep a live status picture across all my projects

  ongoing active

  items / wk

  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.

  ▸ 31 entries behind this

  • Closed a blind spot where Command could not see several of its own repositories aug 6
  • Delivered the morning letter each day and gave it new bands for what needs attention aug 6
  • Redesigned the knowledge browser around how it actually gets used day to day aug 5
  • Activated the watchdog that notices when the machine stops, and fixed the defects that would have made it cry wolf aug 3
  • Nightly ops shift ran read-only against parked checkouts, and flagged a missed routine aug 1
  • Scheduled scouting and venture reads ran on their own cadence jul 27
  • Morning letter now reports publish lag and knowledge-base freshness jul 27
  • Nightly ops shift halted honestly when the live backend predated its own interface jul 26
  • Ran a full status briefing and cleared most of the open pull-request backlog jul 25
  • Nightly ops shift ran read-only because its machinery was still unmerged jul 25
  • Nightly ops shift stayed read-only with its infrastructure still on an open pull request jul 24
  • Fixed several ways the startup session board missed unfinished work jul 21
  • Synced live project health into the operator jul 10
  • Reoriented to the live operator state jul 9
  • Tried to recover a missing operating log jul 6
  • Rebuilt the wiki browser into something actually explorable jul 5
  • Gave the wiki browser an at-a-glance landing overview jul 5
  • Evaluated the newly scheduled nightly wiki digest and merged it jul 5
  • Built the wiki's publish workflow toward a public website jul 4
  • Ran a screenshot-grounded usability review of the wiki browser jul 4
  • Built the operator an LLM-maintained wiki of everything it is working on jul 3
  • Gave the wiki ingest and query skills plus a backfill of past work jul 3
  • Extended the wiki with concept, topic, and dormant-project coverage jul 3
  • Migrated project memories into the wiki without orphaning their provenance jul 3
  • Closed a wiki contradiction and added evidence-backed topic pages jul 3
  • Reconciled the day's sessions and cleaned up stale worktrees jul 2
  • Root-caused the backend's runaway memory growth as an auth outage, not the cache jun 23
  • Traced unexpected image-API spend to a shared key, not the project blamed for it jun 22
  • Checked that the scheduled jobs across projects are firing correctly jun 21
  • Archived stale project repositories to keep the operator's attention on live work jun 19
  • Inventoried a sibling project's repo and documentation state jun 11

• Hold everything I publish to a hard quality and honesty bar

  ongoing resting

  items / wk

  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.

  ▸ 10 entries behind this

  • Corrected a durable internal record that had gone false jul 30
  • Verified public-facing claims and realigned a blog post before publishing jul 24
  • Rebuilt the public profile around the site link, and cut a credit that did not hold up jul 13
  • Adapted the week's work into a social narrative jul 10
  • Added LinkedIn to the publishing system jul 9
  • Traced the site's distribution history jul 8
  • Distribution history search ended before completion jul 6
  • Added a continuous-integration quality gate and repaired the clean-clone install jul 4
  • Built an authoritative goal registry and drift guard to keep the public goal lens in sync jun 20
  • Dropped an over-claim from the publisher copy and recorded the dataset's archival DOIs jun 16

• 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

  no work yet

  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

  no work yet

  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.

how · the 6 goals below

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

  ongoing active

  items / wk

  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.

  ▸ 38 entries behind this

  • Stopped the weekly work-log page from republishing last week’s headline aug 6
  • Drove an in-flight honestweek feature through a closed control loop jul 30
  • Measured whether the work-log publish gate has caught real problems jul 27
  • Weekly work-log preview routine checked the pipeline end to end jul 27
  • Refreshed the weekly work log from the week's sessions jul 26
  • Diagnosed a parity defect between the two work-log generators jul 21
  • Fixed the work-log parity check when run from a sibling worktree jul 21
  • Fixed session attribution for work-log runs in a sibling worktree jul 21
  • Weekly work-log run halted at a data-verification gate before publishing jul 21
  • Traced a weekly report that looked broken, and found a real counting bug behind it jul 13
  • Fixed the weekly log's per-project session counts, which were misattributed rather than miscounted jul 13
  • Served the pending weekly refresh locally for review before merge jul 13
  • Started a local preview of the weekly refresh jul 13
  • Weekly routine stopped itself rather than open a duplicate report jul 13
  • Weekly preview matched the wrong pull request and named the rule that let it jul 13
  • Verified the weekly routine's prior run state jul 12
  • Weekly publishing stopped on a shared branch jul 12
  • Added deterministic safety gates to the weekly report jul 11
  • Turned a day-review gap into a requirements issue jul 10
  • Audited why the weekly report did not publish jul 6
  • Verified the previous weekly report in production jul 6
  • Reviewed the previous weekly report preview jul 6
  • Made every published work-log row trace to a real discovered session jun 30
  • Fixed the weekly work-log routine and delegated its follow-on repairs jun 29
  • Specced a narratives layer for the weekly report and filed the work jun 29
  • Stopped the weekly work log from silently dropping whole threads of the week jun 29
  • Fixed a set of honesty defects on the weekly report and goals pages jun 29
  • Added a previous-weeks selector to the weekly report panel jun 29
  • Enforced the published goal lens against the operator's authoritative registry jun 27
  • Switched this site's work log to be generated by the honestweek engine jun 26
  • Migrated the Weekly Work Log to a judgment-assisted, Claude-scheduled flow jun 22
  • Surfaced week-to-week goal changes on the goals page jun 22
  • Built a goal-based lens over the Weekly Work Log, gated by a publish registry jun 19
  • Added a goals measurement layer with two-way goal and session linking jun 19
  • Shipped the Weekly Work Log to production and surfaced it in the site nav jun 17
  • Researched and assembled a comprehensive set of goals from real project history jun 17
  • Brief planning session before the work-log build jun 14
  • Designed and built this weekly work-log page jun 14

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

  ongoing resting

  items / wk

  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

  • Drafted and opened a blog post on building an evaluation framework jul 24
  • Turned video notes into article directions jul 11
  • Published the AI engineering field guide jul 8
  • Published how the Command wiki works jul 6
  • Planned the public AI engineering article jul 6
  • Published a post on Claude Code's silent session-log deletion jun 26
  • Rewrote the Command write-up around its design decisions jun 11

• Raise the writing bar on this site against engineers I admire

  ongoing resting

  items / wk

  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

  items / wk

  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.

  ▸ 14 entries behind this

  • Ranked the next month on the site by what can actually produce paying work aug 7
  • Ran a maintenance pass across the site: image generation, the art lightbox, and search-console setup aug 5
  • Migrated the site's page-image generator off a deprecated model jul 30
  • Closed the remaining open site pull requests and regenerated goals from committed code jul 25
  • Assessed structured-data adoption across the active projects jul 25
  • Added a goals-only regeneration mode to the work-log build jul 24
  • Prepared the goal system for the public site jul 10
  • Cleaned up the public portfolio jul 9
  • Audited the site's current state before changing it jul 8
  • Filed the question surface as a product idea jul 6
  • Fixed the project name and metrics overlapping in the mobile weekly-report header jun 19
  • Eliminated weekly-report navigation flicker and a mobile popover clip jun 17
  • Added a working-tree-hygiene guardrail and cleared the scratch backlog jun 17
  • Shipped the Command project page and a site-wide dark-mode pass jun 13

• Keep this site's lint gate green

  milestone resting

  items / wk

  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

  no work yet

  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.

how · the 4 goals below

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

  ongoing resting

  items / wk

  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.

  ▸ 11 entries behind this

  • Checked the latest image model and corrected the premise before migrating the skills jul 30
  • Deployed the hardened session-portal skill over a stale installed copy jul 27
  • Fixed two record-keeping defects in the open-source skills library jul 26
  • Consolidated the global skill library jul 11
  • Made the skill library deploy consistently across runtimes jul 11
  • Audited the cross-session message portal jul 11
  • Implemented the safe cross-session portal jul 11
  • Added a reusable lower-context operating profile jul 11
  • Built a ship-it skill from the build prompt used across the most projects jun 25
  • Audited the live skills against the public mirror and back-ported the portability wins jun 23
  • Made the global skills repo open-source-ready and hardened the review-loop jun 15

• Get a contribution accepted into the official MCP Python SDK

  milestone underway

  no work yet

  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

  no work yet

  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

  no work yet

  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.

how · the 2 goals below

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

  ongoing resting

  items / wk

  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

  • Resolved a long-open merge conflict and merged a stalled pull request jul 25
  • Reframed the storefront around demand before automation jul 12
  • Ran a deep research pass on distribution for the storefront service jul 3
  • Diagnosed and fixed a batch of defects in the storefront automation jul 1
  • Explored where an illustration skill could improve the project's presentation jun 21
  • Reviewed and triaged the project's open issues jun 20
  • Cleaned up the store builder's repo and docs after a rebuild landed jun 11

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

  milestone new goal → not started

  no work yet

  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.