MichaelLeeHobbs
- 13 skills
- 0 followers
- 6 hours ago last updated
- ▌
- ▌ Steelman · michaelleehobbsSettle a real either/or design question by having agents argue the opposing positions at full strength, test both against a ground-truth agent, then judge. Use for "steelman this", "argue both sides", "set up a panel", or when a binary design choice keeps getting deferred. NOT for open-ended shape questions, which have many answers rather than two.
- ▌ Brainstorm · michaelleehobbsExplore a problem the user has not solved yet. They bring the problem and the goal, you bring the option space. Use when the user says "brainstorm", "help me think through", "I don't know how to approach this", or hands you a goal with no chosen solution. NOT for a decision already made, and not for a problem with one obvious answer.
- ▌ Postmortem · michaelleehobbs bundleWrite a blameless incident postmortem collaboratively. Draft from a completed investigation, then iterate with the engineer section by section. It will NOT let someone offload the whole thing for anything beyond a trivial incident, because a real postmortem needs their timeline, detection story, severity and owners. Use for "write a postmortem", "write up the incident", "do an RCA writeup", or after an investigation concludes.
- ▌ Write Tests · michaelleehobbs bundleWrite or fix a test without writing one that passes while proving nothing. Covers vacuous assertions, tests that encode the bug, green from two cancelling faults, unscoped queries, fixtures the product never produces, shared state between tests, sleeps instead of conditions, probe-and-skip fake passes, and mocks so broad the test asserts nothing about real code. Use whenever authoring a test, changing one, reviewing one, or asking whether a green suite actually means anything.
- ▌ Hands Off · michaelleehobbs bundlePrepare a project for an unattended build-out, then hand the run to whatever continuation mechanism your agent provides. Use once per project when the user hands over design authority and wants the thing built from its spec with little input, saying "let it run overnight", "build this out while I am away" or "hands off". Fits an unpublished library or a personal project, anything they will test and review after it exists rather than steer while it is written. NOT for production work, and not for a project whose spec is still being argued about.
- ▌ Optimize Docs · michaelleehobbs bundleAudit the prose documentation in a repository and make it smaller: delete what the code already says, fix what the code contradicts, and move a real decision into a dated record. Grades every claim it can against the repository instead of grading prose by how it reads. Use for "clean up the docs", "our docs are out of date", "too much documentation", "the README is wrong", "prune the docs", "these docs drifted", or before handing a repository to someone new. NOT for code comments, which is optimize-comments, and NOT for files that instruct an agent, which is optimize-agent-instructions.
- ▌ UI Feature Spec · michaelleehobbs bundleReverse-engineer a live web page into a build-ready UI and feature specification by operating it, with no access to its source. Use for "spec this page", "document this UI", "reverse-engineer this page", or before rebuilding or replacing an existing interface. Clean-room by default: it captures behaviour and content exactly, and describes appearance by intent rather than copying style values. REQUIRES browser control, and cannot be done from a screenshot or a URL alone.
- ▌ Deep Code Review · michaelleehobbs bundleRun an exhaustive, file-by-file review of a whole service, package or directory by splitting it across parallel reviewers that each read every assigned file in full, then merging into one severity-tagged report grouped per file. Use for "deep review", "extremely thorough review", "file-by-file review", "audit this service", "review everything under <path>", or any review too large for one pass, especially when the user says not to bias them about what to look for. NOT for a quick diff or pull-request review, and not for a single file.
- ▌ Optimize Comments · michaelleehobbs bundleAudit and tighten comments in a file, diff or package. Use for "clean up these comments", "the comments are out of date", "too many comments", or "this file is over-commented". Delete information readily recoverable from nearby code, preserve the shortest useful explanation of constraints and intent, and add missing reasons only when supported by evidence. NOT a general code review, and not for generated or vendored files.
- ▌ Oie Plugin Development · michaelleehobbs bundleDevelop, scaffold, and build a plugin/extension for Open Integration Engine (OIE) or Mirth Connect. Use when creating a new OIE/Mirth plugin, setting up its Maven project (root/module POMs), writing the plugin.xml descriptor, implementing server-side or client-side (Administrator GUI) plugin classes, building a source/destination connector (subclassing a stock connector, settings panel, TLS-plugin compatibility), adding a REST servlet endpoint, doing database migrations (Migrator + MyBatis), handling permissions/event logging/XStream serialization, or packaging/signing the plugin .zip. NOT for engine-core changes or for channel/template JavaScript.
- ▌ Oie Channel Code Review · michaelleehobbsReview OIE/Mirth channel and code-template JavaScript, which runs on Rhino, the way an experienced and AI-skeptical developer would. Covers the one real block-scoping trap, ES6 features Rhino handles poorly, E4X/HL7 field access, scope-map lifetime, per-message cost, unclosed database connections, PHI in logs, and channel test coverage. Use before deploying a channel, or when asked to review a transformer, filter or code template. NOT for Java, plugin or server-side code, which is a different runtime with different rules.
- ▌ Optimize Agent Instructions · michaelleehobbsAudit and tighten any file that instructs an agent: a context file (CLAUDE.md, AGENTS.md, GEMINI.md, .cursorrules), a skill, a slash command, a subagent definition, or a reference file one of those links to. Use when one of these is bloated, over-explained, stale or duplicative, or when the user asks to review / trim / tidy / refactor / slim one. Not for user-facing documentation, a README, or a prompt embedded in application code.