feat(skills): contribute skill for registry block authoring

[miguel-heygen]

Summary

New /contribute skill that guides users through the full workflow of adding components to the HyperFrames registry — from idea to merged PR.

What it does

When a user says "I want to contribute a new caption style" or "create a VFX block", the skill:

1. Clarifies what they're building (caption, VFX, transition, block)
2. Scaffolds the registry structure (registry/blocks/{name}/ with HTML + registry-item.json)
3. Applies proven patterns — seeded PRNG, paused timelines, hard kills, unique ID prefixes, overflow prevention
4. Validates via hyperframes lint + hyperframes validate
5. Renders a preview MP4
6. Prepares the PR with formatting (oxfmt)

Files

• skills/contribute/SKILL.md — main skill with the 6-step workflow
• skills/contribute/templates.md — copy-paste HTML starters for caption and Three.js components

Tested by unbiased agent

An agent with zero prior HyperFrames knowledge used the skill to build a cap-typewriter component (terminal-style character-by-character captions). It passed lint and validate on the first attempt.

Agent feedback incorporated into the skill:

• Added per-character animation guidance (typewriter, scramble patterns)
• Monospace font size exception (64-72px OK, vs 96px for proportional)
• Positioning variants (left-aligned, right-aligned, not just centered)
• PREFIX naming convention table with examples
• Deterministic cursor/blink pattern using tl.set intervals

Test plan

• Skill file passes skill structure requirements (description with triggers, under 200 lines)
• Templates produce valid compositions that pass lint + validate
• Unbiased agent successfully used the skill to build a component from scratch
• Feedback from unbiased test incorporated

[jrusso1020]

Skill is a clean encoding of hard-won block-authoring lessons (hard kill on every group, ID-prefix collision avoidance, the tl.from(opacity:0) vs tl.set(opacity:1) anti-pattern). Two important items before merge: CI is red on Format, and the trigger description overlaps with hyperframes-registry in a way that risks spurious agent loads.

What I read

Both files in full:

• skills/contribute/SKILL.md (157 lines) — main skill workflow
• skills/contribute/templates.md (284 lines) — caption + Three.js + registry-item templates

Cross-referenced against existing skill descriptions on the branch (hyperframes, hyperframes-registry, hyperframes-cli) for trigger-surface conflict analysis. PR description claims verified — yes, exactly 2 files added, no CLI machinery touched.

Important — Format CI job is red

npx oxfmt --check skills/contribute/SKILL.md fails locally; verified the fixes oxfmt wants:

-| Block name | ID prefix for elements | Example IDs |
-|-----------|----------------------|-------------|
-| `cap-hormozi` | `hz` | `hz-cg-0`, `hz-cw-3` |
+| Block name       | ID prefix for elements | Example IDs            |
+| ---------------- | ---------------------- | ---------------------- |
+| `cap-hormozi`    | `hz`                   | `hz-cg-0`, `hz-cw-3`   |

Plus blank-line normalization in a few sections. Run npx oxfmt skills/contribute/SKILL.md skills/contribute/templates.md and commit. The Format check is a required CI gate; the rest of the pipeline (Lint, Test, Build, runtime contract) is skipped because no code paths changed, so Format is the only gate that matters here.

Important — trigger surface is broader than the skill's actual scope

The description ends with: "Use when user says 'contribute', 'new component', 'add a block', 'create a caption style', 'build a transition', or wants to add something to the HyperFrames registry."

Compare against the existing on-branch skills:

• hyperframes-registry triggers on: "running hyperframes add, installing a block or component, wiring an installed item into index.html"
• hyperframes triggers on: "build any HTML-based video content, add captions or subtitles synced to audio... add transitions between scenes"

/contribute overlaps with both:

• "add a block" also fires hyperframes-registry (which handles INSTALL of existing blocks)
• "create a caption style" / "build a transition" also fires hyperframes (which handles in-project caption/transition AUTHORING — most users want this when they say "build a transition," not "open an upstream PR")

The actual scope of /contribute is: author a NEW registry block for upstream contribution, scaffold the registry/blocks structure, validate, and open a PR to the hyperframes repo. The triggers should reflect that intent specifically, not the broad shape that overlaps. Tighter wording:

