leo

Plugin leo from marketplace leo-skills in leonoronhas/leo-skills. Commands read from the repo's manifest — 1 month ago.

Skills (28)

• leo-brainstorming

  You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

• leo-code-review

  Reviews the branch diff on two axes, repo standards and the originating issue, with confidence-scored findings. Use before opening a PR, when asked to review a branch or working tree, or as the code stage of leo-gauntlet.

• leo-codebase-design

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• leo-diagnosing-bugs

  Use BEFORE reading or editing any code whenever the user reports a bug, regression, error, crash, failing test, or wrong, broken, or slow behavior, even when the fix looks obvious. The first step for every bug, ahead of leo-tdd. Builds a red feedback loop that reproduces the bug, finds the root caus

• leo-domain-modeling

  Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.

• leo-executing-plans

  Use when executing an implementation plan with independent tasks in the current session. Dispatches a fresh implementer per task, reviews each diff, and ends at leo-finishing-branch.

• leo-explain

  Use for "how does X work", "why is Y built this way", "where should this live", a walkthrough before changing a subsystem, or the history behind a regression. Explains runtime flow and design rationale with cited evidence and confidence labels, and ends with what a change must preserve.

• leo-finishing-branch

  Use when implementation is complete and checks pass, to choose how to integrate the work. Offers merge, pull request, keep, or discard. A pull request needs a passing leo-gauntlet report for the current tree.

• leo-gauntlet

  Use before opening a pull request, or any time you want the full pre-merge gate. Runs simplify, code, security and performance review, a live check for customer-facing changes, and a final verification, auto-fixes confirmed findings, and writes a pass/fail report keyed to the working tree.

• leo-grilling

  Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test a proposal before committing.

• leo-handoff

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

• leo-live-check

  Use to prove a customer-facing change works in the running app before a PR. Starts or reuses the dev server, exercises the changed behavior in a browser or over HTTP, captures evidence and errors, and ends with a fingerprinted pass/fail line.

• leo-mode

  Sticky working mode for autonomous, evidence-first engineering. Matches the task to a flow, runs the leo-* skills each step needs, delegates by role across model tiers and vendors (a 3-model diagnosis panel, reviewer and verifier lanes), and asks the human only at batched gates. Use for /leo-mode or

• leo-performance-review

  Performance review of a diff: N+1 queries, paging correctness, bundle size, caching, missing indexes, mobile runtime pitfalls. Use for performance-focused code review.

• leo-pr-review

  Review pull requests in CI against repository standards, written policy, and their issue specification. Use for automated or manual pre-review of a fixed base...head diff when findings must be high-confidence, actionable, and terse.

• leo-prototype

  Build a throwaway prototype to answer one design question. Use when the user wants to feel out a state model or business logic before building it, or to see several UI directions for a page before committing to one.

• leo-receiving-review

  Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

• leo-research

  Investigate a question against high-trust primary sources and capture the findings as a Markdown file in the repo. Use when the user wants a topic researched, docs or API facts gathered, or reading legwork delegated to a background agent.

• leo-resolving-merge-conflicts

  Resolve an in-progress git merge or rebase conflict. Use when `git status` shows unmerged paths, a rebase onto the base branch stopped on a conflict, or a stacked PR shows conflicts after its base moved.

• leo-security-review

  Security review of a diff against a stack-neutral checklist covering authz on every entry point, tenant isolation, trusted identity, webhook signatures, test-vs-live credentials, SSRF, secrets, dependency advisories, and injection through agent-instruction files. Use for security-focused code review

• leo-setup

  Use first in any repo without `.agents/leo.md`, or when project facts changed. Inspects the repo and writes the adapter every leo-* skill reads.

• leo-simplify

  Code simplification with preserve-functionality rules. Use when code is complex, hard to read, or has unnecessary abstraction.

• leo-tdd

  Use before writing or changing any source code, and before creating or editing any test file, for a feature, bug fix, refactor, call-site sweep, or plan task. Test-driven development with Iron Law enforcement (failing test first, minimum code to green, one slice per cycle). Combines Superpowers TDD

• leo-trust-but-verify

  Verify before claiming done. PROVEN / NOT YET / CAN'T PROVE verdict spine. Use before saying anything is done, fixed, working, passing, implemented, or ready.

• leo-verification-skill

  Use when a repo has no scripted way to drive its app and prove behavior, or when its verification skill has drifted from the app. Creates a project-local verify-<app> skill (launch, doctor, drive, evidence, cleanup, feature map) and records it in .agents/leo.md, or maintains an existing one with one

• leo-worktrees

  Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback

• leo-writing-plans

  Use when you have a spec or requirements for a multi-step task, before touching code.

• leo-writing

  Use whenever you write prose a person or agent will read, such as a reply, PR description, commit message, doc, README, ADR, spec, plan, review finding, decision-log row, or code comment. Writes it plain, specific, and free of AI tells, and cleans up existing text on request ("unslop this", "tighten

Similar plugins