Claude Skills by mxrsv

Brainstorm a feature into an approved spec via clarify → propose 2-3 approaches → present sections → write file → self-review → hard gate. Use when the ask is ambiguous or has several possible outcomes, when it changes architecture, data model or a public contract (API, CLI, UI flow), or when the user asks for a spec. Trigger phrases - "I want to add", "let's build", "design X", "how should we approach Y".

Use when entering a new codebase, needing a fast architecture map, or generating onboarding notes from an unfamiliar project. Focuses on reconnaissance first, then targeted reads.

Use to audit token consumption across always-loaded guidance — agents, skills, MCP servers, CLAUDE.md / AGENTS.md, rules, hooks and config — in Claude Code or Codex. Identifies bloat, redundancy and duplicate skill roots, and produces optimization recommendations. Meta-maintenance skill.

Đối chiếu tài liệu sống với code thật để tìm chỗ tài liệu mô tả hành vi code không có. Mặc định là scan READ-ONLY, không ghi file nào. Chỉ ghi khi chạy với --apply và sau khi người dùng duyệt diff. Fires ONLY when the user types /docs-drift.

Explain concepts, bugs, or design decisions in a deliberately chosen teaching style. Use when the user invokes the skill by name, says "explain", or wants to understand *why* (not just a fix). Honors flags `--story` (Journey + Analogy for bugs), `--why` (First principles + Counterfactual for design decisions), and `--diff` (Compare + Layered onion for X vs Y). Auto-picks style if no flag. Output in Vietnamese.

Use when building, reshaping, or reviewing any web UI (landing page, hero, dashboard, component, marketing site) and it must look designed, not generated. Triggers — a UI that reads flat, generic, templated, or static; calling UI "done" from code/build/TypeScript without looking at a screenshot; deciding whether a design is good enough to ship; prototyping a new template or hero.

Compact the current conversation into a handoff document for another agent to pick up.

Capture knowledge vào Tolaria wiki từ mốc lastLoggedAt — cook gợi nhớ (Claude/Codex/Cursor + git), hỏi người kể, soạn entry, xin duyệt rồi ghi qua record-capture.js. Dùng khi người dùng nói "log-wiki", "ghi wiki", "capture wiki", "tổng kết knowledge wiki", hoặc gọi /log-wiki.

Create or update a plan file at `docs/plans/{YYYY-MM-DD}-{feature}.md` from a spec or available context. Use after "what to build" is clear - a written spec in `docs/specs/` or a well-defined task spanning several commits. Trigger phrases - "plan this", "break into tasks". Not for vague requests - go back to `brainstorm` first.

Review a change you just implemented — correctness against its callers, test quality, and code-level security — over a git range or the working tree. Run right after finishing a unit of implementation and before committing it. Not for reviewing a spec or a plan (use /review), not for whole-repo architecture, dependencies or docs drift (use /review-health), not for user flow in a browser (use /review-experience).

Review the real user experience of a running app in a real browser — walk the affected flows, force loading/error/empty states, check 375/768/1440, and capture console and network evidence. Use after UI, navigation or flow changes when a dev or staging URL is reachable, or when someone reports the app is confusing, broken or slow in actual use. Requires a running app. Not for code-level bugs (use /review-change) and not for architecture, dependency or docs health (use /review-health).

Structural health review of a repository — architecture and coupling, dependency risk, and drift between living docs/schema/config and the code. Run it at a milestone, after a large refactor or a big merge, when git churn is concentrated in a few files, when the user says the code is hard to change or keeps breaking in the same place, or as the first review on a repo that has never been reviewed (cold start — this is the cheapest profile: it needs only the repo, no running app and no diff). D...

Decide whether to ship, fix, refactor, keep building, or rethink — by synthesizing the review reports that /review-change, /review-experience and /review-health already wrote. Use at a milestone, before cutting a release, or when stuck and unsure whether the work is ready to ship or needs more work first. Reads existing reports in docs/review/ plus your product direction; it never re-scans the codebase.

Review a spec or a plan before implementation starts — completeness, ambiguity, feasibility, executable steps, missing dependencies. For reviewing the project itself (code, UX, architecture, deps, docs) use the /review-change, /review-experience, /review-health and /review-release commands instead.

Use this skill when adding authentication, handling user input, working with secrets, creating API endpoints, or implementing payment/sensitive features. Provides comprehensive security checklist and patterns.