claude-code-arcane 1.0.0

package/rules/gamedev/ai-code.md

@@ -0,0 +1,15 @@
+---
+paths:
+  - "src/ai/**"
+---
+
+# AI Code Rules
+
+- AI update budget: 2ms per frame maximum — profile to verify
+- All AI parameters must be tunable from data files (behavior tree weights, perception ranges, timers)
+- AI must be debuggable: implement visualization hooks for all AI state (paths, perception cones, decision trees)
+- AI should telegraph intentions — players need time to read and react
+- Prefer utility-based or behavior tree approaches over hard-coded if/else chains
+- Group AI must support formation, flanking, and role assignment from data
+- All AI state machines must log transitions for debugging
+- Never trust AI input from the network without validation

package/rules/gamedev/design-docs.md

@@ -0,0 +1,18 @@
+---
+paths:
+  - "design/gdd/**"
+---
+
+# Design Document Rules
+
+- Every design document MUST contain these 8 sections: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
+- Formulas must include variable definitions, expected value ranges, and example calculations
+- Edge cases must explicitly state what happens, not just "handle gracefully"
+- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A
+- Tuning knobs must specify safe ranges and what gameplay aspect they affect
+- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail
+- No hand-waving: "the system should feel good" is not a valid specification
+- Balance values must link to their source formula or rationale
+- Design documents MUST be written incrementally: create skeleton first, then fill
+  each section one at a time with user approval between sections. Write each
+  approved section to the file immediately to persist decisions and manage context

package/rules/gamedev/engine-code.md

@@ -0,0 +1,41 @@
+---
+paths:
+  - "src/core/**"
+---
+
+# Engine Code Rules
+
+- ZERO allocations in hot paths (update loops, rendering, physics) — pre-allocate, pool, reuse
+- All engine APIs must be thread-safe OR explicitly documented as single-thread-only
+- Profile before AND after every optimization — document the measured numbers
+- Engine code must NEVER depend on gameplay code (strict dependency direction: engine <- gameplay)
+- Every public API must have usage examples in its doc comment
+- Changes to public interfaces require a deprecation period and migration guide
+- Use RAII / deterministic cleanup for all resources
+- All engine systems must support graceful degradation
+- Before writing engine API code, consult `docs/engine-reference/` for the current engine version and verify APIs against the reference docs
+
+## Examples
+
+**Correct** (zero-alloc hot path):
+
+```csharp
+// Pre-allocated list reused each frame
+private readonly List<Transform> _nearbyCache = new(capacity: 64);
+
+void FixedUpdate()
+{
+    _nearbyCache.Clear();  // Reuse, don't reallocate
+    _spatialGrid.QueryRadius(transform.position, radius, _nearbyCache);
+}
+```
+
+**Incorrect** (allocating in hot path):
+
+```csharp
+void FixedUpdate()
+{
+    var nearby = new List<Transform>();  // VIOLATION: allocates every frame
+    nearby.AddRange(FindObjectsOfType<Enemy>());  // VIOLATION: scene scan every frame
+}
+```

package/rules/gamedev/gameplay-code.md

@@ -0,0 +1,31 @@
+---
+paths:
+  - "src/gameplay/**"
+---
+
+# Gameplay Code Rules
+
+- ALL gameplay values MUST come from external config/data files, NEVER hardcoded
+- Use delta time for ALL time-dependent calculations (frame-rate independence)
+- NO direct references to UI code — use events/signals for cross-system communication
+- Every gameplay system must implement a clear interface
+- State machines must have explicit transition tables with documented states
+- Write unit tests for all gameplay logic — separate logic from presentation
+- Document which design doc each feature implements in code comments
+- No static singletons for game state — use dependency injection
+
+## Examples
+
+**Correct** (data-driven):
+
+```csharp
+float damage = combatConfig.BaseDamage;
+float speed = stats.MovementSpeed * Time.deltaTime;
+```
+
+**Incorrect** (hardcoded):
+
+```csharp
+float damage = 25.0f;   // VIOLATION: hardcoded gameplay value
+float speed = 5.0f;     // VIOLATION: not from config, not using delta
+```

package/rules/gamedev/narrative.md

