[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C27MC7QTMQAMSAJREF6VNJ":3,"skill-same:01M6C27MC7QTMQAMSAJREF6VNJ":93},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":75,"ownerHtmlUrl":76,"ownerBlogUrl":77,"ownerDescription":78,"updatedAt":79,"install":80,"resources":92},"01M6C27MC7QTMQAMSAJREF6VNJ","flow-release",null,"Config-driven release orchestration — reads .aiwg\u002Frelease.config plus optional .aiwg\u002Freleases\u002F\u003Cplan-id> sidecars and walks the selected release plan's gates","jmagly\u002Faiwg","jmagly","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1159087?v=4","01M6C10AK8N2WCSQN11FYGTJWN","Joseph Magly","01M6C10AQ8A2RMED1Y1BSVY7NF",229,"MIT","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fskills\u002Fflow-release\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"release","flow release","flow","Safety","release readiness","sonnet","release flow","dry","edit","write","read","coding","text","plan","Bash","MCP","pipeline","start","ci","beta","alpha","git","run","config","orchestration","2026-11-10 10:12:30",false,"---\nnamespace: aiwg\nname: flow-release\nplatforms: [all]\ndescription: Config-driven release orchestration — reads .aiwg\u002Frelease.config plus optional .aiwg\u002Freleases\u002F\u003Cplan-id> sidecars and walks the selected release plan's gates\ntriggers:\n  - \"help with CI builds or deployment\"\n  - \"help me make the build or deployment path safer\"\n  - \"start with pipeline safety or release readiness\"\n  - \"pipeline safety ci\"\n  - \"release flow\"\n  - \"flow release\"\n  - \"flow-release\"\n  - \"run the release flow\"\n  - \"run release flow\"\ncommandHint:\n  argumentHint: '\u003Cversion> [--plan \u003Cid>] [--channel \u003Cstable|rc|beta|alpha|nightly>] [--dry-run] [--skip-uat] [--no-mirror] [--config \u003Cpath>] [--guidance \"text\"]'\n  allowedTools: 'Task, Read, Write, Edit, Bash, Glob, Grep, mcp__git-gitea__*'\n  model: sonnet\n  category: sdlc-orchestration\n  orchestration: true\n  modelRole: coding\n  modelTier: standard\n---\n\n# Release Orchestration Flow (config-driven)\n\n> **Declarative Flow source of truth (#1539):** the release gate sequence is\n> defined as a YAML Flow at\n> [`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fflows\u002Fflow-release.playbook.yaml`](..\u002F..\u002Fflows\u002Fflow-release.playbook.yaml)\n> (with release capabilities under `flows\u002Fcapabilities\u002F`). This skill is the\n> human-readable **wrapper** over that Flow — it stays for discoverability and\n> operator guidance, and is a candidate for retirement once discovery surfaces\n> YAML Flows directly (#1540). Per-gate config still lives in\n> `.aiwg\u002Frelease.config`; the Flow encodes the gate sequence and dependencies.\n\n**You are the Core Orchestrator** for the project's release sequence.\n\n## Artifact root resolution\n\nTreat every `.aiwg\u002F...` path in this skill as a logical artifact path. Before\nreading or writing release configuration, sidecars, evidence, or reports, run\n`aiwg artifacts path` from the active workspace and use the returned absolute\ndirectory as `AIWG_ARTIFACT_ROOT`. An explicit `--config` path still wins.\nNever assume the repository-local `.aiwg\u002F` directory is the artifact corpus:\nsplit-root projects may redirect it with `AIWG_ARTIFACTS_PATH` or\n`.aiwg-location`. Do not copy redirected payload back into the local control\nplane.\n\n## Threat-assessment gate\n\nBefore publishing release notes, announcements, or forge release content,\nresolve the active workspace member's `.aiwg\u002Faiwg.config`\n`security.threatAssessment` policy and assess the final content as\n`release-note` with `tools\u002Fsecurity\u002Fthreat-assessment.mjs`. Persist the\nmachine-readable report with the release evidence. `audit` records without\ninterrupting; enforce-mode `flag`\u002F`require-authorization` pauses publication\nand `reject` blocks it. Off mode disables only this AIWG classifier.\n\n## Your role\n\nYou walk the gates declared in `.aiwg\u002Frelease.config`, in order, enforcing `hard_stop` semantics. You do not hard-code which gates exist or what they do — the config does. This is what makes the skill portable across projects with different release policies (a CalVer + npm project like AIWG vs. a SemVer + container-only project will share this skill body but differ entirely in their config).\n\nWhen the user requests a release:\n\n1. **Resolve `AIWG_ARTIFACT_ROOT` with `aiwg artifacts path`, then read `$AIWG_ARTIFACT_ROOT\u002Frelease.config`** (or the path passed via `--config`). If absent, scaffold a starter copy from the schema at `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-config.yaml` and ask the operator to review before continuing.\n2. **Discover release-plan sidecars** under `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.json`, `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.yaml`, and `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.yml`.\n   - If `--plan \u003Cid>` is passed, select that plan.\n   - If exactly one sidecar exists and no `--plan` is passed, select it.\n   - If multiple plans exist and no plan is selected, halt with an actionable error listing available plan ids.\n   - If duplicate plan ids exist, halt and require unique ids.\n   - If no sidecar exists, continue with `.aiwg\u002Frelease.config` as the legacy project-wide plan.\n3. **Report the active release plan before actions.** Print the selected plan id, sidecar path, target, and effective delivery mode before executing build, validation, publish, tag, or post-release steps.\n4. **Apply sidecar precedence.** When a release plan is active, its `delivery.mode` is authoritative for this release and overrides broad project defaults such as `direct`, `pr`, or `pr-required` where they conflict.\n5. **Resolve the target channel** from `--channel` (default: `stable`).\n6. **Validate the version** against `version_policy.format` and the `versioning` rule (CalVer no-leading-zeros, semver, etc.).\n7. **Walk the selected plan's gates in order.** For a sidecar plan, use its `build.commands`, `validation_gates`, publish target policy, and `post_release_verification` commands. Without a sidecar, walk `.aiwg\u002Frelease.config`'s `gates` array. For each gate:\n   - Skip if `required_for_channels` is present and the target channel isn't in it.\n   - Execute the gate's body (steps, invoke_skill, artifacts, review_diff, actions).\n   - On failure: if `hard_stop: true`, **halt and report**. If false, log a warning and continue.\n8. **Report** with the release tag URL, CI run URL, and tracker actions taken.\n\n## Natural language triggers\n\n- \"release v2026.5.2\"\n- \"release flow\"\n- \"flow release\"\n- \"flow-release\"\n- \"run the release flow\"\n- \"cut a release\"\n- \"promote to stable\"\n- \"ship it\"\n- \"tag a nightly\"\n\n## Release plan sidecars\n\nRelease plan sidecars are optional per-target release configs stored beside the\nmain project config:\n\n```text\n.aiwg\u002Faiwg.config\n.aiwg\u002Frelease.config\n.aiwg\u002Freleases\u002F\u003Cplan-id>.json\n.aiwg\u002Freleases\u002F\u003Cplan-id>.yaml\n.aiwg\u002Freleases\u002F\u003Cplan-id>.yml\n```\n\nUse sidecars when one repository has independent release tracks, such as an npm\npackage, documentation site, plugin bundle, container image, or customer-specific\ndistribution. The schema lives at\n`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-plan.schema.yaml`.\n\nEach sidecar can declare:\n\n- release identity: `id`, `name`, and `target`\n- build commands and validation gates\n- publish targets and registry\u002Fremote details\n- artifact, signing, SBOM, and provenance requirements\n- docs, changelog, and release-note expectations\n- post-release verification commands\n- `delivery.mode`, which overrides broad project delivery defaults while that plan is active\n\nAgents must fail closed on missing, ambiguous, or conflicting sidecars. Do not\nfall back silently to `.aiwg\u002Frelease.config` when the user requested a specific\nplan and that plan cannot be resolved.\n\n## Config-driven gate semantics\n\nThe config schema (`release-config.yaml`) defines six gate shapes. Each gate has exactly one shape:\n\n### Shape 1: `steps`\n\nSequential shell commands. Each step has an `id`, a `run` template (supports `{version}`, `{tag}`, `{channel}` placeholders), and an `expect_exit` (default 0).\n\n```yaml\n- name: local-build-test\n  hard_stop: true\n  steps:\n    - id: typecheck\n      run: npx tsc --noEmit\n    - id: unit-tests\n      run: npm test\n      tolerate_pre_existing_flakes: [test\u002Fintegration\u002Fcli-perf.test.ts]\n```\n\nExecution: run each step in order. Capture stdout\u002Fstderr. Compare exit code to `expect_exit`. If `tolerate_pre_existing_flakes` is set, treat failures in those test files as warnings (not gate failures) — useful for known-flaky perf tests.\n\nSteps may carry:\n- `required_for_channels` (skip when channel not listed)\n- `skip_when_flag` (skip when the named CLI flag is present)\n- `depends_on_channel` (per-channel variant of the `run` command)\n\n### Shape 2: `invoke_skill`\n\nDispatch another AIWG skill via the Task tool. Pass `args` as input.\n\n```yaml\n- name: doc-sync\n  hard_stop: true\n  invoke_skill: doc-sync\n  args:\n    direction: code-to-docs\n    guidance: |\n      \u003Cprose explaining the doc-sync intent>\n    dry_run_first: true\n```\n\nExecution: spawn a sub-agent invoking the named skill with `args`. Wait for completion. On failure, apply the gate's `hard_stop` policy.\n\n### Shape 3: `tracker` (CI poll)\n\nPoll an issue\u002FCI tracker until the workflows referenced complete.\n\n```yaml\n- name: ci-green\n  hard_stop: true\n  tracker: gitea\n  owner: roctinam\n  repo: aiwg\n  timeout_seconds: 600\n  poll_interval_seconds: 30\n  required_workflows: [ci.yml, validate.yml]\n```\n\nExecution: list recent action runs for the release commit. For each `required_workflows` entry, wait for `status: completed` and assert `conclusion: success`. Fail the gate on timeout or any non-success conclusion.\n\nFor Gitea, use `mcp__git-gitea__actions_run_read` if available. For GitHub, use `gh run list\u002Fview`.\n\n### Shape 4: `artifacts`\n\nAssert release-time files exist (and optionally contain a section).\n\n```yaml\n- name: changelog-and-announcement\n  hard_stop: true\n  required_for_channels: [stable]\n  artifacts:\n    - path: CHANGELOG.md\n      section_pattern: '## [{version}]'\n    - path: 'docs\u002Freleases\u002Fv{version}-announcement.md'\n      must_exist: true\n```\n\nExecution: for each artifact, check `must_exist` (default true) and, if `section_pattern` is provided, grep the file for the pattern (with `{version}` interpolated).\n\n### Shape 5: `review_diff`\n\nSurface a diff and prompt the operator.\n\n```yaml\n- name: readme-freshness\n  hard_stop: false\n  review_diff:\n    path: README.md\n    since_tag: latest-stable\n    prompt: 'Has the README been reviewed for changes shipping in this release?'\n```\n\nExecution: run `git diff \u003Csince_tag>..HEAD -- \u003Cpath>` and present to the operator. Wait for explicit acknowledgment before proceeding. With `hard_stop: false`, a \"no\" response logs a warning and continues; with `hard_stop: true`, it halts.\n\n### Shape 6: `actions` (post-release)\n\nDeclarative actions for post-release housekeeping.\n\n```yaml\n- name: post-release\n  hard_stop: false\n  actions:\n    - close_imported_issues_with_thanks: true\n    - update_release_entry: gitea\n    - update_release_entry: github\n      skip_when_flag: '--no-mirror'\n    - create_github_announcement_discussion:\n        category: Announcements\n        required_for_channels: [stable]\n        hard_stop: true\n        skip_when_flag: '--no-mirror'\n        links: [github_release, npm_version, release_notes, changelog]\n        style: conversational-impact-guidance\n```\n\nEach action is interpreted by the skill:\n\n- `close_imported_issues_with_thanks: true` — find issues with the `imported` label closed by commits in this release, post a thank-you comment on the source tracker, then close on both sides. Mirrors the May-2026 jmagly→roctinam sweep pattern.\n- `update_release_entry: \u003Ctracker>` — create or update the release entry (Gitea\u002FGitHub) with the announcement body.\n- `create_github_announcement_discussion` — after GitHub release publication\n  is verified, create one discussion in the configured category for stable\n  releases. **This action is tool-backed, not prose.** Draft the body, write it\n  to `{evidence_dir}\u002Fdiscussion.md`, then run the action's `run` command\n  (reference: `tools\u002Frelease\u002Fpublish-github-release-discussion.mjs`). The\n  publisher refuses to run until the GitHub release is published and not a\n  draft, validates the four required links and the `no_ai_attribution` policy\n  in the body, resolves the repository and category node IDs, searches the\n  category for an existing discussion titled `AIWG {version}…` and reuses it\n  so retries are idempotent (updating the body only when required links are\n  missing or `--update` is passed), issues GitHub's GraphQL `createDiscussion`\n  mutation, writes `discussion-preflight.json`, `discussion-request.json`, and\n  `discussion-result.json` beside the body, and finishes by running\n  `verify-github-release-discussion.mjs`. It fails with an actionable message\n  when Discussions are disabled, the category is absent, the release is\n  missing, or authentication lacks Discussions write access. Respect\n  `required_for_channels`, `hard_stop`, and `skip_when_flag`; the reference\n  release uses `hard_stop: true`, so a non-zero exit halts the flow and the\n  stable release is **not** reported complete without its discussion. Do not\n  substitute a hand-run GraphQL call or skip the step because the gate that\n  contains it is `hard_stop: false`; the action-level flag governs.\n\n  `{evidence_dir}` resolves to `\u003Cartifact_root>\u002Freleases\u002Fevidence\u002F{version}`,\n  where `\u003Cartifact_root>` comes from `aiwg artifacts path --json`. Create it at\n  the start of the release run and write every gate's log there; a release run\n  that leaves no evidence directory is itself a defect to report.\n\n  The discussion is a companion to the durable release records, not another\n  copy of them. Its body must link to the GitHub release, the published npm\n  version, the release announcement\u002Fnotes, and the matching CHANGELOG section.\n  Summarize the few changes with the greatest user impact; explain who each\n  helps, what it changes in practice, and one concrete way to try it. Use a\n  friendly, educational, professional voice, and close with specific questions\n  about how people are using the update or where they want more guidance. For\n  `style: conversational-impact-guidance`, prefer direct language, concrete\n  examples close to claims, varied sentence length, and useful analogies only\n  when they clarify the change. Avoid corporate filler, hype, and exhaustive\n  restatement. Keep raw install commands out of the body and point at the\n  release notes for upgrade steps; that keeps the `release-note` threat\n  assessment at `proceed`. Optional `voice_sources` refine that style when\n  readable; absence of a local voice file must not block an otherwise valid\n  release.\n\n## Completion gate: post-release verification is mandatory\n\nA stable release is **not complete** until every command in the active release\nplan sidecar's `post_release_verification` list has exited 0 (respecting\n`required_for_channels` and `skip_when_flag`). For AIWG that means both\n`release-publication-verify` and\n`node tools\u002Frelease\u002Fverify-github-release-discussion.mjs --version {version}`.\nRun them after the `post-release` gate, record their output in\n`{evidence_dir}`, and only then report the release done or close release\nissues. If a verification command fails, apply the anti-laziness recovery\nprotocol: fix the missing surface (for example, run the discussion publisher)\nand re-verify. Never report completion with a failing or unexecuted\nverification; 2026.9.7 and 2026.9.9 shipped without their announcement\ndiscussions because this gate was skipped.\n\n> **Verify publication before closing release-completion issues.** After the\n> `release` gate pushes the tag and the release workflows run, invoke the\n> `release-publication-verify` skill with the tag *before* the `post-release`\n> close-outs. It turns the tag into concrete proof — Gitea\u002FGitHub release assets,\n> `SHA256SUMS` + native package checksums, GHCR images, and installer dry-run —\n> and emits an issue-comment-ready evidence summary distinguishing MISSING from\n> FAILED proof. Do not close a release-completion issue on assumption; paste the\n> verifier's evidence into the close comment. Configure what \"published\" means\n> via the optional `publication_verify` block in `.aiwg\u002Frelease.config`.\n\n## Policy enforcement\n\nThe config's `policy` block applies at every gate:\n\n- `no_ai_attribution`: scan commit message \u002F tag message \u002F announcement body for AI-tool branding. Fail if found.\n- `ci_green_before_done`: enforced via the CI gate; never finalize a release on a red CI run.\n- `preserve_pre_release_announcements`: false by default — pre-release tags do NOT get announcements (per CLAUDE.md release-channels guidance).\n- `thank_external_reporters`: enforced in the `post-release` action above.\n\n## Failure handling\n\n- **Pre-tag failures**: revert any version-bump commits, restart after fixing the issue.\n- **Post-tag failures**: never delete pushed tags. Increment patch and re-run the flow.\n- **Gate failures with `hard_stop: true`**: halt immediately, surface the failure log, do not advance.\n- **Gate failures with `hard_stop: false`**: log a warning, continue.\n- **Supply-chain gate (signed-tag verify) failure**: this is the recovery exception to \"never delete pushed tags.\" If `tools\u002Fci\u002Fverify-signed-tag.sh` rejects the tag (wrong signing key, expired key, missing-from-maintainers.asc), no artifacts are emitted by `npm-publish.yml` \u002F `gitea-release.yml` \u002F `github-mirror.yml` — the bad tag is an empty shell. Recovery: `git tag -d \u003Ctag>`, push delete to both remotes (`git push origin :refs\u002Ftags\u002F\u003Ctag>` and `git push github :refs\u002Ftags\u002F\u003Ctag>`), then re-cut via `tools\u002Frelease\u002Fcut-tag.sh \u003Cversion>` which forces the release key. Document the incident in `docs\u002Fcontributing\u002Fversioning.md` for the next release.\n\nApply the `anti-laziness` recovery protocol (PAUSE→DIAGNOSE→ADAPT→RETRY→ESCALATE) when a gate fails — do not silently bypass with destructive shortcuts like skipping tests or stripping rules.\n\n## Tag-cutting must use the wrapper\n\n**`git tag -a` and `git tag -s` are NOT to be used directly by this skill.** The maintainer's global git config typically has `tag.gpgsign=true` and `user.signingkey=\u003Cpersonal-commit-signing-key>`, which causes plain `git tag` invocations to sign with the **wrong key** — the personal key, not the release key. The supply-chain gate will reject the tag and no artifacts will ship.\n\nAlways use `tools\u002Frelease\u002Fcut-tag.sh \u003Cversion>` for the tag step. The wrapper:\n\n1. Runs 10 pre-tag sanity checks (CalVer shape, package.json + marketplace.json lockstep, CHANGELOG entry, announcement file present, release-signing key present locally AND published in `.gitea\u002Fkeys\u002Fmaintainers.asc`)\n2. Signs with `-u \u003CRELEASE_KEY_FINGERPRINT>` (defaults to the AIWG release key; override via `AIWG_RELEASE_KEY_FINGERPRINT` env var for forks)\n3. Verifies the local signature via `git tag -v` before declaring success\n4. Does NOT push automatically — push is left to the operator so a final sanity step can run\n\nThis is the canonical path. Any release config that templates a raw `git tag -s` is incorrect and must be migrated to call the wrapper.\n\n## Defaults when no config exists\n\nIf `.aiwg\u002Frelease.config` is missing, scaffold one from the schema and ask the operator to review before continuing. The AIWG repo's own config is the reference implementation; new projects can copy it as a starting point.\n\n## Owner\n\nCanonical owner: **Deployment Manager** (`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fagents\u002Fdeployment-manager.md`).\n\nMay delegate to:\n- **Reliability Engineer** — SLO validation in pre-release gates\n- **Security Architect** — for security-sensitive releases\n- **Technical Writer** — for the announcement body\n\n## AIWG-specific reference\n\nThis repository's `.aiwg\u002Frelease.config` declares the gates AIWG uses today:\n\n1. **local-build-test** (typecheck, unit tests, build, UAT for stable)\n2. **ci-green** (Gitea workflows on the release commit)\n3. **doc-sync** (code-to-docs sync with agentic\u002F + docs\u002F scope)\n4. **changelog-and-announcement** (CHANGELOG.md + docs\u002Freleases\u002F for stable)\n5. **readme-freshness** (diff prompt for stable)\n6. **release** (tag, push, mirror, npm dist-tag)\n7. **post-release** (release entries, stable GitHub announcement discussion, tracker close-outs, and reporter thanks)\n\nThat config IS the AIWG release checklist — what was previously prose in CLAUDE.md is now an executable spec.\n\n## Related\n\n- Schema: `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-config.yaml`\n- Release plan schema: `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-plan.schema.yaml`\n- Config: `.aiwg\u002Frelease.config` (per project)\n- Release plan sidecars: `.aiwg\u002Freleases\u002F\u003Cplan-id>.yaml`, `.yml`, or `.json`\n- Rules: `versioning`, `no-attribution`, `ci-green-before-done`, `delivery-policy`, `anti-laziness`\n- Skills: `doc-sync` (called by gate 3), `release-publication-verify` (post-tag proof before closing release issues), `aiwg-pr` (when delivery.mode is pr-required for release prep), `aiwg-issue` (filing release-blocker issues)\n- Doc: CLAUDE.md \"Release Documentation Requirements\" + \"Release Checklist\"\n\n## Acceptance criteria\n\n- [ ] `.aiwg\u002Frelease.config` validated against the schema\n- [ ] Every gate in `gates` either executed or skipped per `required_for_channels`\n- [ ] All `hard_stop: true` gates green before tag push\n- [ ] CI green on the tag commit\n- [ ] No AI attribution in commits, tags, or announcement\n- [ ] Original reporters thanked (if release closes imported issues)\n- [ ] Release entry created on Gitea (and GitHub mirror for stable)\n- [ ] One idempotent GitHub Announcements discussion created for stable\n      releases, linking the GitHub release, npm version, release notes, and\n      CHANGELOG\n- [ ] npm dist-tag updated correctly per channel\n","# Release Orchestration Flow (config-driven)\n\n> **Declarative Flow source of truth (#1539):** the release gate sequence is\n> defined as a YAML Flow at\n> [`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fflows\u002Fflow-release.playbook.yaml`](..\u002F..\u002Fflows\u002Fflow-release.playbook.yaml)\n> (with release capabilities under `flows\u002Fcapabilities\u002F`). This skill is the\n> human-readable **wrapper** over that Flow — it stays for discoverability and\n> operator guidance, and is a candidate for retirement once discovery surfaces\n> YAML Flows directly (#1540). Per-gate config still lives in\n> `.aiwg\u002Frelease.config`; the Flow encodes the gate sequence and dependencies.\n\n**You are the Core Orchestrator** for the project's release sequence.\n\n## Artifact root resolution\n\nTreat every `.aiwg\u002F...` path in this skill as a logical artifact path. Before\nreading or writing release configuration, sidecars, evidence, or reports, run\n`aiwg artifacts path` from the active workspace and use the returned absolute\ndirectory as `AIWG_ARTIFACT_ROOT`. An explicit `--config` path still wins.\nNever assume the repository-local `.aiwg\u002F` directory is the artifact corpus:\nsplit-root projects may redirect it with `AIWG_ARTIFACTS_PATH` or\n`.aiwg-location`. Do not copy redirected payload back into the local control\nplane.\n\n## Threat-assessment gate\n\nBefore publishing release notes, announcements, or forge release content,\nresolve the active workspace member's `.aiwg\u002Faiwg.config`\n`security.threatAssessment` policy and assess the final content as\n`release-note` with `tools\u002Fsecurity\u002Fthreat-assessment.mjs`. Persist the\nmachine-readable report with the release evidence. `audit` records without\ninterrupting; enforce-mode `flag`\u002F`require-authorization` pauses publication\nand `reject` blocks it. Off mode disables only this AIWG classifier.\n\n## Your role\n\nYou walk the gates declared in `.aiwg\u002Frelease.config`, in order, enforcing `hard_stop` semantics. You do not hard-code which gates exist or what they do — the config does. This is what makes the skill portable across projects with different release policies (a CalVer + npm project like AIWG vs. a SemVer + container-only project will share this skill body but differ entirely in their config).\n\nWhen the user requests a release:\n\n1. **Resolve `AIWG_ARTIFACT_ROOT` with `aiwg artifacts path`, then read `$AIWG_ARTIFACT_ROOT\u002Frelease.config`** (or the path passed via `--config`). If absent, scaffold a starter copy from the schema at `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-config.yaml` and ask the operator to review before continuing.\n2. **Discover release-plan sidecars** under `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.json`, `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.yaml`, and `$AIWG_ARTIFACT_ROOT\u002Freleases\u002F*.yml`.\n   - If `--plan \u003Cid>` is passed, select that plan.\n   - If exactly one sidecar exists and no `--plan` is passed, select it.\n   - If multiple plans exist and no plan is selected, halt with an actionable error listing available plan ids.\n   - If duplicate plan ids exist, halt and require unique ids.\n   - If no sidecar exists, continue with `.aiwg\u002Frelease.config` as the legacy project-wide plan.\n3. **Report the active release plan before actions.** Print the selected plan id, sidecar path, target, and effective delivery mode before executing build, validation, publish, tag, or post-release steps.\n4. **Apply sidecar precedence.** When a release plan is active, its `delivery.mode` is authoritative for this release and overrides broad project defaults such as `direct`, `pr`, or `pr-required` where they conflict.\n5. **Resolve the target channel** from `--channel` (default: `stable`).\n6. **Validate the version** against `version_policy.format` and the `versioning` rule (CalVer no-leading-zeros, semver, etc.).\n7. **Walk the selected plan's gates in order.** For a sidecar plan, use its `build.commands`, `validation_gates`, publish target policy, and `post_release_verification` commands. Without a sidecar, walk `.aiwg\u002Frelease.config`'s `gates` array. For each gate:\n   - Skip if `required_for_channels` is present and the target channel isn't in it.\n   - Execute the gate's body (steps, invoke_skill, artifacts, review_diff, actions).\n   - On failure: if `hard_stop: true`, **halt and report**. If false, log a warning and continue.\n8. **Report** with the release tag URL, CI run URL, and tracker actions taken.\n\n## Natural language triggers\n\n- \"release v2026.5.2\"\n- \"release flow\"\n- \"flow release\"\n- \"flow-release\"\n- \"run the release flow\"\n- \"cut a release\"\n- \"promote to stable\"\n- \"ship it\"\n- \"tag a nightly\"\n\n## Release plan sidecars\n\nRelease plan sidecars are optional per-target release configs stored beside the\nmain project config:\n\n```text\n.aiwg\u002Faiwg.config\n.aiwg\u002Frelease.config\n.aiwg\u002Freleases\u002F\u003Cplan-id>.json\n.aiwg\u002Freleases\u002F\u003Cplan-id>.yaml\n.aiwg\u002Freleases\u002F\u003Cplan-id>.yml\n```\n\nUse sidecars when one repository has independent release tracks, such as an npm\npackage, documentation site, plugin bundle, container image, or customer-specific\ndistribution. The schema lives at\n`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-plan.schema.yaml`.\n\nEach sidecar can declare:\n\n- release identity: `id`, `name`, and `target`\n- build commands and validation gates\n- publish targets and registry\u002Fremote details\n- artifact, signing, SBOM, and provenance requirements\n- docs, changelog, and release-note expectations\n- post-release verification commands\n- `delivery.mode`, which overrides broad project delivery defaults while that plan is active\n\nAgents must fail closed on missing, ambiguous, or conflicting sidecars. Do not\nfall back silently to `.aiwg\u002Frelease.config` when the user requested a specific\nplan and that plan cannot be resolved.\n\n## Config-driven gate semantics\n\nThe config schema (`release-config.yaml`) defines six gate shapes. Each gate has exactly one shape:\n\n### Shape 1: `steps`\n\nSequential shell commands. Each step has an `id`, a `run` template (supports `{version}`, `{tag}`, `{channel}` placeholders), and an `expect_exit` (default 0).\n\n```yaml\n- name: local-build-test\n  hard_stop: true\n  steps:\n    - id: typecheck\n      run: npx tsc --noEmit\n    - id: unit-tests\n      run: npm test\n      tolerate_pre_existing_flakes: [test\u002Fintegration\u002Fcli-perf.test.ts]\n```\n\nExecution: run each step in order. Capture stdout\u002Fstderr. Compare exit code to `expect_exit`. If `tolerate_pre_existing_flakes` is set, treat failures in those test files as warnings (not gate failures) — useful for known-flaky perf tests.\n\nSteps may carry:\n- `required_for_channels` (skip when channel not listed)\n- `skip_when_flag` (skip when the named CLI flag is present)\n- `depends_on_channel` (per-channel variant of the `run` command)\n\n### Shape 2: `invoke_skill`\n\nDispatch another AIWG skill via the Task tool. Pass `args` as input.\n\n```yaml\n- name: doc-sync\n  hard_stop: true\n  invoke_skill: doc-sync\n  args:\n    direction: code-to-docs\n    guidance: |\n      \u003Cprose explaining the doc-sync intent>\n    dry_run_first: true\n```\n\nExecution: spawn a sub-agent invoking the named skill with `args`. Wait for completion. On failure, apply the gate's `hard_stop` policy.\n\n### Shape 3: `tracker` (CI poll)\n\nPoll an issue\u002FCI tracker until the workflows referenced complete.\n\n```yaml\n- name: ci-green\n  hard_stop: true\n  tracker: gitea\n  owner: roctinam\n  repo: aiwg\n  timeout_seconds: 600\n  poll_interval_seconds: 30\n  required_workflows: [ci.yml, validate.yml]\n```\n\nExecution: list recent action runs for the release commit. For each `required_workflows` entry, wait for `status: completed` and assert `conclusion: success`. Fail the gate on timeout or any non-success conclusion.\n\nFor Gitea, use `mcp__git-gitea__actions_run_read` if available. For GitHub, use `gh run list\u002Fview`.\n\n### Shape 4: `artifacts`\n\nAssert release-time files exist (and optionally contain a section).\n\n```yaml\n- name: changelog-and-announcement\n  hard_stop: true\n  required_for_channels: [stable]\n  artifacts:\n    - path: CHANGELOG.md\n      section_pattern: '## [{version}]'\n    - path: 'docs\u002Freleases\u002Fv{version}-announcement.md'\n      must_exist: true\n```\n\nExecution: for each artifact, check `must_exist` (default true) and, if `section_pattern` is provided, grep the file for the pattern (with `{version}` interpolated).\n\n### Shape 5: `review_diff`\n\nSurface a diff and prompt the operator.\n\n```yaml\n- name: readme-freshness\n  hard_stop: false\n  review_diff:\n    path: README.md\n    since_tag: latest-stable\n    prompt: 'Has the README been reviewed for changes shipping in this release?'\n```\n\nExecution: run `git diff \u003Csince_tag>..HEAD -- \u003Cpath>` and present to the operator. Wait for explicit acknowledgment before proceeding. With `hard_stop: false`, a \"no\" response logs a warning and continues; with `hard_stop: true`, it halts.\n\n### Shape 6: `actions` (post-release)\n\nDeclarative actions for post-release housekeeping.\n\n```yaml\n- name: post-release\n  hard_stop: false\n  actions:\n    - close_imported_issues_with_thanks: true\n    - update_release_entry: gitea\n    - update_release_entry: github\n      skip_when_flag: '--no-mirror'\n    - create_github_announcement_discussion:\n        category: Announcements\n        required_for_channels: [stable]\n        hard_stop: true\n        skip_when_flag: '--no-mirror'\n        links: [github_release, npm_version, release_notes, changelog]\n        style: conversational-impact-guidance\n```\n\nEach action is interpreted by the skill:\n\n- `close_imported_issues_with_thanks: true` — find issues with the `imported` label closed by commits in this release, post a thank-you comment on the source tracker, then close on both sides. Mirrors the May-2026 jmagly→roctinam sweep pattern.\n- `update_release_entry: \u003Ctracker>` — create or update the release entry (Gitea\u002FGitHub) with the announcement body.\n- `create_github_announcement_discussion` — after GitHub release publication\n  is verified, create one discussion in the configured category for stable\n  releases. **This action is tool-backed, not prose.** Draft the body, write it\n  to `{evidence_dir}\u002Fdiscussion.md`, then run the action's `run` command\n  (reference: `tools\u002Frelease\u002Fpublish-github-release-discussion.mjs`). The\n  publisher refuses to run until the GitHub release is published and not a\n  draft, validates the four required links and the `no_ai_attribution` policy\n  in the body, resolves the repository and category node IDs, searches the\n  category for an existing discussion titled `AIWG {version}…` and reuses it\n  so retries are idempotent (updating the body only when required links are\n  missing or `--update` is passed), issues GitHub's GraphQL `createDiscussion`\n  mutation, writes `discussion-preflight.json`, `discussion-request.json`, and\n  `discussion-result.json` beside the body, and finishes by running\n  `verify-github-release-discussion.mjs`. It fails with an actionable message\n  when Discussions are disabled, the category is absent, the release is\n  missing, or authentication lacks Discussions write access. Respect\n  `required_for_channels`, `hard_stop`, and `skip_when_flag`; the reference\n  release uses `hard_stop: true`, so a non-zero exit halts the flow and the\n  stable release is **not** reported complete without its discussion. Do not\n  substitute a hand-run GraphQL call or skip the step because the gate that\n  contains it is `hard_stop: false`; the action-level flag governs.\n\n  `{evidence_dir}` resolves to `\u003Cartifact_root>\u002Freleases\u002Fevidence\u002F{version}`,\n  where `\u003Cartifact_root>` comes from `aiwg artifacts path --json`. Create it at\n  the start of the release run and write every gate's log there; a release run\n  that leaves no evidence directory is itself a defect to report.\n\n  The discussion is a companion to the durable release records, not another\n  copy of them. Its body must link to the GitHub release, the published npm\n  version, the release announcement\u002Fnotes, and the matching CHANGELOG section.\n  Summarize the few changes with the greatest user impact; explain who each\n  helps, what it changes in practice, and one concrete way to try it. Use a\n  friendly, educational, professional voice, and close with specific questions\n  about how people are using the update or where they want more guidance. For\n  `style: conversational-impact-guidance`, prefer direct language, concrete\n  examples close to claims, varied sentence length, and useful analogies only\n  when they clarify the change. Avoid corporate filler, hype, and exhaustive\n  restatement. Keep raw install commands out of the body and point at the\n  release notes for upgrade steps; that keeps the `release-note` threat\n  assessment at `proceed`. Optional `voice_sources` refine that style when\n  readable; absence of a local voice file must not block an otherwise valid\n  release.\n\n## Completion gate: post-release verification is mandatory\n\nA stable release is **not complete** until every command in the active release\nplan sidecar's `post_release_verification` list has exited 0 (respecting\n`required_for_channels` and `skip_when_flag`). For AIWG that means both\n`release-publication-verify` and\n`node tools\u002Frelease\u002Fverify-github-release-discussion.mjs --version {version}`.\nRun them after the `post-release` gate, record their output in\n`{evidence_dir}`, and only then report the release done or close release\nissues. If a verification command fails, apply the anti-laziness recovery\nprotocol: fix the missing surface (for example, run the discussion publisher)\nand re-verify. Never report completion with a failing or unexecuted\nverification; 2026.9.7 and 2026.9.9 shipped without their announcement\ndiscussions because this gate was skipped.\n\n> **Verify publication before closing release-completion issues.** After the\n> `release` gate pushes the tag and the release workflows run, invoke the\n> `release-publication-verify` skill with the tag *before* the `post-release`\n> close-outs. It turns the tag into concrete proof — Gitea\u002FGitHub release assets,\n> `SHA256SUMS` + native package checksums, GHCR images, and installer dry-run —\n> and emits an issue-comment-ready evidence summary distinguishing MISSING from\n> FAILED proof. Do not close a release-completion issue on assumption; paste the\n> verifier's evidence into the close comment. Configure what \"published\" means\n> via the optional `publication_verify` block in `.aiwg\u002Frelease.config`.\n\n## Policy enforcement\n\nThe config's `policy` block applies at every gate:\n\n- `no_ai_attribution`: scan commit message \u002F tag message \u002F announcement body for AI-tool branding. Fail if found.\n- `ci_green_before_done`: enforced via the CI gate; never finalize a release on a red CI run.\n- `preserve_pre_release_announcements`: false by default — pre-release tags do NOT get announcements (per CLAUDE.md release-channels guidance).\n- `thank_external_reporters`: enforced in the `post-release` action above.\n\n## Failure handling\n\n- **Pre-tag failures**: revert any version-bump commits, restart after fixing the issue.\n- **Post-tag failures**: never delete pushed tags. Increment patch and re-run the flow.\n- **Gate failures with `hard_stop: true`**: halt immediately, surface the failure log, do not advance.\n- **Gate failures with `hard_stop: false`**: log a warning, continue.\n- **Supply-chain gate (signed-tag verify) failure**: this is the recovery exception to \"never delete pushed tags.\" If `tools\u002Fci\u002Fverify-signed-tag.sh` rejects the tag (wrong signing key, expired key, missing-from-maintainers.asc), no artifacts are emitted by `npm-publish.yml` \u002F `gitea-release.yml` \u002F `github-mirror.yml` — the bad tag is an empty shell. Recovery: `git tag -d \u003Ctag>`, push delete to both remotes (`git push origin :refs\u002Ftags\u002F\u003Ctag>` and `git push github :refs\u002Ftags\u002F\u003Ctag>`), then re-cut via `tools\u002Frelease\u002Fcut-tag.sh \u003Cversion>` which forces the release key. Document the incident in `docs\u002Fcontributing\u002Fversioning.md` for the next release.\n\nApply the `anti-laziness` recovery protocol (PAUSE→DIAGNOSE→ADAPT→RETRY→ESCALATE) when a gate fails — do not silently bypass with destructive shortcuts like skipping tests or stripping rules.\n\n## Tag-cutting must use the wrapper\n\n**`git tag -a` and `git tag -s` are NOT to be used directly by this skill.** The maintainer's global git config typically has `tag.gpgsign=true` and `user.signingkey=\u003Cpersonal-commit-signing-key>`, which causes plain `git tag` invocations to sign with the **wrong key** — the personal key, not the release key. The supply-chain gate will reject the tag and no artifacts will ship.\n\nAlways use `tools\u002Frelease\u002Fcut-tag.sh \u003Cversion>` for the tag step. The wrapper:\n\n1. Runs 10 pre-tag sanity checks (CalVer shape, package.json + marketplace.json lockstep, CHANGELOG entry, announcement file present, release-signing key present locally AND published in `.gitea\u002Fkeys\u002Fmaintainers.asc`)\n2. Signs with `-u \u003CRELEASE_KEY_FINGERPRINT>` (defaults to the AIWG release key; override via `AIWG_RELEASE_KEY_FINGERPRINT` env var for forks)\n3. Verifies the local signature via `git tag -v` before declaring success\n4. Does NOT push automatically — push is left to the operator so a final sanity step can run\n\nThis is the canonical path. Any release config that templates a raw `git tag -s` is incorrect and must be migrated to call the wrapper.\n\n## Defaults when no config exists\n\nIf `.aiwg\u002Frelease.config` is missing, scaffold one from the schema and ask the operator to review before continuing. The AIWG repo's own config is the reference implementation; new projects can copy it as a starting point.\n\n## Owner\n\nCanonical owner: **Deployment Manager** (`agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fagents\u002Fdeployment-manager.md`).\n\nMay delegate to:\n- **Reliability Engineer** — SLO validation in pre-release gates\n- **Security Architect** — for security-sensitive releases\n- **Technical Writer** — for the announcement body\n\n## AIWG-specific reference\n\nThis repository's `.aiwg\u002Frelease.config` declares the gates AIWG uses today:\n\n1. **local-build-test** (typecheck, unit tests, build, UAT for stable)\n2. **ci-green** (Gitea workflows on the release commit)\n3. **doc-sync** (code-to-docs sync with agentic\u002F + docs\u002F scope)\n4. **changelog-and-announcement** (CHANGELOG.md + docs\u002Freleases\u002F for stable)\n5. **readme-freshness** (diff prompt for stable)\n6. **release** (tag, push, mirror, npm dist-tag)\n7. **post-release** (release entries, stable GitHub announcement discussion, tracker close-outs, and reporter thanks)\n\nThat config IS the AIWG release checklist — what was previously prose in CLAUDE.md is now an executable spec.\n\n## Related\n\n- Schema: `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-config.yaml`\n- Release plan schema: `agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fschemas\u002Fflows\u002Frelease-plan.schema.yaml`\n- Config: `.aiwg\u002Frelease.config` (per project)\n- Release plan sidecars: `.aiwg\u002Freleases\u002F\u003Cplan-id>.yaml`, `.yml`, or `.json`\n- Rules: `versioning`, `no-attribution`, `ci-green-before-done`, `delivery-policy`, `anti-laziness`\n- Skills: `doc-sync` (called by gate 3), `release-publication-verify` (post-tag proof before closing release issues), `aiwg-pr` (when delivery.mode is pr-required for release prep), `aiwg-issue` (filing release-blocker issues)\n- Doc: CLAUDE.md \"Release Documentation Requirements\" + \"Release Checklist\"\n\n## Acceptance criteria\n\n- [ ] `.aiwg\u002Frelease.config` validated against the schema\n- [ ] Every gate in `gates` either executed or skipped per `required_for_channels`\n- [ ] All `hard_stop: true` gates green before tag push\n- [ ] CI green on the tag commit\n- [ ] No AI attribution in commits, tags, or announcement\n- [ ] Original reporters thanked (if release closes imported issues)\n- [ ] Release entry created on Gitea (and GitHub mirror for stable)\n- [ ] One idempotent GitHub Announcements discussion created for stable\n      releases, linking the GitHub release, npm version, release notes, and\n      CHANGELOG\n- [ ] npm dist-tag updated correctly per channel\n",{"name":5,"triggers":54,"namespace":61,"platforms":62,"commandHint":64,"description":7},[55,56,57,58,30,25,5,59,60],"help with CI builds or deployment","help me make the build or deployment path safer","start with pipeline safety or release readiness","pipeline safety ci","run the release flow","run release flow","aiwg",[63],"all",{"model":29,"category":65,"modelRole":35,"modelTier":66,"allowedTools":67,"argumentHint":68,"orchestration":69},"sdlc-orchestration","standard","Task, Read, Write, Edit, Bash, Glob, Grep, mcp__git-gitea__*","\u003Cversion> [--plan \u003Cid>] [--channel \u003Cstable|rc|beta|alpha|nightly>] [--dry-run] [--skip-uat] [--no-mirror] [--config \u003Cpath>] [--guidance \"text\"]",true,"main","6754967c344ccb087a8de06972f55a41067b291b","agentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fskills\u002Fflow-release",36,"https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg","https:\u002F\u002Faiwg.io","https:\u002F\u002Fgithub.com\u002Fjmagly","https:\u002F\u002Fintegrolabs.io","ml\u002Fai, industrial automation, safety\u002Fsecurity, ssi\r\n\r\nmagly.net\r\nintegrolabs.io\r\naiwg.io\r\nfortemi.com\r\npagenary.com\r\nbytecask.com","2026-11-11 08:11:25",{"source":8,"skillName":5,"commands":81,"prompt":91,"zipAvailable":69},[82,85,88],{"tool":83,"command":84},"npx","npx skills add jmagly\u002Faiwg --skill flow-release",{"tool":86,"command":87},"bunx","bunx skills add jmagly\u002Faiwg --skill flow-release",{"tool":89,"command":90},"pnpm","pnpm dlx skills add jmagly\u002Faiwg --skill flow-release","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fsdlc-complete\u002Fskills\u002Fflow-release\u002FSKILL.md",[],[94,119,142,148,155,169],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":101,"publishedAt":49},"01M70QA0BSYJ49EES9V4RE8QH1","host-hardening","Read-only system hardening baseline and plan-first host hardening recommendations for SSH, Docker bind addresses, firewall persistence, datastores, exporters and audit retention.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[100],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[102,103,104,34,105,106,107,37,108,109,38,110,111,112,113,114,115,116,117,118],"host","host hardening","hardening","re","recommendations","remediation","port","verification","access","only","retention","audit","never","firewall","bind","secrets","request",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":129,"publishedAt":49},"01M70PNT2Z4HMZPRBTAF6073NN","exposure-analysis","Read-only firewall analysis and effective host exposure reconstruction for Docker published ports, UFW bypass, stale rules, CDN scope, IPv6 asymmetry and external probe allowlists.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fforensics\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[125,128],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[130,131,132,34,133,108,134,135,38,136,102,137,111,138,139,114,115,140,141,33],"exposure analysis","analysis","unknown","credentials","collection","ufw","ports","internet","local","scope","reconstruction","operator",{"skillNo":143,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":147,"publishedAt":49},"01M70P8QATMPKA78E4FT5D2TNA","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[146],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[104,102,103,110,34,118,107,106,113,37,108,109,38,117,111,112,105,114,115,116],{"skillNo":149,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":154,"publishedAt":49},"01M70NMPVJ5H0JH131P60FW4R8","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fforensics-complete\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[152,153],{"categoryNo":126,"categoryName":127,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[131,130,114,133,108,134,38,132,102,137,111,138,139,34,115,136,135,140,141,33],{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":49},"01M6CB4DDR0B4NNCFK7ZK7449H","fixture-skill","Exercise rule delivery.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Frule-delivery\u002Fskills\u002Ffixture-skill\u002FSKILL.md",[161],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,165,166,167,168],"fixture skill","fixture","rule","delivery","true","exercise",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":176,"publishedAt":49},"01M6CB4AVK1W76MFMPP0JP32CJ","pi-local","Pi-local duplicate-precedence fixture.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fproviders\u002Fpi\u002Fproject\u002F.pi\u002Fskills\u002Fpi-local\u002FSKILL.md",[175],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[177,178,138,179,164],"pi","pi local","duplicate"]