tsharp/geist

Help a user refine an idea, plan, requirements, process, or draft through focused questions, concrete scenarios, and evolving documentation. Use when the user wants an iterative refinement interview with written outcomes; direct edits and factual questions do not require this workflow.

Classify a response, draft, code change, or assistant trace as slop or not slop, explain why with concrete evidence, and recommend specific fixes. Use when asked for a slop check; do not turn every task into a critique or attempt to identify AI authorship.

Examine and explain the current architecture of a whole repository or a named section in a visual HTML report. Use for system context, domains, domain terminology, components, layers, dependencies, data ownership, runtime flows, and architectural decisions; improvement candidates belong to an improvement review.

Create or refine SWE skills from the user's requirements, interviews, and representative engineering work. Use for authoring engineering practices, language styles, communication rules, or engineering workflows; activating existing packages is separate setup work.

Diagnose and fix a reported software failure or performance regression using a reproduction, targeted investigation, and verification of the original symptom. Use for debugging; an obvious local correction does not require a full investigation.

Find architecture improvement candidates, generate a visual before/after report, and explore the selected design. Use for module deepening, dependency problems, responsibility changes, or architectural refactoring; a descriptive architecture survey is a separate task.

Find and prioritize maintainability improvements with a visual HTML report. Use for reducing change cost, improving testability and ownership, or addressing recurring maintenance friction; use a change review for diff correctness.

Configure or repair Geist startup routing for selected personal or workspace style skills. Use when asked to activate existing styles; creating or refining style content is separate authoring work.

Build a small disposable experiment to answer a concrete engineering, state-model, integration, or UI design question. Use when an experiment would resolve uncertainty faster than discussion; ordinary implementation does not require a prototype.

Review an engineering session or repeated workflow friction and propose evidence-backed improvements to tools, checks, navigation, and guidance. Use for a requested retrospective; do not add a retrospective to every task.

Review a branch, commit range, or working changes against the requested behavior and applicable engineering standards. Use for code review or an authorized implementation review; ordinary edits do not require a separate review workflow.