refactor(marketplace): split cc-architect from ultraplan-local into its own plugin
Extract `/ultra-cc-architect-local` and `/ultra-skill-author-local` plus all 7 supporting agents, the `cc-architect-catalog` skill (13 files), the `ngram-overlap.mjs` IP-hygiene script, and the skill-factory test fixtures from `ultraplan-local` v2.4.0 into a new `ultra-cc-architect` plugin v0.1.0. Why: ultraplan-local had drifted into containing two distinct domains — a universal planning pipeline (brief → research → plan → execute) and a Claude-Code-specific architecture phase. Keeping them together forced users to inherit an unfinished CC-feature catalog (~11 seeds) when they only wanted the planning pipeline, and locked the catalog and the pipeline into the same release cadence. The architect was already optional and decoupled at the code level — only one filesystem touchpoint remained (auto-discovery of `architecture/overview.md`), which already handles absence gracefully. Plugin manifests: - ultraplan-local: 2.4.0 → 3.0.0 (description + keywords updated) - ultra-cc-architect: new at 0.1.0 (pre-release; catalog is thin, Fase 2/3 of skill-factory unbuilt, decision-layer empty, fallback list still needed) What stays in ultraplan-local: brief/research/plan/execute commands, all 19 planning agents, security hooks, plan auto-discovery of `architecture/overview.md` (filesystem-level contract, not code-level). What moved (28 files via git mv, R100 — full history preserved): - 2 commands, 8 agents, 1 skill catalog (13 files), 2 scripts, 8 fixtures Documentation updates: plugin CLAUDE.md and README.md for both plugins, root README.md (added ultra-cc-architect section, updated ultraplan-local section), root CLAUDE.md (added ultra-cc-architect to repo-struktur), marketplace.json (registered ultra-cc-architect), ultraplan-local CHANGELOG.md (v3.0.0 entry with migration guidance). Test verification: ngram-overlap.test.mjs passes 23/23 from new location. Memory updated: feedback_no_architect_until_v3.md now points at the new plugin and reframes the threshold around catalog maturity rather than an ultraplan-local milestone. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
parent
97c5c9d934
commit
ab504bdf8c
48 changed files with 627 additions and 177 deletions
|
|
@ -1,193 +0,0 @@
|
|||
---
|
||||
name: cc-architect-catalog
|
||||
description: Internal catalog for ultra-cc-architect-local — not invoked directly. Indexes CC-feature reference and pattern skills.
|
||||
layer: manifest
|
||||
cc_feature: meta
|
||||
source: https://docs.claude.com/en/docs/claude-code
|
||||
concept: catalog-index
|
||||
last_verified: 2026-04-18
|
||||
ngram_overlap_score: null
|
||||
review_status: approved
|
||||
---
|
||||
|
||||
# CC Architect Catalog — Manifest
|
||||
|
||||
This file is the catalog index consumed by the `feature-matcher` and
|
||||
`gap-identifier` agents inside `/ultra-cc-architect-local`. It is NOT
|
||||
intended to be auto-invoked by Claude Code's skill system — the
|
||||
description above exists only so the skill loader has something to
|
||||
display if it indexes this directory.
|
||||
|
||||
## Purpose
|
||||
|
||||
The catalog enumerates which Claude Code features the architect command
|
||||
can reason about, and at which layer of abstraction. Each feature gets
|
||||
one or more skill files in this directory. A skill is a self-contained
|
||||
note about *one* feature at *one* layer.
|
||||
|
||||
## Layers (frontmatter `layer` field)
|
||||
|
||||
| Layer | Purpose | Kilde |
|
||||
|-------|---------|-------|
|
||||
| `reference` | Facts, API, syntax. What the feature *is*. | CC changelog, official docs |
|
||||
| `pattern` | When and how to use it. Typical shapes, pitfalls. | Synthesized from practice |
|
||||
| `decision` | Operational decision tree across features. | Synthesized. (No seeds yet.) |
|
||||
|
||||
Lag representeres som frontmatter-felt, ikke mappestruktur. Rationale:
|
||||
one feature can have skills at multiple layers without relocation, and
|
||||
future skill-factory output can target a specific layer without moving
|
||||
files.
|
||||
|
||||
## Frontmatter contract (per skill file)
|
||||
|
||||
Every skill file in this directory MUST have this frontmatter. The
|
||||
fields are load-bearing for the architect command.
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: <skill-id> # unique, kebab-case
|
||||
description: <one-line matcher hint> # used by feature-matcher
|
||||
layer: reference | pattern | decision
|
||||
cc_feature: <feature-id> # see table below
|
||||
source: <URL> # canonical upstream source
|
||||
concept: <short phrase> # 3–6 word concept handle
|
||||
last_verified: <YYYY-MM-DD> # when a human last checked against upstream
|
||||
ngram_overlap_score: null # reserved for skill-factory IP-hygiene
|
||||
review_status: approved | pending | auto-merged
|
||||
---
|
||||
```
|
||||
|
||||
`ngram_overlap_score` is reserved. This command respects it (will flag
|
||||
non-null values > threshold) but does not compute it. Skill-factory (a
|
||||
separate later process) populates that field.
|
||||
|
||||
`review_status: approved` is the default for seeds (approved by
|
||||
construction — handwritten, no third-party text copied). Future
|
||||
skill-factory output will start as `pending` (channel 2) or
|
||||
`auto-merged` (channel 1).
|
||||
|
||||
## Canonical `cc_feature` values
|
||||
|
||||
| Value | Coverage |
|
||||
|-------|----------|
|
||||
| `hooks` | Event hooks (UserPromptSubmit, PreToolUse, PostToolUse, Stop, Notification, SessionStart, etc.) |
|
||||
| `subagents` | Task-tool sub-agents, delegation patterns |
|
||||
| `skills` | Claude Code skill system (not Agent SDK skills) |
|
||||
| `output-styles` | Output style configuration |
|
||||
| `mcp` | Model Context Protocol servers and tools |
|
||||
| `plan-mode` | Built-in plan mode |
|
||||
| `worktrees` | Git worktree integration |
|
||||
| `background-agents` | `run_in_background`, Monitor, long-running agents |
|
||||
| `meta` | This manifest only — not a real feature |
|
||||
|
||||
If a future skill covers a feature not in this list, add the row above
|
||||
and surface the extension in the relevant CHANGELOG entry.
|
||||
|
||||
## Slug convention
|
||||
|
||||
Skill filenames follow this pattern:
|
||||
|
||||
```
|
||||
<cc_feature>[-<qualifier>]-<layer>.md
|
||||
```
|
||||
|
||||
- **Unqualified slug** (`<feature>-<layer>.md`) — the baseline/canonical
|
||||
entry for that (feature, layer) pair. One per pair. Example:
|
||||
`hooks-pattern.md` = generic hook shapes and pitfalls.
|
||||
- **Qualified slug** (`<feature>-<qualifier>-<layer>.md`) — a
|
||||
specialized variant covering one specific sub-pattern or use-case.
|
||||
Zero-or-more per pair. Example: `hooks-observability-pattern.md` =
|
||||
progressive-alert observability pattern specifically.
|
||||
|
||||
Qualifiers exist because one CC feature can support multiple
|
||||
non-overlapping patterns at different abstraction levels. Forcing
|
||||
everything into a single `<feature>-<layer>.md` either bloats the
|
||||
canonical entry or loses useful specialization. Qualified slugs let the
|
||||
catalog grow with concrete, named patterns without displacing the
|
||||
baseline.
|
||||
|
||||
`feature-matcher` treats all skills with the same `cc_feature` + `layer`
|
||||
as candidates and picks the most relevant to the brief (or proposes
|
||||
several if they cover different aspects). See "How `feature-matcher`
|
||||
uses this file" below.
|
||||
|
||||
## Current seed coverage (v2.3.0 — see .drafts/ for skill-factory output)
|
||||
|
||||
| Feature | reference | pattern | qualified patterns | decision |
|
||||
|---------|-----------|---------|--------------------|----------|
|
||||
| hooks | hooks-reference | hooks-pattern | hooks-observability-pattern | — |
|
||||
| subagents | subagents-reference | subagents-pattern | — | — |
|
||||
| skills | skills-reference | — | — | — |
|
||||
| output-styles | output-styles-reference | — | — | — |
|
||||
| mcp | mcp-reference | — | — | — |
|
||||
| plan-mode | plan-mode-reference | — | — | — |
|
||||
| worktrees | worktrees-reference | — | — | — |
|
||||
| background-agents | background-agents-reference | — | — | — |
|
||||
|
||||
Total: 11 seed skills, 8 features, 2 layers. Decision-layer is
|
||||
intentionally empty — decisions cross features and require broader
|
||||
synthesis than a single seed pass can provide. Skill-factory populates
|
||||
decision-layer later.
|
||||
|
||||
## How `feature-matcher` uses this file
|
||||
|
||||
1. Read this file to learn the `cc_feature` taxonomy and slug convention.
|
||||
2. Glob the directory for `*.md` files (excluding SKILL.md).
|
||||
3. Parse each skill's frontmatter.
|
||||
4. For each feature mentioned in the brief or research, match against
|
||||
`cc_feature` field. Build the candidate set per feature, grouped by
|
||||
layer. Selection rules:
|
||||
- **Layer preference:** prefer `pattern` over `reference` when both
|
||||
exist (pattern is richer).
|
||||
- **Multiple patterns per feature:** when two or more pattern-layer
|
||||
skills share the same `cc_feature`, read each `description` and
|
||||
pick the one(s) most relevant to the brief. If two cover
|
||||
non-overlapping aspects that both apply, propose both with clear
|
||||
rationale. Prefer the unqualified baseline (`<feature>-pattern.md`)
|
||||
when the brief does not specifically justify a qualified variant.
|
||||
- **Be explicit:** name the chosen skill in `supporting_skill` so
|
||||
`architecture-critic` can verify the match.
|
||||
5. When no skill exists for a mentioned feature, fall back to the
|
||||
hardcoded minimum-list inside the `feature-matcher` prompt and mark
|
||||
the gap in stats (`fallback_used: true`).
|
||||
|
||||
## How `gap-identifier` uses this file
|
||||
|
||||
1. Collect every feature referenced in `feature-matcher`'s output.
|
||||
2. For each feature, check whether the catalog has at least one skill at
|
||||
each expected layer (reference always; pattern when complexity
|
||||
warrants; decision for cross-feature choices).
|
||||
3. Emit a gap entry for every missing (feature × layer) pair.
|
||||
4. Label with `skill-layer:<layer>` and `cc-feature:<feature>`.
|
||||
|
||||
## Non-goals for this file
|
||||
|
||||
- No skill-factory logic. That is a separate later process.
|
||||
- No auto-discovery of new CC features.
|
||||
- No n-gram computation.
|
||||
- No triggering Claude Code auto-invocation (description deliberately
|
||||
says "not invoked directly").
|
||||
|
||||
## Modification rules
|
||||
|
||||
- **Adding a canonical skill:** create `<feature>-<layer>.md` with the
|
||||
frontmatter contract above. Bump the coverage table in this file.
|
||||
- **Adding a qualified pattern skill:** create
|
||||
`<feature>-<qualifier>-<layer>.md` when the new pattern covers a
|
||||
distinct sub-case that does not belong in the unqualified baseline.
|
||||
The qualifier MUST be kebab-case and descriptive (e.g.,
|
||||
`observability`, `migration`, `multi-tenant`). Add it to the
|
||||
"qualified patterns" column in the coverage table.
|
||||
- **Choosing qualified vs. canonical:** if no unqualified skill exists
|
||||
yet for a `(feature, layer)` pair, the new skill SHOULD be the
|
||||
unqualified baseline — don't ship a qualified skill without a
|
||||
canonical one, because `feature-matcher` prefers baseline when the
|
||||
brief has no specific justification for a variant.
|
||||
- **Renaming `cc_feature` values:** update both this file AND every
|
||||
skill using the old value in the same commit.
|
||||
- **Removing a skill:** document in CHANGELOG under the version that
|
||||
drops it.
|
||||
- **Slug collision:** two skills with the same slug are a hard error.
|
||||
Skill-factory (`/ultra-skill-author-local`) must refuse to promote a
|
||||
draft that would overwrite an approved skill. Collision is resolved
|
||||
either by qualifying the new slug or by revising the baseline.
|
||||
Loading…
Add table
Add a link
Reference in a new issue