All authors
Claude Skills by mxrsv
github.com/mxrsv17 skills0 installs49 views
- BrainstormClarify ambiguous requirements or material architecture, data-model and public-contract changes before implementation. Settle decisions in conversation and capture them in the requirements section of the task plan when one is needed.Votes: 0GitHub stars: 8
- Codebase OnboardingUse 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.Votes: 0GitHub stars: 8
- Context BudgetUse 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.Votes: 0GitHub stars: 8
- Docs DriftCross-check the living docs against the real code to find places where the docs describe behavior the code does not have. Default is a READ-ONLY scan that writes no file. Writes only when run with --apply and after the user approves the diff. Fires ONLY when the user types /docs-drift.Votes: 0GitHub stars: 8
- ExplainExplain 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.Votes: 0GitHub stars: 8
- Frontend Design BarUse 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.Votes: 0GitHub stars: 8
- Hand OffCompact the current conversation into a handoff document for another agent to pick up.Votes: 0GitHub stars: 8
- Log WikiCapture knowledge into the Tolaria wiki from the lastLoggedAt mark — cook memory prompts (Claude/Codex/Cursor + git), ask the narrator, draft the entry, get approval, then write via record-capture.js. Use when the user says "log-wiki", "ghi wiki", "capture wiki", "tổng kết knowledge wiki", or invokes /log-wiki.Votes: 0GitHub stars: 8
- PlanningTurn clear requirements into one repo task plan containing scope, decisions, implementation, verification and handoff. Use for multi-session or multi-commit work, or an explicit plan request. Use brainstorm first if the outcome is unclear.Votes: 0GitHub stars: 8
- Review ChangeReview 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).Votes: 0GitHub stars: 8
- Review ExperienceReview 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, capture console and network evidence. Use after UI, navigation or flow changes when a dev or staging URL is reachable, or when the app is reported confusing or broken in actual use. Not for code-level bugs (use /review-change), not for architecture or docs health (use /review-health).Votes: 0GitHub stars: 8
- Review HealthStructural health review of a repo — architecture and coupling, dependency risk, and drift between living docs/schema/config and the code. Use at a milestone, after a big refactor or merge, or as the first review on a never-reviewed repo; needs only the repo, no running app and no diff. Not for a specific change or diff (use /review-change), not for UX or runtime behavior (use /review-experience), not for a ship decision (use /review-release).Votes: 0GitHub stars: 8
- Review ReleaseDecide whether to ship, fix, refactor, keep building, or rethink from existing change, experience and health reports in conversation or supplied artifacts. Use at a milestone or before release. Synthesizes evidence without re-scanning the codebase.Votes: 0GitHub stars: 8
- ReviewReview 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.Votes: 0GitHub stars: 8
- Security ReviewUse 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.Votes: 0GitHub stars: 8
- Interview MeExtracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.Votes: 0GitHub stars: 8
- Diagnosing BugsInvestigate reported bugs, failing tests, unexpected behavior, and performance regressions before fixing them. Build evidence for the cause and verify the original symptom. For read-only reviews, use only the evidence discipline and preserve the read-only scope.Votes: 0GitHub stars: 8