菜单
Dispatcher for prumo's debugging methodology — use the moment a user reports a bug, a failing test, an unexpected behaviour, a "weird" UI state, or anything that does not match the spec. Picks the right sub-skill for the phase you are in.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
prumo's visual language — the *what it should look like* layer (Plane/Linear/WorkOS aesthetic). Use when deciding layout structure, density, header height, sidebar behaviour, hover affordances, empty states, loading patterns, or any "how should this screen feel" question for frontend/ pages and components. The sibling ui-styling skill is the *how* layer underneath (Tailwind/shadcn/Radix mechanics) — read this one first when designing, that one when implementing classes.
Use this when writing or modifying anything under `backend/app/` — FastAPI endpoints, SQLAlchemy 2.0 async models or queries, Alembic migrations, Celery tasks in `backend/app/worker/`, Pydantic v2 schemas, Supabase RLS policies in `supabase/migrations/`, or `pytest` tests. Covers prumo's HITL stack (extraction + quality assessment), project-membership auth, structlog observability, and the migration split between Alembic (app schema) and Supabase CLI (auth/storage). Trigger on requests like "add endpoint", "create migration", "write a Celery task", "fix RLS", "new SQLAlchemy model", or anything touching `extraction_*` tables or `/api/v1/runs/...` / `/api/v1/hitl/sessions`.
Runbook for shipping prumo to production — promoting dev to main, Railway deploy mechanics (Wait-for-CI, SKIPPED-SHA recovery), Supabase auth/storage migration deploys, env-var rotation, and rollback. Invoke manually with /deploy-release when deploying, promoting, or recovering a stuck deploy.
Use whenever writing, debugging, or designing tests for prumo — Playwright E2E (with a11y + visual), Vitest unit/component, pytest backend integration, MSW v2 network mocks, or whenever a test is flaky. Pulls in the right tool, the right fixture pattern, and the project rule that integration beats heavy mocking. Trigger on "test", "spec", "flaky", "Playwright", "Vitest", "pytest", "MSW", "axe", "snapshot", "visual regression", "test strategy", "mock the database", "test fixture", "CI test".
Use when writing or modifying the STRUCTURE of anything under `frontend/` — where code lives, data flow, and state. Covers components/{domain} organization, TanStack Query hooks + key factories, `services/*Service.ts` via the typed apiClient, Zustand stores vs React Context, react-hook-form + Zod forms, generated `types/api/schema.d.ts`, ErrorResult boundaries, and the React Compiler constraints. Trigger on "add a page", "add a data hook", "add a mutation", "wire a form", "new store", "fetch data", or anything about how the frontend is organized. NOT for visual language (use `frontend-ux`) or Tailwind/shadcn class mechanics (use `ui-styling`).
Use BEFORE claiming done, before writing a PR body, when receiving review feedback (especially unclear or technically questionable), when requesting review, or after completing a feature/bugfix. Enforces technical rigor over performative agreement, evidence-based completion claims, and a prumo-specific review checklist tuned to recurring incident classes (BOLA, run-state TOCTOU, error swallowing, schema drift, ApiResponse envelope drift, stale TanStack cache). Triggers on phrases "looks good", "should be fine", "I'll fix it", "ready to merge", "tests pass", "done", "complete", "fixed", "ready for review", "let me draft the PR". Be pushy about running it.
| name | debugging |
| description | Dispatcher for prumo's debugging methodology — use the moment a user reports a bug, a failing test, an unexpected behaviour, a "weird" UI state, or anything that does not match the spec. Picks the right sub-skill for the phase you are in. |
Four sub-skills, one philosophy: evidence before hypothesis, root cause before fix, verification before claim.
This is for any technical issue on prumo — backend (FastAPI + SQLAlchemy async + Celery + Supabase RLS), frontend (Vite + TanStack Query + Zustand), or the seams between them.
| Sub-skill | Path | Use when |
|---|---|---|
| systematic-debugging | systematic-debugging/SKILL.md | You just heard about a bug. Before any hypothesis. |
| root-cause-tracing | root-cause-tracing/SKILL.md | Current evidence looks like a downstream symptom; you need to walk backwards through Promise.all, services, or the cache. |
| defense-in-depth | defense-in-depth/SKILL.md | You found the root cause and now want to prevent the class of bug from recurring. Especially for auth, BOLA, RLS. |
| verification-before-completion | verification-before-completion/SKILL.md | You are about to type "fixed", "done", "confirmed", "ready to merge". |
| Symptom | Start here |
|---|---|
| Test failure or unexpected behaviour, no theory yet | systematic-debugging |
Error appears inside extraction_*, deep in a service, but the trigger came from a hook/endpoint | root-cause-tracing |
| Same class of bug keeps coming back (cache key drift, RLS gap, missing await) | defense-in-depth |
| About to claim a fix lands or a flake is real | verification-before-completion |
Empirically on this codebase: most "weird HITL behaviour" reports collapse into one of five classes:
backend/app/api/v1/endpoints/* — a project member can act on another project's resource.run_lifecycle_service.advance_stage or hitl_session_service.open_session.frontend/hooks/extraction/* or frontend/services/* — Promise.all partial failure, .catch(() => undefined).run_id or template_version_id.Each has a known shape. Run the framework first; pattern-matching by gut is what produced the bug in the first place.
systematic-debugging Phase 1 (reproduce, gather evidence at every layer, do not theorise yet).root-cause-tracing to walk back.defense-in-depth so the class is closed, not just this instance.verification-before-completion to actually run make test-backend, pytest -k <name>, vitest run <path>, ruff check, tsc --noEmit, and read the output.Skipping any step is how the same bug keeps coming back.
asyncio.gather swallowing one exception look identical to a logic bug. Eliminate these before deeper hypotheses.runs, extraction_*, hitl_* is a candidate RLS/BOLA bug until you've checked project_members and the endpoint's authorisation.structlog.contextvars.bind_contextvars(run_id=..., project_id=..., user_id=...) over print. Repro evidence is only useful if it carries the IDs.