tarash

Use when the user says "check docs", "audit docs", "doc quality", "doc slop", "stale docs", or wants to verify documentation accuracy and tone against the actual codebase.

Use when the user says "find tech debt", "audit code quality", "what needs cleanup", "show me debt", "code health check", "scan for smells", or wants a comprehensive quality assessment before planning a refactor or sprint.

Structured brainstorming and design gate for deep problem understanding before implementation. Use this skill whenever the user says "brainstorm", "think through", "explore this problem", "let's think about", "what are the angles", "help me understand", "design this", or wants to deeply analyze a problem, feature, architecture decision, or technical challenge before writing code. Also trigger when the user is about to jump into implementation of something non-trivial and hasn't explored the problem space yet — a gentle nudge toward brainstorming prevents wasted effort from unexamined assumptions. This skill is about understanding the problem deeply and producing an approved architectural design, not writing code.

High-quality code patterns with strict types, functional programming, and immutability. Use when writing ANY code in any language. Trigger whenever the user writes, reviews, or refactors code — even if they don't explicitly ask for "quality" or "strict" patterns. This skill applies to TypeScript, Python, and any future languages. Always load this skill for implementation tasks.

Deep code review that hunts for subtle bugs and, when a plan/design document is provided, verifies the change actually accomplishes what the plan describes. Invoke explicitly with /code-review — this skill never triggers automatically. Use when the user says "/code-review", "review my code", "review this change", or "review against the plan".

Inviolable rules injected into every sub-agent context as a preamble. Not directly invocable — loaded by the orchestrate skill and prepended to all sub-agent prompts to enforce scope discipline, verification rigor, and safe coding practices.

Enforce minimum test coverage threshold for tarash-gateway. Use this skill after writing or modifying code to check that unit test coverage meets the required minimum. If coverage is below threshold, generates a test gap spec and invokes the orchestrate skill to implement missing tests automatically.

Analyzes dirty working trees, groups related changes into logical commits using hunk-level staging, and writes conventional commit messages with proper prefixes (feat, fix, refactor, etc.). Triggers when committing code, staging changes, splitting changes into commits, or organizing git changes. Use whenever the user says 'commit', 'commit this', 'commit my changes', 'create commits', 'split into commits', 'stage and commit', or asks for help with their git changes. Does not handle branch management, rebasing, merging, or pushing.

Capture learnings from the current conversation as a clean, human-readable doc in docs/. Use after solving a non-trivial problem, discovering a design pattern, hitting a gotcha, or making an architectural decision worth remembering. Triggers on: 'document this', 'capture this learning', 'that was tricky', 'let's compound this', or /learn.

Multi-agent pipeline orchestrator. Takes a prompt or spec file and runs: brainstorm (interactive), Q&A (interactive), planner (sub-agent), coder (sub-agent with TDD + stagnation detection), quality gate, sync-docs, capture learnings, and commit/PR. Artifacts stored in docs/spec/<name>/. Use when the user says orchestrate, run the pipeline, full workflow, or wants end-to-end development from spec to PR.

Sets up the development pipeline environment. Creates a git worktree, loads the constitution, auto-detects project tooling, runs baseline metrics (typecheck, lint, test, coverage), derives a spec name, and creates the spec artifact directory. Returns all environment variables needed by downstream pipeline stages.

Implementation planning for features, design documents, and multi-step tasks. Use this skill whenever you need to create an implementation plan before writing code — whether from a design document, a feature request, a bug fix, or any non-trivial task. Trigger when the user says "plan", "create a plan", "implementation plan", "break this down", "how should we implement", or when transitioning from brainstorming/design to implementation. Also trigger when the user provides a design document and wants to move to execution, or when a task clearly needs decomposition before coding begins. This skill bridges the gap between understanding a problem (brainstorm skill) and executing it (tdd skill). If no brainstorm/design doc exists and the feature is non-trivial, suggest brainstorming first — but don't block on it for smaller features. Also trigger when the user wants to update an existing plan using @fix tags.

Interactive Q&A session for low-level design — runs between spec-generation and planning. Deeply explores the codebase, identifies implementation questions, and resolves all ambiguities with the user before planning begins. Use when the user says "qa", "questions", "low-level design", "implementation questions", or when transitioning from spec to planning in the orchestrate pipeline. This skill runs in the main conversation (interactive, like brainstorm) — NOT as a sub-agent. By the time this skill completes, the planner should have zero open questions.

Post-stage verification with hard pass/fail thresholds. Every claim backed by verbatim command output — no check may be silently absent, skipped, or weakened. Runs after TDD, refactor, and before PR. Captures baseline metrics to docs/spec/<SPEC_NAME>/baseline.json.

Refactoring assessment and patterns. Use after tests pass (GREEN phase) to assess improvement opportunities, or when the user explicitly asks to refactor code. Guides what to look for, how to prioritize, and which techniques to apply. Trigger this skill whenever refactoring is mentioned, when assessing code quality after a GREEN phase, or when the user asks to clean up or improve existing code structure.

Transforms an approved design doc (from brainstorm) into a structured SPEC with testable acceptance criteria using EARS format. Trigger after brainstorm approval, before planning. Input: design doc path. Output: SPEC.md with requirements, edge cases, and verification matrix.

Synchronizes documentation with code changes. Scans for stale, missing, or contradictory docs, then updates them to reflect the actual implementation. Structures docs for both human readability and AI consumption. Use after code changes are complete and quality gate has passed — before committing.

Test-Driven Development workflow. Use for ALL code changes — features, bug fixes, and especially refactoring — whenever the project's CLAUDE.md indicates TDD is in use. Check the project's CLAUDE.md for TDD signals (mentions of TDD, test-driven, RED-GREEN-REFACTOR, "tests first", or similar). If TDD is indicated, this skill MUST be loaded before writing any production code. Even if the user doesn't explicitly ask for TDD, trigger this skill for any implementation task in a TDD-configured project.

Behavior-driven testing patterns and test-first methodology. Use this skill whenever writing tests, adding test coverage, reviewing test quality, setting up test infrastructure, or when a user mentions testing, TDD, test factories, mocking, or test coverage. Also trigger when asked to "add tests" or "make this testable" for any language or framework. If the user is working with React components, also read references/react-testing.md after this file.

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Add a new model (video, image, or audio/TTS) to the Fal provider in tarash-gateway. Fetches model docs from fal.ai, generates field mappers, registers in the appropriate model registry, writes unit and e2e tests, and runs them.