supermodo
UserA coherent, opinionated toolkit for documentation-driven development with twin-model adversarial checks.
Categories
Indexed Skills (13)
flow
Orchestrates the full supermodo development pipeline end-to-end for one task, running each stage in its own subagent so the main context stays small. Eight stages: librarian task intake (grilled), work implementation, optional hunt bug audit, tdd fixes for any bugs found, a mandatory tests gate (suite green + coverage target), refactor, a mandatory post-refactor verify gate, a final librarian docs pass, and commit. Supports entering at a later stage (--from work|hunt|tests|refactor|librarian|commit) and three job sources: an existing docs/work triad, a backlog entry, or a completely new task — with a context-aware "next job" suggestion when none is named. Use when the user wants to run the whole pipeline, "take this task from spec to commit", orchestrate a feature end-to-end, run the full flow (or the flow from a given stage), or drive a task through the complete dev-to-commit process — anything that means coordinating grill → work → hunt → tdd → tests → refactor → librarian → commit rather than a single stag
sync-configs
Audit and sync Claude Code and Codex CLI configurations so both tools share the same instructions, skills, subagents, MCP servers, hooks, and permission intent. Accepts an optional argument naming one skill, agent, or config file to sync just that item without a full audit. Use this whenever the user mentions config drift, syncing/aligning Claude and Codex, AGENTS.md vs CLAUDE.md differences, keeping skills or agents consistent across AI CLIs, or after editing one tool's config and wanting the other to match — e.g. "sync this skill to codex", "I changed my-agent.md, mirror it". Also use when the user asks "are my Claude and Codex setups aligned?" or wants to migrate config from one tool to the other.
tests
Fixes failing tests and lint/type errors, audits test-suite quality with a fleet of specialist reviewers, or drives coverage — for any project configured with a supermodo skills.config.json. Modes: `tests` (default) fixes every failure tier by tier (unit, integration, E2E, lint); `tests audit [scope]` spawns parallel specialist reviewers (spec-alignment, assertion-strength, corner-cases, coverage-balance, and a domain lens derived from the project's docs), runs mutation probes where configured, and adversarially verifies every finding with a second model before reporting; `tests coverage` drives coverage to the configured target with a balance check. Use whenever the user mentions failing tests, lint errors, "make tests pass", green build, flaky tests, test quality, weak or missing tests, corner cases, coverage, mutation testing, or asks whether the tests actually protect the core logic — even without "/tests".
commit
Generate a one-line Conventional Commits message from the current git changes, then offer to run the commit for the user. Use whenever the user asks for a commit message or wants to commit finished work — "commit message", "write a commit", "generate commit", "commit msg", "cm", "/commit" — even when they don't name this skill. Reads the actual diff to derive what was done. Prints the message; then shows the exact commands and asks whether to commit — runs git only on an explicit yes or a configured auto-consent policy. Works in fresh folders too: no repository yet → same flow, with git init prepended to the offered commands (init always asks, even in auto mode).
config
Keeper of a project's supermodo configuration (skills.config.json) and docs scaffold. Use whenever the user wants to view, check, change, fix, or upgrade the supermodo config, set up or onboard a project onto the supermodo skills, start a new supermodo project, or whenever another supermodo skill reports a missing or invalid skills.config.json. Trigger on 'supermodo config', 'set up supermodo', 'configure supermodo', 'bootstrap supermodo', 'change the coverage target', 'edit the config', 'add a command to the config' — even when the word 'config' itself is not used.
grill
Twin-agent adversarial interview that locks a task or design before implementation. Two models plan independently, attack each other's plans, and only genuinely user-owned questions reach you — the locked outcome is handed to librarian to write. Use for 'grill', 'grill me', plan stress-test, design interview, new-task intake, spec lock, or a flow `needs-input` escalation.
hunt
Systematic bug hunting across a full-stack TypeScript application. Finds semantic bugs, async issues, data integrity problems, security vulnerabilities, performance hotspots, and UI/browser issues — producing a prioritized report with evidence and fix suggestions. Use when the user says /hunt, asks to "find bugs", "audit this", "check for issues", "scan for problems", wants a code review focused on correctness rather than style, mentions specific concerns like "are there race conditions", "check for security issues", "find performance problems", or wants to validate code quality before a release. Also triggers on "what's wrong with this", "anything broken", "smell check", or any request to systematically find problems in code.
librarian
Sole owner of documentation mutations: run the lifecycle pass to close out completed work, reconcile docs and agent definitions with code, promote verified contracts, record ADRs, archive finished tasks, regenerate navigation, and repair links. Also manages the backlog, runs new-task intake, and (with --absorb) performs the one-time sweep that classifies and absorbs pre-existing documentation into the convention. Use for docs maintenance, task closeout, documentation or instruction drift, backlog operations, `--task` intake, `--absorb` onboarding of existing docs, or a flow stage-7 alignment pass.
protocols
The supermodo package's single source of truth and help desk. Holds the master copies of every shared protocol (config contract, docs convention, reports, subagent handoff, cross-model adversary ops, adversarial review stance, user questions, grilling, command tooling) that all other supermodo skills read in place. Invoke to ask how the supermodo package or any of its protocols works, to get an overview of the skills and pipeline, or to check that a supermodo installation is complete and healthy — triggers on "how does supermodo work", "explain the grilling/questions/docs protocol", "supermodo help", "check my supermodo install".
refactor
Deep functional refactoring of TypeScript code for purity, testability, and modularity. Use when the user says /refactor, asks to clean up or restructure code, mentions large files, god functions, mixed concerns, poor testability, or when code grew unwieldy after feature iterations. Also triggers on "this file is too big", "split this", "make this more functional", "extract", "decompose", or any mention of code smells like let, try/catch in business logic, for loops, or files over 300 lines. If the user describes messy, tangled, or overgrown code that needs structural improvement, this is the right skill — even without the word "refactor."
release
Run a versioned release with git-flow discipline: deterministic preflight (branch, clean tree, Conventional Commits since last tag → suggested semver bump), changelog entry written from fragments/commits into the changelog file automatically, then the exact squash-merge/tag/push/GitHub-release sequence printed and consent-gated by default (configurable auto mode). Two configurable modes: light (dev → main) and full git-flow (release/* stabilization + hotfix/* branches). Use for 'release', 'cut a release', 'ship a version', 'bump the version', 'publish vX.Y.Z', 'hotfix production' — whenever accumulated work should become a tagged, published version.
tdd
Test-driven work in two modes. Default: real Test-Driven Development — red-green-refactor, one failing test at a time, used while implementing features (and by the work skill). With --debug: test-first debugging — generate all plausible root-cause hypotheses, write tests to validate each before touching production code, fix based on which tests fail, then sweep the codebase for the same pattern. Use for 'tdd', 'test-driven', 'write the test first', implementing with tests leading — and with --debug whenever the user reports a bug, unexpected behavior, or failed fix attempts and the root cause is unclear.
work
Lead implementer: use the docs router to load the active task and its context chain, pick or receive the next incomplete task, implement it under project conventions, then cross-provider adversarially verify the diff. Use to resume roadmap work, start or continue a task, implement the next item, or as flow stage 2. In flow mode the interview is skipped and doc mutation is left to librarian.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.