100xprism 2.3.1

package/modules/enterprise-design/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: enterprise-design
+description: Produce a comprehensive technical blueprint for a web product or SaaS, suitable for implementation in Figma Make, engineering sprints, and cloud deployment.
+category: design
+tier: on-demand
+slash_command: /enterprise-design
+model: opus
+---
+
+# Enterprise Design — Technical Blueprint Generator
+
+Produce a comprehensive technical blueprint for a web product or SaaS, suitable for implementation in Figma Make, engineering sprints, and cloud deployment.
+
+## How to use
+- `/enterprise-design <product or feature>` — full blueprint
+- `/enterprise-design ia` — information architecture + sitemap only
+- `/enterprise-design api` — API surface definition only
+- `/enterprise-design data` — data architecture + entity model only
+- `/enterprise-design ux` — user journeys + component inventory only
+- `/enterprise-design stack` — tech stack recommendation only
+- `/enterprise-design review` — audit current project against enterprise standards
+
+---
+
+## Step 0 — Load context
+
+```bash
+PROJECT_ROOT=$(git rev-parse --show-toplevel)
+INSTRUCTION_FILE=$(for f in CLAUDE.md AGENTS.md .cursorrules .windsurfrules .github/copilot-instructions.md GEMINI.md; do [ -f "$PROJECT_ROOT/$f" ] && echo "$PROJECT_ROOT/$f" && break; done)
+[ -n "$INSTRUCTION_FILE" ] && head -100 "$INSTRUCTION_FILE"
+```
+
+Establish: site/product type, primary audience, core capabilities (3–5), technical priorities.
+
+---
+
+## Deliverables
+
+Produce a structured technical blueprint covering:
+
+### 1. Information Architecture
+Complete sitemap with primary, secondary, semantic, and neutral path hierarchy. URL conventions (kebab-case, hierarchy reflects ownership, pagination via query params).
+
+### 2. User Journey Mapping
+Three critical conversion paths: acquisition→activation, free→paid, core workflow loop. Include drop-off points and success metrics.
+
+### 3. Data Architecture
+Entity relationships and schema models. Indexing strategy (FK indexes, composite for pagination, GIN for full-text). Caching tier (Redis key patterns + TTLs). Analytics tier (event schema for BigQuery).
+
+### 4. API Surface Definition
+Core REST endpoints (auth, primary entity CRUD, billing, admin). Standard response envelope. Third-party integrations table. Rate limiting per tier.
+
+### 5. Component Inventory (30+)
+Layout, navigation, data display, form, feedback, and feature-specific components. For each: purpose + key props.
+
+### 6. Page Blueprints
+Structural wireframe descriptions for: landing page, dashboard, detail/entity view, settings page.
+
+### 7. Technology Stack
+Recommended stack with rationale for: frontend, styling, state, backend, database, cache, auth, payments, email, hosting, CI/CD, observability, IaC.
+
+### 8. Performance Benchmarks
+Core Web Vitals targets (LCP < 1.8s, INP < 100ms, CLS < 0.05). API latency targets (P50/P95). Performance budget per page.
+
+### 9. SEO Framework
+URL conventions, meta structure per page type, schema markup strategy, Core Web Vitals for SEO.
+
+### 10. Enterprise Considerations (if applicable)
+Domain-Driven Design bounded contexts, API governance, zero-trust security, multi-region DR. Only include if product is at scale (> 10K users / multi-team / regulated).
+
+---
+
+## Output Format
+
+Structured specification with clear headings, bullet points, and numbered lists throughout. Suitable for direct handoff to Figma Make or engineering sprint planning.

