en un clic
claudio
claudio contient 14 skills collectées depuis jrollin, avec une couverture métier par dépôt et des pages de détail sur le site.
Skills dans ce dépôt
Onboard a developer to an unfamiliar repository, big-picture first. Produces a Purpose/Context section (what the repo is and why it exists), a Big Picture built with C4 diagrams (L1 System Context, L2 Container, optional L3 Component) plus event-reaction flow diagrams for async triggers (stream/queue/schedule/object-event), a Navigating-the-Code section (conventions, lean directory map, testing strategy), a Running-It-Locally checklist with the fast pre-PR loop, a Deploying-It section (deployment model, function/trigger inventory, managed-service graph, envs/secrets, CI/CD), and a Security Posture map — every claim cited to exact files, diagrams before code. Use for "onboard me", "help me understand this repo", "give me an overview", "explain this codebase's architecture", "what architecture pattern does this use", "how is this repo structured", "how do I run this locally", "what's the testing strategy here", "how is this service deployed", "how does CI/CD work here", or "what's the security posture". Read-on
Orchestrate implementation of one hexagonal Rust slice by dispatching agents in the correct order — build the domain core (model + use case + ports) first, then fan out the driven and driving adapters in parallel, then wire bootstrap serially. Use when you want to implement a ports-and-adapters slice with parallel adapter work that does not interfere. Trigger for "implement this slice hexagonally", "build the domain then the adapters in parallel", "scaffold a ports-and-adapters feature end to end". For the layering RULES themselves use rust-hexagonal; this skill is the DISPATCH recipe.
Structure and write user documentation with the Diátaxis framework (Tutorials, How-to guides, Reference, Explanation). Use when documenting content for users, designing the architecture of a docs set, or deciding what kind of doc a piece of content should be. Trigger for: "document this for users", "write a tutorial", "write a how-to guide", "structure our docs", "organize the documentation", "what kind of doc is this", "how should I document X", "audit our docs", "are these docs in the right place". NOT for: API rule extraction from code (use spec-extract), feature specs (use spec-create), or onboarding a developer to a repo (use onboarding).
Design or review Rust services using hexagonal (ports and adapters) architecture with idiomatic ownership, errors, and testing. Use when structuring a Rust project, deciding where a trait or dependency belongs, or auditing layering between domain and infrastructure.
Structure Rust code into cohesive modules and functions. Use when writing new Rust feature code, adding a module or a non-trivial function, deciding how to organize a file, splitting a god-file into a directory module, breaking a long function into an orchestrator plus phase functions, keeping an owned resource (transaction, lock, accumulator) from leaking across boundaries, or reviewing module/function structure. Apply while writing, not only when refactoring. Architecture-agnostic — any Rust code, hexagonal or not.
Interview the user relentlessly about every aspect of a plan, walking down each branch of the design tree and resolving dependencies between decisions one-by-one until a shared understanding is reached. Use when pressure-testing a plan, design, or feature idea before implementation, or before running spec-create. Trigger for "grill me", "interview me about this plan", "poke holes in my design", "challenge my assumptions", "stress-test this approach". NOT for writing code or implementing tasks (use spec-impl).
Use when implementing ANY feature or bugfix — invoke this skill before writing a single line of production code. Trigger for: test-driven development, red-green-refactor cycle, failing tests first, TDD workflow, test-first programming. Also trigger when the user asks to "implement", "add", "build", "fix a bug", "write a function", or "create" anything that involves production code — even if they don't mention TDD. Even if the task seems too simple to need tests, invoke this skill.
Use when creating LLM-as-judge behavioral evals for an agent skill. Trigger for: "create tests for skill", "add evals to skill", "test this skill", "behavioral testing", "eval harness", "golden examples". NOT for unit tests, integration tests, or application testing.
Use when designing systems with Event Modeling methodology, creating event models, or when user mentions event modeling, commands/events/views blueprints, system timeline design, or CQRS system design workshops.
Use when translating a completed event model into implementation tasks. Invoke when an event model with slices and specifications exists and needs to become a development plan, task breakdown, or spec-create compatible output.
Create a new feature specification following a phased workflow. Use when starting a new feature that needs requirements, design, and task planning. Invoke for spec-driven development, feature specification, requirements-design-tasks workflow.
Extract business rules, validations, and domain logic from existing codebases. Use when reverse-engineering undocumented business rules, onboarding onto a codebase, preparing for a rewrite, or auditing what a system actually does. Trigger for: "extract rules", "what are the business rules", "reverse-engineer", "document the logic", "rule catalog", "what does this code do" (domain-scoped), "audit the behavior", "understand the domain". NOT for: API documentation, test generation, or creating new feature specs (use spec-create).
Task-by-task implementer that reads a completed spec and executes each task atomically. Use when a feature spec exists and you're ready to implement. Invoke for spec implementation, task execution, spec-driven development.
when asking to check ui or tests automation in browser