ATLAS

The commands I built for myself

Every self-built skill in one place, with what it does, how it is invoked and why it exists. Built because the collection outgrew the memory of it.

skills
35
groups
10
documented
100%
generated
2026-08-03

Costs & Billingwhat it costs, what gets invoiced2

Repo work in, German client invoice PDF out; AI cost stays internal

/bill

whyso tracked ledger work becomes a client invoice without leaking the AI internals

use whenbilling a client; invoice, dunning or status; checking market rates

full how + why

howA Node engine reads the per-repo cost and time ledger for tracked hours, mines git history for output, and reuses a shared repo-quality engine for health checks. The client flow is a multi-agent workflow that extracts client-facing features from git history, web-researches current market rates, and adversarially verifies each feature before rendering an invoice (HTML to PDF via headless Chrome) with a consecutive invoice number per German paragraph 14 UStG, an issued-invoice journal, escalating dunning letters, an embedded GiroCode payment QR, and a mail draft with the PDF attached. A hard rule separates the two views: the client deliverable never contains AI cost, token counts, or raw commit language.

whyBorn from a June 2026 self-analysis of his own Claude Code usage that produced a tooling roadmap with freelance billing as the next item. He already had a per-project cost and time ledger; this turns that tracked work into something a client can actually be invoiced with, without leaking the AI internals behind the work. It later proved solid enough to fork into a commercial skill product.

Per-project AI spend and engaged time, read from repo ledgers

/costs

whyto know which project eats the AI budget and how much engaged time it takes

use when"what did this cost", checking spend per project or month

full how + why

howA Stop hook parses each session transcript (including subagent transcripts), dedups messages by id, and upserts one CSV row per session and day into the repo ledger, with lockfile and atomic-rename writes. The reader walks the home directory at bounded depth, pruning node_modules and similar, to discover every ledger, then aggregates per project and time window; active time is the sum of gaps between transcript events, each gap capped at 15 minutes so idle stretches drop out. A backfill script replays the same math over all historical transcripts, idempotently keyed by session and date.

whyCame out of a usage-analysis session in June 2026 where he mined thousands of his own prompts and scoped a per-project cost CSV as a concrete need: knowing which project eats the AI budget and how much engaged time each takes. The hook, the reader and a full historical backfill across roughly 20 repos shipped within days.

Understanding a Repogetting into a project fast3

Instant repo mental model: stack, entry points, churn hotspots

/prime

whyre-entering repos cold was a recurring cost of multi-repo work

use whenentering an unfamiliar or old repo, getting up to speed fast

full how + why

howA read-only Node script detects the stack from package dependencies, lists runnable scripts, probes conventional entry-point paths, and builds a churn-hotspot table by counting file mentions in 90 days of git log with names. It adds a file-extension histogram, a contributor shortlog, and flags for a rules file and README; the command layer then reads the rules file and adds a two-line synthesis of the top gotchas.

whyBuilt in late June 2026 as part of a four-command dev-workflow batch whose stated purpose is making context switches cheap. His logs from that period show heavy multi-repo work with many parallel sessions, so re-entering a repo cold was a recurring cost.

BM25 search over ~1000 past sessions: find how you solved it

/recall

whyhis session history held solved problems being re-derived from scratch

use when"how did I solve X last time", searching your own history

full how + why

howA local incremental indexer extracts only the human prompts from every main-session transcript, excluding subagents and tool output, into a compact index, re-parsing only files whose mtime or size changed, written via atomic temp-and-rename. Ranking is a hand-rolled BM25 with a combined English and German stopword list and a boost for query terms appearing in a session opening prompt, since that signals intent. No embeddings, no API calls; nothing leaves the machine.

whyAn explicit roadmap item from a June 2026 push where he profiled his accumulated sessions and realised the history already contained solved problems being re-derived from scratch. The script header states the goal: answer how did I deal with this before, without re-deriving it.

What changed in this repo since your last working day

/since

whyturns session tracking into cheap re-entry when juggling many repos

use whenback in a repo after a break or overnight, catching up on changes

full how + why