package/modules/eval/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: eval
+description: Run a module's evals to check it triggers correctly and produces good output. Use when the user wants to evaluate a skill, run evals, grade eval assertions, score skill quality, or asks "do my skills still trigger correctly" or "did this change break a skill". Fans eval cases out to parallel subagents and has Haiku 4.5 grade each assertion into a pass/fail scorecard.
+category: quality
+tier: on-demand
+slash_command: /eval
+allowed-tools: Bash Read Agent
+---
+
+# Eval — Run skill evals and score them
+
+Turns the dormant `modules/<slug>/evals/evals.json` files into a real, graded scorecard:
+does the skill trigger on its prompts, and does its output satisfy each assertion?
+
+The deterministic engine is `scripts/eval-harness.py` (discovery, validation, work-list,
+scorecard rendering — no model calls). **Grading is your job**: fan the cases out to
+subagents and have Haiku 4.5 judge every assertion with structured output. Installed path
+is `~/100xprism/scripts/eval-harness.py`; in a checkout it's `scripts/eval-harness.py`.
+
+## Phase 0 — Pick the target
+
+```bash
+# one module, everything, or just what changed on this branch:
+python3 ~/100xprism/scripts/eval-harness.py validate --module <slug>
+python3 ~/100xprism/scripts/eval-harness.py validate --all
+python3 ~/100xprism/scripts/eval-harness.py validate --changed origin/main
+```
+
+Fix any structural errors before grading — a malformed eval file can't be scored.
+
+## Phase 1 — Get the work-list
+
+```bash
+python3 ~/100xprism/scripts/eval-harness.py plan --module <slug> --json
+```
+
+This emits `{ "modules": [ { "module", "cases": [ { id, prompt, expected_output,
+assertions[], files[] } ] } ] }`. Each `(case, assertion)` is one unit of work.
+
+## Phase 2 — Grade with parallel subagents (Haiku 4.5)
+
+For each case, dispatch **one subagent** (use the **subagents** skill / `Agent` tool, or a
+Workflow fan-out) that:
+
+1. **Runs the prompt against the skill.** Load the target skill (its SKILL.md) as
+   context, then answer the case `prompt` exactly as the assistant would — this is the
+   *candidate response*. Note whether the skill would have auto-triggered on that prompt
+   (trigger accuracy) separately from output quality.
+2. **Grades each assertion.** Spawn a Haiku 4.5 grader (`model: claude-haiku-4-5`) that,
+   given the prompt, the candidate response, the `expected_output`, and one assertion,
+   returns **structured output**:
+
+   ```json
+   { "module": "<slug>", "case_id": <id>, "assertion": "<text>", "passed": true|false, "reason": "<one line>" }
+   ```
+
+Run cases in parallel (independent), cap concurrency sanely, and collect every grader
+object into one results array. Default cheap (Haiku) and only escalate a genuinely
+ambiguous assertion to a stronger model.
+
+Write the collected array to a results file:
+
+```bash
+# results.json = the JSON array of grader objects from every subagent
+```
+
+## Phase 3 — Render the scorecard
+
+```bash
+python3 ~/100xprism/scripts/eval-harness.py score --results results.json
+```
+
+Produces a per-assertion ✓/✗ scorecard with reasons, per-case and overall tallies, and
+exits non-zero if any assertion failed. Use `--json` for machine output.
+
+```
+=== marketing-psychology ===
+  case 1: 6/7 assertions passed
+    ✓ Checks for product-marketing-context.md
+    ✗ References specific mental models by name — named only two of the taxonomy
+scorecard: 41/43 assertions passed across 1 module(s)
+```
+
+## Trigger-overlap lint (no model needed)
+
+Catch skills that would fire on each other's prompts before they ever reach grading:
+
+```bash
+python3 ~/100xprism/scripts/trigger-overlap.py            # report flagged pairs
+python3 ~/100xprism/scripts/trigger-overlap.py --strict   # fail on NEW (non-allow-listed) overlaps
+```
+
+Intentional overlaps live in `scripts/trigger-overlap-allow.txt`. If a real change adds a
+new high-overlap pair, either differentiate the two descriptions or add the pair to the
+allow-list with a note.
+
+## Principles
+
+- **Default cheap.** Haiku grades; escalate only ambiguous assertions.
+- **Structured output, not prose.** Every grader returns the object above so the scorecard
+  is deterministic.
+- **Separate trigger accuracy from output quality.** A skill can answer well yet never
+  have triggered — report both.
+- **Per-PR vs nightly.** Grade only `--changed` modules on a PR; the nightly CI run covers
+  all modules that ship evals.

package/modules/figma-translator/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: figma-translator
+description: Translate any technical specification into five precise, self-contained Figma Make prompts ready to paste and generate. Use when you have an enterprise-design, visual-system-architect, or copywriting output and need to convert it into Figma Make–compatible prompts covering hero, features, social proof, CTA, and mobile views.
+category: design
+tier: on-demand
+allowed-tools: Read Write
+---
+
+You are a specialist in translating technical specifications into optimized Figma Make prompts. Convert the provided specification into five separate, high-precision prompts.
+
+## Required Input
+
+Paste the full technical specification to translate:
+```
+[PASTE SPECIFICATION HERE]
+```
+
+## Each Prompt Must
+
+1. **Begin with the final visual outcome** — what does the finished screen look like?
+2. **Embed brand identity context** — color, typography, and tone
+3. **Define interaction behaviors** — hover, click, scroll, and animated transitions
+4. **Specify responsive adaptation** — how it adapts across breakpoints
+5. **Clearly request structural sections** — hero, feature grid, CTA, footer
+
+## Required Format Per Prompt
+
+```
+"Create a [TYPE] website with a [MOOD] aesthetic.
+Use [PRIMARY COLOR] and [FONT SYSTEM].
+Include:
+1) Hero with [SPECIFIC ELEMENTS]
+2) Interactive feature grid with [DEFINED BEHAVIORS]
+3) Conversion-focused CTA block
+4) Structured footer.
+Ensure full responsiveness and smooth [ANIMATION STYLE] transitions."
+```
+
+## Principles
+
+- Each prompt must be self-contained — Figma Make has no memory between prompts
+- Specificity is everything: vague prompts produce generic output
+- Lead with visual outcome, not technical requirements
+- Name colors, font names, and animation styles explicitly — no abstract descriptions
+- Five prompts should cover: hero, features, social proof, CTA flow, and mobile view
+
+## Output
+
+Return exactly 5 numbered Figma Make prompts, ready to copy-paste.

