メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
| name | generate-bdd-specs |
| description | 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. |
Convert approved ACs into well-formed Cucumber/Gherkin feature files.
<PROJ-NNN>.feature or equivalent naming)Feature: block contains the user story statementBackground: for context shared by all scenarios in the fileScenario: for individual ACsScenario Outline: + Examples: for data-driven variations@smoke, @regression, @accessibility, @negative@regression
Feature: [Story title — PROJ-NNN]
As a [actor]
I want [goal]
So that [benefit]
Background:
Given the system is in [base state]
And [shared precondition]
@smoke
Scenario: [Happy path — AC-001]
Given [specific context]
When [actor performs action]
Then [expected outcome]
And [secondary outcome if needed]
@negative
Scenario: [Failure mode — AC-002]
Given [context]
When [action with invalid input]
Then [error is surfaced appropriately]
And [no state change occurred]
@accessibility
Scenario: [Accessibility — AC-00N]
Given [page/component is rendered]
When [axe-core scan is run]
Then [zero violations are reported at WCAG 2.1 AA level]
Scenario Outline: [Data-driven scenario]
Given [context with <variable>]
When [action with <input>]
Then [outcome is <expected>]
Examples:
| variable | input | expected |
| ... | ... | ... |
| Tag | Meaning |
|---|---|
| @smoke | Run on every deploy — critical path only |
| @regression | Full regression suite |
| @negative | Error handling, invalid inputs, boundary failures |
| @accessibility | axe-core or manual WCAG check required |
| @contract | Cross-service contract test |
| @wip | In progress — excluded from CI until removed |