@@ -0,0 +1,15 @@
+---
+paths:
+  - "design/narrative/**"
+---
+
+# Narrative Rules
+
+- All new lore must be cross-referenced against existing lore for contradictions
+- Every lore entry must specify canon level: Established / Provisional / Under Review
+- Character dialogue must match the voice profile defined for that character
+- World rules (what is possible/impossible) must be explicitly documented and consistent
+- Mysteries must have documented "true answers" even if players never learn them
+- Faction motivations, relationships, and power structures must be internally logical
+- All narrative text must be localization-ready: no idioms that don't translate, named placeholders for variables
+- No line of dialogue should exceed 120 characters for dialogue box constraints

package/rules/gamedev/network-code.md

@@ -0,0 +1,15 @@
+---
+paths:
+  - "src/networking/**"
+---
+
+# Network Code Rules
+
+- Server is AUTHORITATIVE for all gameplay-critical state — never trust the client
+- All network messages must be versioned for forward/backward compatibility
+- Client predicts locally, reconciles with server — implement rollback for mispredictions
+- Handle disconnection, reconnection, and host migration gracefully
+- Rate-limit all network logging to prevent log flooding
+- All networked values must specify replication strategy: reliable/unreliable, frequency, interpolation
+- Bandwidth budget: define and track per-message-type bandwidth usage
+- Security: validate all incoming packet sizes and field ranges

package/rules/gamedev/shader-code.md

@@ -0,0 +1,43 @@
+---
+paths:
+  - "assets/shaders/**"
+---
+
+# Shader Code Standards
+
+All shader files in `assets/shaders/` must follow these standards to maintain
+visual quality, performance, and cross-platform compatibility.
+
+## Naming Conventions
+- File naming: `[type]_[category]_[name].[ext]`
+  - `SG_Env_Water` (Unity Shader Graph)
+  - `M_Env_Water` (Unreal Material)
+- Use descriptive names that indicate the material purpose
+- Prefix with shader type: `spatial_`, `canvas_`, `particles_`, `post_`
+
+## Code Quality
+- All uniforms/parameters must have descriptive names and appropriate hints
+- Group related parameters (Unity: `[Header]`, Unreal: Category)
+- Comment non-obvious calculations (especially math-heavy sections)
+- No magic numbers — use named constants or documented uniform values
+- Include authorship and purpose comment at the top of each shader file
+
+## Performance Requirements
+- Document the target platform and complexity budget for each shader
+- Use appropriate precision: `half`/`mediump` on mobile where full precision isn't needed
+- Minimize texture samples in fragment shaders
+- Avoid dynamic branching in fragment shaders — use `step()`, `mix()`, `smoothstep()`
+- No texture reads inside loops
+- Two-pass approach for blur effects (horizontal then vertical)
+
+## Cross-Platform
+- Test shaders on minimum spec target hardware
+- Provide fallback/simplified versions for lower quality tiers
+- Document which render pipeline the shader targets (Forward/Deferred, URP/HDRP, Forward+/Mobile/Compatibility)
+- Do not mix shaders from different render pipelines in the same directory
+
+## Variant Management
+- Minimize shader variants — each variant is a separate compiled shader
+- Document all keywords/variants and their purpose
+- Use feature stripping where possible to reduce build size
+- Log and monitor total variant count per shader

package/rules/gamedev/ui-code.md

@@ -0,0 +1,15 @@
+---
+paths:
+  - "src/ui/**"
+---
+
+# UI Code Rules
+
+- UI must NEVER own or directly modify game state — display only, use commands/events to request changes
+- All UI text must go through the localization system — no hardcoded user-facing strings
+- Support both keyboard/mouse AND gamepad input for all interactive elements
+- All animations must be skippable and respect user motion/accessibility preferences
+- UI sounds trigger through the audio event system, not directly
+- UI must never block the game thread
+- Scalable text and colorblind modes are mandatory, not optional
+- Test all screens at minimum and maximum supported resolutions

package/rules/gamedev/vn-code.md