howThe clever part is how it defines the last visit: it reads the repo AI cost ledger written by the Stop hook on every session and picks the newest ledger date before today, so the baseline is his own last working day rather than an arbitrary window. From that date it runs git log with numstat to list commits, sum added and deleted lines, rank the most-changed files, and show ahead and behind counts against upstream.

whyBuilt in the same late-June 2026 dev-workflow batch as the repo primer; the script header states the motivation, catch me up on this repo since my last visit. It deliberately piggybacks on the cost ledger he had just built, turning session tracking into a re-entry tool for juggling many repos.

Repo Qualitystate and health checks4

Repo health dashboard: AI cost vs git output vs quality grade

/build

whythe cost ledger said what a repo cost, not what the spend bought

use whenjudging a repo’s state, quality and investment

full how + why

howA single Node script merges four sources: the per-repo cost and time ledger for investment, git statistics like commits, churn and recency for output, read-only quality checks (typecheck, plus lint and tests only when their scripts and hooks are provably write-free), and hygiene probes for README, CI, lockfile and TODOs. Every check is time-boxed and guaranteed read-only; it never runs build, dev, format or deploy scripts, verified by an unchanged git status after a run.

whyGrew out of the cost and time ledger tooling: the ledger said what each repo AI assistance cost but not what it bought. This is the standalone investment versus output versus quality view, and the same engine powers the invoicing tool through its JSON mode, which is why the two are deliberately kept separate.

Read-only gate: env keys, unapplied migrations, toolchain drift

/preflight

whya deploy once shipped with generated migrations never applied

use whena quick repo health check before starting or committing

full how + why

howA Node script diffs the key names in the example env file against local env files (names only, values are never printed), compares git commit dates of the schema directory against the migrations directory to catch a schema changed after the last migration, checks the pinned Node version against the running one, and compares manifest against lockfile mtimes. It never fixes anything; the command layer names the concrete fix for each blocker instead.

whyBuilt, per its own header, to catch the things that silently break a deploy, above all the incident class where a deploy shipped while generated database migrations were never applied, because production deploys do not apply them automatically. That failure mode is called out by name in the command itself.

Deep plan via parallel explorers, attacked by critics first

/ultraplan-local

whyplans should be attacked by critics and survive a session killinferred

full how + why

howA pure prompt-orchestration skill: it fans out two to six read-only explore subagents in parallel to map relevant files, conventions, dependencies and prior art, drafts a fixed-format plan, then hands the draft to two adversarial critic agents, a feasibility skeptic and a risk skeptic, that must attack it with file and line evidence before the user ever sees it. The approved plan can be saved as a checkbox file so a looped session executes it step by step and survives a session kill.

whyNot stated outright in the sources. The local suffix and the design read as rebuilding a deep-planning workflow as a fully self-owned skill: plans are primed on each repo conventions and knowledge graph, and the adversarial critique stage plus the crash-resumable checkbox output plug directly into the loop tooling, so a plan is attacked before it is trusted and survives interruption.

8-lens parallel review; findings must survive a refutation agent

/ultrareview-local

whycounters invented review findings and silently partial auditsinferred

full how + why

howSpawns up to eight parallel specialist reviewers (correctness, security, performance, error handling, tests, style, architecture, docs), fed with read-only toolchain signals such as typecheck output. Findings are deduplicated, re-verified against the actual code line, and every would-be blocker or high goes to a skeptic subagent whose only job is to refute it; only refutation survivors keep high severity. Full audits partition the repo into units of one to two thousand lines ranked by git churn and security surface, tracked in an explicit coverage ledger so partial coverage is never silent.

whyNot stated outright; built the same day as its planning twin as the review-side counterpart. The mandatory refutation pass, the cap on nitpicks and the coverage ledger read as direct countermeasures to the two classic model-review failures: confidently invented findings, and audits that quietly cover only part of the code.

Shippinggoing live safely4

Storyboard to narrated, captioned demo video from real footage

/demo-video

whyfills the gaps a video-tooling audit found: narration, captions, formats

use whenproducing a social or demo video for a repo or product

full how + why

howA storyboard file is the single source of truth; stage scripts capture only real footage, using browser automation for screen recordings and a pseudo-terminal capture to keep true colours from CLI runs, then render narration with a text-to-speech API and align word timestamps locally against the exact same audio so captions and scene cuts cannot drift apart. Everything compiles deterministically into a Remotion composition, and ffmpeg finishes vertical, square and widescreen variants. Speech output is cached by a hash of text, voice and delivery, and every run appends its estimated cost to an append-only log.