description: Author a new HyperFrames registry block (caption style, VFX block,
  transition, or lower third) and ship it as an upstream PR to the hyperframes repo.
  Scaffolds the registry/blocks/{name}/ structure with HTML + registry-item.json,
  applies proven patterns (seeded PRNG, paused timelines, hard kills, ID prefixes),
  validates via hyperframes lint + validate, renders preview MP4, and prepares the
  PR. Use ONLY when the user wants to CONTRIBUTE a block to the public catalog —
  for in-project caption/transition authoring use the `hyperframes` skill, for
  installing existing registry blocks use the `hyperframes-registry` skill.

The "ONLY when... CONTRIBUTE" framing + the explicit "for X use Y" disambiguation is the convention in hyperframes's description (e.g., "For dev-loop CLI commands... see the hyperframes-cli skill").

This matters because skills are loaded by Claude Code / Cursor / Codex based on the description match — a too-broad description costs context on every spurious match.

Smaller observations (non-blocking)

Quality Gate omits --no-contrast. Step 4 says hyperframes validate --no-contrast, but the Quality Gate checklist at the bottom of SKILL.md says just hyperframes validate. Pick one — either always include --no-contrast (if contrast lint produces noisy false-positives on artistic blocks) or never include it (if contrast is a hard requirement for catalog inclusion). The skill should be self-consistent so the agent doesn't get conflicting signals.

Caption template loads Google Fonts unpinned. https://fonts.googleapis.com/css2?family=Montserrat:wght@800;900&display=swap — no version. GSAP and Three.js are version-pinned (gsap@3.14.2, three@0.147.0) which is good. Google Fonts is generally stable but if Montserrat's metrics ever change, captions authored from this template could fit-test differently across time. Low priority — Google Fonts versioning has historically been monotonic — but worth a one-line awareness comment in the template if it's worth pinning.

No CLI parity work needed. Confirmed via git grep that the CLI doesn't have per-agent install flags (no --cursor / --claude / --codex in packages/cli/). Skills are auto-discovered from skills/ by each agent surface. So adding skills/contribute/SKILL.md is sufficient — no concern about agent-surface drift.

Praise

• Version-pinned CDNs in the templates — gsap@3.14.2/dist/gsap.min.js and three@0.147.0/build/three.min.js, not floating gsap@3 (a real failure mode I flagged on a parallel PR earlier today). Version pinning means registry blocks render the same in 2027 as they do today.
• ID prefix collision rule + naming table. The cap-hormozi → hz, cap-typewriter → tw convention with explicit examples is the right primitive for embedding blocks as sub-compositions where two #title elements would clash. Encoding this as a hard rule with a table is the right call.
• The tl.from(opacity: 0) vs tl.set(opacity: 1) anti-pattern callout — "the from clobbers the set. Use tl.to instead." — that's the kind of footgun that costs hours when you hit it. Pinning it as a non-negotiable rule in the skill is exactly what skills are for: encoding lessons learned across many failures.
• Per-character animation pattern with {prefix}-ch-{groupIndex}-{charIndex} ID convention + the cursor-blink-via-tl.set-not-CSS-animation rule. The "not seekable" reasoning for CSS animation is the right framing — explaining the WHY makes the rule survive future drift.
• Step 6's git add registry/blocks/{block-name}/ instead of git add -A — narrow staging is the right convention. Catches the case where the agent's session has unrelated working-tree changes.
• Validation gate is built-in — hyperframes lint + hyperframes validate + visual preview snapshot inspection. Makes the skill self-correcting instead of "submit and pray."
• Tested by unbiased agent (per PR description) and feedback incorporated. The PR enumerates the specific incorporations (per-character animation, monospace font-size exception, positioning variants, PREFIX naming table, deterministic cursor pattern). That's the empirical loop skills should go through.

Summary

Architecture: ✅. Encoded lessons: 🔥. Trigger surface: needs tightening. CI: needs oxfmt. Both are auto-fixable in a one-line change + a commit. Will re-stamp once Format is green and the description scopes itself away from hyperframes-registry and hyperframes overlap.

— Review by Rames Jusso (pr-review)

[jrusso1020]

Follow-up after James's thread question: "Does it handle the case that the user doesn't have a GitHub account?"

Verified against SKILL.md step 6 — no, the skill assumes GitHub end-to-end with no fallback path.

1. Create branch: `git checkout -b feat/registry-{block-name}`
...
5. Push and open PR with rendered MP4 preview linked