@@ -0,0 +1,37 @@
+---
+name: vn-code
+description: "Coding rules for Ren'Py visual novel development"
+---
+
+# Visual Novel Code Rules
+
+## Ren'Py Script Rules
+- Use `default` for variable declarations, not `$ var = value` at init
+- Use layered images for characters — never hardcode expression paths in dialogue
+- Every `jump` must have a matching `label` — validate before committing
+- Every `menu` choice must affect at least one variable (no cosmetic-only choices)
+- Keep dialogue lines under 200 characters to fit standard textboxes
+- Use `nvl` mode for long exposition, letters, or documents — not ADV mode
+- Flag names use snake_case: `flag_met_sakura`, `flag_chapter_2_complete`
+- Relationship variables use pattern: `[character]_affinity`
+
+## File Organization
+- One file per chapter: `game/chapters/chapter_NN.rpy`
+- Character definitions in `game/characters.rpy` — nowhere else
+- Variables and flags in `game/variables.rpy` — nowhere else
+- Game logic (inventory, relationships) in `game/logic/` — not in chapters
+- Custom screens in `game/screens.rpy` — not inline in chapters
+
+## Asset Naming Convention
+- Backgrounds: `bg_[location]_[variant].png` (e.g., `bg_school_night.png`)
+- Character sprites: `chars/[id]/[layer]_[variant].png`
+- CG illustrations: `cg_[NNN]_[description].png`
+- BGM: `bgm/[mood_or_name].ogg`
+- SFX: `sfx/[description].ogg`
+- Voice: `voice/[character]/[id].ogg`
+
+## Quality Gates
+- No `TODO`, `FIXME`, or `[PLACEHOLDER]` in committed scripts
+- Run `/vn-testing paths` before merging any chapter
+- All new flags must be declared in `variables.rpy` before use
+- Every chapter must end with a `jump` to the next chapter or an ending label

package/rules/implementation-workflow.md

@@ -0,0 +1,48 @@
+# Implementation Workflow Rule
+
+Before starting any non-trivial implementation task, you MUST present the user with work mode options using AskUserQuestion. This is mandatory — do not skip it and jump to coding.
+
+## When to trigger
+
+Present work mode options when the user:
+- Asks to implement a new feature ("agregá X", "implementá Y", "hacé Z")
+- Describes a task involving multiple files or architectural decisions
+- Asks for a refactor, migration, or significant change
+- Says "quiero hacer", "necesito", "hay que" followed by implementation work
+
+## When NOT to trigger
+
+Skip the work mode selection when:
+- The user asks a question ("¿qué hace esto?", "¿cómo funciona?")
+- The task is a small fix (typo, 1-3 line change, obvious bug)
+- The user explicitly says "directo", "sin plan", "ya sé qué hacer", "just do it"
+- A plan or goal is already active in the current conversation
+- The user is running a specific skill (/commit, /check, /code-review, etc.)
+- It's an emergency or hotfix scenario
+
+## The question
+
+Use AskUserQuestion exactly like this:
+
+- Question: "¿Cómo querés encarar esta tarea?"
+- Header: "Work mode"
+- Options (4):
+  1. **Plan + Goal (Recommended)** — "Plan detallado de CÓMO + goal de HASTA DÓNDE llegar. Lo más completo: el plan guía la ejecución, el goal define cuándo frenar y qué validar."
+  2. **Action Plan** — "Solo plan paso a paso. Sin goal de sesión — implementamos hasta terminar el plan."
+  3. **Goal-driven** — "Solo objetivo verificable con checkpoints. Sin plan formal."
+  4. **Directo** — "Arrancamos sin ceremonia. Para tareas claras y rápidas."
+
+## After selection
+
+- **Plan + Goal:** First define the verifiable session goal with validation criteria. Then EnterPlanMode and design the implementation plan linked to the goal. Plan includes explicit stop conditions (goal met, blocker, scope creep). After approval, create tasks and execute. After each significant step, check progress against the goal. When goal is met, STOP and run validation.
+- **Action Plan:** Use EnterPlanMode, design the approach, get approval, create tasks, then implement step by step. No formal goal — implement until the plan is done.
+- **Goal-driven:** Help the user define a verifiable goal statement and 2-4 checkpoints, create tasks, implement toward each checkpoint. No formal plan.
+- **Directo:** Proceed immediately without ceremony.
+
+## Key principles
+
+- One question, not a wall of text — present options and wait
+- Respect the user's choice — if they pick "directo", do not add planning overhead
+- Plans should be concise — 10-15 lines max, not a document
+- Goals must be verifiable — "login works with OAuth" not "improve login"
+- Never block urgent work — bugs in production skip this flow entirely

package/rules/infra-code.md

