Skip to main content

The catalog model

Every one of the 122 catalog items carries metadata the CLI uses to decide whether it's eligible for your project, and whether it installs automatically or needs an explicit choice. This page explains that metadata and the vetting behind it.

Review lifecycle​

Every item currently in the catalog has reviewStatus: approved — nothing ships without going through validation first (yarn validate on every PR, mirrored by the CLI's own ingest check). The schema also supports candidate (not yet approved) and deprecated / blocked (being phased out or actively excluded) for items in transition; haus apply prunes deprecated items automatically once your on-disk copy still matches what it originally installed.

Risk level​

riskLevel is low for 119 of 122 items and medium for 3 — all three are auth/payment-adjacent (haus.auth-oidc-azure-bankid-patterns, haus.nextauth-patterns, haus.qliro-patterns). Medium risk doesn't block installation; it's a signal that the skill touches higher-stakes surface area, so review its guidance more carefully before applying it verbatim. No catalog item currently carries riskLevel: blocked — that tier exists for content the recommender would refuse to ever suggest.

Default vs. matched vs. manual​

Whether an item installs comes down to three selection modes (see haus-workflow's recommender):

  • baseline — default: true in the manifest (42 items). Installs for every project regardless of stack — the general workflow skills, ADR tooling, and the agentic workflow standard template.

  • matched — the project's scan signals satisfy the item's requiresAny gate (109 of 122 items carry one). A gate is a list of alternatives — a dependency name, a detected stack, or a repo role — any one of which makes the item eligible:

    "requiresAny": [
      { "dependency": "@apollo/client" },
      { "stack": "graphql" },
      { "dependency": "graphql" }
    ]

    This example (haus.apollo-apollo-client) becomes eligible if your project depends on @apollo/client or graphql, or the scanner detected a graphql stack signal — any one is enough.

  • manual — force-added via haus recommend --include <id>, bypassing an unsatisfied gate. This is how /haus-workflow project:add-skills works: it shows you gated items you don't currently qualify for and lets you opt in anyway.

Opt-in tiers and groups​

16 items also carry an optInTier (workflow, ops, review, or design) and an optInGroup label — even when their requiresAny gate is satisfied, they don't auto-install. They're surfaced instead as a deliberate choice, grouped for a plain-language prompt:

Opt-in groupItems
Code review workflowhaus.superpowers-receiving-code-review, haus.superpowers-requesting-code-review
Git worktrees & branch finishinghaus.superpowers-finishing-a-development-branch, haus.superpowers-using-git-worktrees
Quality gateshaus.superpowers-specifying-gates
TDD workflowhaus.superpowers-test-driven-development
Subagent-driven developmenthaus.superpowers-subagent-driven-development
Skill authoringhaus.superpowers-writing-skills
Security reviewhaus.ecc-security-reviewer
Performance reviewhaus.ecc-performance-optimizer
Refactor cleanuphaus.ecc-refactor-cleaner
Laravel plugin discoveryhaus.ecc-laravel-plugin-discovery
Redis security & observabilityhaus.redis-redis-observability, haus.redis-redis-security
UI designhaus.oh-my-claudecode-designer
Incident tracinghaus.oh-my-claudecode-tracer

Ask for these anytime with /haus-workflow project:add-skills in Claude Code, or haus recommend --include <id> [<id> …] from a terminal, followed by haus apply --write.

License and provenance​

Curated items (source: curated) carry license, licenseConfidence (81 high, 16 medium), originUrl (the exact upstream file), and pinnedRef (the commit it was snapshotted from) — so any item's provenance is traceable without leaving manifest.json. useMode records how the content was brought in: copy (verbatim, the only mode currently in use), adapted, wrapped, or rewritten.

The sync process (scripts/sync-upstream.mjs --apply) hard-stops on any upstream license that isn't MIT or Apache-2.0 — no auto-PR, a human decides. Weekly syncs open a review PR; a maintainer sanity-checks the diff before merging. See Curated skills & agents for the full per-source license table.

What's blocked before it ever ships​

A few gates run on every PR, independent of the review/risk metadata above:

  • Forbidden stack tags — unsupported ecosystems (Python, Django, Go, Rust, Java/Spring, Kotlin, Swift, Android, Flutter, Dart, C++, Perl, and DeFi/trading patterns) can't appear in an item's tags or when-signals at all.
  • Install-command safety — shipped markdown is scanned for auto-install patterns (npx -y, yarn dlx, pnpm dlx) that would run code without a review step; these are never allowed. Non-tsx npx commands (npx playwright, npx prisma) are only permitted in curated verbatim content, never first-party items.
  • Tag allowlist — every tag must be explicitly recognized; a new stack needs an allowlist entry before any item can use it.

None of this is visible in the CLI's own output — it's enforced entirely at catalog-authoring time, before an item is eligible to be recommended at all.

Last updated on