stable

Plugin stable from marketplace railly-skills in Railly/skills. Commands read from the repo's manifest — 28 days ago.

Skills (24)

• pick-an-issue

  Survey an unfamiliar or shared issue backlog, qualify a small set of worthwhile contributor-side candidates, compare them in an evidence-backed matrix, recommend one, let the user make the final selection, and seed the canonical Issue Contract. Use for requests like "what should I work on here", "fi

• unfold

  Understand, diagnose, change, or review an unfamiliar codebase through one evidence-backed mission. Use when learning architecture, tracing a feature, investigating a bug, implementing a real change with guided or agent execution, reviewing a diff or PR, or checking whether tests and the built artif

• before-after

  Create granular, browser-openable visual proof for a web UI change by capturing the same real DOM element or page state before and after with agent-browser. Use when a web bug fix, component change, responsive adjustment, loading state, interaction, or styling change has a visible browser result wor

• handoff

  Escribe el handoff de un ciclo de trabajo en el vault, verificando el estado contra git antes de afirmarlo. Usar al cerrar una sesion larga, antes de compactar, cuando el usuario dice handoff, /handoff, escribi el handoff, donde quedamos, antes de irme, cerra el ciclo, o cuando un hilo se vuelve dem

• herdr-workstreams

  Materialize selected engineering workstreams as visible, persistent Herdr workspaces after a portfolio or handoff review. Use when the user asks to set up, resume, or organize project work in Herdr; turn a workstream-reconcile queue into repo-scoped workspaces; or make specialist agents launched by

• issue-intake

  Survey an unfamiliar or shared issue backlog, qualify a small set of worthwhile contributor-side candidates, compare them in an evidence-backed matrix, recommend one, let the user make the final selection, and seed the canonical Issue Contract. Use for requests like "what should I work on here", "fi

• performance-proof

  Prove a performance improvement before and after changing algorithms, data structures, latency, throughput, memory, bundle size, build time, or repeated work. Use when a concrete path is slow or resource-heavy, when considering Map, Set, heap, trie, queue, cache, index, batching, or memoization, or

• quality-baseline

  Baseline a repository before quality work. Use when asked to audit maintainability, reliability, performance, security, test quality, technical debt, or code health across a codebase; to identify and rank gaps before fixing them; or to compare quality state over time. Remain read-only on target sour

• resilience-audit

  Pressure a system's failure paths. Use to audit or verify timeouts, cancellation, cleanup, retries, idempotency, partial writes, recovery, leaks, bounded queues or caches, overload, backpressure, dependency failure, malformed upstream data, cross-platform lifecycle behavior, or concurrent state tran

• security-review

  Review a code change or security claim by modeling attackers, assets, trust boundaries, exploitability, and impact. Use for authentication, authorization, origin or request validation, secret handling, tenant isolation, sandboxing, privilege changes, injection, unsafe deserialization, or when decidi

• signature-repro

  Candidate: Root-cause a bug you cannot reproduce because it needs another OS or hardware you don't have, by detecting its structural OR visual signature on the machine you DO have. Use whenever you're about to write cannot-reproduce-needs-Windows/Linux/a-device/a-monitor, when a bug is platform-spec

• simplify

  Reduce code size, PR additions, duplication, ceremony, or maintenance surface while preserving behavior and regression protection. Use whenever the user asks to simplify, deduplicate, delete unnecessary code or tests, reduce LOC, shrink a diff below a line budget, centralize repeated runtime logic,

• solution-gate

  Orchestrate Shaping to decide whether a fix or contributor PR is the right thing to build. Use before implementation when a defect has multiple solution shapes, changes a contract or persistent state, follows a prior review finding, or requires adopting, amending, absorbing, recreating, or rejecting

• test-strength

  Test whether behavioral coverage can reject realistic wrong implementations. Use when tests are green but may be weak, after fixing a bug, and whenever code implements or changes a protocol, parser, serializer, state machine, lifecycle, event translation, browser interaction, adapter, or compatibili

• trail-decisions

  Candidate: Keep a decision trail (a.k.a. show-your-work) while implementing, so a later reviewer can audit the choices and not just the diff. A TSV appended one row per real decision (what, why, evidence), written in the moment, never reconstructed. Use at the start of any implementation task an age

• workstream-reconcile

  Reassess one or more ongoing engineering workstreams by treating handoffs as leads and revalidating their drift-prone claims against live GitHub state, local Git checkouts, releases, deployments, and package registries. Use when work may have stalled or changed since the last handoff; when the user

• xref

  Read-only GitHub PR status and reference graphs for maintainers and agents. Use whenever the user asks for PR counts or status by author, project, repository, or review state; approved, changes-requested, conflicting, draft, ready-for-review, or unassigned PRs; a compact portfolio table; or counts f

• solution-gate

  Gate whether a fix or existing contributor PR is the right thing to build. Use before implementation when a defect has multiple solution shapes or changes a contract, especially session state, long-lived process configuration, restart or reuse behavior, fixes to prior review findings, and decisions

• solution-gate

  Gate whether a fix or existing contributor PR is the right thing to build. Use before implementation when a defect has multiple solution shapes or changes a contract, for fixes to prior review findings, and before adopting, absorbing, recreating, or substantially amending an existing PR or patch. In

• contract

  Write the done criteria for one piece of engineering work before any code changes: what it really is, its size class, acceptance criteria each mapped to an executable observation, must-not-change behavior, and non-goals. Writes .agents/verify/contract.md so fresh.sh and the verify-before-done hook r

• loop

  Run one engineering change from contract to a reviewed, observed, human-approved state, with ceremony scaled by size class. Each step ends on command output, never on a claim. Use when the user says take this to PR-ready, fix this issue, implement this, run the full cycle, or resume an interrupted c

• verify-setup

  Give a repository its own executable verification kit under .agents/verify: doctor, deterministic checks, per-feature drivers that observe the real surface and keep evidence tied to the exact tree, and an enforcer table. Use when a repo has no way for an agent to prove a change works, when setting u

• correct

  Close a piece of engineering work: record it as an evidence ledger, then turn every mistake that escaped into a check that fails on it (a driver assertion, a check.sh command, a gate.sh rule, a lint, a test, or a hook), proven failing on the mistake and passing on the fix. Use after resolving, dispr

• gate

  Gate a diff before pushing or requesting review: verify exact-state identity, run deterministic checks, then run only the lenses the change triggers, including test strength, resilience, security, and simplification. Use before opening or updating a PR, for pre-review, or after an external review ro