@@ -0,0 +1,47 @@
+---
+paths:
+  - "infra/**"
+  - "terraform/**"
+  - "pulumi/**"
+  - ".github/workflows/**"
+  - ".gitlab-ci.yml"
+  - "k8s/**"
+  - "kubernetes/**"
+  - "helm/**"
+  - "docker/**"
+  - "Dockerfile"
+  - "**/Dockerfile"
+  - "docker-compose.yml"
+  - "docker-compose.*.yml"
+---
+
+# Infrastructure & CI/CD Rules
+
+- **Infrastructure is code**: every cloud resource created must exist in Terraform / Pulumi / equivalent. No click-ops in production. If you click-ops for an emergency, open a PR within 24h to codify.
+- **State is remote and locked**: no local `terraform.tfstate` committed. Remote backend (S3 + DynamoDB, GCS, Terraform Cloud) with locking.
+- **Least privilege by default**: IAM roles scoped to the narrowest set of actions + resources. No wildcard `*:*`. Service accounts per service, not shared.
+- **Secrets never in IaC files**: reference from secret manager (AWS Secrets Manager, GCP Secret Manager, Vault, K8s Secret). No `password = "..."` in Terraform.
+- **Environment parity**: dev / staging / prod share the same module definitions, differ only via variables. No `if env == "prod"` forks in module code.
+- **Destructive plans require explicit approval**: any `terraform plan` showing `destroy` on a stateful resource (DB, bucket, queue) requires a second reviewer. CI should flag these.
+- **Containers are versioned by digest in production** (`@sha256:...`), not by tag. Tags are mutable; digests are not.
+- **Image builds are reproducible**: pin base image by digest, pin all apt/apk packages by version, run multi-stage builds to minimize attack surface.
+- **Kubernetes resources have limits**: every pod declares CPU + memory requests and limits. Missing limits = OOM-kill + noisy neighbor problems.
+- **Health checks on every service**: liveness + readiness probes. Readiness gates traffic; liveness triggers restart. They are not the same.
+- **CI pipelines fail fast**: run cheapest checks first (lint, typecheck) then tests then integration then build. Short-circuit on first failure unless explicitly matrix-parallel.
+- **CI is the source of truth for deploys**: nobody runs `kubectl apply` / `terraform apply` from their laptop against production. Pipeline auth is what touches prod.
+- **Workflows pin action versions by SHA** for third-party actions (`uses: org/action@<sha>`). Tags are moveable and a supply-chain risk.
+- **Monitoring on day one**: metrics + logs + traces + alerts defined in the same PR that ships the service. No "we'll add monitoring later."
+
+## Change Management
+
+- Infra changes to production go through a staging apply first — same module, different workspace/env
+- `terraform apply` output is archived to the PR so reviewers can see what actually ran
+- Rollback plan documented in PR description for any stateful change
+
+## Anti-Patterns
+
+- `aws configure` / personal credentials being what deploys to prod
+- `latest` tag in any production manifest
+- Inline shell scripts in CI that do complex logic — move to a versioned script with tests
+- Copying `production.tf` to `staging.tf` and diverging them by hand
+- Running DB migrations from a CI job that doesn't have transactional rollback if the deploy fails after

package/rules/migration-code.md

