Work log — 2026-03-02
What shipped today
Two themes today: decision capture and skill consolidation around GitHub primitives.
Decision logging. Created DECISIONS.md in the paulos repo, following the same template used across polymathic-h, authexis, and Textorium. Backfilled 4 recent decisions (skills rationalization, issue decomposition for grindability, MCP server retirement, Fastmail IMAP choice). Added decision-logging steps to 5 skills so significant trade-offs get captured durably during execution — /prep, /exec, /grind, /scout, /create all got lightweight “log decisions” steps with clear guidance on what’s worth logging vs. what’s routine.
Milestone integration and skill consolidation. Feedback from the Textorium v1.0.2 release exposed a gap: milestones existed in GitHub but nothing in the skill pipeline surfaced or enforced them. Added milestone awareness to /ship (reports progress after closing issues), /start (shows milestone completion at session start), /close (includes release progress in work logs), /exec (nudges milestone assignment), and /create (proactively suggests milestones instead of silently defaulting to backlog). Updated /list to group issues by milestone.
Then came the bigger restructure: consolidated skills around GitHub’s native primitives. /create, /prep, /exec, /list were absorbed into a single /issue skill with mode flags (--create, --prep, --exec, --list). /roadmap was retired and replaced by /milestone (create, close, list). /release was rewritten to handle GitHub Releases specifically (tags, release notes), separate from milestone lifecycle. Each new skill includes an intent routing table so the AI maps natural language (“exec 42”, “close the milestone”) to the right mode. Added a routing table to the global CLAUDE.md so all projects see the mapping immediately. Net result: 19 skills → 17, with cleaner alignment to how GitHub actually works.
Completed
- DECISIONS.md created with 4 backfilled entries and decision-logging steps in 5 skills
- Milestone integration across
/ship,/start,/close,/issue,/list - Skill consolidation:
/issue(absorbs create+prep+exec+list),/milestone(absorbs roadmap),/release(rewritten) - Retired 5 skills:
/create,/prep,/exec,/list,/roadmap - Cleaned all stale cross-references in remaining skills
- Added skill routing table to global CLAUDE.md
Release progress
- March 2026: 10/12 closed, due 2026-03-30
Carry-over
- #160 — Background mode for /prep, /exec, and /grind skills (note: issue title still uses old skill names)
- #119 — Explore using Authexis content services to create blog posts
Risks
- Skill routing transition. The old skill names (
/prep,/exec,/create,/list) are baked into work logs, issue specs, and muscle memory. The CLAUDE.md routing table and intent routing in/issueshould handle this, but watch for sessions that get confused — especially in projects that haven’t been opened since the changeover.
Flags and watch-outs
- Issue #160 title references old skill names (
/prep,/exec) — may want to update to reflect the new/issue --prep,/issue --execconvention, or leave it since the AI routes intent anyway. - Global CLAUDE.md was updated outside the paulos repo (at
~/.claude/CLAUDE.md). This isn’t version-controlled. If it gets reset, the routing table disappears and other projects may struggle.
Next session
/issue --exec 160— background mode for skills. This is the remaining March milestone work. Investigate what “background mode” means in the context of Claude Code skills./issue --exec 119— Authexis content services for blog posts. Lower priority.- Test the skill consolidation in another project (authexis or Textorium) to verify the routing works cross-project.
- Consider updating #160’s title to reflect the new skill naming convention.
Why customer tools are organized wrong
This article reveals a fundamental flaw in how customer support tools are designed—organizing by interaction type instead of by customer—and explains why this fragmentation wastes time and obscures the full picture you need to help users effectively.
Infrastructure shapes thought
The tools you build determine what kinds of thinking become possible. On infrastructure, friction, and building deliberately for thought rather than just throughput.
Server-side dashboard architecture: Why moving data fetching off the browser changes everything
How choosing server-side rendering solved security, CORS, and credential management problems I didn't know I had.
The work of being available now
A book on AI, judgment, and staying human at work.
The practice of work in progress
Practical essays on how work actually gets done.
Nothing is finished until you say it is
Continuous delivery removed the endings from work. That felt like progress. But without formal completion, you lose the ability to say what you actually accomplished — and more importantly, what you're done thinking about.
Your biggest problems are the ones running fine
The most dangerous failures in any system — technical or organizational — aren't the ones throwing errors. They're the ones that appear to work perfectly. And they'll keep appearing to work perfectly right up until they don't.
The work that remains
When AI handles implementation, the human job shifts from doing the work to understanding the work. Speed without understanding is just technical debt with better commit messages.