whyDocumented: after building the publishing pipeline he audited his video tooling and found the gaps, no narrated UI footage, no captions, no format variants, and scoped and built this the same day to fill exactly those. Voice and energy controls were added right after the first narrator came out monotone.

Password-gated in-app launch board: channels, rules, ready copy

/launch-board

whya launch plan in markdown is unread at posting time, and public in a repo

use whenlaunching a product: where to post, what to post, and where the plan lives server-side

full how + why

howScaffolds a small Next.js admin route set backed by a private blob store: sessions are signed, expiring cookies keyed from the password via scrypt and compared in constant time, and an unset password makes every entry point answer 404 so forks expose nothing. The template code is committed but the channel plan and post copy are seeded through the panel and deliberately never enter version control; security is proven by running five live refusal checks against a real server, never by reading the code.

whyDocumented in the skill itself: a launch has dozens of channels whose rules get you removed, and a marketing plan in a markdown file is a plan nobody reads at the moment they are actually pasting a post. It also notes that a plan committed to a public repo is readable by the very audience it targets, so the content had to live server-side behind a password.

10-dimension production gate with a single go or no-go verdict

/predeploy

whyevery check encodes a real incident, like unapplied migrations in prod

use whenbefore a production deploy, a hard go or no-go call

full how + why

howA runner auto-loads every check module against a shared read-only context and renders the verdict, exiting non-zero on no-go; a broken check reports itself as a failure instead of crashing the run. Notable checks: schema versus migration date comparison, env key parity against the example file, private-key and live-token scans of tracked files, detection of focused or skipped tests, and a framework module that hunts catch blocks swallowing errors. A quick mode skips the heavy build, test and audit checks.

whyDocumented: the checks are explicitly tuned to real incidents from his own projects, including a deploy that went out with unapplied database migrations and an email integration whose failures were silently swallowed by empty catch blocks. Each incident became a permanent automated check so it cannot recur unnoticed.

Verify, branch, conventional commit, PR, with a confirm gate

/ship

whymechanizes his standing git rules so the discipline is the defaultinferred

use whenchange done: commit and PR without boilerplate

full how + why

howA strictly read-only Node engine reports branch versus default branch, changed and staged file counts, and auto-detects the repo verify command from its scripts, falling back to typecheck, lint and test chained. The command layer then performs the writes under hard rules: never commit straight to the default branch, never bypass a failing verify with no-verify or suppressions, and treat push and PR creation as outward actions requiring a fresh yes.

whyNot stated outright; planned alongside its sibling dev-workflow commands and mechanizes his standing git rules: a pinned commit identity, verify before commit, feature branches only, and explicit confirmation before anything leaves the machine, so the discipline is the default in every repo instead of something to remember.

Loops & Iterationiterating unattended5

One build error fixed at the root per loop tick

/build-pass

whya self-audit found unattended loops drifting; one verifiable fix per tick

use wheninside /loop: fix the build until it is green

full how + why

howA directive-only slash command with no engine script: it runs the repo verify or build script, falling back to a typecheck, picks the first error (or first warning if the build is clean), and fixes the root cause with suppressions explicitly banned. Designed to be composed as a timed loop, turning it into a self-terminating repair loop that reports the remaining error count each tick.

whyBorn from a self-audit: he mined thousands of his own prompts and analysed over a thousand past sessions, found unattended loop runs were his bottleneck, and shipped three one-iteration loop templates so overnight loops make one verifiable fix per tick instead of drifting.

Blind A/B critic loop against a real reference bar, hard-bounded

/gauntlet

whythe viral loop pattern was sound but unbounded, so the limits went into code

use wheniterating a landing page, UI, demo or code to reference level, with a budget and round cap instead of forever

full how + why

howA zero-dependency Node CLI owns all run state with atomic writes and a lockfile, and enforces the rules in code: the scoring rubric is frozen at round zero and later edits are refused, each round copies screenshots or test output into neutral-named A and B blind sets with a crypto-random assignment, and a fresh-context critic subagent judges only those paths. The verdict command validates the critic JSON against the frozen rubric and itself computes win, plateau, cap or continue; a local live board shows score trajectories and a stop button, and the builder must log a root-cause hypothesis before every fix.

