メニュー
Align chosen technologies with the PagoPA DX Technology Radar. Use this skill to check the radar status of cloud services, languages, frameworks, and other technologies before recommending them in code or documentation, and to issue warnings for deprecated or discouraged options.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Create and update a structured Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks for a Design Review, DR, SRS, solution design, technical requirements document, architecture review, or to turn an accepted RFC into the operational design. Write Markdown first, preserve stable IDs, expose gaps without inventing decisions, invoke uc-engraver when detailed Use Cases are requested, and hand confirmed Confluence publication to the confluence-librarian skill.
Project approved DR/SRS and Use Case contracts into a reviewable Jira backlog. Use whenever a user asks to create, decompose, refine, synchronize, or update Jira Epics, User Stories, or technical Tasks from a PRD, DR/SRS, Use Case, JTBD, acceptance check, RFC, or requirements document. Propose multiple cohesive Epics that fit a few sprints, write actor-facing Stories sized for one two-week sprint, separate enabling work into Tasks, preserve source traceability, and require explicit confirmation before Jira mutations.
Create and update structured Use Case child documents for a parent Design Review / Software Requirements Specification (DR/SRS). Use whenever a user asks to define, write, refine, synchronize, or publish a Use Case, UC, scenario, acceptance checks, or detailed behavior from a PRD, DR/SRS, JTBD, Service Blueprint, Figma, RFC, contract, or task intake. Preserve stable UC/AC IDs, reuse actor names exactly from the linked PRD, expose gaps without inventing behavior, update and verify the parent DR/SRS catalog, and hand confirmed Confluence publication to confluence-librarian.
Publish and update prepared pages and document artifacts in Confluence without losing structure or traceability. Use whenever a user asks to publish, create, update, translate, or synchronize Markdown, HTML, or another readable document to Confluence, including hierarchical child pages under a parent catalog. Require explicit confirmation before irreversible publication and preserve headings, tables, links, statuses, IDs, and intentional gaps.
Write and update a structured Product Requirements Document (PRD) from gathered product material. Use when a product manager wants to turn discovery notes, meeting summaries, strategy input, or a rough product document into a Confluence-compatible PRD covering needs, actors, JTBD, goals, metrics, guardrails, dependencies, constraints, feasibility red flags, design discovery, open questions, and support readiness. Preserve stable English IDs, manage explicit draft-to-review readiness, and offer optional Confluence publication only after writing.
Build or extend backend tests for Node.js/TypeScript services with real runtimes, Testcontainers dependencies, optional .env.test cloud services, and integration and/or record-replay coverage. Use for integration tests, live contracts, freeze-before-refactor, VCR/golden-master, cassette record/verify, Azure Functions harnesses, replacing mock-heavy tests, or adding scenarios to an existing backend-test harness. Always use when choosing between integration and record-replay.
| name | technology-radar |
| description | Align chosen technologies with the PagoPA DX Technology Radar. Use this skill to check the radar status of cloud services, languages, frameworks, and other technologies before recommending them in code or documentation, and to issue warnings for deprecated or discouraged options. |
Before choosing any service or technology, verify its adoption status in the PagoPA DX Technology Radar:
GET https://dx.pagopa.it/radar.json
Important Always ask the user to confirm the choice for technolgies that don't appear in the radar, and explain the rationale for the recommendation.
Each entry has a ring field:
| Ring | Meaning | Action |
|---|---|---|
adopt | Stable, widely used in production | Prefer these — use as default choice |
trial | Validated in limited scenarios | Use with awareness — note it in a README comment |
assess | Promising but not yet validated | Avoid unless explicitly requested by the user |
hold | Deprecated or discouraged | Do not use — warn the user and suggest an adopt alternative |
If the user requests a service flagged as hold, issue an explicit warning:
⚠️ [Service name] is marked as hold in the PagoPA DX Technology Radar. It is discouraged for new projects. Consider using [adopt alternative] instead.
If the user explicitly confirms they want to proceed, generate the code but add a comment on the resource block:
Example:
# radar: hold — consider migrating to <alternative>