release-failure-notification
Define actionable, privacy-safe context for notifying maintainers when an expected-success workflow fails.
目录
Release failure notification
Use this project policy when an expected-success workflow failure needs owner-facing incident context. It defines what a notification must contain and how delivery is selected; it does not silently choose a provider, secret, destination, or paging policy. Ordinary CI, Docs Pages, deploy, and gate failures use metadata-only context; a Release failure may additionally carry verified release identity and recovery context.
Workflow
- Copy
assets/templates/release-failure-notification-transport-gate.example.jsonand explicitly select a project-approved transport. - Trigger from a completed expected-success workflow with a failed conclusion. Include repository identity, workflow run, head SHA, actor, and a link or durable reference that the maintainer can inspect. Do not invent release identity for ordinary CI, Docs Pages, deploy, or gate failures; preserve verified release context when the failed workflow is
Release. - Keep notification failure distinct from the failed workflow, avoid leaking secrets or internal paths, and make retries idempotent.
- Validate the selected transport and required credentials before enabling delivery. Without checked-in evidence or owner approval, stop at the selection gate.
Adoption preview
Before applying this policy to a target project, preview the writes to .agents/skills/release-failure-notification/ and skills-lock.json, then wait for explicit owner approval. Install it with npx skills add IvanLi-CN/style-playbook-skills --skill release-failure-notification --yes; the CLI detects the Agent and project layout.
Package resources
assets/templates/release-failure-notification-transport-gate.example.json
手动安装
将指令保存为技能目录中的 SKILL.md,并保持下列资源的相对路径。阅读与下载不会执行安装。
下载 SKILL.md公开资源
SKILL.md
- description
- Define actionable, privacy-safe context for notifying maintainers when an expected-success workflow fails.
- kind
- policy-skill
- name
- release-failure-notification
- policy_dependencies
- []
- primary_topic
- release-failure-notification
- public_url_hosts
- []
- schema_version
- 1
- slug
- release-failure-notification
- visibility
- public
Release failure notification
Use this project policy when an expected-success workflow failure needs owner-facing incident context. It defines what a notification must contain and how delivery is selected; it does not silently choose a provider, secret, destination, or paging policy. Ordinary CI, Docs Pages, deploy, and gate failures use metadata-only context; a Release failure may additionally carry verified release identity and recovery context.
Workflow
- Copy
assets/templates/release-failure-notification-transport-gate.example.jsonand explicitly select a project-approved transport. - Trigger from a completed expected-success workflow with a failed conclusion. Include repository identity, workflow run, head SHA, actor, and a link or durable reference that the maintainer can inspect. Do not invent release identity for ordinary CI, Docs Pages, deploy, or gate failures; preserve verified release context when the failed workflow is
Release. - Keep notification failure distinct from the failed workflow, avoid leaking secrets or internal paths, and make retries idempotent.
- Validate the selected transport and required credentials before enabling delivery. Without checked-in evidence or owner approval, stop at the selection gate.
Adoption preview
Before applying this policy to a target project, preview the writes to .agents/skills/release-failure-notification/ and skills-lock.json, then wait for explicit owner approval. Install it with npx skills add IvanLi-CN/style-playbook-skills --skill release-failure-notification --yes; the CLI detects the Agent and project layout.
Package resources
assets/templates/release-failure-notification-transport-gate.example.json
---
{
"description": "Define actionable, privacy-safe context for notifying maintainers when an expected-success workflow fails.",
"kind": "policy-skill",
"name": "release-failure-notification",
"policy_dependencies": [],
"primary_topic": "release-failure-notification",
"public_url_hosts": [],
"schema_version": 1,
"slug": "release-failure-notification",
"visibility": "public"
}
---
# Release failure notification
Use this project policy when an expected-success workflow failure needs owner-facing incident context. It defines what a notification must contain and how delivery is selected; it does not silently choose a provider, secret, destination, or paging policy. Ordinary CI, Docs Pages, deploy, and gate failures use metadata-only context; a Release failure may additionally carry verified release identity and recovery context.
## Workflow
1. Copy `assets/templates/release-failure-notification-transport-gate.example.json` and explicitly select a project-approved transport.
2. Trigger from a completed expected-success workflow with a failed conclusion. Include repository identity, workflow run, head SHA, actor, and a link or durable reference that the maintainer can inspect. Do not invent release identity for ordinary CI, Docs Pages, deploy, or gate failures; preserve verified release context when the failed workflow is `Release`.
3. Keep notification failure distinct from the failed workflow, avoid leaking secrets or internal paths, and make retries idempotent.
4. Validate the selected transport and required credentials before enabling delivery. Without checked-in evidence or owner approval, stop at the selection gate.
## Adoption preview
Before applying this policy to a target project, preview the writes to `.agents/skills/release-failure-notification/` and `skills-lock.json`, then wait for explicit owner approval. Install it with `npx skills add IvanLi-CN/style-playbook-skills --skill release-failure-notification --yes`; the CLI detects the Agent and project layout.
## Package resources
- `assets/templates/release-failure-notification-transport-gate.example.json`
skills/policies/release-failure-notification/assets/templates/release-failure-notification-transport-gate.example.json
{
"schema_version": 1,
"transport_selection": {
"selection_required_before_rollout": true,
"accepted_selection_evidence": [
"checked-in-project-contract",
"explicit-owner-decision"
],
"required_record": [
"selection_evidence",
"transport_owner",
"configuration_owner",
"required_secrets"
],
"when_unselected": "block-rollout",
"implicit_external_notifier": "forbidden",
"missing_selected_configuration": "fail"
}
}