@funnycode/myclaude 0.1.72 → 0.1.74

package/seed/marketplaces/ecc/skills/benchmark/SKILL.md

@@ -1,93 +1,93 @@
----
-name: benchmark
-description: Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.
-origin: ECC
----
-
-# Benchmark — Performance Baseline & Regression Detection
-
-## When to Use
-
-- Before and after a PR to measure performance impact
-- Setting up performance baselines for a project
-- When users report "it feels slow"
-- Before a launch — ensure you meet performance targets
-- Comparing your stack against alternatives
-
-## How It Works
-
-### Mode 1: Page Performance
-
-Measures real browser metrics via browser MCP:
-
-```
-1. Navigate to each target URL
-2. Measure Core Web Vitals:
-   - LCP (Largest Contentful Paint) — target < 2.5s
-   - CLS (Cumulative Layout Shift) — target < 0.1
-   - INP (Interaction to Next Paint) — target < 200ms
-   - FCP (First Contentful Paint) — target < 1.8s
-   - TTFB (Time to First Byte) — target < 800ms
-3. Measure resource sizes:
-   - Total page weight (target < 1MB)
-   - JS bundle size (target < 200KB gzipped)
-   - CSS size
-   - Image weight
-   - Third-party script weight
-4. Count network requests
-5. Check for render-blocking resources
-```
-
-### Mode 2: API Performance
-
-Benchmarks API endpoints:
-
-```
-1. Hit each endpoint 100 times
-2. Measure: p50, p95, p99 latency
-3. Track: response size, status codes
-4. Test under load: 10 concurrent requests
-5. Compare against SLA targets
-```
-
-### Mode 3: Build Performance
-
-Measures development feedback loop:
-
-```
-1. Cold build time
-2. Hot reload time (HMR)
-3. Test suite duration
-4. TypeScript check time
-5. Lint time
-6. Docker build time
-```
-
-### Mode 4: Before/After Comparison
-
-Run before and after a change to measure impact:
-
-```
-/benchmark baseline    # saves current metrics
-# ... make changes ...
-/benchmark compare     # compares against baseline
-```
-
-Output:
-```
-| Metric | Before | After | Delta | Verdict |
-|--------|--------|-------|-------|---------|
-| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
-| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
-| Build | 12s | 14s | +2s | WARNING: WARN |
-```
-
-## Output
-
-Stores baselines in `.ecc/benchmarks/` as JSON. Git-tracked so the team shares baselines.
-
-## Integration
-
-- CI: run `/benchmark compare` on every PR
-- Pair with `/canary-watch` for post-deploy monitoring
-- Pair with `/browser-qa` for full pre-ship checklist
+---
+name: benchmark
+description: Use this skill to measure performance baselines, detect regressions before/after PRs, and compare stack alternatives.
+origin: ECC
+---
+
+# Benchmark — Performance Baseline & Regression Detection
+
+## When to Use
+
+- Before and after a PR to measure performance impact
+- Setting up performance baselines for a project
+- When users report "it feels slow"
+- Before a launch — ensure you meet performance targets
+- Comparing your stack against alternatives
+
+## How It Works
+
+### Mode 1: Page Performance
+
+Measures real browser metrics via browser MCP:
+
+```
+1. Navigate to each target URL
+2. Measure Core Web Vitals:
+   - LCP (Largest Contentful Paint) — target < 2.5s
+   - CLS (Cumulative Layout Shift) — target < 0.1
+   - INP (Interaction to Next Paint) — target < 200ms
+   - FCP (First Contentful Paint) — target < 1.8s
+   - TTFB (Time to First Byte) — target < 800ms
+3. Measure resource sizes:
+   - Total page weight (target < 1MB)
+   - JS bundle size (target < 200KB gzipped)
+   - CSS size
+   - Image weight
+   - Third-party script weight
+4. Count network requests
+5. Check for render-blocking resources
+```
+
+### Mode 2: API Performance
+
+Benchmarks API endpoints:
+
+```
+1. Hit each endpoint 100 times
+2. Measure: p50, p95, p99 latency
+3. Track: response size, status codes
+4. Test under load: 10 concurrent requests
+5. Compare against SLA targets
+```
+
+### Mode 3: Build Performance
+
+Measures development feedback loop:
+
+```
+1. Cold build time
+2. Hot reload time (HMR)
+3. Test suite duration
+4. TypeScript check time
+5. Lint time
+6. Docker build time
+```
+
+### Mode 4: Before/After Comparison
+
+Run before and after a change to measure impact:
+
+```
+/benchmark baseline    # saves current metrics
+# ... make changes ...
+/benchmark compare     # compares against baseline
+```
+
+Output:
+```
+| Metric | Before | After | Delta | Verdict |
+|--------|--------|-------|-------|---------|
+| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
+| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
+| Build | 12s | 14s | +2s | WARNING: WARN |
+```
+
+## Output
+
+Stores baselines in `.ecc/benchmarks/` as JSON. Git-tracked so the team shares baselines.
+
+## Integration
+
+- CI: run `/benchmark compare` on every PR
+- Pair with `/canary-watch` for post-deploy monitoring
+- Pair with `/browser-qa` for full pre-ship checklist

