ai-team-harness

Turn raw product ideas, vague feature concepts, or partially scoped initiatives into implementation-ready briefs and sliced plans through explicit user alignment, selective research and design, and evidence-backed readiness. Use when moving from an idea or discussion to agreed scope, architecture or technical decisions, a spec, TODO plan, tickets, or implementation handoff. Do not use for already-scoped small implementation work or narrow bug fixes unless the user explicitly wants product-to-implementation alignment.

Review one explicit Git scope along two independent axes: repository standards and fidelity to the originating spec. Use for branch, PR, commit-range, or work-in-progress reviews where both code quality and requested behavior matter.

Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

Configure this repo for the engineering skills — set up its issue tracker, workflow label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Test-driven development using a red-green loop at explicit public seams. Use when the user wants a feature or bug fix built test-first, requests red-green development, or wants behavior-level integration tests.

Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

Break a plan, spec, or current conversation into tracer-bullet tickets with explicit blocking edges, published as local Markdown or native tracker relationships.

Use for Delivery Loop, delivery-loop, or orchestrated-delivery requests, or complex goals needing scope, verification/testing, review, handoff, thread coordination, or user acceptance. Pair with $grill-with-docs for unclear design, domain language, or tradeoffs. Skip tiny mechanical edits unless requested.

Use when an implementation, design, debugging, integration, feature, behavior change, or refactoring task may have unclear intent, hidden constraints, meaningful design choices, or existing project, dependency, framework, platform, current ecosystem, library, component, module, or reference-project solutions worth evaluating. Clarify the real goal, compare local and modern external approaches when the choice matters, dispatch a research sub-agent for non-trivial ecosystem research when available, and prefer the best-fitting path over custom code. Do not use for tiny mechanical edits where intent and implementation path are already obvious.

Review completed work, existing projects, or mature examples to extract reusable lessons, architecture and module patterns, interface designs, workflows, fixes, conventions, and automation opportunities worth preserving or adapting. Use only when the user explicitly asks to review work, a project, or an example for automation, reuse, lessons learned, knowledge capture, design patterns, architecture notes, or repeated manual work. Do not trigger proactively at the end of normal tasks unless the user asks.

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

Define, refine, and set explicit Codex goals. Use when the user asks to create, set, update, clarify, structure, inspect, complete, or block a goal, especially with /goal, goal tooling, target outcomes, done conditions, scope, constraints, completion evidence, completion rules, or blocked/complete status decisions.

Record useful handoff context and put it in the right place. Reusable project knowledge goes into long-lived docs such as README or AGENTS, while task-specific state goes into a handoff note. Use when pausing, transferring, summarizing progress, preserving debugging or implementation context, preparing a resume note, or recording what the next agent should know.

Use when the user asks Codex to manage, inspect, coordinate, continue, message, summarize, organize, rename, pin, archive, hand off, fork, or create Codex threads on their behalf. Operates user-visible Codex threads autonomously within the user's current request, with risk-based user confirmation. Do not use for ordinary internal subagent parallelism or simple implementation tasks.

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

Use this skill when the user explicitly asks to apply the Musk 5-step method, asks to challenge or simplify requirements before optimizing, or wants a structured first-principles review of a system, product feature, workflow, team process, architecture plan, incident, or operational setup. Also use when the user specifically mentions clarify/delete/simplify/accelerate/automate, removing unnecessary requirements, or questioning whether work should exist before building it. Do not trigger for ordinary planning, debugging, implementation, architecture review, or "make this better" requests unless the user wants this five-step lens or a deliberate requirement-challenge pass.