package/modules/fix-bugs/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: fix-bugs
+description: Autonomously fix bugs from any source — Slack threads, failing CI tests, docker logs, or a plain description. Use when you have a bug report or failing test and want Claude to investigate and fix without step-by-step guidance.
+category: engineering
+tier: core
+slash_command: /fix
+allowed-tools: Bash Read Grep Glob Edit Write
+---
+
+# Fix — Autonomous Bug Fixer
+
+Fix the bug described or linked. Investigate and fix without step-by-step guidance.
+
+## Do NOT ask for permission — investigate and fix autonomously.
+
+## How to use
+- `/fix` — fix the most recent failing CI run
+- `/fix <description>` — fix from plain description
+- `/fix <docker logs paste>` — trace error to root cause and fix
+- `/fix <Slack URL or paste>` — read thread, extract bug report, fix
+
+---
+
+## Phase 1 — Gather context
+
+Read the error in full — message, stack trace, or thread. Do not skip this step.
+
+**If the root cause is not obvious from the error/stack/logs → invoke the
+`systematic-debugging` skill first to diagnose before attempting any fix.** `/fix` assumes
+you know (or can quickly find) what's broken; for mysterious failures, diagnosis comes
+first. Don't guess.
+
+Detect the stack so context-gathering matches the project (canonical block — source:
+`_lib/reference.md`):
+
+```bash
+PROJECT_ROOT=$(git rev-parse --show-toplevel); cd "$PROJECT_ROOT"
+CI_SYSTEM=""; ls "$PROJECT_ROOT"/.github/workflows/*.y*ml >/dev/null 2>&1 && CI_SYSTEM=github-actions
+TEST_RUNNER=""
+grep -q '"vitest"' package.json */package.json 2>/dev/null && TEST_RUNNER=vitest
+[ -z "$TEST_RUNNER" ] && grep -q '"jest"' package.json */package.json 2>/dev/null && TEST_RUNNER=jest
+[ -z "$TEST_RUNNER" ] && { [ -f pyproject.toml ] || ls requirements*.txt >/dev/null 2>&1; } && TEST_RUNNER=pytest
+[ -z "$TEST_RUNNER" ] && [ -f go.mod ] && TEST_RUNNER="go test"
+[ -z "$TEST_RUNNER" ] && [ -f Cargo.toml ] && TEST_RUNNER="cargo test"
+
+# If fixing CI on a GitHub-Actions repo with gh available: read the most recent failure
+if [ "$CI_SYSTEM" = github-actions ] && command -v gh >/dev/null 2>&1; then
+  gh run list --limit 3
+  gh run view --log-failed "$(gh run list --limit 1 --json databaseId -q '.[0].databaseId')" 2>/dev/null | tail -80
+fi
+```
+
+For non-GitHub CI, read the failing job from that provider (GitLab/CircleCI UI or CLI).
+For docker logs: parse for ERROR/CRITICAL lines, identify service + file.
+For Slack thread: extract the bug report and reproduction steps.
+
+---
+
+## Phase 2 — Locate the code
+
+Find the exact file(s) and line(s) responsible. Use Grep/Glob aggressively — do not guess.
+
+```bash
+cd "$PROJECT_ROOT"
+git log --oneline -10
+git status
+```
+
+Read the surrounding code. Understand the intent before touching anything.
+
+---
+
+## Phase 3 — Fix
+
+Make the **minimal correct change**. Do not refactor unrelated code. Do not add workarounds or feature flags — fix the root cause.
+
+If the root cause cannot be determined: say so clearly. Do not guess.
+
+---
+
+## Phase 4 — Verify
+
+Run the specific failing test or reproduce the failure condition, using the
+**detected** `$TEST_RUNNER` from Phase 1 (or just defer to `/test`, which auto-detects
+every layer):
+
+```bash
+# Target only the failing test(s) — substitute the file/name that was failing.
+case "$TEST_RUNNER" in
+  vitest|jest)  npx "$TEST_RUNNER" run <failing-test> 2>&1 | tail -30 ;;
+  pytest)       ./venv/bin/pytest <failing-test> -v --tb=short -q 2>&1 | tail -30 ;;
+  "go test")    go test ./<pkg> -run '<TestName>' 2>&1 | tail -30 ;;
+  "cargo test") cargo test <test_name> 2>&1 | tail -30 ;;
+  *)            echo "No test runner detected — run /test, or reproduce the failure manually" ;;
+esac
+```
+
+**GATE: The specific failure condition no longer occurs.**
+
+---
+
+## Phase 5 — Summarize
+
+One sentence: what was wrong and what you changed. Then run `/commit`.