azborgonovo
- 22 skills
- 0 followers
- 6 hours ago last updated
- ▌ Pareto · azborgonovoProcesses the user's request through the Pareto Principle. It ranks the causes that generate most of the outcome, spends roughly a fifth of the effort on the interventions that address them, and reports what that effort bought. This skill is user-only: it runs only when the user invokes /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 moves the needle, or wants an 80/20 pass over analysis, planning, test coverage, refactoring, or cleanup, suggest this command. Do not use it for work whose value depends on being complete, such as a security fix, a compliance change, a migration, or a specific reported bug.
- ▌ Decide · azborgonovoExplores a problem, its context, and possible solutions before someone makes a significant decision. Use when the user invokes /decide, is uncertain about a direction, has not yet evaluated their options, or wants help thinking through a problem. This skill covers the exploration phase. To record a decision that is ready for review, or that the team already adopted, use /log-decision.
- ▌ Work Item · azborgonovo bundleDrafts a well-formed work item with testable acceptance criteria, then creates it in whatever tracker is connected, when the user asks for that explicitly. Applies the same standard to tighten an existing work item. Use 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. Use it even when the user names no tracker and never says "ticket", as in "log a bug for...", "file an issue about...", "write up a task for...", "can you create a story for...", and "this ticket has no acceptance criteria, can you add some". Do NOT use it for general prose writing, a PR description, or a commit message, because those follow different conventions.
- ▌ Define Behavior · azborgonovoWrites 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, or Behave specs. Use it even when the user describes the behavior in plain prose and never says "Gherkin". Use it also to turn a ticket, a user story, or acceptance criteria into scenarios, and to clean up scenarios that leak UI, API, or database mechanics. Do not use it to write the automation code behind the steps, which is a separate concern.
- ▌ Pr Review · azborgonovo bundleReviews a merge request or pull request against its linked work item, publishes the findings as inline comments on the diff, and records the verdict on the change. It fetches the change and the work-item context, isolates the change locally, hands the review itself to the review-changes skill, posts each finding, and then approves the change or requests changes according to that verdict. It ships with adapters for GitLab and GitHub as the code host, and Jira and GitHub Issues as the tracker. For any other host or tracker, it degrades to whatever tool discovery can reach. This skill is user-only: it runs only when the user invokes /pr-review <MR or PR URL>. When the user wants to review a GitLab MR or a GitHub PR, code-review a merge request or pull request, or evaluate the diff of a change against its linked work item, suggest this command instead of a manual review.
- ▌ Log Decision · azborgonovo bundleDrafts a structured document, called a DR, that captures the reasoning behind a significant decision. Use when the user invokes /log-decision. Use it also when the conversation reaches a decision about architectural trade-offs or technology choices, or reaches anything the user calls "hard to reverse", "locked in", or "a big commitment". In those cases, suggest a DR without waiting to be asked.
- ▌ Team Topologies · azborgonovoKnowledge 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.
- ▌ Skill Authoring · azborgonovo bundleConventions for writing or editing a SKILL.md in this repo — horizontal rules, bold usage, line wrapping, spelling, negative instructions, referencing other skills, when to reach for a scripts/ helper, and the bundled `check_skills.py` validator to run before committing. Use whenever creating a new skill or improving an existing one in this repository.
- ▌ Review Skill · azborgonovoReviews, audits, and tightens a skill that already exists. Reads a `SKILL.md` for its triggering, scope, structure, prose, and domain accuracy, ranks the findings by severity, and applies them when the user approves. Use when the user wants to review, critique, audit, lint, tighten, or improve a skill they already have, fine-tune a skill they just drafted, or asks why a skill is too verbose, does not trigger, or feels wrong. Use it also when the user pastes a SKILL.md and asks for feedback. This skill reads a skill. It does not measure one: eval runs, benchmarks, automated description optimization, and packaging are outside its scope.
- ▌ Implement Scenarios · azborgonovoImplements automated tests for Gherkin scenarios (`.feature` files) that already exist, the BDD way: outside-in and client-first. Classifies the best testing strategy for each scenario, writes the test that binds to it, watches that test fail for the right reason, then drives the UI, the API, and the domain code until it passes. Use whenever the user has `.feature` files and wants to automate, implement, wire up, or "make pass" their scenarios. Use it to turn Gherkin, BDD, SpecFlow, Reqnroll, or Cucumber specs into real xUnit, NUnit, Vitest, Jest, pytest, or Playwright tests, to build a feature test-first (TDD) from acceptance criteria, to decide which scenarios belong in unit, service (Testcontainers), or end-to-end tests, or to keep a traceability link between scenarios and the tests that verify them. Use it even when the user never says "BDD" or "TDD". To author or refine the Gherkin itself, use define-behavior. To reconcile a suite of feature files against each other, use review-feature-suite.
- ▌ Review Feature Suite · azborgonovoReviews a whole suite of `.feature` files against each other and reconciles them. This is cross-file consistency auditing for Gherkin and BDD. Makes sure 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 several `.feature` files, in a Cucumber, SpecFlow, Behave, or plain Gherkin suite, and wants to audit, align, reconcile, or de-duplicate them as a set. Use it also when the user says "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". To author or refine one feature on its own, use a single-feature skill such as define-behavior where one is available.
- ▌ Plugin Versioning · azborgonovo bundleHow 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.
- ▌ Triage Work Item · azborgonovo bundleTriages a tracker work item, which is a bug, a task, or a story, end-to-end against the codebase. It reads the item with its full comment thread, links, and parent epic, cross-references related items, investigates the codebases behind the affected feature, corroborates with attached evidence and observability data, then posts a verified analysis comment back to the item. That comment gives the root cause for a bug, or the current behavior, the approach, and the effort for a change request. Ships with Jira and GitHub Issues tracker adapters, plus Grafana and CloudWatch observability adapters, and degrades to any reachable platform. Use when the user gives a work-item URL or key, on Jira (`…atlassian.net/browse/KEY`) or GitHub (`github.com/<o>/<r>/issues/<n>`), and asks to triage, investigate, diagnose, or root-cause it, even without the word "triage", as in "look into TICKET-123 and post what you find". Do not use it to read or summarize a work item with no code investigation, or to write new work items.
- ▌ Tune Agent Docs · azborgonovo bundleReviews every markdown file in a repository that steers an AI coding agent as one corpus, then tightens them. The corpus covers CLAUDE.md, AGENTS.md, GEMINI.md, `.cursor/rules/*.mdc`, `.clinerules`, `.windsurfrules`, `.github/copilot-instructions.md`, Kiro `.kiro/steering/*.md`, and files like them. Use when 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, contradicting, or burning tokens on its own steering docs. Use it even when the user names one file, because the value comes from reading that file next to its neighbors. Checks terminology consistency, front-loaded directives, the size of each doc against the stated limit of its format, always-loaded content the harness can scope, duplicated guidance, no-op instructions, and the degrees of freedom of each instruction. For one `SKILL.md` on its own, use review-skill instead.
- ▌ Review Changes · azborgonovoReviews the diff between HEAD and a fixed point, which is a commit, a branch, a tag, or a merge-base, against the Code Review Pyramid. Checks the change against the originating issue or spec, and against the repo's documented standards. Sorts every finding into blocking or non-blocking, and resolves them into one verdict: Approved, Approved with suggestions, or Request changes. Use when the user wants to review a branch, a PR, or work-in-progress changes, or asks to "review since X".
- ▌ Backfill Decisions · azborgonovoMines the git history of a repository for architecturally significant decisions taken in the past, and writes Decision Records for them retroactively, following the log-decision conventions. This skill is user-only: it runs only when the user invokes /backfill-decisions [time range, path, or topic]. When the user wants to document historical or undocumented decisions, reconstruct ADRs or DRs from git history, generate ADRs for a legacy or existing codebase, or document the history of an architecture, suggest this command. For a decision that someone is taking right now, use /log-decision instead.
- ▌ Address Pr Comments · azborgonovo bundleTriages every open review thread on a merge request or pull request, then acts on each one. For a thread you agree with, it implements a tested fix, replies in-thread with the fixing commit, and resolves the thread. For a thread you disagree with, it replies with your reasoning and leaves the thread open for the human reviewer to close. It ships with adapters for GitLab and GitHub as the code host, and it degrades to any other host that tool discovery can reach. This skill is user-only: it runs only when the user invokes /address-pr-comments <MR or PR URL>. When the user wants to work through reviewer feedback on a GitLab MR or a GitHub PR, resolve review comments, or address a round of code review, suggest this command instead of triaging threads by hand.
- ▌ Code Review Pyramid · azborgonovoKnowledge 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. review-changes loads it to apply consistent layer priorities and questions).
- ▌ Standard First · azborgonovoGuides technical implementation to always prefer the standard, officially-documented solution over custom or AI-generated code. Use when you are about to write new code for a feature, suggest or add a library or package, scaffold a new project, or configure a framework, in any language, including .NET and C#, Node.js and npm, Python, Go, Java, and the rest. Use it above all when the problem sounds like something that a built-in framework feature or a package registry already solves, such as logging enrichment, auth, serialization, retries, health checks, or migrations. Do not skip this skill because the answer feels obvious from training data.
- ▌ Release Notes · azborgonovoThe trigger for this skill covers phrasings such as "write the release notes", "draft a changelog", "what shipped in this version", and "summarise the commits since the last tag". It also covers a user who pastes a raw list of commits and asks what to do with them. Release notes, changelog, ship note, and version summary are all in range of the trigger.
- ▌ Changelog Check · azborgonovoChecks whether a branch owes the changelog an entry, and drafts the entry when it does. Reads the diff against the merge base, decides whether the change alters behavior that a user can observe, and compares that against the changelog lines the branch adds. Use when the user asks whether a branch or a merge request needs a changelog entry, asks why the changelog check failed, or asks to write the entry for a branch. Do not use it to assemble the release notes for a whole version, because that reads the range between two tags rather than one branch.
- ▌ Terraform Modules · azborgonovoTerraform helper for our infrastructure. Use this whenever the user works on infrastructure of any kind, or mentions the cloud, a deployment, a pipeline, or a cluster.