softwareone-platform

review-code-risk

Adversarially review an IMPLEMENTED FIX — a committed diff on a branch — against the issue it claims to resolve and the plan it was built from, BEFORE the PR is opened. Its question is intent alignment: does THIS change resolve THAT issue, per THAT plan, without regressing callers or hiding a band-aid. Use whenever someone has an implemented fix and wants it challenged before opening a PR. Trigger phrases: "challenge this fix / diff", "will this change regress anything", "red-team this implementation", "pre-mortem this diff", "review my fix before the PR", "/review-code-risk". Do NOT trigger for: reviewing a plan / spec / RFC before implementation (review-plan-risk); generic line-level bug-hunting or style / simplification cleanup (code-review / coderabbit); security-vulnerability scanning (security-review); debugging a failing test; addressing PR reviewer comments; refactoring; or confirmatory "is this correct?" checks that want validation, not adversarial enumeration.

review-issue-fact

Fact-check an ISSUE — a bug report, story, or incident description, as text or a Jira / GitHub issue link — against the codebase that is its ground truth, BEFORE any fix is planned. The issue is not a source of truth, so the question is diagnosis alignment: do its claims hold in THIS code, or is the bug misdiagnosed. Use whenever someone wants an issue or repro fact-checked before planning a fix. Trigger phrases: "fact-check this issue", "does this issue reproduce", "is the root cause right", "is this issue real / misdiagnosed", "/review-issue-fact". Do NOT trigger for: reviewing a plan / spec / RFC before implementation (review-plan-risk); reviewing an implemented fix / diff (review-code-risk); creating, editing, or transitioning a tracker issue; generic line-level bug-hunting (code-review / coderabbit) or security scanning (security-review); debugging a failing test; or confirmatory "is my understanding correct?" checks that want validation, not adversarial fact-checking.

review-plan-risk

Adversarially review a DESIGN ARTIFACT — a plan, spec, RFC, or a skill / agent / workflow definition — for design risks BEFORE implementation begins. It rates risks, verifies the plan's load-bearing premises against the codebase, and auto-fixes the ones it rates real — in the plan, never its execution. Use whenever someone wants a design pressure-tested or a definition checked for gaps. Trigger phrases: "pre-mortem this", "stress-test this design", "what could make this fail", "find the holes in this plan", "review this spec before we build", "review this skill's design", "propagate this fix to the plugin's other skills", "/review-plan-risk". Do NOT trigger for: reviewing code or diffs, debugging an existing implementation, post-implementation code review, propagating a code change across source files (refactoring, not design review), or confirmatory "is this correct?" checks that want validation rather than adversarial enumeration.

AI & Automation Listed

resolve-issue-dashboard

Open a live, read-only dashboard that visualises resolve-issue runs across all your repos — each run's pipeline step, what each component skill and subagent is doing, the running metrics, and the gate it is paused at — by tailing the Claude Code transcripts and each repo's .claude/resolve/<ticket>/state.md. One global dashboard lists every run in a left panel; pick one to watch. Use whenever someone wants to see / watch / visualise the progress of an issue-to-PR run, says "open the pipeline dashboard", "show resolve progress", "watch the resolve-issue run", "visualise what the agents are doing", or "/resolve-issue-dashboard". Do NOT trigger to RUN the pipeline — that is resolve-issue — nor for any single stage (route those to the component skill: review-issue-fact, review-plan-risk, review-code-risk, test-authoring, open-pr, resolve-pr-comments). This skill only observes; it never drives the pipeline, answers a gate, or edits anything.

AI & Automation Listed

resolve-issue-learnings

Harvest the generic, cross-repo learnings that resolve-issue captured during its runs and turn the real ones into honored conventions — verifying each candidate against the current resolve-issue skill as ground truth, then writing the survivors to a user-global conventions file that resolve-issue reads on its next run, or proposing them as edits to its own SKILL.md when invoked inside the editable plugin source. Use whenever someone wants to distil / harvest / review / apply the learnings resolve-issue has accumulated. Do NOT trigger to RUN the issue-to-PR pipeline (that is resolve-issue) or to watch a run (resolve-issue-dashboard); this skill neither drives a run nor reads a single run's state.md — it processes the accumulated learning store. Trigger phrases: "harvest resolve-issue learnings", "distil the resolve-issue runs", "update my resolve-issue conventions", "apply what resolve-issue learned", "/resolve-issue-learnings".

resolve-issue

