القائمة
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 |