@@ -0,0 +1,41 @@
+---
+paths:
+  - "migrations/**"
+  - "db/migrations/**"
+  - "prisma/migrations/**"
+  - "alembic/versions/**"
+  - "**/migrate/**"
+  - "**/migrations/**"
+---
+
+# Database Migration Rules
+
+- Migrations are **immutable once merged to main**. To fix a bad migration, write a new one — never edit history. Editing a shipped migration breaks every environment that already ran it.
+- Every migration has a matching **rollback** (down) script or is explicitly marked `irreversible` with a comment explaining why.
+- Migrations are **idempotent where possible**: `CREATE TABLE IF NOT EXISTS`, `ADD COLUMN IF NOT EXISTS`. Never assume clean state.
+- Naming: timestamp-prefixed, snake_case, imperative verb: `20260416_143022_add_email_to_users.sql`. Timestamp sorts chronologically.
+- One logical change per migration. Don't bundle "add users table + add posts table + backfill data" — three migrations.
+- **Online schema changes only** for production tables >100k rows:
+  - No `ALTER TABLE ... ADD COLUMN NOT NULL DEFAULT X` on large tables (locks). Instead: add nullable → backfill in batches → add constraint in a separate migration.
+  - No blocking index creation — use `CREATE INDEX CONCURRENTLY` (Postgres) / equivalent.
+  - No renaming columns in-place — add new, dual-write, backfill, cut over, drop old. Minimum 3 deploys.
+- **Backfills live in their own migration**, not mixed with schema changes. Batched, resumable, idempotent. Log progress.
+- Test migrations on a **production-sized snapshot** before merging if the table is large. Measure lock time and write it in the PR description.
+- Never `DROP TABLE` / `DROP COLUMN` in the same deploy that removes its last usage in code. Sequence: ship code that stops using → verify zero reads for N days → drop in a later migration.
+- Secrets / seed data / PII **never** in a migration file committed to git. Use environment-specific seed scripts.
+- Migrations run automatically on deploy. If a migration is too risky to run unattended (multi-hour lock, destructive), mark it `manual` and include the runbook in the PR.
+
+## Required PR Checklist for Migrations Touching Production Tables
+
+- [ ] Up script tested on prod-sized snapshot — lock time recorded
+- [ ] Down script tested (or `irreversible` marked with justification)
+- [ ] Backfill (if any) is batched and resumable
+- [ ] Rollback plan written if migration fails mid-run
+- [ ] DBA / senior reviewer signed off if table is >1M rows or critical path
+
+## Anti-Patterns
+
+- Using the ORM's "auto-generate migration" on a shared dev DB and committing the diff without reading it
+- `DELETE FROM users WHERE ...` in a migration without a backup and written-out rollback
+- Migration that depends on application code (calling service layer) — migrations run with DB access only, not app code
+- Migrations that only work if previous migration left specific data — be defensive, check before mutating

package/rules/prototype-code.md

@@ -0,0 +1,40 @@
+---
+paths:
+  - "prototypes/**"
+---
+
+# Prototype Code Standards (Relaxed)
+
+Prototypes are throwaway code for validating ideas. Standards are intentionally
+relaxed to maximize iteration speed. The goal is learning, not production quality.
+
+## What's Allowed in Prototypes
+- Hardcoded values (no need for data-driven config)
+- Minimal or no doc comments
+- Simple architecture (no dependency injection required)
+- Singletons and global state
+- Copy-pasted code (no need for abstraction)
+- Debug output left in place
+- Placeholder art and audio
+- Quick-and-dirty solutions
+
+## What's Still Required
+- Each prototype lives in its own subdirectory: `prototypes/[name]/`
+- Every prototype MUST have a `README.md` with:
+  - What hypothesis is being tested
+  - How to run the prototype
+  - Current status (in-progress / concluded)
+  - Findings (updated when prototype concludes)
+- No production code may reference or import from `prototypes/`
+- Prototypes must not modify files outside `prototypes/`
+- Prototypes must not be deployed or shipped
+
+## When a Prototype Succeeds
+If a prototype validates a concept and the feature moves to production:
+1. The prototype code is NOT migrated directly — it is rewritten to production standards
+2. The prototype `README.md` findings inform the production design document
+3. The prototype directory is preserved for reference but never extended
+
+## Cleanup
+Concluded prototypes should be archived or deleted after findings are captured.
+Never let prototype code grow into production code through incremental "cleanup."

package/rules/test-standards.md