package/seed/marketplaces/ecc/skills/benchmark-optimization-loop/SKILL.md

@@ -1,69 +1,69 @@
----
-name: benchmark-optimization-loop
-description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests.
-origin: ECC
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Benchmark Optimization Loop
-
-Use this skill to convert "make it 20x faster" or "try 50 recursive
-optimizations" into a bounded measured loop that can actually improve a system.
-
-## Required Baseline
-
-Do not optimize until these exist:
-
-- the operation being optimized;
-- the correctness gate that must stay green;
-- the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
-- the current baseline;
-- the search budget: max variants, max time, max spend, max data impact.
-
-If the user asks for an unrealistic target, keep the ambition but make the loop
-bounded and measurable.
-
-## Loop
-
-1. Measure the baseline.
-2. Identify bottlenecks from evidence.
-3. Generate variants that test one hypothesis each.
-4. Run variants with the same input shape.
-5. Reject variants that fail correctness, safety, or reproducibility.
-6. Promote the fastest safe variant.
-7. Codify the winning path in a script, command, test, config, or doc.
-8. Rerun the baseline and winner to confirm the delta.
-
-## Variant Table
-
-Track variants like this:
-
-```text
-Variant | Hypothesis | Command | Time | Correct? | Notes
-baseline | current path | npm run job | 120s | yes | stable
-batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
-parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited
-```
-
-## Recursive Search
-
-For recursive or hyperparameter work:
-
-- persist every run to a ledger;
-- compare against the prior accepted winner, not only the previous run;
-- keep a holdout or replay check;
-- stop when improvement is within noise, correctness fails, cost exceeds the
-  budget, or the search starts changing more variables than it can explain.
-
-Use phrases like "best measured safe variant" instead of "global optimum" unless
-the search space was actually exhaustive.
-
-## Promotion Gate
-
-A variant cannot become the new default until:
-
-- correctness tests pass;
-- the performance delta is repeated or explained;
-- rollback is obvious;
-- the change is encoded in source control or a durable runbook;
-- the final summary includes exact commands and measurements.
+---
+name: benchmark-optimization-loop
+description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Benchmark Optimization Loop
+
+Use this skill to convert "make it 20x faster" or "try 50 recursive
+optimizations" into a bounded measured loop that can actually improve a system.
+
+## Required Baseline
+
+Do not optimize until these exist:
+
+- the operation being optimized;
+- the correctness gate that must stay green;
+- the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
+- the current baseline;
+- the search budget: max variants, max time, max spend, max data impact.
+
+If the user asks for an unrealistic target, keep the ambition but make the loop
+bounded and measurable.
+
+## Loop
+
+1. Measure the baseline.
+2. Identify bottlenecks from evidence.
+3. Generate variants that test one hypothesis each.
+4. Run variants with the same input shape.
+5. Reject variants that fail correctness, safety, or reproducibility.
+6. Promote the fastest safe variant.
+7. Codify the winning path in a script, command, test, config, or doc.
+8. Rerun the baseline and winner to confirm the delta.
+
+## Variant Table
+
+Track variants like this:
+
+```text
+Variant | Hypothesis | Command | Time | Correct? | Notes
+baseline | current path | npm run job | 120s | yes | stable
+batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
+parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited
+```
+
+## Recursive Search
+
+For recursive or hyperparameter work:
+
+- persist every run to a ledger;
+- compare against the prior accepted winner, not only the previous run;
+- keep a holdout or replay check;
+- stop when improvement is within noise, correctness fails, cost exceeds the
+  budget, or the search starts changing more variables than it can explain.
+
+Use phrases like "best measured safe variant" instead of "global optimum" unless
+the search space was actually exhaustive.
+
+## Promotion Gate
+
+A variant cannot become the new default until:
+
+- correctness tests pass;
+- the performance delta is repeated or explained;
+- rollback is obvious;
+- the change is encoded in source control or a durable runbook;
+- the final summary includes exact commands and measurements.

