refactor(skills): rename skills with category prefixes (setup-/security-)

.claude/skills/allocate-cve/SKILL.md → .claude/skills/security-allocate-cve/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: allocate-cve
+name: security-allocate-cve
 description: |
   Walk a security team member through allocating a CVE for an
   <tracker> tracking issue. Prints the ASF Vulnogram
@@ -11,7 +11,7 @@ description: |
   *CVE tool link* field, adds the `cve allocated` label, posts a
   collapsed status-change comment, and runs `generate-cve-json
   --attach` to embed the paste-ready JSON in the body. Finishes by
-  handing off to the `sync-security-issue` skill to reconcile the
+  handing off to the `security-sync-issues` skill to reconcile the
   rest of the tracker (milestone, assignee, reporter drafts, fix-PR
   state) now that the CVE landing is complete.
 when_to_use: |
@@ -32,7 +32,7 @@ when_to_use: |
      Before running any bash command below, substitute these with the
      concrete values from the adopting project's <project-config>/project.md. -->
 
-# allocate-cve
+# security-allocate-cve
 
 Walks a security team member through the CVE-allocation step of the
 [handling process](../../../README.md) for a given
@@ -81,7 +81,7 @@ of the allocated ID does not need to be done by the PMC member.
 
 **Golden rule — every `<tracker>` reference is a clickable
 link**, per Golden rule 2 in
-[`sync-security-issue`](../sync-security-issue/SKILL.md). The
+[`security-sync-issues`](../security-sync-issues/SKILL.md). The
 allocation recipe, the post-allocation proposal, and the status-
 change comment must all follow the link-form convention from
 [`AGENTS.md`](../../../AGENTS.md).
@@ -345,7 +345,7 @@ user to confirm. Numbered items:
 1. **Set the *CVE tool link* body field** to
    `https://cveprocess.apache.org/cve5/CVE-YYYY-NNNNN`. Patch only
    this one field; do not touch the rest of the body. Use the
-   `sync-security-issue` skill's body-field-surgery recipe — read
+   `security-sync-issues` skill's body-field-surgery recipe — read
    the full body, replace the *CVE tool link* field's value between
    its `### CVE tool link\n\n` header and the next `### ` or
    end-of-body, write back via `gh issue edit --body-file`.
@@ -363,8 +363,8 @@ user to confirm. Numbered items:
    creates one; on the way, the skill must also fold any
    pre-existing legacy bot comments into the new rollup per the
    fold-legacy sub-step described in
-   [`sync-security-issue`](../sync-security-issue/SKILL.md) —
-   allocate-cve is a common first write after a long pause, so
+   [`security-sync-issues`](../security-sync-issues/SKILL.md) —
+   security-allocate-cve is a common first write after a long pause, so
    the legacy comments are often there.
 4. **Regenerate the CVE JSON attachment** in the tracker body by
    running
@@ -374,12 +374,12 @@ user to confirm. Numbered items:
    This is how the CVE record first gets seeded with the allocated
    ID. The remediation-developer credit (if any) comes from the
    tracker's *Remediation developer* body field — populated by the
-   `sync-security-issue` skill from the linked PR's author the
+   `security-sync-issues` skill from the linked PR's author the
    first time *PR with the fix* is set, and editable by hand
    thereafter. No CLI flag needed.
 5. **Draft a reporter status update** — only when the real
    reporter's Gmail thread is known and the ball is in our court
-   (see `sync-security-issue` Step 1c). Keep the draft short, per
+   (see `security-sync-issues` Step 1c). Keep the draft short, per
    the "Brevity: emails state facts, not context" section of
    [`AGENTS.md`](../../../AGENTS.md): one sentence that the CVE has
    been allocated, one sentence that the advisory will be sent
