CodingThrust

Use when you want to take a Backlog issue all the way to Final review without manual orchestration — chains check-issue, fix-issue, add-model/add-rule, run-pipeline, and review-pipeline; substantive issue-quality problems are sent to a rewrite subagent; algorithmically unsalvageable issues are parked on OnHold

Use when reviewing a [Rule] or [Model] GitHub issue for quality before implementation — checks usefulness, non-triviality, correctness of literature claims, and writing quality

Use when a user wants to propose a new problem model or reduction rule — guides them through brainstorming, clarifies the design, and files a GitHub issue

Review the Typst paper (docs/paper/reductions.typ) for quality issues — evaluates 10 entries per session, reports mechanical and critical issues without fixing

Reverse of find-solver — given a solver for a model, discover what other problems it can handle via incoming reductions, ranked by effective complexity

Interactive guide — match a real-world problem to a library model, explore reduction paths, recommend solvers (built-in + external), and generate a solution doc

Update the research paper collection — download new papers from references.bib, retry failed downloads, sync to Google Drive, and regenerate index.md

Use when adding a new problem model to the codebase, either from an issue or interactively

Use when a pull request on the current branch has review comments, failing CI checks, or coverage gaps to address — guides a triaged cleanup pass that fixes feedback in priority order without bundling unrelated changes.

Use when you have a GitHub issue and want to open a PR carrying an implementation plan — guides fetching the issue, brainstorming an approach with the user, writing a plan file, and pushing a plan-only PR ready for implementation (manual or automated).

Use when auditing a software repository for beginner-level best-practice violations, repo health, Git history hygiene, issue and PR usage, branch discipline, tests, docs, coding style, CI, security basics, or maintainability signals.

Use when setting up or writing a research documentation/report site — scaffolds a fresh site (Makefile, build script, GitHub Pages workflow, HTML templates) or refreshes templates in an existing setup. Output is a single-page index with download cards, rendered markdown prose, and PDF viewers, all sharing the same neutral-academic stylesheet (ink + terracotta on warm paper). The build pipeline is a single Python script driven by a doc registry; the visual identity is fixed; the contents are yours.

Use when a code change is finished but not yet committed — dispatches a fresh-context subagent to review the diff for design principles (DRY/KISS/HC-LC), test quality, and (where applicable) public-API ergonomics, then consolidates findings and applies the clear fixes automatically.

Use when building a scroll-snapped, two-column slide deck in a neutral-academic house style — research-style and formal — for research talks, project briefings, group-meeting decks, anywhere a one-figure-plus-commentary rhythm beats bulleted Keynote slides. Forces a two-phase workflow — agree on the logic flow first, then design each page — so the deck has a thesis before it has visuals. The output is a single self-contained HTML file (CSS, JS, fonts via CDN) with arrow-key navigation, page indicators, and a section component library (masthead, spec list, stats grid, data table, conclusion 2x2, voice-quote wall, tool stack, key-links). The visual identity is fixed; the contents are yours.

Use when given a topic and a list of sources (URLs, arxiv IDs, DOIs, PDFs, local notes) and asked to collect what each source says about the topic and synthesize them into a single cited report. Drives a three-pass workflow — per-source extraction, cross-source synthesis, structured write-up — and grounds every claim in a specific source.

Configure, run, reproduce, smoke-test, or generate a submission for the standardized problem-reductions Self-selected Top50 benchmark, and route an existing submission to the upload workflow.

Validate and officially upload an existing problem-reductions benchmark submission. Use when the user wants to submit a submission.json. If no result exists yet, route the request to $run-benchmark.

Use when the user wants to create a new Rust crate or package — scaffolds a library (optionally with CLI subcrate), Makefile, mdBook docs, GitHub Actions (CI/docs/release), codecov wiring, and `.claude/CLAUDE.md` stub into `$(pwd)/<crate-name>/`. Trigger phrases include "new rust crate", "scaffold a rust package", "create a rust library", "new rust package", "新建 rust 项目", "新建 rust 包".

Use when a VibeYoga participant wants to critically evaluate their hackathon project or harness idea — surveys prior art and context first, then walks through novelty, acknowledgment, uniqueness, human benefit, MVP scope, validation tests, and the skill-vs-program choice in brainstorming style. Trigger phrases include "reflect on my project", "is my idea worth building", "what should my MVP cover", "help me validate this", "should this be a skill or a program".