whyHe asked for a critical review of a viral gauntlet-loop prompting pattern and concluded the blind fresh-critic mechanic is sound but the unbounded execution is not, so he built the bounded version with limits enforced by code rather than prompt. Its first real run then produced the core doctrine: a lazy-load screenshot bug briefly let his page win against a broken photograph of the reference, the round was abandoned, and capture-fidelity rules became permanent.

On-disk checkbox ledger so killed loops resume mid-plan

/loop-resume

whykilled loop runs re-derived their plan and repeated work

use whenlong unattended /loop runs that must survive rate-limit kills

full how + why

howOn first invocation it decomposes the task into five to fifteen independently shippable checkbox steps and writes them to a markdown ledger in a global store that outlives any session. Every iteration reads the file, takes the first unchecked box, does only that, flips it to done, and appends a timestamped log line; blocked steps are marked with a reason instead of being deleted. The file, not conversation memory, is the source of truth on resume.

whyDocumented in the skill itself: long loop runs die mid-flight from a usage cap, a crash or a closed tab, and the next iteration would re-derive the plan, drifting and repeating work. Built during the same session-analysis sweep that produced the loop templates.

One component polished per pass, design skills enforced

/pretty-pass

whyencodes the mandatory design-skill bar into a bounded loop step

use wheninside /loop: polishing one page’s UI and design

full how + why

howA directive-only slash command that force-invokes his design skill stack through the Skill tool before any edit, then applies concrete rules: spacing on a 4px grid, clear type hierarchy, one accent colour used for meaning, motion with correct easing. Functionality and copy stay untouched, the repo verify command must pass afterwards, and the scope is hard-limited to one component per pass so it composes safely with a loop.

whyPart of the same session-analysis batch as the other one-iteration loop templates: it encodes his mandatory design-skills rule into a bounded loop step, so unattended polish runs still meet the taste bar instead of redesigning wholesale.

LaTeX thesis: one defect fixed per iteration, build kept clean

/thesis-pass

whyso overnight loops polish the thesis one verifiable defect at a time

use wheninside /loop: working down LaTeX thesis defects

full how + why

howIt builds the document, captures warnings, then fixes one defect in strict priority order: LaTeX error, then undefined reference or missing citation, then an overfull or underfull box beyond a threshold, then a TODO marker, then a typo verifiable from context. Silencing tricks and commenting out content are banned; it must fix causes, and it stops after a single fix so it can run for hours under a loop without wrecking the manuscript.

whyBuilt in the same batch of one-iteration loop templates so his university thesis could be polished incrementally by overnight loop runs, one verifiable defect per tick instead of open-ended rewriting.

Projects & Applicationsnew projects and job applications3

Five adversarial personas plus a judge: go, pivot or kill

/council

whya cheap, brutal pre-commitment check before build time sinks into an ideainferred

use whenbrutally testing an idea BEFORE time goes in; later adding evidence, rechecking or appealing the verdict, ranking ideas

full how + why

howThe personas run in parallel and blind to each other, each bound to a fixed charter and a strict schema: position, three to five testable arguments, evidence needed, one kill-shot question, and a score on its own axis, with an explicit assumed line whenever the idea is silent on price, buyer or channel. A judge reads all cases and rules on argument strength, never averaging scores; everything persists to a per-idea directory with an assumptions ledger, so recheck, answer, evidence and appeal commands compute a delta against the previous verdict.

whyNo source states the trigger directly. The evidence-based reading: he ships a steady stream of side projects and wanted a cheap, brutal pre-commitment check before sinking build time into an idea. He built it test-driven through an eleven-agent workflow that fixed 27 findings, then judged it strong enough to fork into a public product two days later.

New client site from zero to sixty percent on the house stack

/scaffold-client-site

whyevery client site has the same shape but used to restart from zero

use whenstarting a new client site on the house stack

full how + why