@@ -0,0 +1,55 @@
+---
+paths:
+  - "tests/**"
+  - "**/*.test.*"
+  - "**/*.spec.*"
+  - "**/*_test.go"
+  - "**/test_*.py"
+---
+
+# Test Standards
+
+- Test naming: `test_[system]_[scenario]_[expected_result]` (or framework idiom: `should [behavior] when [condition]`)
+- Every test must have a clear Arrange / Act / Assert structure
+- Unit tests must not depend on external state (filesystem, network, database, clock, randomness)
+- Integration tests must clean up after themselves — transactional rollback or explicit teardown
+- Performance tests must specify acceptable thresholds (p95 latency, throughput) and fail if exceeded
+- Test data must be defined in the test or in dedicated fixtures — never shared mutable state
+- Mock external dependencies (network, DB, third-party APIs) — tests must be fast and deterministic
+- Every bug fix must ship with a regression test that would have caught the original bug
+- No skipping/disabling tests to make CI green — fix the root cause
+
+## Examples
+
+**Correct** (proper naming + AAA + isolation):
+
+```typescript
+it("should reduce health by damage amount when take_damage is called", () => {
+  // Arrange
+  const health = new HealthComponent({ maxHealth: 100, current: 100 });
+
+  // Act
+  health.takeDamage(25);
+
+  // Assert
+  expect(health.current).toBe(75);
+});
+```
+
+**Incorrect**:
+
+```typescript
+it("test1", () => {                       // VIOLATION: no descriptive name
+  const h = new HealthComponent();
+  h.takeDamage(25);                        // VIOLATION: no arrange step
+  expect(h.current).toBeLessThan(100);     // VIOLATION: imprecise assertion
+});
+```
+
+## Anti-Patterns
+
+- Assertions that only check "not null" / "truthy" when exact value is knowable
+- Tests that pass only because of execution order (order-dependent)
+- Tests with `sleep()` / arbitrary timeouts — prefer deterministic signals
+- Snapshot tests for rapidly-changing UI without visual review
+- Mocking the system under test

package/skills/ab-test-setup/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: ab-test-setup
+description: "Plan, design, and implement A/B tests and experiments with statistical rigor. Covers hypothesis frameworks, sample sizing, metrics, and result analysis."
+argument-hint: ""
+category: "marketing-strategy"
+user-invocable: true
+allowed-tools: Read, Glob, Grep, Bash
+---
+# A/B Test Setup
+
+Expert experimentation and A/B testing — design tests that produce statistically valid, actionable results.
+
+## Before Starting
+
+If `.claude/product-marketing-context.md` exists, read it first. Then understand: test context (what to improve, what change), current state (baseline conversion, traffic), constraints (complexity, timeline, tools).
+
+## Core Principles
+
+1. **Start with a hypothesis** — Specific prediction based on data, not "let's see what happens"
+2. **Test one thing** — Single variable per test
+3. **Statistical rigor** — Pre-determine sample size, don't peek and stop early
+4. **Measure what matters** — Primary metric tied to business value, secondary for context, guardrail to prevent harm
+
+---
+
+## Hypothesis Framework
+
+```
+Because [observation/data],
+we believe [change]
+will cause [expected outcome]
+for [audience].
+We'll know this is true when [metrics].
+```
+
+---
+
+## Test Types
+
+| Type | Description | Traffic Needed |
+|------|-------------|----------------|
+| A/B | Two versions, single change | Moderate |
+| A/B/n | Multiple variants | Higher |
+| MVT | Multiple changes in combinations | Very high |
+
+For detailed sample size tables and duration calculations, see [references/sample-size-guide.md](references/sample-size-guide.md).
+
+---
+
+## Metrics Selection
+
+- **Primary:** Single metric that matters most, tied to hypothesis
+- **Secondary:** Support interpretation (e.g., time on page, plan distribution)
+- **Guardrail:** Things that shouldn't get worse (e.g., support tickets, refund rate)
+
+---
+
+## Running the Test
+
+### Pre-Launch Checklist
+- [ ] Hypothesis documented
+- [ ] Primary metric defined
+- [ ] Sample size calculated
+- [ ] Variants implemented and QA'd
+- [ ] Tracking verified
+
+### During: Monitor for technical issues, check segment quality, document external factors. Do NOT peek, change variants, or add new traffic sources.
+
+---
+
+## Analyzing Results
+
+1. Reach sample size? If not, result is preliminary
+2. Statistically significant? (95% confidence = p < 0.05)
+3. Effect size meaningful? Compare to MDE
+4. Secondary metrics consistent?
+5. Guardrail concerns?
+6. Segment differences? (mobile vs desktop, new vs returning)
+
+| Result | Action |
+|--------|--------|
+| Significant winner | Implement variant |
+| Significant loser | Keep control, learn why |
+| No difference | Need more traffic or bolder test |
+
+---
+
+## Documentation
+
+Document every test: hypothesis, variants (with screenshots), results, decision, learnings. For templates, see [references/test-templates.md](references/test-templates.md).
+
+---
+
+## Related Skills
+
+- **page-cro** — Ideas for what to test
+- **analytics-tracking** — Measurement infrastructure
+- **campaign-analytics** — Fold results into campaign attribution
+- **marketing-context** — Align hypotheses with ICP and positioning