This requires: cloned hyperframes repo, git push permissions (or a fork they own), a GitHub account, and gh CLI / web UI proficiency for opening a PR. A user who has none of those — designers, motion designers, agency users without dev infrastructure — silently runs the skill, builds a great component through steps 1-5, then hits step 6 with no exit ramp:

• No alternative submission channel mentioned (form, email, Discord, etc.)
• No "set up GitHub if you don't have one" onboarding link
• No instruction to share the rendered preview MP4 + HTML zip with the maintainers
• The skill keeps recommending PR-related commands (git checkout -b, git add, git commit, "Push and open PR") that are dead ends for that user

Two reasonable shapes for the fix:

Option A — gate at the top of the skill:

### Prerequisites

Before starting, verify the user has:
- A GitHub account (https://github.com/signup if not)
- The hyperframes repo cloned locally (or a fork they can push to)
- Either gh CLI installed OR comfort with the github.com web UI for opening a PR

If they don't have a GitHub account: stop, link to https://github.com/signup,
and offer to resume after they've signed up. If they refuse to use GitHub,
direct them to the community submission form at <link> instead.

Option B — narrow the trigger surface in the description:

Add to the existing description: "...Use when a user with a GitHub account and a local hyperframes clone wants to contribute..." so the skill only fires on users it can actually help. Combined with a community-submission alternative skill or doc for the no-GitHub case.

Option A is more user-friendly (catches the user mid-flow rather than failing to fire), Option B is cheaper to implement. Either works. The current state — no handling at all — leaves the skill silently broken for an entire user segment.

Adding this on top of the prior comment (CI Format + trigger-surface tightening). All three are addressable in one fix-up commit.

— Review by Rames Jusso (pr-review)

[vanceingalls]

Verdict: REQUEST CHANGES. The skill encodes a contribution workflow that diverges from the actual registry conventions in this repo. Following it as a contributor today produces a broken PR — wrong directory for components, an invented stability field, missing the mandatory registry/registry.json update, missing the docs/catalog generation step, missing the S3 thumbnail upload, and missing attribution fields that the schema explicitly supports. The skill itself also fails oxfmt --check, breaking CI on the very PR introducing the skill that tells contributors to run oxfmt. Foundationally good idea — but the contract has gaps that will produce a stream of broken PRs.

---

Blockers

[blocker] CI Format check is failing on this PR
Format job (bun run format:check) fails with skills/contribute/SKILL.md and skills/contribute/templates.md both unformatted. Step 6 of the skill literally says "Format: npx oxfmt registry/blocks/{block-name}/*.html" — the skill that teaches oxfmt doesn't pass oxfmt. Run bun run format and re-push.

[blocker] registry/blocks/ is hardcoded — components don't go there — SKILL.md:30-37 and throughout
The four most recent catalog additions (grain-overlay, shimmer-sweep, grid-pixelate-wipe, texture-mask-text) are all in registry/components/, not registry/blocks/. packages/core/src/registry/types.ts defines three item kinds: hyperframes:example, hyperframes:block, hyperframes:component. The Step 1 clarifier already separates "caption style / VFX block / transition / block" — a contributor told to "build a caption style" will end up with registry/blocks/cap-foo/ and type: hyperframes:block, but most of these likely belong in registry/components/ with type: hyperframes:component (they're effects merged into a host composition, not standalone). Skill must teach the kind-to-directory mapping or it sends contributors to the wrong place. See scripts/generate-catalog-pages.ts which walks both dirs and routes them differently in docs.

[blocker] stability: "experimental" is not a real field — SKILL.md:50 and templates.md:269
The RegistryItem schema in packages/core/src/registry/types.ts has no stability field. None of the 12 real registry-item.json files I sampled use it. Contributors copy-pasting the template will get unknown-field warnings and will be confused when reviewers strip it. Drop stability and document the fields that actually exist: author, authorUrl, sourcePrompt, license, minCliVersion, relatedSkill.

[blocker] Components must NOT have dimensions / duration — templates.md:255-280
Per types.ts: ComponentItem.dimensions?: never; duration?: never. Components inherit from the host composition. The single registry-item.json template has both fields baked in — fine for blocks, schema violation for components. Need two templates (block vs component) or a clear conditional. This is a load-bearing distinction the skill flattens.

[blocker] Missing the registry/registry.json update step — Step 6
Every catalog addition must add an entry to the top-level registry/registry.json items array (verified against PR #650 diff: registry/registry.json: +4/-0). Without this, npx hyperframes add <name> cannot resolve the item. Skill never mentions this file. This is the difference between a PR that works and a PR that ships an unreachable component.

[blocker] Missing the docs/catalog page + index regeneration step — Step 6
PR #650 added docs/catalog/components/texture-mask-text.mdx (487 lines), updated docs/public/catalog-index.json, and updated docs/docs.json navigation. The catalog generator exists at scripts/generate-catalog-pages.ts and walks registry/blocks/ + registry/components/ to emit MDX + index. Skill must instruct: "run npx tsx scripts/generate-catalog-pages.ts and commit the generated docs/catalog/.../*.mdx and docs/public/catalog-index.json deltas, then update docs/docs.json navigation." Otherwise the component is invisible on the docs site.

[blocker] Missing the S3 thumbnail upload step — Step 6
Real catalog entries use thumbnails at https://static.heygen.ai/hyperframes-oss/docs/images/catalog/blocks/<name>.png (verified in docs/public/catalog-index.json). The repo has scripts/upload-docs-images.sh exactly for this purpose. PR #650's Slack thread surfaced exactly this issue — referencing an S3 URL before it was uploaded produced a 403'd thumbnail. Skill currently has zero mention of: generating a thumbnail, where to put it locally, how to upload it, and the URL convention to reference. The skill must encode the S3 path prefix (hyperframes-oss/docs/images/catalog/<kind>/<name>.png) and explicitly warn: "do not commit a preview URL until the asset is live at that URL — verify with curl first."

Important

[important] No attribution / credit guidance — templates.md:255-280
Schema supports author, authorUrl, sourcePrompt. Recent catalog work credits creators (e.g. blue-sweater-intro-video credits @blue_sweater; texture masks credit ambientCG). For an AI-driven contribution flow this is the easiest field to forget and the most awkward to backfill. Make it part of the registry-item.json template with a comment like // REQUIRED if derived from external source/creator.

[important] No mention of THUMBNAIL_CACHE_VERSION when registry shape changes — Step 6
Surfaced on PR #683. If the contribution touches anything that changes the rendered thumbnail (registry shape, render pipeline, default styles), the cache version needs a bump. A skill encoding the contribution workflow should at minimum mention "if you're not sure, ask a maintainer whether THUMBNAIL_CACHE_VERSION needs to bump" so the AI agent doesn't ship stale thumbnails.

[important] hyperframes lint and hyperframes validate are not the only validation gates — Step 4
PR #650 added new lint rules (packages/core/src/lint/rules/textures.ts) for the texture component and added test coverage in lintProject.test.ts. If a new component introduces new patterns (e.g. a new caption family), the contributor frequently needs to add lint rules. Skill should at least flag this: "if your component introduces a novel pattern, propose a lint rule under packages/core/src/lint/rules/ so future contributions stay correct."

[important] No self-check loop / failure-mode for skipped steps — Quality Gate
The "Quality Gate" checklist is one-shot. There's no instruction like "if any item fails, return to Step 4 and re-run; do not proceed". For an AI agent following this skill, this is the difference between confidently shipping a broken PR and bouncing back. Recommend: turn the Quality Gate into a hard gate — agent must enumerate the checklist, run each command, and abort if any fails.

[important] ID prefix table only has 3 examples, no rule for collisions — SKILL.md:38-46
The collision rule is real and important ("ALL element IDs … must use this prefix to avoid collisions when embedded as sub-compositions"), but the prefix derivation is hand-wavy ("a 2-3 letter prefix derived from the block name"). Two concurrent contributors picking tw for cap-typewriter and tw for transitions-warp will silently collide. Either: (a) derive prefix algorithmically (first letters of hyphen-separated parts), (b) document a registry of taken prefixes, or (c) have the skill grep registry/**/*.html for existing prefix usage before committing. Option (c) is the least friction for an agent and catches the collision deterministically.

[important] Per-character animation guidance pre-supposes word-level timestamps — SKILL.md:67-71
Typewriter/scramble require character-level timing computed from word ranges. The current guidance assumes WORDS[wi].start/end exists but doesn't say where it comes from for new contributions or what to do when the contributor has no transcript yet. Add a one-liner: "for testing, use a placeholder transcript; for real use the project's transcript output from hyperframes transcribe."

Nits

[nit] data-track-index="0" on a hidden driver clip — templates.md:74-75, templates.md:148-149
The driver clip is on track 0. Conventionally most root-level visible content is on track 0 too — if a contributor copies this pattern and adds visible content also on track 0, the lint rule same-track overlap will fire. Either move the driver to a high track index or comment it explicitly: <!-- driver clip stays on a unique track (e.g., 99) to avoid conflicts -->.

[nit] Hardcoded gsap@3.14.2 and three@0.147.0 versions — templates.md:13, templates.md:96
These versions will go stale. Either pin a specific tested version with a "tested as of YYYY-MM" comment, or document where the canonical versions live (e.g., skills/hyperframes/SKILL.md references the same library set).

[nit] No mention of running hyperframes inspect — Step 4
The sibling skill skills/hyperframes-cli/SKILL.md says "Lint and inspect before preview" — inspect catches text overflow that lint misses. Worth pulling into Step 4.

[nit] oxfmt invocation is ad-hoc — Step 6
"npx oxfmt registry/blocks/{block-name}/*.html" is targeted, but the repo runs oxfmt --check . in CI. Easier and safer to recommend bun run format (which the repo defines) so contributors run the same thing CI runs.

[nit] gsap.timeline({ paused: true }) rule is buried — SKILL.md:90
This and "no Math.random()" are listed under "All component types" near the bottom; they're load-bearing rules. Worth lifting into a top-level "Non-negotiable" callout.

Praise

• The Step 1 clarifier (caption / VFX / transition / block) is exactly right — forces shape decisions before code.
• The PRNG / paused timeline / hard-kill pattern is well captured and matches what recent catalog HTMLs actually do.
• The "tested by an unbiased agent" methodology is excellent — that's how you know a skill is real and not aspirational. Worth socializing.
• Per-character animation guidance + monospace font-size exception is the kind of empirical detail a docs page would never capture but a skill genuinely needs.
• 200-line cap on SKILL.md with templates split into a sibling file is the right structural choice — Claude Code's skill loading penalizes long top-level skills.

— Vai

[jrusso1020]

blocking merge until we align on this, so agents don't auto approve

[jrusso1020]

Retracting my earlier COMMENT to REQUEST_CHANGES. Vai's parallel review surfaced load-bearing schema/conventions gaps I missed on the first pass — I focused on the skill's micro-correctness (caption rules, ID prefixes, GSAP patterns) and didn't trace the workflow against the actual catalog-submission conventions in registry/. Verified each of his blockers against source on pr-685. Each one is a real defect.

Verifying Vai's blockers against pr-685 source

1. Components vs. blocks split — confirmed

Vai: "hardcodes registry/blocks/ + type: hyperframes:block — but the recent catalog work uses registry/components/ + type: hyperframes:component."

Verified via git ls-tree pr-685:registry:

blocks/
components/    ← exists
examples/
registry.json

registry/components/ has 4 items including texture-mask-text (which I lived through on hf#650 — I should have caught this myself). Inspected registry/components/texture-mask-text/registry-item.json:

{
  "name": "texture-mask-text",
  "type": "hyperframes:component",
  "title": "Texture Mask Text",
  "description": "...",
  "tags": ["text", "texture", "mask", "effect"],
  "textureGroups": [...]
}

No dimensions, no duration. The PR's SKILL.md teaches:

• ALL items go to registry/blocks/{name}/
• ALL items have type: hyperframes:block
• ALL items include dimensions: { width: 1920, height: 1080 }, duration: 10

A contributor following this skill to author a caption-style component (which is structurally a component, not a block — captions don't have a fixed canvas size or duration) ends up at the wrong path with the wrong type and irrelevant dimensions/duration. The agent who's "tested by unbiased agent" produced cap-typewriter as a block, but the team's recent caption-style work has been landing as components.

2. stability field not in schema — confirmed

Inspected packages/core/schemas/registry-item.json:

"properties": {
  "$schema": {...},
  "name": {...},
  "type": {"enum": ["hyperframes:example", "hyperframes:block", "hyperframes:component"]},
  "title": {...},
  "description": {...},
  "tags": {...},
  "author": {...},
  "authorUrl": {...},
  "sourcePrompt": {...},
  "license": {...},
  "minCliVersion": {...},
  "deprecated": {...},
  "dimensions": {...},
  "duration": {...},
  "registryDependencies": {...}
}

No stability. The skill teaches:

"stability": "experimental",

A handful of existing files (vfx-iphone-device, vfx-liquid-background, vfx-liquid-glass, vfx-magnetic, vfx-portal) include stability but those predate the schema lock-down. JSON-schema validation tolerance depends on additionalProperties, but the field is undocumented and not part of the contract — teaching it as the canonical pattern propagates a future cleanup target.

3. Skipped registry/registry.json update — confirmed

Inspected pr-685:registry/registry.json — it's the discovery index:

{
  "$schema": "https://hyperframes.heygen.com/schema/registry.json",
  "items": [
    {"name": "data-chart", "type": "hyperframes:block"},
    ...
  ]
}

The skill never instructs the agent to update registry/registry.json. A new entry without this update is invisible to hyperframes add and the catalog UI. Step 3 (Build) → Step 6 (Ship) skips straight from creating files to opening a PR.

4. Skipped scripts/generate-catalog-pages.ts — confirmed

scripts/generate-catalog-pages.ts exists at repo root. Adjacent: scripts/generate-catalog-previews.ts. The skill never mentions either. Without running these, the docs page at docs/catalog/components/{name}.mdx doesn't render and the user-facing catalog page doesn't materialize.

(Verified by spot-checking docs/catalog/components/texture-mask-text.mdx exists for the texture-mask-text component — that page came from generate-catalog-pages.ts, not by hand.)

5. S3 thumbnail upload — same step that 403'd on hf#650

I literally wrote a memory entry about this PR (feedback_get_files_drops_deletions.md) — Vance's hf#650 retracted because of bundled deletions, but the underlying catalog-entry-submission flow hit the S3 thumbnail upload step that 403'd in production. The skill makes no mention of:

• The S3 upload destination (static.heygen.ai/hyperframes-oss/...)
• The credentials needed to upload
• The expected thumbnail dimensions / format
• How to retry on 403

A contributor who walks the skill end-to-end opens a PR with no thumbnail uploaded — the catalog card on the public site shows a broken image until a maintainer uploads it manually. That's the failure shape we documented after hf#650.

6. CI Format failure — already in my prior comment

Format job is red because npx oxfmt --check rejects both files. Auto-fixable with npx oxfmt skills/contribute/.

Trigger surface — already in my prior comment

Description triggers on "add a block" / "create a caption style" / "build a transition" — overlaps with hyperframes-registry (install) and hyperframes (in-project authoring). Tightening to "author and submit a NEW block to the catalog" would scope it correctly.

GitHub-account question (resolved with James in Slack thread)

Confirmed via packages/cli/src/commands/skills.ts:18: hyperframes skills runs npx skills add heygen-com/hyperframes --all which git clones the public repo over HTTPS. No GitHub account required for install. A designer can install the skill on a fresh machine with no auth, walk steps 1-5, and only hit the wall at step 6 (Push + PR). Either gate at step 6 with a graceful "you need a GitHub account to submit" or update the trigger to require GitHub up front.

Verdict

The skill is well-intentioned and the encoded patterns (PRNG, paused timelines, hard kills, ID prefixes, tl.from(opacity:0) vs tl.set(opacity:1) anti-pattern) are real lessons worth pinning. But the workflow it teaches produces broken catalog PRs against the actual repo conventions. Following this skill end-to-end:

• Goes to the wrong directory for component-shaped contributions
• Uses an invalid type for components
• Includes a stability field that isn't in the schema
• Skips the registry/registry.json update (entry not discoverable)
• Skips scripts/generate-catalog-pages.ts (no docs page)
• Skips S3 thumbnail upload (broken card image — same 403 we saw on hf#650)
• Fails CI Format on its own files

This is a meta-skill about contribution hygiene that doesn't pass its own contribution hygiene check. Worth fixing before it ships — once a skill teaches a wrong workflow at scale, the resulting PRs become a maintenance load on the team that has to teach contributors the right way after each one.

Convergence with Vai: identical blockers (he gets the catch — I missed all six on round 1). My earlier praise for the encoded patterns + the unbiased-agent test methodology still stands. Will re-stamp once the workflow is realigned with the actual registry/components/ + registry.json + generate-catalog-pages.ts + S3-upload pipeline.

(Apologies for the round-trip — this should have been caught on first pass; my discipline memory specifically warns against under-auditing meta-PRs against actual conventions, and I missed it here.)

— Review by Rames Jusso (pr-review)