howIt loads his mandatory design skills before generating any UI, gathers the brief in one batched question covering business, pages, brand direction with three concrete proposals and deploy target, detects the package manager by checking sibling repos for lockfiles, then runs the framework and component-library initialisers non-interactively with matching import aliases. It finishes by setting the required local git identity and shipping an on-brand first screen with a motion micro-interaction, never an empty template.

whyDocumented in the skill: his client sites all have the same shape, and each new one used to restart from zero; the skill exists so every new site starts where the last one left off. It came out of the same prompt-mining session that catalogued his most repetitive work.

Job posting in, tailored cover letter plus CV diff out

/tailor-application

whyprompt mining surfaced application writing as a recurring chore

use whenapplying to a specific job posting

full how + why

howIt ingests the posting, scraping it if given as a URL, extracts hard requirements, nice-to-haves, the implicit ask, and three to five keywords worth mirroring for both scanners and human readers, then maps each requirement to real attributable evidence from his background. Fabricating experience is explicitly banned and unmet requirements are flagged with the closest honest angle. Output language and register follow the posting, including German formal and informal address rules, and the CV output is a targeted diff, not a rewrite.

whyDocumented origin: a mining pass over 6,373 of his own prompts surfaced repeated application writing as a recurring chore, and a CV-tailoring skill was scoped in that same session so each application starts from a process instead of a blank page.

Study & Learningexams, corrections, progress1

Grades mock exams like a tutor, corrections written into the PDF

/klausur-korrektur

whyno tutor grades a mock exam, and an ungraded attempt teaches nothinginferred

use whenafter every written past or mock exam, before the next study block

full how + why

howEvery page is rendered to an image so the model actually reads the handwriting; an anchor pass extracts each question page and vertical position from the blank exam sheet so margin notes land beside the right answer. A PDF generator then rebuilds the document from a grading config: original pages untouched, a colour-coded correction column beside them, block summaries and an error-profile section. An overflow checker acts as a gate that must report zero clipped text, and an ink-colour scan separates answers written under exam conditions from ones added afterwards, which are scored separately.

whyBuilt during his own university exam prep for grading past-paper simulations: there is no tutor available to correct a mock exam, and an ungraded attempt teaches nothing. The blind versus added-later split is the core idea, because only the score achieved under exam conditions counts as the real measurement.

Workflow & Metahelpers and overview4

Speak a task, it runs in the background, get pinged when done

/bg

whythe missing verb between voice input, background runs and push pings

use whendelegating a task while you keep working, often by voice

full how + why

howRoutes the task to the Agent tool with background execution enabled, or a background shell job for pure shell work, choosing a real subagent type by task shape and passing the global rules through to the worker. The harness re-invokes the session on completion and the push-notification setting pings the phone, so nothing polls; recurring tasks are refused and redirected to the loop tooling instead.

whyA session that mined 6,373 of his own past prompts scoped voice and background automation as a feature to build. Voice input, push notifications and remote control were already switched on; the skill calls itself the missing verb that connects them: speak a task, it runs in the background, you get pinged.

One-page cheat sheet for the council idea court

/council-help

whyasking how council works risked triggering an expensive council runinferred

use when"how do I use /council", which council commands exist

full how + why

howPure display: the entire cheat sheet lives verbatim inside the skill file and is rendered as-is, under a hard rule that invoking it never runs anything, writes anything or starts a council. Only the explanation text may be translated to the session language; commands and file paths stay verbatim.

whyThe council skill had grown to roughly a dozen subcommands by the time it was forked and launched as a public product, and asking how council works risked accidentally triggering an expensive multi-agent run. A guaranteed side-effect-free card fixes both the recall problem and the misfire problem.

Local-only dashboard: costs, live sessions, skills, notes vault

/os

whymany sessions share one rate limit; one screen shows the fleet and its burn

full how + why

howA zero-dependency Node HTTP server bound to loopback only, reading everything live on each request: per-repo ledger files discovered by a bounded directory walk, session heartbeat files for the live fleet and burn meter, command frontmatter for the launcher cards, and transcript metadata for feeds and punchcards. Writes are limited to three endpoints: quick capture appends to the vault inbox, vault sync regenerates notes between auto-markers so hand-written text survives, and skill cards open a new terminal tab running the chosen command.

