Loading...
Loading...
Found 7 Skills
Plan the smallest complete happy-path change or implement an approved happy-path plan. Use when asked to plan or implement a feature, change, or bug fix for only the normal valid path.
Production-readiness pass — audits and implements the full non-happy-path matrix: loading skeletons, empty states, error messages, partial data, i18n, offline, permissions, and first-run guidance. Use when preparing a surface for production or when the user says "it crashes on empty data" / "there's no loading state" / "harden this". Invoke when the user asks for harden on their UI, or mentions 'harden' alongside design / UI / frontend work.
Audits AI-implemented work for honest completion. Runs independent-evaluator checks against task artifacts, transcripts, tests, CI evidence, requirement-to-test mapping, status front matter, and quality gates; flags skipped tests, weakened assertions, mock-only confidence, snapshot drift, happy-path-only coverage, flaky retries, and status/evidence mismatches. Use when validating completed Compozy tasks, AI-authored PRs, or codex-loop iterations. Do not use for real-user QA, persona/journey testing, exploratory charters, or product usability sessions; use qa-execution for those.
Use when writing, fixing, editing, or refactoring TypeScript tests, especially slow or flaky tests, skipped or focused tests, happy-path-only coverage, missing boundaries, brittle fixtures, coverage gaps, or multi-concept tests.
Turn a settled business-logic spec (from `feature-discovery` or a freshly-described feature in chat) into a detailed, code-grounded implementation plan saved as `docs/<feature-slug>-plan.md`, ready for `plan-task-breakdown` to convert into checkboxes. Verifies feasibility against the actual codebase, names the specific files/types/actions/components to touch, identifies test cases at every layer that fits (unit, integration, and — for user-visible flows — a Playwright happy-path e2e test), and asks the user clarifying questions for implementation-level ambiguities only — never re-litigates business logic. Use this skill whenever a feature's *what* is clear and the next move is mapping it to *how*. Trigger on phrases like "make a plan", "write the implementation plan", "plan this out", "design the build", "turn this spec into a plan", "how would we implement this", "scope out how to build X", "draft a plan for <feature>", or whenever the conversation just produced a business spec and the natural next step is implementation design — even if the user doesn't say "implementation plan" explicitly.
Workflow required before generating, writing, or updating BAT (Blackbox API Testing) tests for a Mule app. Call use_skill as your FIRST action — before reading or writing any .dwl file — whenever the user asks to create, generate, add, write, refresh, extend, or fix BAT tests, a BAT suite, BDD API tests, black-box API tests, or Anypoint API Functional Monitoring tests for a deployed Mule HTTP API. Do not read the app source, open the existing suite, or author any .dwl yourself and attempt the task in one turn — even a targeted single-test change like 'add a 401 test' or 'fix the orders happy-path test' requires loading this skill first. Covers generating a suite from app source (OpenAPI + Mule XML), extending an existing hand-written BAT baseline, and running the suite against the live endpoint. Not for MUnit (build-time, in-process, XML) — use the Mule developer workflow for that. When you call this skill, it must be the only tool call in that response.
Force the states a happy-path run never reaches (a failing API, an empty list, a slow request, a timeout, an expired session, a toast that auto-dismisses) and check the UI actually handles them. Use when error handling was written but never run, when a loading or empty state needs verifying, when a bug only happens on a slow connection, or when a timer, poll, debounce or retry needs testing without sleeping.