agentic-plugins-marketplace

Use when working inside an api-cp-* repo and the user wants to publish/expose their API docs, "add my API to the catalog", set up the publish-api-docs workflow, or get a hmcts.github.io docs site. Wires the current repo into the amp-catalog Swagger UI pipeline, handles the two one-time GitHub Pages admin gaps that fail silently otherwise, and verifies the live site. This is the per-repo counterpart to the catalog-publisher agent, which only touches amp-catalog/docs/apis.json.

Wire up auto-dev and auto-SIT deployment CI for a service-cp-* repo after Azure provisioning and cp-vp-aks-deploy registration are complete. Idempotent — safe to invoke again if the jobs already exist. Use when a service-cp-* repo is missing the deploy-dev and deploy-sit jobs in its ci-build-publish.yml, or when setting up a newly bootstrapped service for the first time.

Start a new HMCTS API-Marketplace API specification repo using the canonical HMCTS template (api-hmcts-crime-template) as master source. Use when creating a new api-cp-* repo (OpenAPI-first, spec-only) distinct from a runtime service-cp-* service.

Stand up a new HMCTS API-Marketplace service-cp-* using the canonical HMCTS template (service-hmcts-crime-springboot-template) as master source. Use when creating a new Spring Boot service for the Common Platform.

Bootstrap the gitignored .claude/CLAUDE.md for any api-cp-* or service-cp-* repo with three @import lines pointing to hmcts-apim-sdlc-orchestrator context standards. Runs automatically on every session start via the SessionStart hook — invoke manually only to force an update.

Use when the user wants to review, audit, or check an OpenAPI v3 spec — applies HMCTS data-sharing policy (UK GDPR/DPA 2018), infrastructure SLA (Azure APIM/AKS), API standards, and security standards (OAuth 2, TLS, input validation). Returns a scored report with Critical/Warning/Info findings.

Export a self-contained, night-friendly HTML artifact for a CPP pipeline stage — using the right template from the bundled gallery. Use whenever a decision must be made, a plan needs improving, or a design gap is discovered — AND always to export the implementation plan before any code is written. Picks the template that fits the scenario (plan, decision, comparison, architecture, investigation, status) and writes it to docs/pipeline/artifacts/. <example> user: "We've finished the design — get ready to implement the booking engine." assistant: "Before implementation starts I'll use export-design-artifact to export the implementation plan (template 03) to docs/pipeline/artifacts/ and surface it at the Stage 4 gate." </example> <example> user: "Should the move-to-past action be a new endpoint or extend the existing one?" assistant: "That's a decision — I'll use export-design-artifact to produce a decision record (template 07) weighing the options before we commit." </example> <example> user: "The design does

Review a pull request for a CPP or HMCTS Crime Common Platform repository against CPP coding standards. Use when asked to review a PR or code changes specifically in a CP or HMCTS context service.

Use when the user wants to check accessibility, run an a11y review, verify WCAG 2.1 AA compliance, or add axe-core tests to a UI component or page.

Use when the user wants to record an architecture decision, document a design choice, write an ADR, or capture why a significant technical choice was made.

Use when the user wants to convert acceptance criteria into Cucumber/Gherkin feature files, write a .feature file, or produce BDD scenarios for a story.

Use when the user wants to write, derive, or review acceptance criteria for a requirement or user story. Triggers on phrases like "write ACs for…", "turn this into Given/When/Then", or "what are the acceptance criteria for…".

Use when the user asks to review the current branch, check code quality, run a code review, or assess changes before merging.

Use when the user wants a structured code review checklist, a pass/fail rubric for a PR, or a consistent review record across correctness, tests, security, quality, dependencies, and docs.

Use when the user asks to commit staged changes, create a commit message, or write a git commit following conventional commits format.

Use when the user asks to explain the codebase, onboard a new developer, give an overview of the project, or describe the architecture and structure.

Use when the user asks what plugins are available, wants to find or install a plugin, searches for a specific capability, or asks about the marketplace.