whyThe setup notes list a fleet cockpit among proposed tools and mark it delivered by this dashboard: he runs many concurrent sessions sharing one rate limit, and wanted a single screen showing what the fleet is doing and burning instead of tabbing through terminals.

Generated catalog of every self-built skill, grouped by purpose

/skills

whydozens of self-built commands outgrew memory; the registry is generated, never hand-keptinferred

use whenan overview of what exists and which skill fits

full how + why

howThe catalog scans the frontmatter of every command file plus every skill file whose description contains a literal convention marker, which excludes installed and plugin skills automatically. Hand-curated labels, use-when lines and category maps inside the script override raw descriptions so the output stays curated rather than raw. A flag combination emits a Markdown catalog redirected into the registry file, and provenance is encoded in directory shape: a real directory means self-built, a symlink means installed.

whyThe setup grew to dozens of self-built commands living beside installed ones, and the global rules mandate a fully generated, never hand-edited registry regenerated after every skill change. The catalog is what makes that inventory queryable without trusting memory.

More5

Moves a project onto its own hostname and fixes every loose end

/domain

whyattaching a domain takes two commands, finishing the job takes fifteen

full how + why

howFour small Node engines carry the mechanics: detection identifies the linked project, the framework origin variable and a proposed hostname; a rewrite pass walks git-tracked files and replaces old-origin references while refusing to touch third-party raw URLs or hosts the project does not own; a state file records created record ids so the run can be undone by reading rather than guessing; a verifier runs eight end-to-end checks whose exit code is the verdict. DNS is written with proxying always off, because a proxied record in front of the platform breaks certificate renewal weeks later.

whyStated in the skill itself: attaching a domain takes two commands, finishing the job takes fifteen, and the skipped ones are always the same, so the build keeps advertising its preview URL to crawlers, the README badge points at a dead address, and the old host serves a duplicate forever. The rewrite engine comments say its two hard rules were learned the expensive way.

Blinks the laptop keyboard when a Claude turn finishes

/keyboard-backlight

whyknow a turn is done without watching terminals during parallel runs

full how + why

howA Stop hook pipes its payload into a notifier that merges user config over defaults (quiet hours, one-shot mute, per-event blink patterns), re-spawns itself detached so the hook returns in milliseconds, and calls a blink function from his own published npm package, a native binding that snapshots and restores the exact brightness and auto-brightness state per keyboard. It exits successfully on every path, because a notifier that breaks its host hook is worse than a missed blink.

whyThe skill states it plainly: know the turn is done without watching the terminal, which matters when many sessions run in parallel. He built and published the underlying package himself in July 2026, and the installer also removes an older hand-rolled hook that made every blink fire twice.

From local code to a licensed, audited, published repo

/launch

whypublishing is irreversible: every commit that ever existed goes public

full how + why

howDeterministic Node engines do the mechanical work: the audit scans the full git history, not just the worktree, for secrets, personal data and packaging gaps; a security stage opportunistically orchestrates external scanners and reports per scanner whether it actually ran, so absence of findings is never mistaken for coverage; an agent-readiness scorer checks whether a machine reader can use the resulting site; a state file makes every phase resumable. A separate hook independently re-runs the audit on any publish-shaped command and blocks on critical findings, so skipping the skill never skips the gate.

whyIts own opening line: publishing is irreversible in the ways that matter, since a public repo publishes every commit that ever existed and a license is a promise to strangers. Built in July 2026 while turning a string of personal tools into public repos and packages, to make each launch a checklist instead of a gamble.

Five-lens mandatory review gate before any git push

/push-review

whywith permission prompts off, nothing else stands between code and a remoteinferred

full how + why

howA preparation script resolves the outgoing base and head once and writes a binary-safe patch plus a review packet with changed files, risk tags, per-lens file lists, static suppression findings and suggested gates. Five read-only reviewer agents run concurrently against that shared packet and each must end in a machine-parseable verdict. A finalizer re-verifies head, base, the exact diff hash, gate results and all five verdicts before writing an evidence file, and a global pre-push hook blocks any push whose evidence does not match the exact commit being pushed; any new commit invalidates the approval.