@@ -434,7 +434,7 @@ spaces inside the block, one blank line after
 - Label `cve allocated` added.
 - CVE JSON attachment embedded in the issue body — paste into [Vulnogram `#source`](https://cveprocess.apache.org/cve5/<CVE-YYYY-NNNNN>#source) to seed the record.
 
-**Next:** <one-sentence next step — e.g. "design the fix (`fix-security-issue` skill)", or "release manager completes [process step 12](../../../README.md) once the fix ships">.
+**Next:** <one-sentence next step — e.g. "design the fix (`security-fix-issue` skill)", or "release manager completes [process step 12](../../../README.md) once the fix ships">.
 
 <Reporter-notification line — one of the four options below.>
 
@@ -496,16 +496,16 @@ partial failures stay legible:
 
 If any step fails, stop and ask the user how to proceed — do not
 guess. The body edit (step 1) is the only *load-bearing* step; if
-steps 2–5 fail, a subsequent `sync-security-issue` run will pick up
+steps 2–5 fail, a subsequent `security-sync-issues` run will pick up
 the slack because it reads the CVE ID from the body.
 
 ---
 
-## Step 6 — Hand off to `sync-security-issue`
+## Step 6 — Hand off to `security-sync-issues`
 
 Right after the apply loop finishes (and before the recap in Step
 7), invoke the
-[`sync-security-issue`](../sync-security-issue/SKILL.md) skill on
+[`security-sync-issues`](../security-sync-issues/SKILL.md) skill on
 the same tracker. The CVE allocation touches every axis the sync
 skill reconciles — labels, body fields, assignees, milestone,
 reporter-notification drafts, cross-referenced fix PRs — and
@@ -526,7 +526,7 @@ that the next triage sweep has to clean up from scratch. Always
 run it.
 
 **How to invoke.** The sync skill is prompt-driven, so this is a
-meta-step: tell the user *"running `sync-security-issue` on
+meta-step: tell the user *"running `security-sync-issues` on
 [<tracker>#<N>](...) to reconcile the rest of the
 tracker"* and then run the sync skill's Step 1 (Gather state) on
 the same issue. Sync produces its own numbered proposal with its
@@ -542,7 +542,7 @@ bump.
 **When the handoff is not appropriate.** Skip the sync handoff
 **only** if the user explicitly says they are about to close the
 tracker (e.g. allocated-then-decided-to-reject — a rare case, but
-possible), or if sync was already running when `allocate-cve` was
+possible), or if sync was already running when `security-allocate-cve` was
 invoked (nested invocation — sync's own Step 1 will detect the
 fresh CVE on its next pass anyway). In every other case, run it.
 
@@ -607,19 +607,19 @@ presenting.
   particular step 6 (CVE allocation).
 - [`AGENTS.md`](../../../AGENTS.md) — confidentiality, linking
   conventions, reporter-supplied CVSS rule.
-- [`sync-security-issue`](../sync-security-issue/SKILL.md) —
+- [`security-sync-issues`](../security-sync-issues/SKILL.md) —
   **mandatory follow-up** to this skill (Step 6). Reconciles the
   tracker, the mail thread, and any fix PR after the CVE landing
   touches labels, body fields, and comments. Always runs; only
   skipped in the explicit edge cases listed in Step 6.
 - [`generate-cve-json`](../../../tools/vulnogram/generate-cve-json/SKILL.md) — Step 4
   regenerates the CVE JSON attachment in the body so Vulnogram can
   be seeded via the `#source` tab paste.
-- [`import-security-issue`](../import-security-issue/SKILL.md) /
-  [`deduplicate-security-issue`](../deduplicate-security-issue/SKILL.md)
+- [`security-import-issues`](../security-import-issues/SKILL.md) /
+  [`security-deduplicate-issues`](../security-deduplicate-issues/SKILL.md)
   — the two on-ramps that feed trackers into this skill; running
   dedupe before allocation is how we avoid burning two CVE IDs on
   the same root-cause bug.
-- [`fix-security-issue`](../fix-security-issue/SKILL.md) — the
+- [`security-fix-issue`](../security-fix-issue/SKILL.md) — the
   follow-up after allocation: open the public fix PR with the CVE
   context kept internal.

.claude/skills/deduplicate-security-issue/SKILL.md → .claude/skills/security-deduplicate-issues/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: deduplicate-security-issue
+name: security-deduplicate-issues
 description: |
   Merge two <tracker> tracking issues that describe the same
   root-cause vulnerability (typically discovered independently by two
@@ -12,7 +12,7 @@ description: |
 when_to_use: |
   Invoke when a security team member says "dedupe #NNN and #MMM",
   "merge #MMM into #NNN", "#MMM is a duplicate of #NNN", or when the
-  import-security-issue skill's Step 2a surfaces a STRONG match (GHSA
+  security-import-issues skill's Step 2a surfaces a STRONG match (GHSA
   ID collision) between a new report and an existing tracker. Also
   appropriate as a periodic cleanup action when a triager spots two
   open trackers describing the same bug from different angles.
@@ -27,7 +27,7 @@ when_to_use: |
      Before running any bash command below, substitute these with the
      concrete values from the adopting project's <project-config>/project.md. -->
 
-# deduplicate-security-issue
+# security-deduplicate-issues
 
 Merges two `<tracker>` tracking issues that describe the
 same underlying vulnerability. The output is a single tracker
@@ -55,7 +55,7 @@ different **scope labels** (`airflow` vs. `providers`, `airflow`
 vs. `chart`, etc.) must not be merged. If an external reporter
 rediscovers the same bug in two different products' surfaces, that
 is a multi-scope report and the resolution is a
-**scope split** handled by the `sync-security-issue` skill, not a
+**scope split** handled by the `security-sync-issues` skill, not a
 dedupe. This skill refuses to operate when the two candidate
 trackers have different scope labels, and the proposal says so
 explicitly.
@@ -129,7 +129,7 @@ Verify:
 - Both have the **same scope label** — `airflow` vs. `airflow`,
   or `providers` vs. `providers`, or `chart` vs. `chart`. If the
   scope labels differ, refuse the merge and tell the user this is
-  a multi-scope report to be handled by `sync-security-issue`'s
+  a multi-scope report to be handled by `security-sync-issues`'s
   scope-split flow instead.
 - Neither tracker is already labelled `duplicate` (that would
   indicate a partial-merge already happened and someone left it
@@ -286,7 +286,7 @@ merges.
 
 Two rollup-comment entries, one per tracker — **not** two new
 top-level comments. The entries are appended to each tracker's
-existing status-rollup comment (created by `import-security-issue`)
+existing status-rollup comment (created by `security-import-issues`)
 via the upsert recipe in
 [`tools/github/status-rollup.md`](../../../tools/github/status-rollup.md#upsert-recipe--append-to-an-existing-rollup-or-create-one).
 When either tracker does not yet carry a rollup (legacy tracker
@@ -387,7 +387,7 @@ After confirmation, apply **sequentially** (never in parallel):
    the rollup if none exists yet. The same step folds any legacy
    bot comments on the kept tracker into the rollup first, per
    the fold-legacy sub-step in
-   [`sync-security-issue`](../sync-security-issue/SKILL.md).
+   [`security-sync-issues`](../security-sync-issues/SKILL.md).
 3. Rollup-comment upsert on the dropped tracker — append the
    `Merge (dropped)` entry (same recipe; fold legacy comments
    first when needed).
@@ -399,7 +399,7 @@ After confirmation, apply **sequentially** (never in parallel):
 6. `uv run --project <framework>/tools/vulnogram/generate-cve-json generate-cve-json <keep> --attach`
    — the *Remediation developer* body field is the source of truth
    for remediation-developer credits (populated by the
-   `sync-security-issue` skill from the linked PR's author); no CLI
+   `security-sync-issues` skill from the linked PR's author); no CLI
    flag needed
 7. For each legacy bot comment folded in steps 2 / 3, delete the
    original with `gh api -X DELETE
@@ -434,7 +434,7 @@ recap before presenting.
 ## Hard rules
 
 - **Never merge across scopes.** Different scope labels → scope
-  split (via `sync-security-issue`), not dedupe.
+  split (via `security-sync-issues`), not dedupe.
 - **Never re-synthesize credits.** Copy each reporter's credit line
   verbatim from their tracker.
 - **Never propagate a reporter-supplied CVSS** from the dropped
@@ -457,7 +457,7 @@ recap before presenting.
 ## When dedupe is **not** appropriate
 
 - The two trackers are in **different scopes** → use the scope-split
-  flow in `sync-security-issue` instead.
+  flow in `security-sync-issues` instead.
 - The two trackers describe the same code surface but **different
   bugs** with **different fixes** (for example, two separate
   allowlist gaps in the same file, each requiring its own
@@ -476,11 +476,11 @@ recap before presenting.
 - [`README.md`](../../../README.md) — the handling process;
   duplicates are resolved here at various steps rather than at a
   single numbered step.
-- [`import-security-issue`](../import-security-issue/SKILL.md) —
+- [`security-import-issues`](../security-import-issues/SKILL.md) —
   Step 2a surfaces potential duplicates before a new tracker is
   even created, so in the ideal case this skill is never needed
   on a fresh import.
-- [`sync-security-issue`](../sync-security-issue/SKILL.md) — runs
+- [`security-sync-issues`](../security-sync-issues/SKILL.md) — runs
   on the kept tracker after the merge to reconcile labels /
   milestone / credit-preference drafts for both reporters.
 - [`generate-cve-json`](../../../tools/vulnogram/generate-cve-json/SKILL.md) —

.claude/skills/fix-security-issue/SKILL.md → .claude/skills/security-fix-issue/SKILL.md

@@ -1,9 +1,9 @@
 ---
-name: fix-security-issue
+name: security-fix-issue
 description: |
   Attempt to fix a security issue tracked in <tracker> by
   implementing the change in a public <upstream> PR. Runs the
-  sync-security-issue skill first to reconcile the issue's state, then
+  security-sync-issues skill first to reconcile the issue's state, then
   analyses the discussion to decide whether the issue is easily fixable
   (clear consensus, small scope, known location). If it is, proposes an
   implementation plan, waits for explicit user confirmation, writes the
@@ -33,11 +33,11 @@ when_to_use: |
      Before running any bash command below, substitute these with the
      concrete values from the adopting project's <project-config>/project.md. -->
 
-# fix-security-issue
+# security-fix-issue
 
 This skill automates the "attempt a fix" step of the security handling
 process for issues in [`<tracker>`](https://github.com/<tracker>).
-It composes with the [`sync-security-issue`](../sync-security-issue/SKILL.md)
+It composes with the [`security-sync-issues`](../security-sync-issues/SKILL.md)
 skill — it always runs the sync first so that the issue's state is
 reconciled with the mail thread and any existing PRs before attempting
 any new work.
@@ -167,7 +167,7 @@ Only after **every** check is green, proceed to Step 1.
 
 ## Step 1 — Sync the issue first
 
-Run the [`sync-security-issue`](../sync-security-issue/SKILL.md) skill
+Run the [`security-sync-issues`](../security-sync-issues/SKILL.md) skill
 on the same issue number and apply any state corrections the user
 confirms there. **Do not attempt a fix before the sync has completed**,
 because:
@@ -552,7 +552,7 @@ Now that a public PR exists, update the private tracking issue:
    convention), run the upsert recipe's Step 2b to create it and
    fold any pre-existing bot comments into the new rollup first —
    see the fold-legacy sub-step in
-   [`sync-security-issue`](../sync-security-issue/SKILL.md).
+   [`security-sync-issues`](../security-sync-issues/SKILL.md).
 
    Before writing the entry, **scrub the body for bare-name
    mentions** of project maintainers, release managers, and
@@ -570,14 +570,14 @@ Now that a public PR exists, update the private tracking issue:
 2. **Update the issue body "PR with the fix" field** if it is empty
    or points to a stale PR. Use `gh issue view --json body`, patch
    only that field, and apply via `gh issue edit --body-file`, as
-   in the [`sync-security-issue`](../sync-security-issue/SKILL.md)
+   in the [`security-sync-issues`](../security-sync-issues/SKILL.md)
    skill.
 
 3. **Maintain milestones and labels** — see the next section.
 
 4. **Status update to the reporter** — if the <tracker> issue has an
    identified external reporter and the reporter has not yet been
-   told about the fix PR, delegate to the `sync-security-issue`
+   told about the fix PR, delegate to the `security-sync-issues`
    skill's "Status update to the reporter" category by re-running
    that skill with a pointer to the new PR. Do **not** draft the
    reporter email directly in this skill — it is the sync skill's
@@ -661,7 +661,7 @@ For a post-triage, pre-merge fix, the target label set is:
 - `needs triage` **removed** (if still present after triage);
 - `pr created` once the public PR is open;
 - **not** `pr merged` or `fix released` (those belong to post-merge
-  / post-release states, applied by the `sync-security-issue` skill
+  / post-release states, applied by the `security-sync-issues` skill
   on later runs);
 - **not** `announced - emails sent` or `announced` (those
   belong to post-advisory states, also applied by the sync skill).
@@ -723,7 +723,7 @@ Print a short recap:
 - the comment posted on the `<tracker>` issue,
 - the backport label that was applied (or a note that none was needed),
 - the next step — typically *"wait for review; re-run
-  sync-security-issue after the PR merges to transition the issue
+  security-sync-issues after the PR merges to transition the issue
   from `pr created` to `pr merged` and update the milestone"*.
 
 ---
@@ -766,7 +766,7 @@ Print a short recap:
 
 ## References
 
-- [`sync-security-issue` skill](../sync-security-issue/SKILL.md) — run this first.
+- [`security-sync-issues` skill](../security-sync-issues/SKILL.md) — run this first.
 - [`README.md`](../../../README.md) — canonical process description, especially steps 7–9 (implementing the fix).
 - [`AGENTS.md`](../../../AGENTS.md) — repo-wide rules (confidentiality, commit trailers, tone, CVE linking).
 - [`<upstream>/AGENTS.md`](https://github.com/<upstream>/blob/main/AGENTS.md) — parent conventions this skill defers to.