复制安装命令
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
Essays and writing behind this toolkit live at vexjoy.com.
用 Codex 或 Claude 安装复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它先审查 Skill 页面再帮你安装。
复制前请先查看来源、License 和安全提示。
来源文件:README.md
Essays and writing behind this toolkit live at vexjoy.com.
AI agents skip steps.
"Looks correct" replaces running tests. "Trivial change" replaces verification. The agent confidently ships broken code because nothing structurally prevented it from skipping the work.
Harnesses have a second problem: given only a skill list, they do not route eagerly enough, or correctly enough. Good skills sit unused. So this toolkit connects the skills, agents, and workflows we want directly into the harness, automatically. You don't have to understand what is here. Say what you want in plain English and you get all the value we have put into it: the right specialist with the right methodology, behind gates that demand exit codes, not assertions.
44 domain agents, 122 workflow skills, 78 hooks, 136 scripts. Agents carry knowledge, skills enforce methodology, hooks block incomplete work, scripts handle determinism.
Works across Claude Code (/do), Codex ($do), Factory (/do), Reasonix (/do).
$ claude
> /do debug this Go test
Routing: go-engineer + systematic-debugging
Phase 1/4: Reproduce: running test, capturing failure...
Phase 2/4: Hypothesize: 3 candidates from stack trace...
Phase 3/4: Verify: isolated root cause in connection pool timeout
Phase 4/4: Fix: patch applied, test passing, PR opened
✓ Delivered: PR #847, fix connection pool timeout in health check
The router reads intent, picks a Go agent paired with a debugging skill, and runs the full lifecycle. You typed one sentence. The system did the rest.
ROUTE PLAN EXECUTE VERIFY DELIVER RECORD
┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐
│ /do │───▶│ Task │───▶│Agent │───▶│Tests │───▶│ PR │───▶│Route │
│Router│ │ Plan │ │+Skill│ │Gates │ │Branch│ │Result│
└──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘
This is the single thing that separates it from "agent with a system prompt."
| Agent Says | What Happens |
|---|---|
| "Code looks correct, skip tests" | Exit gate requires test output. Blocked. |
| "Trivial change, no verification" | Hook blocks completion without evidence. |
| "Similar to before" | Skill demands case-specific proof. |
| "User is in a hurry" | Protocol overrides time pressure. |
| "I'm confident" | Gate demands exit code, not assertion. |
Hooks fire automatically. Gates block completion. Skills encode counter-arguments at every skip-worthy step. The agent verifies or it doesn't finish.
For what I do, the difference is enormous. If you're doing simple single-file edits, maybe less so.
The same routing serves knowledge work. The content engine researches, drafts in a calibrated voice, validates against 397 AI patterns, and repurposes finished pieces for each platform. /html turns any request into a single self-contained HTML file: report, slide deck, prototype, data viz, diagram. Non-engineers who try the toolkit consistently name the HTML artifacts as the thing they love. No code, no setup beyond the installer.
Changes to the toolkit itself ship with evidence. New skills get blind A/B tests against a no-skill baseline before merge. Routing and writing-standard decisions carry measured verdicts; PHILOSOPHY.md cites the numbers. Experiments that lost go into the negative-results registry, what-didnt-work.md; the registry now covers routing reversals, unvalidated A/B citations, and disabled lint rules alongside the original program refutations.
The automated nightly evolution loop (/evolve, writes to evolution-reports/) ran regularly through mid-May 2026. It is currently dormant; recent evidence has come from manual PRs instead.
git clone https://github.com/notque/vexjoy-agent.git ~/vexjoy-agent
cd ~/vexjoy-agent
./install.sh
Links into ~/.claude/ and mirrors into ~/.codex/, ~/.factory/, ~/.reasonix/ — each mirror only when that runtime is detected (its command on PATH or its home dir already exists). The installer asks symlink (live updates via git pull) or copy (stable snapshot).
Want only part of the toolkit? Run ./install.sh --configure to pick which skills, agents, and hooks install, or copy .local.example/profile.yaml to .local/profile.yaml and edit. No profile file = full install, unchanged behavior. Credit: @thomasvan. Details: .local.example/README.md.
| CLI | Entry Point |
|---|---|
| Claude Code | /do |
| Codex | $do |
| Factory | /do |
| Reasonix | /do |
Full setup: docs/start-here.md
Mirrors agents, skills, and supported hooks into ~/.codex/. The original six-hook allowlist was correct for Codex v0.114, when tool hooks only intercepted Bash. Current support requires Codex v0.144.1+ and classifies the 74 Claude hook registrations as 26 native, 35 adapter-backed, and 13 unsupported (61 supported). These are registration counts, not unique hook files. The installer also preserves explicit per-subagent model routing for GPT-5.6 Sol by setting the MultiAgent V2 compatibility keys documented in openai/codex#31814.
Codex now exposes apply_patch to tool hooks. VexJoy's adapter converts each patch operation into the Write/Edit payload expected by existing guards, but it cannot intercept writes performed through unified_exec, unmatched MCP tools, WebSearch, or other unsupported tool paths. PreCompact and Stop adapters also receive less telemetry than Claude Code: Codex does not provide Claude's conversation_history or session_data. This is expanded compatibility, not full Claude parity.
After install or any hook-definition change, run /hooks in Codex and review the new definitions before trusting them. Codex hash-trusts hook commands and skips changed, unreviewed definitions.
Gemini CLI support removed (deprecated upstream, transitioned to Antigravity CLI); Antigravity support pending CLI maturity. Per Google's transition announcement, Gemini CLI stops serving requests on 2026-06-18 for Google AI Pro / Ultra and free Gemini Code Assist for individuals. Gemini API integrations (image-gen backends, sprite pipeline, GEMINI_API_KEY) are unaffected and stay in the toolkit.
If a prior install mirrored into ~/.gemini/, remove the stale mirrors with:
rm -rf ~/.gemini/skills ~/.gemini/agents ~/.gemini/hooks ~/.gemini/scripts ~/.gemini/antigravity/plugins/vexjoy-agent
Mirrors agents (as "droids"), skills, and all hooks into ~/.factory/. Hook config merges into ~/.factory/settings.json with paths rewritten.
Mirrors skills, scripts, and the allowlisted hooks (scripts/reasonix-hooks-allowlist.txt) into ~/.reasonix/ (no agent or custom-command surface, so neither is installed; the /do router rides in as a skill). Reasonix fires only 4 events (PreToolUse, PostToolUse, UserPromptSubmit, Stop), so only hooks for those events are allowlisted. Hook config is written to the hooks key of ~/.reasonix/settings.json in Reasonix's native flat shape (one entry per hook, match regex over the tool name); the generator builds absolute python3 commands, so no path rewrite is applied. MCP/model/permissions in ~/.reasonix/config.json are user-owned and left untouched.
The toolkit supplies its own routing, domain knowledge, methodology, and enforcement. The default system prompt duplicates most of that.
claude --system-prompt "."
Strips built-in tool-use instructions. The toolkit's agents, skills, hooks, and CLAUDE.md provide equivalent coverage.
| Layer | Count | Does |
|---|---|---|
| Agents | 44 | Domain knowledge: idiom tables, failure mode catalogs, error-to-fix mappings |
| Skills | 122 | Phased methodology with gates. Can't skip steps. Each phase has exit criteria requiring evidence. |
| Hooks | 78 | Fire on lifecycle events. Block incomplete work. Zero LLM cost. |
| Scripts | 136 | Determinism: test runners, linters, validators. No LLM judgment. |
Full skill catalog: docs/skills.md.
┌─────────────────────────────────────────────────┐
│ SKILL.md │
│ ┌─ Frontmatter ─────────────────────────────┐ │
│ │ triggers, pairs_with, success-criteria │ │
│ └────────────────────────────────────────────┘ │
│ Reference Loading Table (conditional imports) │
│ Phased Instructions (numbered, with gates) │
│ Verification (evidence requirements) │
└─────────────────────────────────────────────────┘
A game built entirely by Claude Code using these agents, skills, and pipelines:
I just want to use it Install, learn /do, done.
I do knowledge work Writing, research, data analysis, moderation, HTML artifacts. No code.
I'm a developer Architecture, extension points, adding agents and skills.
I'm an AI power user Routing tables, pipelines, hooks, telemetry DB.
I'm an AI agent Machine-dense inventory. Tables, paths, schemas.
I'm on LinkedIn 🚀 Thought leadership. Agree? 👇
Full design philosophy: PHILOSOPHY.md
One report-only script surfaces upkeep work; it prints a digest and never edits, deletes, or blocks.
python3 scripts/stale-skill-scan.py --top 20 ranks stale skills and agents as pruning candidates. Run it quarterly; see docs/deprecation-template.md.Scheduled work follows the same boundary as everything else: judgment uses agents; repeatable plumbing uses scripts.
| Need | Use |
|---|---|
| Run a deterministic command on a schedule | scripts/agent-scheduler.py with runner: "command" |
| Run an agent judgment on a schedule, webhook, or file change | scripts/agent-scheduler.py with the default runner: "claude" |
| Install or remove a user crontab entry safely | scripts/crontab-manager.py |
| Audit shell cron reliability | cron-automation |
| Keep one interactive objective moving until criteria verify | objective-loop |
See CONTRIBUTING.md.
MIT. See LICENSE.
name: threejs-builder
description: "Three.js app builder: imperative, React Three Fiber, and WebGPU in 4 phases."
agent: typescript-frontend-engineer
user-invocable: false
command: /threejs
allowed-tools:
- Read
- Write
- Bash
- Grep
- Glob
- Edit
- Task
routing:
triggers:
- threejs
- three.js
- 3D web
- 3D scene
- WebGL
- WebGPU
- 3D animation
- 3D graphics
- react three fiber
- r3f
- drei
- react-three
- "@react-three/fiber"
- postprocessing 3D
- TSL shader
- three shading language
- compute shader three
- WebGPURenderer
- node material three
- game architecture three
- gltf loading
- glb model
- animation state machine three
- eventbus game
- game state management three
- three.js game
pairs_with:
- typescript-frontend-engineer
- react-native-engineer
- distinctive-frontend-design
complexity: Medium
category: frontendThis skill builds complete Three.js web applications using a Phased Construction pattern with four phases: Design, Build, Animate, Polish. It supports three paradigms — imperative Three.js, React Three Fiber (R3F), and WebGPU — detected automatically from project context. Only the relevant paradigm's reference is loaded.
Scope: Use for 3D web apps, interactive scenes, WebGL/WebGPU visualizations, R3F declarative 3D, and product viewers. For game engines, 3D model creation, VR/AR experiences, or CAD workflows, use a more specialized skill.
| Signal | Load These Files | Why |
|---|---|---|
@react-three/fiber, r3f, drei, useFrame, <Canvas>, <mesh>, React project with 3D | react-three-fiber.md | React Three Fiber |
WebGPURenderer, TSL, tsl, compute shader, wgsl, node material, WebGPU mentioned | webgpu.md | WebGPU |
Standalone HTML, CDN imports, new THREE.Scene(), no React, vanilla JS/TS | advanced-topics.md (load as needed)` | Imperative |
Game project: EventBus, GameState, player controller, enemies, scoring, multiple game systems | game-patterns.md (alongside paradigm reference)` | Game architecture |
GLTF/GLB model loading, .glb files, animated characters, skeletal rigs, model import | gltf-loading.md (alongside paradigm reference)` | GLTF loading |
references/build-recipes.md | build-recipes.md | Phase 2/3 build, error diagnosis |
references/advanced-topics.md | advanced-topics.md | Imperative paradigm |
references/react-three-fiber.md | react-three-fiber.md | R3F paradigm |
references/webgpu.md | webgpu.md | WebGPU paradigm |
references/visual-polish.md | visual-polish.md | Visual quality signal |
references/gltf-loading.md | gltf-loading.md | GLTF/GLB model loading signal |
references/game-patterns.md | game-patterns.md | Game project signal |
references/game-architecture.md | game-architecture.md | Game project signal |
references/shader-patterns.md | shader-patterns.md | Custom GLSL / visual effects |
references/performance-patterns.md | performance-patterns.md | Performance / many objects |
references/advanced-animation.md | advanced-animation.md | Animation systems / skeletal rigs |
Goal: Detect the paradigm, understand what the user wants, and select appropriate components.
Core Constraints:
Group for logical groupings and maintain proper hierarchyStep 0: Detect paradigm
Scan the user's request, existing project files (package.json, imports), and stated requirements to identify which paradigm applies:
| Signal | Paradigm / Context | Reference to Load |
|---|---|---|
@react-three/fiber, r3f, drei, useFrame, <Canvas>, <mesh>, React project with 3D | React Three Fiber | references/react-three-fiber.md |
WebGPURenderer, TSL, tsl, compute shader, wgsl, node material, WebGPU mentioned | WebGPU | references/webgpu.md |
Standalone HTML, CDN imports, new THREE.Scene(), no React, vanilla JS/TS | Imperative | references/advanced-topics.md (load as needed) |
Game project: EventBus, GameState, player controller, enemies, scoring, multiple game systems | Game architecture | references/game-architecture.md + references/game-patterns.md (alongside paradigm reference) |
GLTF/GLB model loading, .glb files, animated characters, skeletal rigs, model import | GLTF loading | references/gltf-loading.md (alongside paradigm reference) |
If ambiguous (e.g., user says "3D scene" with no project context), ask which paradigm — don't guess, because imperative Three.js patterns actively conflict with R3F patterns (OrbitControls setup, animation loops, component lifecycle).
Game and GLTF references load alongside the paradigm reference — they are complementary, not alternative. A game project using R3F loads both react-three-fiber.md and the relevant game references.
After detecting paradigm: Read the corresponding reference file. The reference contains paradigm-specific patterns, failure modes, and component selection guidance that override the generic steps below.
Additional reference loading signals (visual-polish, shader-patterns, performance-patterns, advanced-animation) are listed in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 1: Additional Reference Loading Signals).
Step 1: Identify the core visual element
Determine from the user request:
Step 2: Select components
See the Scene Plan template in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 1: Scene Plan Template).
Step 3: Document visual style
Record the visual direction for this scene (e.g., "elegant minimal portfolio style", "vibrant interactive game", "clean data visualization"). Use this to guide material colors, lighting warmth, and animation pacing.
Gate: Scene plan documented with geometry, material, lighting, animation, and controls selected. Proceed only when gate passes.
Goal: Construct the scene with proper structure and modern patterns.
Paradigm-specific build instructions: If you loaded a paradigm reference in Step 0, follow its build patterns instead of the imperative defaults. R3F uses JSX components and <Canvas>, not manual renderer setup. WebGPU uses WebGPURenderer with different initialization. The reference file is authoritative for its paradigm.
Core constraints for the imperative paradigm (single HTML, resize handling, CONFIG object, modular setup functions, three-point lighting, renderer.setAnimationLoop()) are in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 2: Core Constraints).
Step 1: Create HTML boilerplate
See the HTML boilerplate in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 2: HTML Boilerplate).
Step 2: Build scene infrastructure
See the scene infrastructure code (CONFIG object, scene/camera/renderer setup, resize handler) in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 2: Scene Infrastructure).
Step 3: Add lighting, geometry, and materials per scene plan
Build each component from the Phase 1 plan. Create geometry once and reuse where possible (avoid allocating new geometries in animation loops). Use Group for hierarchical transforms and logical scene organization.
Gate: Scene renders without errors. All planned geometry, materials, and lights are present. Proceed only when gate passes.
Goal: Add motion, interaction, and life to the scene.
Paradigm-specific animation: R3F uses useFrame hooks (never requestAnimationFrame or setAnimationLoop). WebGPU may use compute shaders for GPU-driven animation. See the loaded paradigm reference for patterns.
Core constraints for the imperative paradigm (no geometry/material allocation in the loop, time parameter usage, OrbitControls default, transform-only-per-frame) are in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 3: Core Constraints).
Step 1: Set up animation loop
See the animation loop pattern in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 3: Animation Loop).
Step 2: Implement planned animations
Apply transforms per frame. Time-based animation follows the pattern shown in references/build-recipes.md.
Step 3: Add interaction handlers
Wire up mouse/touch events, orbit controls, or raycasting per the scene plan.
Gate: Animations run smoothly. Interactions respond correctly. No console errors. Proceed only when gate passes.
Goal: Ensure quality, performance, and completeness.
Core constraints (remove debug helpers / commented code, handle window resize, ensure visible lighting, match visual style) and the four verification steps (responsive behavior, visual quality, output testing, cleanup) are in ${CLAUDE_SKILL_DIR}/references/build-recipes.md (Phase 4: Core Constraints + Polish Verification Steps).
Gate: All verification steps pass. Output is complete and ready to deliver.
See ${CLAUDE_SKILL_DIR}/references/build-recipes.md for error cases: black screen / nothing renders, OrbitControls not defined, model loads but is invisible or tiny.
| Reference | When to Load | Content |
|---|---|---|
references/build-recipes.md | Phase 2/3 build, error diagnosis | HTML boilerplate, CONFIG + scene/camera/renderer setup, animation loop, error handling (black screen, OrbitControls, model scale) |
references/advanced-topics.md | Imperative paradigm | GLTF loading, post-processing, shaders, raycasting, physics, InstancedMesh, TypeScript |
references/react-three-fiber.md | R3F paradigm | Declarative patterns, Drei helpers, camera pitfalls, post-processing, Zustand, performance |
references/webgpu.md | WebGPU paradigm | WebGPURenderer, TSL shaders, compute shaders, version-specific changes, device loss |
references/visual-polish.md | Visual quality signal | Material recipes, dramatic lighting, post-processing stacking, HDR environments, shadow quality |
references/gltf-loading.md | GLTF/GLB model loading signal | Coordinate system contract, SkeletonUtils.clone, model caching, auto-centering, bone hierarchy, asset manifest |
references/game-patterns.md | Game project signal | Animation state machine, camera-relative movement, delta capping, mobile input, player controller |
references/game-architecture.md | Game project signal | EventBus, GameState singleton, Constants module, restart-safety, pre-ship checklist |
references/shader-patterns.md | Custom GLSL / visual effects | ShaderMaterial vs RawShaderMaterial, vertex displacement, fragment effects (holographic, dissolve, chromatic aberration), EffectComposer postprocessing pipeline |
references/performance-patterns.md | Performance / many objects | InstancedMesh, BufferGeometry typed arrays, draw call batching, LOD, KTX2 textures, dispose patterns |
references/advanced-animation.md | Animation systems / skeletal rigs | AnimationMixer morph targets, bone manipulation, procedural IK, spring physics, GSAP integration, particle animation |
评论 (0)
暂无评论,成为第一个评论者吧!