package/seed/marketplaces/ecc/skills/blender-motion-state-inspection/SKILL.md

@@ -1,164 +1,164 @@
----
-name: blender-motion-state-inspection
-description: Use this skill when inspecting Blender characters, rigs, poses, animation retargeting, ground contact, facing direction, or model-vs-motion alignment where screenshots alone are not enough.
-origin: ECC
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Blender Motion State Inspection
-
-## When to Use
-
-- A Blender character looks twisted, mirrored, flattened, offset, or foot-sliding in an animation.
-- A user asks whether an imported avatar, armature, or retargeted motion matches an expected pose.
-- You need to compare rendered evidence with structured facts such as bones, bounding boxes, contacts, and facing vectors.
-- A workflow depends on deciding whether a model is a character, prop, proxy mesh, control rig, or broken import.
-
-## Core Principle
-
-Do not judge animated 3D assets only from screenshots. Screenshots are review evidence, but they hide axis conventions, bone names, object scale, local transforms, parented meshes, material slots, and frame-by-frame contact state.
-
-First extract structured Blender state, then use viewport screenshots or renders to confirm what the facts imply.
-
-## How It Works
-
-1. Establish the clean scene and asset baseline before judging motion.
-2. Extract structured facts from Blender using an exporter or Blender Python run inside Blender's own interpreter.
-3. Sample the frames most likely to expose contact, orientation, scale, and retargeting errors.
-4. Compare the measured facts against the user's expected pose, direction, ground plane, and render goal.
-5. Return a concise report that separates confirmed facts, likely causes, and required fixes.
-
-## Inspection Workflow
-
-1. Inventory the scene.
-   - List meshes, armatures, empties, cameras, lights, modifiers, parent relationships, and hidden objects.
-   - Separate character meshes from helper/proxy geometry before judging the avatar.
-   - Record object-space and world-space bounding boxes.
-
-2. Identify the skeleton.
-   - Capture armature names, pose bones, bone heads/tails, roll, parent chains, constraints, and rest-pose axes.
-   - Map semantic bones such as hips, spine, neck, head, shoulders, elbows, hands, thighs, knees, ankles, and feet.
-   - Flag missing left/right pairs and unusual naming schemes.
-
-3. Determine forward, up, and side axes.
-   - Use the pelvis, spine, shoulders, hips, head, and feet together; do not rely on a single mesh normal.
-   - Compare local armature axes with world axes and imported file conventions such as glTF Y-up vs Blender Z-up.
-   - Mark likely mirrored or backwards imports when face/head/feet direction conflicts with root motion.
-
-4. Sample animation frames.
-   - Inspect first, middle, contact, airborne, and extreme frames.
-   - Record root location, root heading, pelvis height, torso lean, limb directions, foot clearance, and mesh bounds.
-   - For long or fast motion, sample more densely around flips, landings, turns, collisions, and floor contacts.
-
-5. Check model integrity before retargeting blame.
-   - Confirm the clean baseline shape before applying animation.
-   - Preserve original mesh, materials, armature, and skinning unless the user explicitly asks for repair.
-   - Treat unexplained sphere-like blobs, giant proxy meshes, or crushed bodies as import/selection issues until proven otherwise.
-
-6. Diagnose contact and motion issues.
-   - Ground penetration: compare lowest foot or shoe vertices with floor height per frame.
-   - Foot sliding: compare foot world positions across planted frames.
-   - Leg crossover: compare left/right thigh, knee, ankle, and foot side ordering.
-   - Twist damage: compare bone swing direction separately from roll/twist around the limb axis.
-   - Scale drift: compare animated mesh bounds against the clean baseline bounds.
-
-7. Report facts before opinions.
-   - Include frame numbers, object names, bone names, world coordinates, and thresholds.
-   - Separate confirmed failures from visual suspicions.
-   - Attach screenshots only after the structured state explains what to look for.
-
-## Recommended Report Shape
-
-```markdown
-## Blender Motion Inspection
-
-### Scene Inventory
-- Character candidates:
-- Armatures:
-- Helper/proxy objects:
-- Cameras/lights:
-
-### Orientation
-- World up:
-- Character forward:
-- Root heading:
-- Mirrored/backwards risk:
-
-### Baseline Integrity
-- Clean mesh bounds:
-- Animated mesh bounds:
-- Materials/skin preserved:
-- Suspicious non-character meshes:
-
-### Frame Findings
-| Frame | Finding | Evidence |
-| --- | --- | --- |
-| 1 | Clean baseline pose | hips/spine/feet aligned |
-| 96 | Foot penetrates floor | left_foot min_z = -0.04 |
-
-### Verdict
-- Pass/fail:
-- Required fix:
-- Render readiness:
-```
-
-## Examples
-
-### Walk Cycle With Foot Sliding
-
-Scenario: a retargeted character appears to skate during a walk cycle, but the front camera angle makes the foot contact hard to judge.
-
-Apply the workflow:
-- Inventory the scene: character mesh `HeroBody`, armature `HeroRig`, ground plane `Floor`, no hidden proxy meshes.
-- Identify the skeleton: semantic feet are `foot.L` and `foot.R`; hips are `pelvis`; root bone is `root`.
-- Sample animation frames: inspect frames 1, 18, 24, 30, 42, and 48 around planted-foot moments.
-- Diagnose contact and motion issues: compare world-space foot locations during planted frames.
-
-Extracted facts:
-
-| Frame | Fact | Evidence |
-| --- | --- | --- |
-| 18 | Left foot is planted | `foot.L min_z = 0.004`, toe and heel both near floor |
-| 24 | Left foot slides while planted | `foot.L x = 0.21 -> 0.28` over six frames |
-| 30 | Pelvis keeps moving forward | `pelvis y = 1.14 -> 1.31` |
-
-Verdict: fail for render readiness. The motion needs foot-lock cleanup or retargeting constraint review; the body mesh does not need proportion changes.
-
-### Backwards Imported Character
-
-Scenario: a character looks correct in a still frame, but the animation moves opposite the expected travel direction.
-
-Apply the workflow:
-- Determine forward, up, and side axes: compare head, chest, feet, and root motion.
-- Sample animation frames: inspect frame 1 and the midpoint of the travel path.
-- Report facts before opinions: include the root heading and model-facing direction separately.
-
-Extracted facts:
-
-| Frame | Fact | Evidence |
-| --- | --- | --- |
-| 1 | Character face points toward world `-Y` | head/chest vector from `neck` to `head` resolves to `-Y` |
-| 72 | Root motion travels toward world `+Y` | `root y = 0.0 -> 2.8` |
-| 72 | Feet remain visually forward-facing opposite travel | toe bones point `-Y` while displacement is `+Y` |
-
-Verdict: likely backwards import or retargeting forward-axis mismatch. Fix the import/retarget axis mapping before editing animation curves.
-
-## Practical Thresholds
-
-- Assume Blender's default meter-scale units unless the scene unit scale says otherwise.
-- Treat ground penetration above 1-2 cm as visible unless the floor is soft or intentionally stylized.
-- Treat a sudden scale change above 5% as a likely rig, constraint, or transform inheritance problem.
-- Treat left/right ankle side-order flips during airborne inverted motion as leg crossover risk even if it recovers later.
-- Treat root heading jumps above 30 degrees per frame as suspicious unless the source motion includes a snap turn.
-
-## Anti-Patterns
-
-- Do not modify body proportions to force pose matching unless the task is explicitly mesh repair.
-- Do not bake away the clean baseline before recording it.
-- Do not use one rendered camera angle as proof that a pose is correct.
-- Do not delete helper objects until you have recorded why they are not part of the character.
-- Do not assume an avatar faces +Y, -Y, +X, or -X without checking head, feet, torso, and root motion together.
-
-## Tooling Notes
-
-If a Blender state exporter is available, prefer JSON that includes meshes, armatures, pose bones, materials, contacts, bounding boxes, and sampled animation frames. If no exporter exists, run a small Blender Python script through Blender itself, for example `blender --background scene.blend --python collect_motion_state.py`, because `bpy` is not available in a normal system Python interpreter.
+---
+name: blender-motion-state-inspection
+description: Use this skill when inspecting Blender characters, rigs, poses, animation retargeting, ground contact, facing direction, or model-vs-motion alignment where screenshots alone are not enough.
+origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Blender Motion State Inspection
+
+## When to Use
+
+- A Blender character looks twisted, mirrored, flattened, offset, or foot-sliding in an animation.
+- A user asks whether an imported avatar, armature, or retargeted motion matches an expected pose.
+- You need to compare rendered evidence with structured facts such as bones, bounding boxes, contacts, and facing vectors.
+- A workflow depends on deciding whether a model is a character, prop, proxy mesh, control rig, or broken import.
+
+## Core Principle
+
+Do not judge animated 3D assets only from screenshots. Screenshots are review evidence, but they hide axis conventions, bone names, object scale, local transforms, parented meshes, material slots, and frame-by-frame contact state.
+
+First extract structured Blender state, then use viewport screenshots or renders to confirm what the facts imply.
+
+## How It Works
+
+1. Establish the clean scene and asset baseline before judging motion.
+2. Extract structured facts from Blender using an exporter or Blender Python run inside Blender's own interpreter.
+3. Sample the frames most likely to expose contact, orientation, scale, and retargeting errors.
+4. Compare the measured facts against the user's expected pose, direction, ground plane, and render goal.
+5. Return a concise report that separates confirmed facts, likely causes, and required fixes.
+
+## Inspection Workflow
+
+1. Inventory the scene.
+   - List meshes, armatures, empties, cameras, lights, modifiers, parent relationships, and hidden objects.
+   - Separate character meshes from helper/proxy geometry before judging the avatar.
+   - Record object-space and world-space bounding boxes.
+
+2. Identify the skeleton.
+   - Capture armature names, pose bones, bone heads/tails, roll, parent chains, constraints, and rest-pose axes.
+   - Map semantic bones such as hips, spine, neck, head, shoulders, elbows, hands, thighs, knees, ankles, and feet.
+   - Flag missing left/right pairs and unusual naming schemes.
+
+3. Determine forward, up, and side axes.
+   - Use the pelvis, spine, shoulders, hips, head, and feet together; do not rely on a single mesh normal.
+   - Compare local armature axes with world axes and imported file conventions such as glTF Y-up vs Blender Z-up.
+   - Mark likely mirrored or backwards imports when face/head/feet direction conflicts with root motion.
+
+4. Sample animation frames.
+   - Inspect first, middle, contact, airborne, and extreme frames.
+   - Record root location, root heading, pelvis height, torso lean, limb directions, foot clearance, and mesh bounds.
+   - For long or fast motion, sample more densely around flips, landings, turns, collisions, and floor contacts.
+
+5. Check model integrity before retargeting blame.
+   - Confirm the clean baseline shape before applying animation.
+   - Preserve original mesh, materials, armature, and skinning unless the user explicitly asks for repair.
+   - Treat unexplained sphere-like blobs, giant proxy meshes, or crushed bodies as import/selection issues until proven otherwise.
+
+6. Diagnose contact and motion issues.
+   - Ground penetration: compare lowest foot or shoe vertices with floor height per frame.
+   - Foot sliding: compare foot world positions across planted frames.
+   - Leg crossover: compare left/right thigh, knee, ankle, and foot side ordering.
+   - Twist damage: compare bone swing direction separately from roll/twist around the limb axis.
+   - Scale drift: compare animated mesh bounds against the clean baseline bounds.
+
+7. Report facts before opinions.
+   - Include frame numbers, object names, bone names, world coordinates, and thresholds.
+   - Separate confirmed failures from visual suspicions.
+   - Attach screenshots only after the structured state explains what to look for.
+
+## Recommended Report Shape
+
+```markdown
+## Blender Motion Inspection
+
+### Scene Inventory
+- Character candidates:
+- Armatures:
+- Helper/proxy objects:
+- Cameras/lights:
+
+### Orientation
+- World up:
+- Character forward:
+- Root heading:
+- Mirrored/backwards risk:
+
+### Baseline Integrity
+- Clean mesh bounds:
+- Animated mesh bounds:
+- Materials/skin preserved:
+- Suspicious non-character meshes:
+
+### Frame Findings
+| Frame | Finding | Evidence |
+| --- | --- | --- |
+| 1 | Clean baseline pose | hips/spine/feet aligned |
+| 96 | Foot penetrates floor | left_foot min_z = -0.04 |
+
+### Verdict
+- Pass/fail:
+- Required fix:
+- Render readiness:
+```
+
+## Examples
+
+### Walk Cycle With Foot Sliding
+
+Scenario: a retargeted character appears to skate during a walk cycle, but the front camera angle makes the foot contact hard to judge.
+
+Apply the workflow:
+- Inventory the scene: character mesh `HeroBody`, armature `HeroRig`, ground plane `Floor`, no hidden proxy meshes.
+- Identify the skeleton: semantic feet are `foot.L` and `foot.R`; hips are `pelvis`; root bone is `root`.
+- Sample animation frames: inspect frames 1, 18, 24, 30, 42, and 48 around planted-foot moments.
+- Diagnose contact and motion issues: compare world-space foot locations during planted frames.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 18 | Left foot is planted | `foot.L min_z = 0.004`, toe and heel both near floor |
+| 24 | Left foot slides while planted | `foot.L x = 0.21 -> 0.28` over six frames |
+| 30 | Pelvis keeps moving forward | `pelvis y = 1.14 -> 1.31` |
+
+Verdict: fail for render readiness. The motion needs foot-lock cleanup or retargeting constraint review; the body mesh does not need proportion changes.
+
+### Backwards Imported Character
+
+Scenario: a character looks correct in a still frame, but the animation moves opposite the expected travel direction.
+
+Apply the workflow:
+- Determine forward, up, and side axes: compare head, chest, feet, and root motion.
+- Sample animation frames: inspect frame 1 and the midpoint of the travel path.
+- Report facts before opinions: include the root heading and model-facing direction separately.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 1 | Character face points toward world `-Y` | head/chest vector from `neck` to `head` resolves to `-Y` |
+| 72 | Root motion travels toward world `+Y` | `root y = 0.0 -> 2.8` |
+| 72 | Feet remain visually forward-facing opposite travel | toe bones point `-Y` while displacement is `+Y` |
+
+Verdict: likely backwards import or retargeting forward-axis mismatch. Fix the import/retarget axis mapping before editing animation curves.
+
+## Practical Thresholds
+
+- Assume Blender's default meter-scale units unless the scene unit scale says otherwise.
+- Treat ground penetration above 1-2 cm as visible unless the floor is soft or intentionally stylized.
+- Treat a sudden scale change above 5% as a likely rig, constraint, or transform inheritance problem.
+- Treat left/right ankle side-order flips during airborne inverted motion as leg crossover risk even if it recovers later.
+- Treat root heading jumps above 30 degrees per frame as suspicious unless the source motion includes a snap turn.
+
+## Anti-Patterns
+
+- Do not modify body proportions to force pose matching unless the task is explicitly mesh repair.
+- Do not bake away the clean baseline before recording it.
+- Do not use one rendered camera angle as proof that a pose is correct.
+- Do not delete helper objects until you have recorded why they are not part of the character.
+- Do not assume an avatar faces +Y, -Y, +X, or -X without checking head, feet, torso, and root motion together.
+
+## Tooling Notes
+
+If a Blender state exporter is available, prefer JSON that includes meshes, armatures, pose bones, materials, contacts, bounding boxes, and sampled animation frames. If no exporter exists, run a small Blender Python script through Blender itself, for example `blender --background scene.blend --python collect_motion_state.py`, because `bpy` is not available in a normal system Python interpreter.