whyHe runs with permission prompts skipped and long unattended loops, so nothing else stands between generated code and a remote. Binding approval to the exact diff hash turns this was reviewed from a claim into a checkable fact.

The logged, user-only escape hatch for the push gate

/push-skip

whya gate that blocks every repo needs a visible, logged emergency exit

full how + why

howRuns exactly one command, a push with the gate-skip environment flag that the pre-push hook recognises as the sanctioned override; no reviewers, no gates, no approval file. Every use is automatically recorded in the push-gate log, and the command is defined as user-only: the model must never suggest or trigger it on its own when a review finds problems.

whyA push gate that blocks every repo needs a visible emergency exit; the setup notes call it exactly that. Making the escape hatch an explicit, logged command keeps it auditable and deliberately out of the model own hands.

Infrastructure (not directly invocable)4

Writes session observations to a personal second brain via API

hub-syncinfrastructure

whythe second brain starved because his whole day happens in the terminal

full how + why

howA small Node script posts operations with a bearer token to a deliberately narrow ingest endpoint that is insert-only, with no update, delete or read, validates against a per-kind allowlist schema, deduplicates word-identical facts, and stamps every row server-side with a non-spoofable origin marker so machine-written entries stay distinguishable from manual ones. The more important half is the rule set: hard limits on what never gets logged, capped at a handful of facts per session, with an optional session-end harvester left off by default because it costs per session.

whyDocumented in its README: the second brain starves because his whole day happens in the terminal, not in the web interface, so the skill closes that gap. Writing directly to the database with a service key on the laptop was considered and deliberately rejected in favour of the narrow endpoint.

Shared severity and output contract for five push-review lenses

push-review-finding-contractinfrastructure

whyshared prep and a fixed output format cut token cost, keep verdicts comparable

full how + why

howA pure instruction contract with no code, loaded through the reviewers frontmatter: each reviewer works only from a precomputed review packet, and re-running git discovery, builds, linters or tests is forbidden. Every finding must pin to a file and line with a concrete failure scenario, uses only blocking or advisory severity under per-lens ownership rules with cross-lens labelling for deduplication, and emits a compact findings array plus exactly one verdict line. That fixed format lets a finalizer compare five independent verdicts mechanically before approving the push.

whyDocumented in the setup notes: the review redesign needed lower token cost and precise, comparable verdicts, so shared preparation and a compact standard output replaced five reviewers each re-exploring the repo. The review quality is carried by the contract rather than the model tier, which later allowed pinning the reviewers to a cheaper configuration.

Lists recent sessions with ready-to-paste resume commands

recapinfrastructure

whyborn from recovering six working sessions by hand after a reboot

full how + why

howIt parses the local history file as a fast index and opens per-session transcripts only for the rows actually displayed; project paths always come from recorded working-directory fields because the transcript folder-name encoding is lossy. It over-fetches by file mtime then re-sorts by internal timestamps, because compaction touches make mtimes lie about last activity. Python standard library only, read-only, about two tenths of a second offline; the only network path is an opt-in flag making one summarization call, and the tab-reopening mode drives the terminal through scripting with an explicit confirmation gate.

whyDocumented: it was built for the post-reboot moment. Weeks before it existed the owner had to recover six working sessions after a reboot through manual session-file forensics; this turns that recovery into a single instant command.

Playbook to wire real keys and verify a SaaS at the live edge

saas-launch-wiringinfrastructure

whydistilled from a launch where every dashboard lied and every service hid a blocker

full how + why

howSix phases built on one belief, that dashboards lie and only a live request proves a claim. The first phase greps the code for its real env contract, which variables flip which feature flags, placeholder detection, server-only versus public. Provisioning runs in dependency order with the redeploy last, and secrets travel from dashboard to a permission-restricted transient file to the platform CLI, verified only by a length-and-prefix fingerprint so the value never enters the transcript. Verification is end to end at HTTP level: expect unauthorized on protected routes, a signed versus unsigned webhook roundtrip, then a real browser user loop confirmed by querying the database rather than trusting the UI.

whyDocumented: distilled from one real launch session in which every dashboard looked ready and every service hid a blocker, including a paused free-tier database, a dev-only auth instance with no production keys, a payment store containing zero products, and eleven deploy variables that had all been silently stored as empty strings.