Learn a tech topic to a correct 101 level in minimal time. Researches open sources (official docs/releases, engineering blogs, YouTube talks, HN/Reddit, news, papers) restricted to recent material, then produces a brief with a 101 mental model, what changed, tradeoffs, an adopt/trial/hold/avoid verdict, a…
Builds a Thoughtworks-style learning radar of what a principal software + AI engineer should learn next — crawl registry feeds, triage, confirm adoption, place Learn/Try/Watch/Skip blips, save dated HTML. Use when the user asks what to learn, scan the radar, recent topics worth learning, what is moving in tech, or…
Use when the user explicitly asks for brainstorming, pre-ticket discovery, fuzzy product shaping, visual option exploration, or turning an idea into an approved design before implementation planning.
Implement a written plan (from write-plan or interview-plan) when the user says execute or implement it. Loads the plan, executes ready tasks in waves in the ticket venue, runs the plan's review gate itself. Do not use while still interviewing or writing the plan.
Set up an isolated git worktree so the current checkout stays untouched and several tickets can run at once on one repo. Detects existing isolation and reuses a ticket's worktree, creates or attaches .worktrees/ , verifies setup. Use when the user asks for a worktree; execute-plan calls it when the checkout is not…
Post-merge retrospective on the SDLC skill chain (interview-plan → write-plan → execute-plan → review). Reads one ticket's plan and spec, attributes failure signals to the skill that should have prevented them, and proposes one-line amendments. Use after merge and deploy, when the user says "retro this ticket", or…
Interview the user one question at a time to produce an ambiguity-free implementation plan across three lenses — business requirements, backward compatibility, and technical. The model actively investigates the codebase first (Discovery Phase), confronts the user with what it found, and pushes back with alternatives …
Branch-diff review in five lenses — spec conformance, simplify (YAGNI / over-engineering), maintainability, merge safety, then mandatory feature-docs sync. Use /thermo-nuclear-code-quality-review after a dev session, before a PR. Repo-agnostic.
Write a bite-sized TDD implementation plan from a spec before touching code. Saves under docs/plans/ / (gitignored WIP); promote to docs/features/ / when stable. Use when the user invokes write-plan, or when interview-plan hands off an assembled spec. Do not use to implement.