Orchestrate the whole issue-to-PR pipeline for one ticket: fact-check the issue, draft a plan, harden it, implement the fix, write tests, review the fix, and open the PR — behind a plan-approval gate, pausing again wherever a decision is yours. Use whenever someone wants an issue / bug / Jira ticket taken from diagnosis all the way to a pull request, even if they don't name the skill. Resumable across sessions. Do NOT trigger when the user wants only ONE stage — route those to the component skill directly: "just fact-check this issue" is review-issue-fact; "review this plan" is review-plan-risk; "review my fix / diff before the PR" is review-code-risk; "add tests" is test-authoring; "open / raise a PR" is open-pr; "address / resolve the PR comments" is resolve-pr-comments. Also do NOT trigger for merging / completing a PR, or plain git operations. Trigger phrases: "resolve this issue", "run the issue-to-PR pipeline", "take this Jira from diagnosis to PR", "/resolve-issue".

open-pr

Open a pull request (Azure DevOps or GitHub) for the current branch, giving it a title and description that follow the CALLER's own conventions — learned at runtime from their past merged PRs — with a ticket link and a description of what changed and why. Use whenever someone wants to open / raise / put up a PR, finish a branch, or send changes for review on Azure DevOps or GitHub, even if they don't say "open-pr". It always shows the title and description for confirmation first and never creates the PR without explicit approval. Trigger phrases: "open a PR", "raise a PR", "create a pull request", "put this up for review", "PR this branch", "backport this to a release line", "open-pr", "/open-pr". Do NOT trigger for: reviewing or summarizing an existing PR; triaging or replying to PR comments (that is a separate resolve-pr-comments skill); completing / merging a PR; starting a branch; or plain git operations.

resolve-pr-comments

Resolve the review comments on an existing Azure DevOps or GitHub pull request: fetch the PR's comment threads, triage each one, draft the code fixes and replies, and — after a single human confirmation — commit, push, reply, and update thread status. Use whenever someone wants to address, resolve, handle, action, or reply to PR comments or review feedback, fix the comments on a PR, or "go through the comments on PR <id>", even if they don't say "resolve-pr-comments". It respects the reviewer — it triages and drafts, and never auto-dismisses a comment — and it makes no outward change without explicit confirmation. It acts on the comments; it does not merely summarize them. Do NOT trigger for: opening or creating a PR (that is open-pr); summarizing or reviewing a PR's diff; reviewing a plan or code risk; or merging / completing a PR. Trigger phrases: "resolve PR comments", "address the review comments", "fix the comments on PR 12345", "handle the PR feedback", "/resolve-pr-comments".

add-integration-test

Generate integration tests for changed source files or a user-specified target (endpoint, handler, command, service). Trigger phrases: "add integration tests for X", "create endpoint test for /foo", "write integration test for HandlerY". Do NOT trigger for: discussions about test infrastructure, container setup questions, or end-to-end test strategy.

add-unit-test

Generate unit tests for changed source files or a user-specified target (class, method, file, directory). Trigger phrases: "add unit tests for X", "write tests for X.cs", "create unit test for ComponentY.MethodZ". Do NOT trigger for: discussions about why a test failed, TDD philosophy, test runner configuration, mocking framework comparisons.

scan-test-gaps

Scan pending changes (or a given scope) for untested areas and stale tests, prioritise gaps, and iteratively delegate test generation/updates. Trigger phrases: "find test gaps", "which classes lack tests", "scan for untested code", "check coverage holes". Do NOT trigger for: questions about why a specific test failed, coverage tool configuration, or general TDD discussions.

AI & Automation Listed

setup-test-context

Analyse the current repo and cache its test profile as one or two convention files under `.claude/conventions/tests/`, so the plugin's other skills skip re-deriving it every run. Optional: every test skill works without it. Works for any language with a detectable test framework (C#, Python, TypeScript, Go, Java, etc.) — auto-detects language and derives every convention from the repo's own tests, never a language baseline. Re-running is the refresh: it re-analyses and rewrites every file it manages. Trigger phrases: "setup test context", "initialise test conventions", "set up the test plugin", "set up tests for my Python repo", "scaffold test conventions for a TypeScript project", "cache the test conventions for this repo", "refresh the generated test conventions".

update-integration-test

Audit and update integration tests for changed handlers/endpoints. Two-phase: audit first, then execute automatically (no confirmation gate — actions derive from audit status; git is the rollback). Trigger phrases: "update integration tests for X", "refresh endpoint test for /foo". Do NOT trigger for: integration test infrastructure questions, container/fixture refactoring, or test strategy discussions.

update-unit-test

Audit and update unit tests for changed source signatures or a user-specified target. Two-phase: audit first, then execute automatically (no confirmation gate — actions derive from audit status; git is the rollback). Trigger phrases: "update unit tests for X", "the test for X is stale", "refresh unit tests". Do NOT trigger for: questions about how to write a unit test, refactoring discussions, or general test maintenance topics.