---
name: catalyst-update-skill-registry
description: >
  Regenerates the project's skill catalog at `.claude/skills/REGISTRY.md` by scanning every
  SKILL.md across the three scopes (monorepo, frontend, backend) and preserving the scope-first
  taxonomy. Trigger: IMMEDIATELY after creating, editing, deleting, or renaming ANY SKILL.md in the
  project — even if the user does not ask explicitly — because a stale registry lies to the next
  Claude and breaks skill discovery. Also trigger whenever the user mentions "update the registry",
  "regenerate the catalog", "skill catalog", "skill index", or anything related to the inventory of
  skills, EVEN IF they don't use the word "registry".
license: MIT
metadata:
  author: aurora
  version: '1.1'
  auto_invoke: 'After creating/editing/deleting a SKILL.md; when user asks to update the skill registry'
allowed-tools: Read, Edit, Write, Glob, Grep, Bash
---

## When to Use

- You have just created a new `SKILL.md` in any scope
- You have just edited the `name`, `description`, or trigger of an existing `SKILL.md`
- You have just deleted or renamed a skill
- The user asks to "update the registry", "regenerate the skill catalog", or similar

**STOP if you are not sure** which skills changed. Scan first, do not assume.

## Critical Patterns

### 1. Scope-first taxonomy

The REGISTRY is organized into three sections by scope, and within each one by type. Scope comes
first because it matches the directory layout and the way a reader filters: "I'm touching Angular"
→ go to Frontend. Breaking that order forces readers to re-learn the mental model.

| Scope | Directory | Current subcategories |
| --- | --- | --- |
| **Monorepo** | `.claude/skills/` | Aurora Domain, Code Quality, Workflow — OpenSpec SDD, Meta |
| **Frontend** | `frontend/.claude/skills/` | UI & Components, Layout & Design, i18n, Structure & Review |
| **Backend** | `backend/.claude/skills/` | Structure & Review (add others if new skills appear) |

**Do NOT change the taxonomy without reason.** If a new skill does not fit an existing
subcategory, add a new one — but preserve the existing ones.

### 2. Exclude this skill from self-processing

`catalyst-update-skill-registry` must appear under the `Meta` section of the monorepo scope, but do NOT
self-duplicate logic by scanning itself multiple times. Include it exactly once.

### 3. Skills duplicated between frontend and backend

If a skill with the same `name` exists in both `frontend/.claude/skills/` AND
`backend/.claude/skills/`, they are TWO separate skills (not a single dual-scope one):

- One entry in the `frontend` scope table, marked with `*`
- One entry in the `backend` scope table, marked with `*`
- Section note: *"Skills marked with `*` also exist in the other stack. When modifying one version,
  evaluate whether the change applies to the other."*

### 4. Trigger formatting

Extract from the frontmatter `description` the text after `Trigger:` if present. Otherwise, use
the full description text. Keep it concise (1-2 lines).

### 5. Preserve the preamble

The REGISTRY preamble (title, "How to use", sync rule) is preserved across regenerations. Only the
tables change.

## Procedure

### Step 1 — Scan SKILL.md files

```bash
for f in .claude/skills/*/SKILL.md frontend/.claude/skills/*/SKILL.md backend/.claude/skills/*/SKILL.md; do
  echo "=== $f ==="
  awk '/^---$/{c++; next} c==1{print}' "$f"
done
```

Extract for each skill:

- `name` (from frontmatter)
- `description` (from frontmatter, the narrative part)
- Trigger (the text after `Trigger:` inside `description`)

### Step 2 — Classify

For each skill:

1. **Scope** = the directory it lives in (monorepo / frontend / backend)
2. **Subcategory** = infer from the skill's function:
   - catalyst-schema (operates on `*.aurora.yaml` schemas/DDD) → `Aurora Domain`
   - typescript, prettier, eslint → `Code Quality`
   - openspec-\*, sdd-\* → `Workflow — OpenSpec SDD`
   - catalyst-skill-creator, catalyst-update-skill-registry → `Meta`
   - catalyst-component-\*, catalyst-data-table-\*, catalyst-form-\* → `UI & Components`
   - layout-\*, design-\* → `Layout & Design`
   - transloco-\*, i18n-\* → `i18n`
   - catalyst-project-structure, catalyst-review-module → `Structure & Review`

If a skill does not fit, STOP and ask the user before inventing a new subcategory.

### Step 3 — Detect duplicates

Compare names between `frontend/.claude/skills/` and `backend/.claude/skills/`. Mark matches with
`*` in both entries.

### Step 4 — Write REGISTRY.md

Use exactly this template (preserving the preamble and section order):

```markdown
# Skill Registry — Aurora Catalyst

A navigable catalog of the project's skills, organized by **scope** (physical location) and within
each scope by **type**. Each `SKILL.md` is the source of truth — this file is only the index.

**Sync rule**: after creating, editing, or deleting any skill, regenerate this file so it reflects
the real state.

## How to use this registry

1. Detect the **scope** of your task (monorepo, frontend, backend) — usually the first thing you know
2. Go to the matching section and locate the applicable skill type
3. Read the `SKILL.md` BEFORE writing code
4. Multiple skills may apply at once — read them all and combine their rules

---

## Monorepo (`.claude/skills/`)

Apply to the whole project, stack-agnostic.

### {Subcategory}

| Skill | Trigger | Path |
| --- | --- | --- |
| `{name}` | {trigger} | `.claude/skills/{name}/SKILL.md` |

---

## Frontend (`frontend/.claude/skills/`)

Angular-specific.

### {Subcategory}

...

---

## Backend (`backend/.claude/skills/`)

NestJS-specific.

### {Subcategory}

...
```

### Step 5 — Verify

After writing the REGISTRY:

1. Count skills per scope: `ls .claude/skills/ frontend/.claude/skills/ backend/.claude/skills/`
2. Count entries in the generated REGISTRY
3. The numbers must match (each existing SKILL.md = one entry in the registry)
4. If there is a mismatch, investigate before marking the task complete

## Rules

- Keep a REGISTRY section even when it feels redundant, unless a skill has actually disappeared
  from the filesystem. Removing a section may delete navigational context that other entries still
  lean on.
- Do not invent new subcategories on the fly. If a new skill doesn't fit an existing one, ask the
  user first — subcategories are UX for humans, and arbitrary ones fragment the mental model.
- Preserve the preamble verbatim. It explains the usage flow; rewriting it every regeneration is
  churn with no reader benefit.
- Maintain scope order (monorepo → frontend → backend) and alphabetical order of skills within each
  subcategory. This matches the cognitive flow "what am I touching first" and avoids diff noise
  when skills are added.
- Mark duplicates with `*` in both entries and include the cross-stack section note. Without it,
  readers assume the frontend and backend versions are identical when they may differ.

## Commands

```bash
# List every skill across the three scopes
ls .claude/skills/ frontend/.claude/skills/ backend/.claude/skills/

# Extract frontmatter from every SKILL.md
for f in .claude/skills/*/SKILL.md frontend/.claude/skills/*/SKILL.md backend/.claude/skills/*/SKILL.md; do
  echo "=== $f ==="
  awk '/^---$/{c++; next} c==1{print}' "$f"
done

# Detect duplicates between frontend and backend
comm -12 \
  <(ls frontend/.claude/skills/ | sort) \
  <(ls backend/.claude/skills/ | sort)
```
