azborgonovo
UserSoftware-delivery AI skills to extend the engineering capabilities of agent harnesses.
Categories
Indexed Skills (19)
address-pr-comments
Triages every open review thread on a merge/pull request, then does something about each one: implements a tested fix, replies in-thread with the fixing commit, and resolves it — or, for a thread you disagree with, replies with your reasoning and leaves it open for the human reviewer to close. Ships with adapters for GitLab and GitHub as the code host, but degrades gracefully to any other host reachable via tool discovery. User-only: runs only when explicitly invoked with /address-pr-comments <MR or PR URL>. When the user wants to work through reviewer feedback on a GitLab MR or GitHub PR, resolve review comments, or address a round of code review, suggest running this command rather than triaging threads by hand.
pr-review
Reviews a merge/pull request against its linked tracker ticket, then posts inline comments on the diff for you to submit — it fetches the change and ticket context, structures the review, and writes the comments directly to the host's draft/pending-review mechanism. Ships with adapters for GitLab and GitHub as the code host, and JIRA and GitHub Issues as the tracker, but degrades gracefully to any other host or tracker reachable via tool discovery. User-only: runs only when explicitly invoked with /pr-review <MR or PR URL>. When the user wants to review a GitLab MR or GitHub PR, code-review a merge/pull request, or evaluate a change's diff against its linked ticket, suggest running this command rather than doing a manual review.
backfill-decisions
Mine a repository's git history for architecturally significant decisions made in the past and retroactively write Decision Records for them, following the log-decision conventions. User-only: runs only when explicitly invoked with /backfill-decisions [time range, path, or topic]. When the user wants to document historical or undocumented decisions, reconstruct ADRs/DRs from git history, generate ADRs for a legacy or existing codebase, or document the architecture history, suggest running this command. For a decision being made right now, use /log-decision instead.
review-skill
Reviews and audits an existing skill, then tightens it — a fast, static, read-only audit of a `SKILL.md`'s triggering, scope, structure, prose, and domain accuracy, with severity-ranked findings applied on approval. Use whenever the user wants to review, critique, audit, lint, tighten, or improve a skill they already have, fine-tune a skill drafted with skill-creator, or asks why a skill is too verbose, won't trigger, or feels off — even when they just paste a SKILL.md and ask for feedback. Defers the empirical loop (running evals, benchmarking, the automated description optimizer, packaging) to skill-creator; this is the static counterpart that reads rather than measures.
tune-agent-docs
Reviews every markdown file in a repository that steers an AI coding agent — CLAUDE.md, AGENTS.md, GEMINI.md, `.cursor/rules/*.mdc`, `.clinerules`, `.windsurfrules`/`.windsurf/rules`, `.github/copilot-instructions.md`, Kiro's `.kiro/steering/*.md`, and similar — together as one corpus, then tightens them. Use whenever the user wants to audit, tune, reconcile, or clean up the instructions a repo gives its AI agents, or asks why an agent keeps missing or contradicting its own steering docs, or burning tokens on them — even when they only name one file, since the value is in reading it alongside its neighbors. Checks consistent terminology, leading-word front-loading, and each doc's token budget — size against its own format's stated limits, content loaded unconditionally that the harness could scope instead, guidance duplicated across multiple docs — applies the repo's own doc-authoring conventions where they hold generally, and calibrates each instruction's degrees of freedom to the fragility of what it govern
define-behavior
Writes behavior-driven features and scenarios in Gherkin (`.feature` files) that read as specification by example — domain-level, one behavior per scenario, observable outcomes. Use this skill whenever the user wants to author or refine Gherkin, BDD scenarios, acceptance criteria, Given/When/Then steps, feature files, or Cucumber/SpecFlow/Behave specs — even when they describe the behavior in plain prose and don't say "Gherkin". Also use to turn a ticket, user story, or acceptance criteria into scenarios, or to clean up scenarios that leak UI/API/DB mechanics. Do not use for writing the automation code behind the steps — that is a separate concern.
implement-scenarios
Implements automated tests for existing Gherkin scenarios (`.feature` files) the BDD way — outside-in and client-first: classify each scenario's best testing strategy, write the test that binds to it, watch it fail for the right reason, then drive the UI/API and domain code until it passes. Use whenever the user has `.feature` files and wants to automate, implement, wire up, or "make pass" their scenarios; turn Gherkin/BDD/SpecFlow/Reqnroll/Cucumber specs into real xUnit/NUnit/Vitest/Jest/pytest/Playwright tests; build a feature test-first (TDD) from acceptance criteria; decide which scenarios belong in unit vs service (Testcontainers) vs end-to-end tests; or keep a traceability link between scenarios and the tests that verify them — even when they don't say "BDD" or "TDD". This is BDD's automation step, the one that runs after define-behavior writes the Gherkin and review-feature-suite audits it. Do not use it to author or refine the Gherkin itself (that is define-behavior) or to reconcile a suite of feature
review-feature-suite
Reviews a whole suite of `.feature` files against each other and reconciles them — cross-file consistency auditing for Gherkin/BDD. Checks that the suite holds one shared language across files, reuses step phrasing instead of duplicating it, carries no contradictory or redundant scenarios, and stays consistent in tags, naming, and data. Use whenever the user has multiple existing `.feature` files (a Cucumber, SpecFlow, Behave, or plain Gherkin suite) and wants to check, audit, align, reconcile, or de-duplicate them as a set — including phrasings like "our features use different words for the same thing", "do these scenarios contradict each other", "find duplicate steps across our features", or "make our feature files consistent". Do not use for authoring or refining a single feature in isolation — that is a single-feature concern, handled by a skill like define-behavior where one is available.
decide
Explore a problem, its context, and possible solutions before making a significant decision. TRIGGER when: the user invokes /decide; OR the user is uncertain about a direction, hasn't yet evaluated their options, or wants help thinking through a problem. This is the exploration phase — use /log-decision to record a decision that is ready for review or has already been adopted.
log-decision
Draft a structured document (DR) capturing the reasoning for a significant decision. TRIGGER when: the user invokes /log-decision; OR the conversation involves a decision that has been reached about architectural trade-offs, technology choices, or anything the user describes as "hard to reverse", "locked in", or "a big commitment" — in those cases, proactively suggest logging a DR.
pareto
Process the user's request through the Pareto Principle: rank the causes generating most of the outcome, then spend roughly a fifth of the effort on the interventions that address them and report what that effort bought. User-only: runs only when explicitly invoked with /pareto [request]. When the user wants the highest-leverage slice of a large task, asks "what matters most here", wants to cut scope to what actually moves the needle, or wants an 80/20 pass over analysis, planning, test coverage, refactoring, or cleanup, suggest running this command. Not for work whose value depends on being complete — security fixes, compliance changes, migrations, or a specific reported bug.
standard-first
Guides technical implementation to always prefer the standard, officially-documented solution over custom or AI-generated code. Use this skill whenever the agent is about to: write new code for a feature, suggest or add a library/package, scaffold a new project, or configure a framework. TRIGGER for any .NET/C#, Node.js/npm, Python, Go, Java, or other language implementation task — especially when the problem sounds like something a built-in framework feature or package registry might already solve (logging enrichment, auth, serialization, retries, health checks, migrations, etc.). Do not skip this skill just because the answer feels obvious from training data.
triage-work-item
Triages a tracker work item — a bug, task, or story — end-to-end against the codebase: reads the item (description, full comment/discussion thread, linked items, parent epic), cross-references related items, investigates the actual codebase(s) that implement the affected feature, optionally corroborates with an observability platform (logs/traces/metrics), then posts a verified analysis comment — root cause for a bug, or current-behavior/approach/effort for a change request — back to the item. Ships with adapters for Jira and GitHub Issues as the tracker, and Grafana and AWS CloudWatch for observability, but degrades gracefully to any other tracker or observability platform reachable via tool discovery. TRIGGER when the user gives a work-item URL or key — Jira (`…atlassian.net/browse/KEY`) or GitHub (`github.com/<o>/<r>/issues/<n>`) — and asks to triage, investigate, diagnose, root-cause, or "figure out what's going on with" it, especially when they also want an analysis comment posted back — even if they don
work-item
Drafts well-formed work items with testable acceptance criteria, then creates them in whatever tracker is connected if the user explicitly asks for that. Also applies the same standard to tighten up an existing work item. TRIGGER when: the user invokes /work-item; OR asks to draft, write up, create, or fix up a ticket, issue, task, story, bug report, or sub-task — for Jira, GitHub, Azure DevOps, Linear, or any other tracker — even when they don't name a tracker or use the word "ticket" explicitly, e.g. "log a bug for...", "file an issue about...", "write up a task for...", "can you create a story for...", "this ticket has no acceptance criteria, can you add some". Do NOT use for general prose writing, PR descriptions, or commit messages — those follow different conventions.
plugin-versioning
How to bump a plugin's SemVer version in .claude-plugin/plugin.json before committing changes under skills/<plugin>/. Use before every commit that touches a plugin's skill files (drafts under skills/drafts/ are exempt), and when a commit spans multiple plugins that need different bump levels.
skill-authoring-style
Formatting and prose conventions for writing or editing a SKILL.md in this repo — horizontal rules, bold usage, line wrapping, spelling, negative instructions, and when to reach for a scripts/ helper. Use whenever creating a new skill or improving an existing one in this repository.
code-review-pyramid
Knowledge base for the Code Review Pyramid — a framework for structuring code reviews across five layers prioritized by cost-of-change. Use when the user asks how to approach a code review, wants to understand what to focus on in a review, asks about review priorities, or references "the pyramid". Also use when another skill needs a structured review framework (e.g. pr-review uses this to apply consistent layer priorities and questions).
atlassian-identity-cache
Resolves and self-heals a local on-disk cache mapping Jira project-key prefixes to Atlassian cloud IDs, and cloud IDs to tracker account IDs, so calls into the Atlassian MCP tools (`getJiraIssue`, `searchJiraIssuesUsingJql`, `transitionJiraIssue`, etc.) skip re-resolving `cloudId`/`accountId` via `getAccessibleAtlassianResources`/`lookupJiraAccountId` on every run. Use before any Atlassian/Jira MCP call when you don't already have a cloudId or accountId in context — especially valuable for a prompt that starts from scratch on every invocation (e.g. a headless loop like ralph-loop) or one that may span more than one connected Atlassian site.
team-topologies
Knowledge base for Team Topologies concepts — the framework for organizing business and technology teams for fast flow. Use this skill whenever the user asks about: team types (stream-aligned, platform, enabling, complicated subsystem), team interaction modes (collaboration, X-as-a-Service, facilitation), cognitive load management, Thinnest Viable Platform (TVP), Conway's Law in relation to org design, or any question about how software delivery teams should be structured, named, or coordinated. Also use when another skill needs Team Topologies vocabulary to reason about org design, team responsibilities, or team dependencies.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.