en un clic
dotfiles
dotfiles contient 14 skills collectées depuis camercu, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Exercise software as real consumer would — docs-first walkthrough, full public surface coverage, adversarial misuse — producing a ranked friction report. Works for any software type (library, CLI, server/API, web UI, TUI). Use when user says "dogfood", "exercise as a consumer/user", "friction report", "consumer trial", "try it like a real user", or as harden skill Phase 1 (Exercise → friction). Re-eval mode re-runs a prior report for a resolved/still-live delta.
Iterative refinement loop for taking a change to a high quality bar. Sequences exercise→friction, grill→decide, TDD slices, then review→soundness→simplify→architecture→test-health→docs passes — repeating until a full round finds nothing significant — under fixed discipline (authority docs sacred, commit per slice, verify every slice, reverse your own calls on evidence, capture decisions durably). Use when the user wants to build or refine something "properly", harden a change, run a multi-pass quality loop, evaluate an API as a real consumer, or asks to "harden", "do this properly", "full quality pass", "refine loop", "keep going until clean", or "production-grade" work. Gated — stops for the user's call at authority conflicts, fix decisions, architecture do/decline, and irreversible actions.
MUST be used for every git commit. Formats Conventional Commit messages, checks for breaking changes, and stages files atomically.
Collaborative specification refinement through codebase analysis, discovery interviews, and iterative red-teaming. Use when user wants to write a spec, refine requirements, design a feature, or mentions "spec", "requirements", "PRD", or "specification".
Break a plan or spec into vertical-slice tasks. Use when user wants to break down work into tasks, slice a spec into implementable pieces, or mentions "to-tasks", "break down", "task breakdown", or "slice".
Audit and improve a user-facing entry doc (README, docs-site landing, man-page intro, getting-started guide) for factual accuracy and for three reader audiences — evaluator, newcomer, returner. Use when asked to "improve/proofread/audit the readme (or docs)", "is my readme any good", "make the docs clearer / more motivating", or to check docs for stale/inaccurate information.
Review changed code for reuse, quality, and efficiency, then fix any issues found. Understands before touching, guards against over-simplification.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", "tdd", wants acceptance tests, or asks for test-first development.
Extract a DDD-style ubiquitous language glossary from the current conversation into CONTEXT.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
Stress-test a plan against the project's domain model. Challenges terminology, cross-references code, updates CONTEXT.md and ADRs inline. Use when user wants to validate a plan against domain language, sharpen terminology, or mentions "domain model".
Surface architectural friction, propose deepening opportunities. Use when user wants to clean up or improve the codebase architecture or design.
Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
Use this skill to review code. It supports both local changes (staged or working tree) and remote Pull Requests (by ID or URL).
Audit, write, and improve code comments against John Ousterhout's "A Philosophy of Software Design" principles. Use when the user asks to review, clean up, improve, or write comments in source code. Triggers on: "review comments", "clean up comments", "improve docs", "comment audit", "are these comments good", "write better comments", "remove redundant comments".