Retired Skill Article Ledger

Archive of verbose retired wiki/skills/<slug>.md article bodies preserved during the skill-registry compaction. Family pages are the readable synthesis layer; this ledger keeps the old text searchable without making every family page a dump. Source: User request, 2026-06-27

How To Use This Ledger

Use this page for retrieval and provenance when an old skill-article slug or phrase appears in search. Do not treat archived sections as current routing guidance. Current execution lives in skills/{engineering,productivity,personal,misc}/<slug>/SKILL.md, current inventory lives in Skill Registry, and current family synthesis lives in wiki/concepts/*-skills.md.

If archived text contains durable knowledge that still matters, promote it into the owning family page, tool page, concept page, workflow, or executable skill source, then refresh generated surfaces through Generated Surface Contract. Keep this ledger append-only unless running the archive script or correcting broken provenance.

Agent Engineering Skills

Merged Article Notes

Commit Skill

Former page: wiki/skills/commit.md. Runtime source: skills/engineering/commit/SKILL.md

Commit Skill

Create a git commit in conventional-commit format, auto-injecting the current git state so the message reflects what is actually staged.

The commit skill turns a working tree into a single, well-scoped conventional commit. It is one of the Dedalus git-workflow skills and is deliberately narrow: it gathers context, applies a strict format, stages by intent, and commits, with nothing else in the loop. Source: skills/engineering/commit/SKILL.md, 2026-05-31

Auto-injected context

Before composing a message the skill reads the live repository state so the commit is grounded in reality rather than memory:

• git status -sb for the staged and unstaged picture
• git diff HEAD --stat for the shape of the change
• git branch --show-current for the active branch
• git log --oneline -10 to match the repository's recent message style

Source: skills/engineering/commit/SKILL.md, 2026-05-31

Message rules

Commits are terse one-line conventional commits of the form type(scope): description.

• type: one of feat, fix, refactor, docs, test, chore
• scope: the affected area (module, package, or feature)
• description: imperative mood, lowercase, no trailing period, under 72 characters
• never use "and": if a message needs "and", it is two changes and therefore two commits

Source: skills/engineering/commit/SKILL.md, 2026-05-31

Staging discipline

Files are staged by name. The skill never runs git add -A or git add ., because blanket staging mixes unrelated changes into one commit. Changes are grouped by intent, which pairs naturally with the "no and" rule: each commit is one coherent unit of work. This keeps history bisectable and keeps individual diffs within the project's review-size norms. Source: skills/engineering/commit/SKILL.md, 2026-05-31

Constraints

The skill is allowed only the git add, git status, git commit, and git diff tools, and it emits tool calls without prose. It pairs with the Browser Testing Skills skill (open a pull request) and the Frontend and Design Skills skill (changelog promotion between branches), and follows the conventions in Git Workflow. Source: skills/engineering/commit/SKILL.md, 2026-05-31

Greentext

Former page: wiki/skills/greentext.md. Runtime source: skills/engineering/greentext/SKILL.md, skills/engineering/greentext/SKILL.md, skills/engineering/greentext/SKILL.md

Greentext

Explain code, request flows, lifecycles, and architecture as terse >-prefixed lines. 4chan greentext meets sysadmin postmortem.

Originated as /greentext in dedalus-monorepo/.claude/skills/greentext/. Mirrored to ~/.cursor/skills/greentext/, ~/.claude/skills/greentext/, and ~/.codex/skills/greentext/ so the skill triggers in any repo on any agent surface.

When it fires

• "explain the logic of X"
• "greentext this flow"
• "walk me through what happens when Y"
• "why won't this overwrite tenant Z's data?"
• request-flow / lifecycle / state-machine / failure-mode walkthroughs
• post-incident "what actually happened, in order" reconstructions

The contract (strict)

• Every content line starts with >
• One event, cause, or invariant per line - no compound sentences
• Concrete nouns over abstractions (dm-123, /run/dedalus-bootstrap/home, virtio-fs tag)
• Prefer present tense, verbs first, drop articles
• Safety checks get their own line. Failure modes get their own line.
• Deadpan delivery - comedy comes from precision, not jokes
• Punchline is its own line; set up with straight facts
• ≤15 lines. Anything longer is a blog post wearing > signs.
• 100% technically accurate - readable as documentation

What it's good for

Bootstrap/identity flows, fd leaks, delete lifecycles, virtio-fs tag wiring, etcd race conditions, billing edge cases, scheduler decisions, anything where "the order matters and the failure mode is non-obvious." See the canonical example in the skill: guest-agent checks bootstrap machine-id == bind machine-id before writing /etc, fails closed if mismatched, prevents cross-machine /etc poisoning regardless of traffic volume.

What it's not for

Code blocks, formal docs, user-facing copy, marketing, anything that needs hierarchy or nested structure. If you find yourself wanting headers, this is the wrong tool - write prose with Writing and Content Skills instead.

Why it lives in the wiki

The skill is dedalus-native (the canonical example is the host-agent / storage-daemon / guest-agent bootstrap flow), but the format is universal. Promoted to global so any repo can ask "explain this flow" and get the same terse, precise output.

Lamport

Former page: wiki/skills/lamport.md. Runtime source: skills/engineering/lamport/SKILL.md, skills/engineering/dedalus-lamport/SKILL.md

Lamport

Reason about state, not stories — replace case-by-case sequence reasoning with a state invariant.

Invoked via /lamport or when a task has so many cases, phases, interactions, or edge conditions that reasoning through every possible sequence of events is untrustworthy. Instead of enumerating sequences (which grow combinatorially, so cases get missed), the skill names the boolean property of the state that must hold for the final answer to be correct — the invariant — and then each operation only has to prove it preserves that invariant. Source: skills/engineering/dedalus-lamport/SKILL.md, 2026-06-13

The pass starts from the final answer (the product promise), describes the concrete state (fields, flags, counters, sets, locks, files, tables, UI state), states the invariant, and for each operation shows why the property still holds afterward. Crucially it splits surprising cases into impossible-by-invariant versus real cases that need handling, and names a witness — a test, assertion, type, or observation — that would catch a violation. It is fail-closed: never add fallback behavior to hide an invariant violation. Source: skills/engineering/dedalus-lamport/SKILL.md, 2026-06-13

The output shape is fixed (Product promise → State → Invariant → Operations → Tests → Decision); multi-part problems add per-subsystem invariants plus a composition law. Coding guidance: encode states as types or enums, prefer exhaustive case analysis over open-ended conditionals, and leave proof comments (invariant / preservation / witness; fences and witnesses for concurrent or distributed work). Named for Leslie Lamport's state-machine / TLA+ style of reasoning. Lives in the Dedalus harness namespace; executable body at skills/engineering/dedalus-lamport/SKILL.md. See Skill Resolver § Dedalus monorepo.

RTFM

Former page: wiki/skills/rtfm.md. Runtime source: skills/engineering/rtfm/SKILL.md, skills/engineering/dedalus-rtfm/SKILL.md

RTFM

Verify claims against primary sources before writing code or docs. Read the actual API, run the actual command, check the actual docs, then decide.

When To Use

Use rtfm every time you:

• claim a tool can or cannot do something
• write docs about a fast-moving SDK/API
• choose between tools based on capabilities
• write a workaround for a supposed limitation
• touch security, payments, auth, infra, or external services
• cite specs, changelogs, or package behavior

Procedure

1. Read the primary source: official docs, source code, spec, type definition, OpenAPI schema, --help.
2. Read secondary source: official examples, changelog, migration guide, release notes.
3. Check tertiary evidence when needed: issues, PRs, community examples, first-hand reports.
4. Run it if the claim is runtime behavior.
5. Only then decide.

Source Hierarchy

Output Standard

When RTFM affects a decision, state:

• source opened
• relevant fact
• date checked if time-sensitive
• whether behavior was tested locally
• remaining uncertainty

Why It Matters

Wrong assumptions create fake constraints. Fake constraints create workarounds. Workarounds become architecture. Then someone has to maintain a little monument to a thing that was never true. Dark stuff, honestly.

Frontend and Design Skills

Merged Article Notes

A-Frame WebXR

Former page: wiki/skills/aframe-webxr.md. Runtime source: skills/engineering/aframe-webxr/SKILL.md

A-Frame WebXR

Declarative HTML framework for building browser-based VR, AR, and 3D experiences with minimal JavaScript, built on Three.js.

A-Frame uses an entity-component-system (ECS) architecture exposed through HTML custom elements. Scenes are declared with <a-scene>, entities with <a-entity>, and behavior is added via component attributes like geometry, material, and position. Primitives (<a-box>, <a-sphere>) provide shorthand for common entity-component combinations.

The framework auto-injects a default camera, look controls, and WASD movement. Custom components are registered via AFRAME.registerComponent() with lifecycle hooks (init, tick, update). Components define a schema for configuration and run per-frame logic in tick(). Groups of reusable attribute sets are defined as <a-mixin>.

VR support works through <a-entity hand-controls laser-controls> attached to a camera rig. AR uses the ar-hit-test component with WebXR hit-test feature flags. Gaze interaction uses <a-cursor> with raycaster targeting. Assets are preloaded in <a-assets> for textures, models, audio, and video. GLTF models load via gltf-model component with animation-mixer for skeletal animation playback.

Key Patterns

• Camera rig: Wrap <a-camera> and controllers in a parent <a-entity id="rig"> so movement applies to the rig, not the camera.
• 360 viewer: <a-sky src="#equirectangular"> with thumbnail planes that swap the sky source on click.
• Dynamic scenes: document.createElement('a-entity') with setAttribute() for programmatic generation.
• Three.js escape hatch: entity.object3D gives direct Three.js access for advanced manipulation.
• Performance: Pool entities, use InstancedMesh via Three.js for repeated geometry, throttle tick() updates, limit lights on mobile.

When to Choose A-Frame

Over Three.js: rapid prototyping, VR-first projects, minimal JS requirement. Over React Three Fiber: non-React projects, HTML-first workflow. Three.js or R3F are better when you need full programmatic control or React integration.

Animated Component Libraries

Former page: wiki/skills/animated-component-libraries.md. Runtime source: skills/engineering/animated-component-libraries/SKILL.md

Animated Component Libraries

Component-source routing for polished React, Tailwind, shadcn/Radix, chart, and shader UI libraries.

The executable skill now covers more than animation. It is the "check the good component shelves before hand-rolling" route for shadcn/ui, Radix UI, Blocks.so, Chanh Dai Components, Evil Charts, Skiper UI, Cult UI, Magic UI, React Bits, Fancy Components, Origin UI, and Shaders.com. Read Component Library Sources for the current routing order. Source: skills/engineering/animated-component-libraries/SKILL.md; User request, 2026-06-26

Magic UI provides copy-paste components built on Tailwind CSS and Framer Motion, designed for smooth shadcn/ui integration. Install via npx shadcn@latest add https://magicui.design/r/<component>. Components follow the cn() utility pattern and extend React.ComponentPropsWithoutRef. Strengths: grid patterns, animated backgrounds, shimmer buttons, border beams, marquees.

React Bits offers standalone components with minimal external dependencies. Some use WebGL via the ogl library for effects like Particles, Plasma, and Aurora backgrounds. Strengths: text animations (BlurText, CircularText, CountUp), interactive elements (Dock, Magnet, Stepper), and high-performance background effects.

Radix UI is the primitive/accessibility layer. Use it before rebuilding focus, keyboard, overlays, menus, selects, dialogs, popovers, or tooltip behavior.

Blocks.so and Origin UI are block/variant sources for app UI. Use them before inventing common page sections or control variants.

Chanh Dai Components is a pixel-exact Tailwind/shadcn craft source. Use it for dense, sharp, component-forward interfaces and showcase patterns.

Evil Charts is the chart/dashboard source. Use it before defaulting to generic Recharts examples.

Skiper UI provides uncommon shadcn/ui components for Next.js projects. Use it when a page needs distinctive but editable component patterns and the local design system does not already have the primitive.

Cult UI expands shadcn/ui with animated components, blocks, full templates, and AI-agent artifact patterns. Use it for agent/product surfaces, animated sections, and template-driven TypeScript/Next.js work.

Fancy Components and React Bits cover expressive microinteractions, text effects, backgrounds, and animated flourishes. Shaders.com covers shader/effect components and routes to Shaders MCP when an agent should search or install presets.

The sources complement each other well. Use Radix for behavior, shadcn for owned app primitives, Blocks/Origin for common app blocks, Chanh Dai for craft, Evil Charts for dashboards, Skiper/Cult for uncommon shadcn patterns, Magic/React Bits/Fancy for animation, and Shaders.com for shader material. Read Component Library Sources before choosing a source.

Key Patterns

• Source selection first: Check Component Library Sources before hand-rolling animated or uncommon components.
• Primitive before custom behavior: Use Radix UI / Base UI before building focus, keyboard, overlay, select, dialog, menu, or popover behavior.
• Charts before dashboards: Check Evil Charts before hand-rolling chart cards, graph shells, or Recharts compositions.
• Shader effects as components: Route shader visuals through Shaders.com and Shader Effects Libraries before writing raw shader code.
• Progressive enhancement: Check navigator.hardwareConcurrency and fall back from WebGL Particles to GridPattern on low-end devices.
• Reduced motion: Respect prefers-reduced-motion by disabling delays and animation modes.
• Z-index layering: Background patterns at -z-10, content at z-10 to prevent overlap.
• CSS animations: Magic UI requires keyframes in globals.css (ripple, shimmer-slide, marquee) for manual installations.
• Lazy load heavy effects: React.lazy() for AnimatedGridPattern and WebGL components.

Common Pitfalls

• Missing cn() utility in lib/utils.ts (requires clsx + tailwind-merge).
• Tailwind content paths not including components/ directory.
• WebGL components (Particles, Plasma) need the ogl package installed separately.
• Multiple heavy animations simultaneously cause frame drops; limit to one WebGL effect per viewport.

App Onboarding Questionnaire - Conversion-Optimized Onboarding Flows

Former page: wiki/skills/app-onboarding-questionnaire.md. Runtime source: skills/engineering/app-onboarding-questionnaire/SKILL.md

App Onboarding Questionnaire - Conversion-Optimized Onboarding Flows

Design and build high-converting questionnaire-style onboarding flows modelled on proven patterns from top subscription apps (Headspace, Noom, Duolingo, Mob). Multi-phase process: discovery, transformation mapping, blueprint, content, implementation. 374 GitHub stars.

The Pattern

Top subscription apps don't just show feature tours - they run the user through a structured questionnaire that creates psychological investment before the paywall. The upstream skill describes a multi-phase flow modeled on apps such as Mob, Headspace, Duolingo, and Noom, with analysis of Mob's onboarding used as the reference pattern. Source: adamlyttleapps/claude-skill-app-onboarding-questionnaire, accessed 2026-06-25

By the time the user sees pricing, they've identified their goals, felt understood, seen social proof, configured preferences, and used the app. The paywall becomes the natural final step, not an ambush.

The Five Phases

Phase 1: App Discovery

Analyze the codebase to understand what the app does, who it's for, the core loop, the "aha moment," existing paywall/subscription, and required permissions. Ask targeted clarifying questions for what the code doesn't answer. Source: upstream SKILL.md, accessed 2026-06-25

Phase 2: User Transformation

Define the before/after state the app creates. This is the conceptual foundation - every screen in the flow serves this transformation story. Extract 3-5 benefit statements that are specific, measurable, pain-point-addressed, and user-centered.

Phase 3: Onboarding Blueprint

Design the screen sequence using 14 archetypes:

Phase 4: Screen Content

Draft headlines, subheadlines, options, CTAs, stats for each screen. Key principles: write like a human, pass the "would I say this to a friend?" test, specific stats over round numbers, CTAs that describe what happens next.

Phase 5: Implementation

Build screen-by-screen following the app's existing architecture. Wire navigation, progress bar, response persistence, interactions (swipe, grid select, multi-select). The app demo screen is the hardest - reduce the core loop to its simplest form with a tangible output.

Key Insights

• Permission priming converts at 70-80%+ vs 40% for cold system prompts. Frame around user benefit, never app need.
• The app demo is the conversion driver. User must DO something and GET something back - a result, plan, score. Creates sunk cost before the paywall.
• Progress persists across sessions via memory/state. Users can resume from any phase.
• The viral moment is the output from the demo - design it to be shareable.
• Stats: 83% feels more credible than 80%. Specific numbers over round ones.

Babylon.js Engine

Former page: wiki/skills/babylonjs-engine.md. Runtime source: skills/engineering/babylonjs-engine/SKILL.md

Babylon.js Engine

Full-featured 3D rendering engine for real-time web experiences, browser games, and interactive visualizations with built-in physics, GUI, and inspector.

Babylon.js provides a batteries-included approach to web 3D. Initialize with new BABYLON.Engine(canvas) and new BABYLON.Scene(engine), then run engine.runRenderLoop(() => scene.render()). The engine supports both WebGL and WebGPU backends. ES6 tree-shakeable imports from @babylonjs/core keep bundle size manageable.

Camera options include FreeCamera (FPS-style), ArcRotateCamera (orbit), and UniversalCamera (with collision detection). Always call camera.attachControl(canvas, true) or controls will not respond. Lighting uses HemisphericLight, DirectionalLight, PointLight, and SpotLight with includedOnlyMeshes for per-mesh optimization. PBR materials use PBRMaterial with metallic/roughness workflow and environment maps.

Physics uses Havok (via @babylonjs/havok) with PhysicsAggregate for shape/body creation. Shapes include sphere, box, capsule, cylinder, convex hull, and mesh. Static bodies use mass: 0. Models load via SceneLoader.ImportMeshAsync for GLTF/GLB. Animation groups control skeletal playback from imported models.

Key Patterns

• Instancing: mesh.createInstance() for repeated geometry (1 draw call for 1000 copies). thinInstanceSetBuffer for extreme counts.
• Post-processing: DefaultRenderingPipeline gives bloom, DOF, FXAA. GlowLayer and HighlightLayer for selection feedback.
• Scene optimizer: SceneOptimizer with graduated optimizations (hardware scaling, shadow reduction, texture downscaling, mesh merging).
• GUI: AdvancedDynamicTexture.CreateFullscreenUI() for 2D HUD or CreateForMesh() for world-space UI.
• Freeze static assets: mesh.freezeWorldMatrix() and material.freeze() for objects that do not move.

Common Pitfalls

• Memory leaks from scene.removeMesh() instead of mesh.dispose().
• Physics not working: must call scene.enablePhysics() with Havok plugin before creating aggregates.
• Blocking main thread with large mesh creation loops; use setTimeout yield every 100 meshes.

Barba.js

Former page: wiki/skills/barba-js.md. Runtime source: skills/engineering/barba-js/SKILL.md

Barba.js

Lightweight (~7KB) page transition library that makes multi-page websites feel like SPAs by intercepting navigation and managing animated content swaps.

Barba.js hijacks internal link clicks, fetches the next page via AJAX, and transitions between old and new content containers. The DOM requires three elements: a data-barba="wrapper" (persistent frame), a data-barba="container" (swapped content), and a data-barba-namespace identifier per page type. Static elements like headers and footers live outside the container and persist across navigations.

Transitions define leave and enter hooks that return promises (typically GSAP timelines). Async mode runs leave then enter sequentially; sync: true runs both simultaneously for crossfade effects. Eleven lifecycle hooks run in order: before, beforeLeave, leave, afterLeave, beforeEnter, enter, afterEnter, after. Views provide namespace-scoped hooks for page-specific initialization and cleanup.

The @barba/router plugin adds route-based transition matching with dynamic segments. @barba/prefetch preloads pages on link hover. @barba/head auto-updates <head> tags (title, meta) on navigation.

Key Patterns

• Conditional transitions: Match from/to namespace pairs for different animation styles per route pair.
• Analytics tracking: barba.hooks.after() fires gtag('config', ...) on every navigation.
• Script re-init: Re-run third-party widgets (Twitter, Prism, Facebook) in the after hook.
• Prevent flash: Set gsap.set(next.container, { opacity: 0 }) in beforeEnter to avoid content flash before enter animation.
• Sync positioning: Absolutely position containers during sync transitions to prevent layout shift.

Common Pitfalls

• Not returning promises from leave/enter causes instant transitions with no animation.
• Page title and meta tags do not update without @barba/head or manual hook logic.
• CSS conflicts between namespaces during sync mode; scope styles with [data-barba-namespace="x"].
• Event listeners not cleaned up in beforeLeave cause memory leaks in SPAs.

Blender Web Pipeline

Former page: wiki/skills/blender-web-pipeline.md. Runtime source: skills/misc/blender-web-pipeline/SKILL.md

Blender Web Pipeline

Workflows for exporting Blender 3D models and animations to web-optimized glTF 2.0 format via Python scripting, Draco compression, and batch automation.

The skill covers the full pipeline from Blender scene to browser: exporting via bpy.ops.export_scene.gltf(), optimizing geometry with the Decimate modifier, baking textures to single atlases, generating LOD chains, and compressing with Draco. The primary output format is GLB (single binary file) for web delivery.

Target metrics for web-ready assets: file size under 5MB (ideally under 1MB), polygon count under 50K triangles, textures at 1024x1024 (max 2048x2048), and load time under 2 seconds. Draco mesh compression at level 6 with position quantization at 14 bits typically achieves 60-90% geometry size reduction.

Batch processing runs via blender --background --python script.py -- /input /output. Scripts iterate .blend files, open each headless, apply modifiers, decimate, and export. Texture optimization downscales images and exports as JPEG (quality 85) for size or PNG for transparency.

Key Patterns

• Pre-export checklist: Apply all modifiers, merge vertices, triangulate, UV unwrap, use Principled BSDF only, apply transforms (Ctrl+A), orphan cleanup.
• LOD generation: Duplicate object, apply Decimate at ratios [0.75, 0.5, 0.25] for distance-based switching in Three.js/Babylon.
• Material compatibility: Only Principled BSDF maps to glTF PBR. Custom shader nodes do not export. Supported maps: Base Color, Metallic, Roughness, Normal, Emission.
• Three.js loading: GLTFLoader with DRACOLoader.setDecoderPath('/draco/') for compressed models.
• Animation export: Ensure actions are on timeline (not NLA strips only). Use "Bake Actions" for complex rigs before export.

Common Pitfalls

• Materials look different in browser: caused by non-Principled BSDF nodes that do not export.
• Missing textures: images must be saved (not just packed) with relative paths.
• Slow exports: apply modifiers before export instead of exporting non-destructively.
• Large file sizes: enable Draco compression, reduce texture resolution, use JPEG format.

Content Strategy

Former page: wiki/skills/content-strategy.md. Runtime source: skills/personal/content-strategy/SKILL.md

Content Strategy

Complete self-promotion and content strategy covering social media workflows, organic traction plans, content calendars, and a multi-month positioning arc.

Positioning Arc

The progression: "talented builder" (March-April) → "dangerous early engineer with taste" (April-May) → "operator mode" (May-June). Each phase has specific content types and proof requirements.

Current mode: artifact-led operator with taste. The newest public signals are Loop as a shipped agent-skills product and Sigil UI as Kevin's opinionated design language ("building Sigil" in the X bio). Content should treat those as the proof spine: one side shows agent-systems infrastructure, the other shows taste and design-system judgment. Source: X/@kevskgs Loop release and profile snapshot, 2026-05-12

Content Calendar

March-April: Dev diary + frontend theses (Princeton Tower Defense, custom renderers, architecture posts)

April-May: Design system work (behavior vs aesthetic control, shadcn-killer positioning)

May-June: Operator mode (PMF, agent revenue, conversion, growth loops)

Evergreen execution now lives in Content Backlog. This page sets strategy; the backlog decides what is actually ready to post. Drafts in the wiki are not shipped until Kevin posts them. Source: Content Backlog, 2026-05-12

Weekly Rhythm

• 5 X posts (3 build logs, 1 take, 1 trend reaction)
• 2 LinkedIn posts (narrative, credibility-building)
• 2-3 Reddit posts (project showcases, technical breakdowns, community participation)
• 15-20 meaningful replies across all platforms
• 5 DMs to people whose work connects
• 1 artifact/diagram per week (screenshot, architecture sketch, code snippet)

Reddit Distribution

Reddit is a project-specific channel. Each project maps to target subreddits where the community already cares about the topic. Reddit rewards community participation over self-promotion - follow the 90/10 rule (90% community engagement, 10% your own posts). Screenshots/GIFs are mandatory; text-only project posts get downvoted.

Reddit-specific rules:

• PTD has the easiest on-ramp: r/KingdomRush, r/TowerDefense, and r/playmygame explicitly welcome "look what I made" posts.
• Loop and Sigil UI need thesis posts ("here's the problem I'm solving"), not launch posts ("check out my app").
• Every Reddit post needs a visual: gameplay GIF, component demo screenshot, architecture diagram.
• Engage in target subs for 1-2 weeks before posting your own projects. Comment helpfully on others' posts first.

Algorithm-aware posting (X, May 2026 update)

X open-sourced its current For You algorithm (X For You Algorithm (2026 Open Source)): a Grok transformer ranks by a weighted sum of predicted actions, and a VLM assigns a slop_score that throttles AI-generated-looking content (Algorithmic Slop Throttling (Posting for the X Algorithm)). When drafting or scheduling X posts, apply that checklist: de-slop via Security and Review Skills (the same pass now doubles as reach optimization), optimize for replies/dwell/reposts (not just likes), avoid block/mute/report bait (scored negatively), and lead with an artifact. Follower count no longer carries ranking weight — reach is earned per-post. Source: xai-org/x-algorithm README, 2026-05-15

Integration

This page provides the strategic layer. Social Content OS provides the operating system for managing the backlog. Security and Review Skills handles the actual post writing. The three pages form a complete pipeline: strategy → planning → execution.

The Content Pipeline Workflow automation runs daily to analyze LinkedIn/X performance, identify content gaps, and generate recommendations aligned with this strategy. The Career Profile page ensures content also serves recruiter visibility goals - technical posts that demonstrate skills matching target roles get priority.

For launch / announcement posts specifically, see Launch Post Playbook — the 7-beat anatomy and two archetypes (honest-pivot+product vs origin-myth/ethos) distilled from high-performing YC founder launches, to apply when announcing a product, milestone, or new chapter.

Emil Design Engineering

Former page: wiki/skills/emil-design-eng.md. Runtime source: skills/engineering/design-engineering-polish/SKILL.md

Emil Design Engineering

Emil Kowalski's design engineering philosophy. Covers animation decisions, component polish, spring physics, gesture design, performance rules, and the review checklist that makes software feel right. From the creator of Sonner (13M+ npm/week) and Vaul. Skill: skills/engineering/design-engineering-polish/. Course: animations.dev.

When to Use

• Reviewing animation code (easing, duration, transform-origin, stagger)
• Building interactive components (buttons, tooltips, popovers, drawers, toasts)
• Debugging janky animations (Framer Motion GPU, CSS variable inheritance, keyframe restart)
• Deciding whether something should animate at all (frequency-based decision framework)
• Spring animation design (drag gestures, momentum, interruptibility)
• Performance-sensitive animation (WAAPI, CSS vs JS, hardware acceleration)

Key Concepts

Animation Decision Framework: frequency -> purpose -> easing -> duration. If > 100x/day, no animation. If entering viewport, ease-out. If UI element, under 300ms.

Custom easing curves: built-in CSS easings lack punch. Use cubic-bezier(0.23, 1, 0.32, 1) for ease-out, cubic-bezier(0.77, 0, 0.175, 1) for ease-in-out.

Framer Motion GPU caveat: x/y/scale props use requestAnimationFrame (main thread). Use transform: "translateX()" for actual hardware acceleration.

CSS transitions over keyframes: transitions are interruptible and retargetable. Keyframes restart from zero. Use transitions for anything triggered rapidly (toasts, toggles).

Sonner Principles: no hooks, no context, no setup. Good defaults > options. Handle edge cases invisibly. Match motion to mood.

Review Checklist (from skill)

Notable References

• 2026-06-24 | Emil noted that /emil-design-eng had crossed 100K installs and argued that design-engineering skills remain underexplored. Students of animations.dev should expect an updated AI section in August. This supports keeping design-engineering-polish above generic design-review skills in routing. Source: X/@emilkowalski, 2026-06-24
• 2026-05-15 | Emil shared "The OG frontend skill file", Frontend Guidelines (Bendc) (bendc/frontend-guidelines), a foundational frontend principles repo. 2,018 likes, 2,876 bookmarks. Emil positioning it as a predecessor to current agent skill files. Source: X/@emilkowalski, 2026-05-15
• 2026-06-01 | Dedicated wiki tool page created for Frontend Guidelines (Bendc) from enriched bookmark absorption. Source: enrichment pipeline, 2026-06-01

Frontend Design

Former page: wiki/skills/frontend-design.md. Runtime source: skills/engineering/frontend-design/SKILL.md, skills/engineering/claude-frontend-design/SKILL.md

Frontend Design

Distinctive, production-grade frontend interfaces that reject generic AI aesthetics. Based on anthropics/skills (259K weekly installs).

Design Thinking (Before Coding)

Commit to a BOLD aesthetic direction:

• Purpose: What problem does this interface solve? Who uses it?
• Tone: Pick an extreme - brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian
• Differentiation: What makes this UNFORGETTABLE?

The key is intentionality, not intensity. Bold maximalism and refined minimalism both work.

Five Pillars

1. Typography - distinctive, characterful choices. Pair a display font with a refined body font. Never Inter, Roboto, Arial, system fonts.
2. Color & Theme - cohesive aesthetic via CSS variables. Dominant colors with sharp accents > timid, evenly-distributed palettes.
3. Motion - one well-orchestrated page load with staggered reveals > scattered micro-interactions. Scroll-triggering and hover states that surprise.
4. Spatial Composition - unexpected layouts. Asymmetry, overlap, diagonal flow, grid-breaking. Generous negative space OR controlled density.
5. Backgrounds & Visual Details - gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, grain overlays.

NEVER

• Overused font families (Inter, Roboto, Arial)
• Cliched color schemes (purple gradients on white)
• Predictable layouts and component patterns
• Cookie-cutter design that lacks context-specific character

No design should be the same. Vary light/dark, fonts, aesthetics. NEVER converge on common choices across generations.

Match implementation complexity to the aesthetic vision. Maximalist needs elaborate code. Minimalist needs restraint, precision, and careful attention to spacing, typography, and subtle details.

Frontend Design Taste Guide

Former page: wiki/skills/frontend-design-taste.md. Runtime source: skills/engineering/frontend-design-taste/SKILL.md

Frontend Design Taste Guide

A framework for building distinctive frontends that avoid the generic "vibecoded" look. Incorporates tasteskill.dev anti-slop framework. Core thesis: LLMs default to the center of their training data. You must provide hard constraints, not just better prompts.

Kevin's local version is an adaptation layer: use the upstream taste framework for anti-slop constraints, then route to local design-system pages and executable frontend skills. Source: skills/engineering/frontend-design-taste/SKILL.md; https://www.tasteskill.dev/

The Problem with Default AI UI

Vibecoded frontends look the same because LLMs choose the safest, most-seen patterns: Inter font, generic card grids, blue accent, minimal animation. The fix is not better prompting alone - it's providing a real design system with tokens, linter enforcement, variance dials, banned patterns, and explicit creative direction.

The Vocabulary Bottleneck

From @itsandrewgao (27.5K bookmarks, 1.8M views): "you can instantly 10x your vibecoded frontends by just learning what different ui components are called. ofc opus is creating generic slop, the only words you know are menu and button."

The agent generates generic UI because the user prompts with generic vocabulary. When you say "menu" the LLM picks the safest interpretation. When you say "command palette" or "combobox" or "disclosure" or "popover" or "drawer" or "sheet" or "toast" or "accordion" or "data table with column pinning" - the output jumps in specificity and quality.

Reference: Spotted in Prod - iOS pattern gallery categorized by interaction type.

Variance Dials

Three numbers from tasteskill.dev that drive all downstream decisions:

Adapt dynamically: "make it airy" → DENSITY 2; "dashboard" → DENSITY 7-8; "cinematic" → MOTION 8-9.

Five Archetypes

1. Premium AI B2B: confident, expensive, quiet. Warm white or carbon base, one deep accent. Strong sans + mono labels. Subtle reveals.
2. Editorial Devtool: intelligent, technical, fast. Paper or off-black, one electrical accent. Sharp grotesk + mono. Layout reveals, crossfades.
3. Architectural Blueprint: schematic, exacting. Off-white, deep ink, cobalt/cyan. Precise sans + mono annotations. Line draws, panel reveals.
4. Cinematic 3D: immersive, atmospheric, slower. Shadow-heavy neutrals. Camera drift, pointer parallax, idle loops.
5. Neo-Brutalist: blunt, memorable, anti-corporate. Black/white + one aggressive accent. Abrupt transitions, no syrupy easing.

Style Variables to Lock

Banned Patterns

Full list in Taste Enforcement - Anti-Slop Frontend Rules. Key items:

• Centered hero + blur blobs (VARIANCE > 4)
• 3 equal cards in a row
• Inter / Roboto / Open Sans as primary
• h-screen (use min-h-[100dvh])
• Pure #000000, neon glows, excessive gradient text
• "John Doe", "Acme Corp", 99.99%, lorem ipsum
• AI clichés: "Elevate", "Smooth", "Unleash", "Next-Gen", "Examine"
• Emojis in code or content
• Unsplash links, generic Lucide icons, uncustomized shadcn

Required UI States

Every interactive component: loading (skeletal), empty (with guidance), error (inline), active/pressed (tactile feedback), hover (meaningful change).

Creative Arsenal

Heroes (asymmetric, split-screen, curtain reveal, text mask), navigation (dock magnification, magnetic buttons, dynamic island, mega menu), layout (bento, masonry, split-screen scroll, horizontal hijack), cards (parallax tilt, spotlight border, holographic foil, morphing modal), scroll (sticky stack, zoom parallax, progress path), typography (kinetic marquee, text scramble, circular path), micro-interactions (particle explosion, shimmer, directional hover, ripple click, SVG line draw, mesh gradient).

Performance Guardrails

• Hardware acceleration only (transform + opacity)
• Perpetual animations in React.memo leaf components
• IntersectionObserver over scroll listeners
• Never mix GSAP/Three.js with Motion in same tree
• useEffect cleanup on every animation

Pro Tips

• Build a real design system with tokens + linter enforcement before generating UI
• Ban default fonts - require deliberate type choices
• Encourage bold agent decisions by framing the brief aggressively
• Provide screenshots and reference URLs, not just text descriptions
• Use precise component names in prompts

Moodboard Sources

Curated Resource Index

Component galleries: component.gallery, fancycomponents.dev, uiverse.io, aceternity.com/components

Font sources & foundries: Type Foundries Reference (Klim, ABC Dinamo, Grilli, Pangram; libre via Velvetyne/Open Foundry) and Fonts — Picks & Free (Google Fonts + free picks); browse via Arcotype Font Browser

Agency references: Design Agencies Reference - basement.studio, heykuba.com, kreos.agency, darkroom.engineering (Lenis), lusion.co. (Section galleries like supahero.io are inspiration sites, not agencies → Niche UI Inspiration Galleries.)

Animation libraries: Frontend and Design Skills, Frontend and Design Skills, Frontend and Design Skills, Frontend and Design Skills

Where This Is Enforced

• Sigil UI: .cursor/rules/taste-enforcement.mdc (cross-referenced from sigil-design-system.mdc)
• Dedalus: .cursor/rules/taste-enforcement.mdc
• Cursor skill: ~/.cursor/skills/frontend-design-taste/SKILL.md
• Wiki: Taste Enforcement - Anti-Slop Frontend Rules (design page with full reference)
• Source: github.com/Leonxlnx/taste-skill

Frontend Frontier

Former page: wiki/skills/frontend-frontier.md. Runtime source: skills/engineering/frontend-frontier/SKILL.md

Frontend Frontier

Opinionated frontend skill for building distinctive, high-signal UI with strong art direction, motion design, 3D/shader effects, and tokenized design systems that avoid generic AI aesthetics.

Workflow

The skill enforces a deliberate design process before writing code. The eleven-step workflow: (1) lock art direction by choosing a primary mode (editorial technical, cinematic 3D, architectural blueprint, neo-brutalist, experimental lab, premium AI SaaS), (2) choose discovery/system/evaluation methodologies, (3) build the token system (color, spacing, radii, shadows, type scale, motion tokens), (4) select the frontier runtime stack, (5) choose tactic families, (6) route to specialized skills, (7) decide the motion stack, (8) use references intentionally, (9) apply prompt recipes, (10) run the micro-polish pass, (11) run the trust/infra checklist.

Runtime Stack

Default stack: Tailwind v4 @theme + CSS variables for tokens, Motion for component animation, GSAP + ScrollTrigger for scroll choreography, Lenis for synchronized scroll, React Three Fiber + drei for 3D, OGL or raw shaders for shader-first microsites. CSS is treated as substrate (tokens, layout, fallbacks), not the primary animation architecture.

Non-Negotiables

Non-negotiables: one strong hero move beats ten moving things, 3D presence means quieter surrounding UI, typography-as-star means reduced ornament, motion that hurts comprehension gets cut, and performance must be profiled before adding complexity. The skill ships with reference documents covering aesthetic systems, design methodology, frontier stack defaults, tactics atlas, motion/3D playbook, micro-polish checklist, and infra/trust verification.

Grill with Docs (Skill)

Former page: wiki/skills/grill-with-docs.md. Runtime source: skills/engineering/grill-with-docs/SKILL.md

Grill with Docs (Skill)

Kevin's fork of Matt Pocock's grill-with-docs, evolved into a two-stage pre-PRD alignment skill: first map the shape of the design tree (breadth), then walk the load-bearing branches (depth) with escalating prototype fidelity — capturing decisions into CONTEXT.md (ubiquitous language) and ADRs inline. Lives at skills/engineering/grill-with-docs/.

What it does

The pre-PRD phase of the 7-phase pipeline. It exists because the original skill went straight to depth-first decision-walking, so a late branch could invalidate decisions already settled. The fork adds a breadth-first pass.

Files

• SKILL.md — the two-stage flow + domain-awareness/CONTEXT/ADR guidance.
• DESIGN-TREE.md — the breadth-pass format (the local contribution).
• CONTEXT-FORMAT.md, ADR-FORMAT.md — adapted from Pocock (MIT).

When it triggers

Planning or stress-testing a non-trivial app/feature/refactor before a PRD or code: "grill me", "let's think through this", "help me plan X", "what am I missing", "interrogate this idea".

Relationship to other skills

• Feeds to-prd (the load-bearing decisions are settled and cited before the PRD).
• Hands off to prototype when a branch needs higher-fidelity validation.
• Complements Browser Testing Skills (authoring) and overlaps conceptually with the depth-modules thinking in Frontend and Design Skills / Frontend and Design Skills.

GSAP ScrollTrigger

Former page: wiki/skills/gsap-scrolltrigger.md. Runtime source: skills/engineering/gsap-scrolltrigger/SKILL.md

GSAP ScrollTrigger

Industry-leading JavaScript animation platform for high-performance tweens, timelines, and scroll-driven experiences.

Core Concepts

Tweens animate from A to B: gsap.to(), gsap.from(), gsap.fromTo(). Accepts CSS transforms, SVG attributes, and JS object properties with easing.

Timelines orchestrate multiple tweens in sequence or overlap. Use labels and position parameters ("-=1", "+=0.5", absolute time) to control when child tweens start.

ScrollTrigger Fundamentals

Register plugin with gsap.registerPlugin(ScrollTrigger). Key config properties:

• trigger -- DOM element that drives activation
• start / end -- format "[trigger position] [viewport position]" (e.g., "top center", "top 80%", "+=500")
• scrub -- links animation to scrollbar (boolean for direct, number for smoothing delay in seconds)
• toggleActions -- four actions for onEnter | onLeave | onEnterBack | onLeaveBack (play, pause, resume, restart, reset, complete, reverse, none)
• pin -- pins element while scrolling through the trigger range
• markers -- dev-only visual debug markers
• snap -- snap to labels or progress increments

Key Patterns

Fade-in on scroll: gsap.from() with start: "top 80%", scrub: 1, once: true.

Pin element: ScrollTrigger.create({ pin: true, end: "+=500" }).

Horizontal scroll section: animate xPercent: -100 * (sections.length - 1) with pin: true, scrub: 1.

Parallax: different y values with scrub: true, ease: "none" on foreground vs background layers.

Scroll-triggered timeline: attach scrollTrigger to the timeline itself, not individual tweens. Use snap: { snapTo: "labels" } for chaptered narratives.

Batch animations: ScrollTrigger.batch(".box", { onEnter: batch => gsap.to(batch, { opacity: 1, stagger: 0.15 }) }).

Stagger: stagger: 0.1 or stagger: { each: 0.1, from: "center", grid: "auto" }.

Integration Patterns

Three.js: animate camera.position, mesh.rotation, material.opacity directly with GSAP + scroll.

React: use useGSAP hook from @gsap/react with a scope container ref for automatic cleanup.

Locomotive Scroll: use ScrollTrigger.scrollerProxy() to sync custom scroll containers.

Advanced Techniques

Image sequence scrubbing: animate a frame index object tied to scroll, draw frames on canvas with onUpdate.

Conditional animations: ScrollTrigger.matchMedia() for desktop vs mobile variants.

Dynamic values: invalidateOnRefresh: true to recalculate computed values on resize.

Performance

• Animate transform and opacity (GPU accelerated). Avoid width, height (causes reflow).
• Use will-change: transform, opacity CSS.
• Dispose triggers with trigger.kill() or ScrollTrigger.getAll().forEach(t => t.kill()).
• In React, return cleanup from useGSAP.

Common Pitfalls

• Multiple tweens on same element: use fromTo, immediateRender: false, or a timeline.
• Not looping for multiple elements: gsap.utils.toArray() with individual triggers.
• Forgetting gsap.registerPlugin(ScrollTrigger).
• Nested ScrollTriggers on individual tweens inside a timeline: put ScrollTrigger on the parent timeline.

Easing Quick Reference

power1-4.in/out/inOut (subtle to dramatic), elastic.out (bouncy), back.out (overshoot), bounce.out, expo.inOut (dramatic), none (linear, for scrubbed scroll).

GStack Design Review

Former page: wiki/skills/gstack-design-review.md. Runtime source: skills/engineering/gstack-design-review/SKILL.md

GStack Design Review

Rendered-UI design audit with usability tests, design-system extraction, AI Slop scoring, Goodwill Reservoir tracking, and before/after screenshots.

When To Use

Use gstack-design-review when:

• Kevin asks "design review", "UX audit", "visual audit", "how does this site look"
• a page feels generic or confusing
• a frontend needs professional polish before sharing
• the issue is rendered experience, not just code correctness

Use Browser Testing Skills for functional browser bugs. Use Security and Review Skills for source/diff review.

Contract

The skill guarantees:

• Real rendered-page evaluation.
• First-person narration to avoid generic critique.
• Letter grades for design and AI slop.
• Six usability tests per page.
• Design-system extraction from actual pixels.
• Findings sorted by impact.
• Before/after screenshots for fixes.
• One atomic commit per fix when mutating.
• Hard cap of 30 fixes.

Six Phases

1. First impression: screenshot, first-person read, page-area test.
2. Design system extraction: fonts, colors, heading scale, spacing.
3. Page audit: trunk test plus 10-category checklist.
4. Interaction flow review: 2-3 flows with Goodwill Reservoir score.
5. Cross-page consistency: nav, components, tone, spacing rhythm.
6. Report and fix loop: grades, top findings, quick wins, verified fixes.

Scoring Axes

AI slop checks include decorative blobs, generic hero copy, 3-column feature grids, colored icon circles, centered everything, purple gradients, uniform bubbly radius, emoji-as-design, colored left-border cards, and cookie-cutter section rhythm.

Proof Standard

A design finding without a screenshot is weak. A design fix without an after screenshot is unfinished. Source code can look correct while the actual UI is doing performance art in a haunted layout engine.

Source

Executable source: skills/engineering/gstack-design-review/SKILL.md.

Import Spinner Frames

Former page: wiki/skills/import-spinner-frames.md. Runtime source: skills/engineering/import-spinner-frames/SKILL.md

Import Spinner Frames

Extract animation frame data from upstream Unicode spinner libraries into the wiki's runtime-agnostic spinners-catalog.json. Never swap unicode-animations; extend the catalog instead.

When to Use

• Kevin shares a spinner repo URL and asks "should I swap?" or "do a 1v1"
• Kevin says "import the spinners from X" or "add these frames"
• A new spinner library surfaces via signal-radar or general browsing
• The loading-screens catalog needs fresh palette variety

The Rule

unicode-animations is the canonical npm-installable library - framework-agnostic, 18 braille spinners. Do not replace it. Upstream libraries contribute frame data into wiki/assets/spinners-catalog.json, which any project can consume alongside the canonical library.

This matters because most spinner libraries are wrong-runtime (React Native, CLI-only, shader-based) for Kevin's Next.js web stack. Extracting the data side-steps the dependency question entirely.

Flow

1. 1v1 evaluation - runtime, distribution, variety, frame format, license, stars. Present as a table in chat before any clone.
2. Shallow clone to /tmp - never commit the upstream.
3. Locate frame files - usually one file per spinner with const FRAMES = [...]
   • const INTERVAL = N. If it's a single catalog file, read + JSON stringify instead.
4. Run the extractor at scripts/extract-frames.mjs. Merges into existing catalog; upstream names win on conflict.
5. Verify - counts per category, render a sample to terminal, check for mojibake.
6. Update wiki/design/loading-screens.md - new category tags, updated counts, highlights tables, attribution. Do not duplicate every frame in markdown; the JSON is source of truth.
7. Log to wiki/log.md - what was extracted, why the library swap was rejected, attribution + license.

Component API

Extractor:

node skills/engineering/import-spinner-frames/scripts/extract-frames.mjs \
  --src /tmp/<repo>/src/components/spinners \
  --out ~/Documents/GitHub/kevin-wiki/wiki/assets/spinners-catalog.json \
  --source-url <repo-url> \
  --license MIT \
  --attribution "frames derived from <owner>/<repo>" \
  --categories /tmp/categories.json

Output entry shape: { category, frames, interval }. The catalog top-level carries source, license, attribution, extracted, and count.

Anti-Patterns

• Adopting the upstream library as a dependency - almost never correct
• Letting a new library redefine the default (stays unicode-animations)
• Committing the /tmp clone
• Hand-typing frame arrays (Unicode silently breaks; use the extractor)
• Skipping the 1v1 - if the conclusion would have been "adopt instead," this skill doesn't apply

First use

Created 2026-04-21 from the expo-agent-spinners import. 55 spinners landed (32 braille / 15 ASCII / 2 arrow / 6 emoji). See timeline in Frontend and Design Skills and wiki/log.md entry [2026-04-21] asset-add | spinner catalog from expo-agent-spinners.

Resources

• Canonical library: unicode-animations
• Custom spinner designer: dab
• Catalog file: wiki/assets/spinners-catalog.json
• Design doc: Frontend and Design Skills (design)
• Skill consumer doc: Frontend and Design Skills (skill)

Improve

Former page: wiki/skills/improve.md. Runtime source: skills/engineering/improve/SKILL.md

Improve

An agent skill (by shadcn) that audits any codebase and writes self-contained implementation plans for other, cheaper agents to execute. The reference implementation of Borrowed Intelligence (Drain It into Plans). The plan is the product; the skill never edits source itself. Executable source: skills/engineering/improve/SKILL.md. Source: github.com/shadcn/improve, 2026-06-13

you          ->  /improve                 (expensive model, advises)
plans/       ->  001-fix-n-plus-one.md     (self-contained specs)
other agent  ->  implements, tests, ships  (cheap model, executes)

Status

Installed at skills/engineering/improve/SKILL.md (SKILL.md + references/), live in Cursor via the ~/.cursor/skills symlink, on 2026-06-13 at Kevin's explicit request. Brin gate waived per standing policy: when Kevin names a tool, install it; the in-house skill-auditor + NVIDIA SkillSpector are the preferred deeper checks. License MIT.

Commands

How it works

Recon - maps stack, conventions, exact build/test/lint commands (these become verification gates), and ingests intent docs (ADRs, PRD, CONTEXT.md, DESIGN.md) so decided tradeoffs are not re-flagged. Audit - parallel subagents across nine categories (correctness, security, perf, tests, tech debt, deps/migrations, DX, docs, direction); every finding cites file:line evidence, impact, effort, confidence. Vet - the advisor re-reads each cited location to drop false positives. Prioritize - findings ranked by impact (impact / effort x confidence). Plan - one self-contained spec per selected finding into plans/ with an index, order, and dependency graph.

Hard rules (why it is safe)

• Never modifies source itself - the only writes go to plans/; executors edit only in disposable worktrees; merging is always yours.
• Never runs commands that mutate the working tree - read-only analysis.
• Never reproduces secret values - locations and credential types only.
• Asked to implement, it declines and points at the plan (or execute).

Fit in Kevin's stack

improve = the audit+plan (expensive) phase of Borrowed Intelligence (Drain It into Plans); Browser Testing Skills = the execute+ship (cheap) phase; Browser Testing Skills = a first-run-UX audit lens that produces plan candidates. Plans bank in the repo-root plans/ catalog (plans/README.md).

Lightweight 3D Effects

Former page: wiki/skills/lightweight-3d-effects.md. Runtime source: skills/engineering/lightweight-3d-effects/SKILL.md

Lightweight 3D Effects

Three small libraries for decorative 3D visuals without heavy frameworks: Zdog (pseudo-3D illustrations), Vanta.js (animated WebGL backgrounds), and Vanilla-Tilt.js (parallax card effects).

Zdog (~28KB) renders flat, round vector shapes in pseudo-3D space using Canvas or SVG. Its declarative API (new Zdog.Ellipse({ addTo, diameter, stroke, color })) builds illustrations from shapes and groups with built-in drag rotation. Animation runs via requestAnimationFrame calling illo.updateRenderGraph(). Best for: decorative icons, logo animations, small interactive illustrations.

Vanta.js (~120KB with Three.js) provides 14+ animated background effects (Waves, Birds, Net, Clouds, Fog, Cells, Globe, etc.). Initialize with VANTA.WAVES({ el, color: 0x23153c, waveHeight: 15 }). Colors use hex numbers (not strings). Supports mouse and touch interaction. Each effect accepts customization options for speed, density, and color. Always call .destroy() on unmount in SPAs.

Vanilla-Tilt.js (~8.5KB, zero dependencies) adds smooth 3D tilt effects on mouse hover with optional glare overlay. Configure via data-tilt attributes or VanillaTilt.init(element, { max: 25, glare: true }). Use transform-style: preserve-3d with translateZ() layers for depth separation. Supports gyroscope input on mobile.

Key Patterns

• Hero section: Vanta background + z-indexed content overlay.
• Card gallery: Vanilla-Tilt with glare on product/service cards using layered translateZ for depth.
• Combined effect: Vanta.NET background + Vanilla-Tilt service cards in one section.
• Mobile fallback: Detect mobile and use CSS gradient instead of Vanta to preserve performance.
• Intersection Observer: Lazy-initialize Vanta effects only when sections scroll into view.

Common Pitfalls

• Multiple Vanta instances degrade performance; limit to one per page or lazy-load per section.
• Vanta colors must be hex numbers (0x23153c), not strings ("#23153c").
• Zdog canvas blank: forgot to call illo.updateRenderGraph() or canvas has zero dimensions.
• Memory leaks: always destroy Vanta and Vanilla-Tilt instances on component unmount.

Locomotive Scroll

Former page: wiki/skills/locomotive-scroll.md. Runtime source: skills/engineering/locomotive-scroll/SKILL.md

Locomotive Scroll

Smooth scrolling library with hardware-accelerated lerp, element-level parallax speeds, viewport detection, sticky positioning, and GSAP ScrollTrigger integration.

Locomotive Scroll transforms native scrolling into a smooth, lerp-based experience. The DOM requires data-scroll-container as root, optional data-scroll-section segments for performance, and data-scroll on tracked elements. Parallax is controlled per-element with data-scroll-speed (negative values reverse direction). Initialize with new LocomotiveScroll({ el, smooth: true, lerp: 0.1 }).

Elements receive the is-inview class when visible. The scroll event provides current position, speed, direction, and per-element progress (0 to 1). The call event fires when elements with data-scroll-call enter or exit the viewport. Sticky elements use data-scroll-sticky with data-scroll-target to define boundaries. Horizontal scrolling is supported via direction: 'horizontal'.

GSAP ScrollTrigger integration requires a ScrollTrigger.scrollerProxy() that maps to Locomotive's scroll instance. Sync updates with locoScroll.on('scroll', ScrollTrigger.update) and refresh on Locomotive updates.

Key Patterns

• Section segmentation: Wrap content in data-scroll-section divs to improve render performance on long pages.
• Programmatic scroll: scroll.scrollTo('#target', { offset: -100, duration: 1000, easing: [0.25, 0, 0.35, 1] }).
• Mobile disable: smartphone: { smooth: false } to preserve native touch scrolling on low-end devices.
• Accessibility: Disable smooth scroll when prefers-reduced-motion: reduce matches.
• Dynamic content: Call scroll.update() after any DOM mutation that changes element positions.

Common Pitfalls

• position: fixed breaks inside the scroll container. Place fixed elements outside the container or use data-scroll-sticky.
• Z-index conflicts between parallax layers; set explicit z-index with CSS custom properties.
• Memory leaks in SPAs: always call scroll.destroy() on route change or component unmount.
• Images not lazy-loading: integrate with Intersection Observer or use data-scroll-call for trigger.

Loop Me

Former page: wiki/skills/loop-me.md. Runtime source: skills/productivity/loop-me/SKILL.md

Loop Me

Executable personal skill for interviewing Kevin about recurring day-to-day work and turning it into agent-delegable workflow specs.

loop-me is Kevin's local adaptation of Matt Pocock's in-progress /loop-me skill. The upstream skill interviews the user about work loops and writes specs for workflows that agents can build. Kevin's version routes the output into the wiki/workflow system and keeps the no-one-off rule explicit: recurring work should become a spec, then a skill or automation when it proves useful. Source: Matt Pocock skill, 2026-06-24; local skill, 2026-06-25

The updated local version preserves Pocock's core loop vocabulary: a loop is a recurring pattern in life or work; a workflow is the spec that makes that loop delegable; a trigger is either an event or schedule; a checkpoint is a human decision point; push right means do maximal useful work before asking Kevin; and a brief is the decision-ready checkpoint artifact, not a raw dump. Source: upstream loop-me/SKILL.md, commit 8370e760d0251a3738e006aeacec6d1cb31dd208

When To Use

Use loop-me when Kevin asks:

• /loop-me
• "loop me"
• "what should I automate?"
• "find work to delegate to AI"
• "what day-to-day work can agents take over?"
• "turn my repeated work into workflows"

It is for recurring operational loops, not product feature planning. Use Frontend and Design Skills for a feature/refactor/product design interrogation.

What It Produces

The skill writes candidate workflow specs with:

• trigger
• current manual path
• agent-delegable path
• inputs and tools
• approval checkpoints
• output artifact
• acceptance criteria
• failure modes
• first implementation brief

In kevin-wiki, candidate specs land under wiki/inbox/loop-specs/ unless Kevin asks to promote them. In app repos, repo-owned loops can live under workflows/.

Raw workspace observations can land in NOTES.md when the agent needs to learn Kevin's or a project's world before it can write a useful workflow. Source: upstream loop-me/SKILL.md, 2026-06-25

Why It Matters

This closes a gap between Kevin's No One-Off Work philosophy and actual day-to-day delegation. The wiki already says repeated work should become infrastructure. loop-me is the interview mechanism that discovers those repetitions before Kevin has to ask twice. It also complements Loop Library: Loop Library is a catalog of external loop templates; loop-me extracts Kevin-specific loops.

Upstream Notes

The upstream mattpocock/skills@loop-me entry was visible in npx skills add mattpocock/skills --list --full-depth on 2026-06-25 and appeared in skills.sh search with about 1.9K installs. The upstream frontmatter described it as: "Grill me about specs for the workflows I want to build, within this workspace." Source: npx skills find "loop me", 2026-06-25

Lottie Animations

Former page: wiki/skills/lottie-animations.md. Runtime source: skills/engineering/lottie-animations/SKILL.md

Lottie Animations

After Effects animations rendered in real-time on web. Designers ship animations as easily as static assets. Vector-based, scalable, smaller than GIF/video, editable at runtime.

Format Types

JSON Lottie (.json): original format, human-readable, larger files, widely supported. dotLottie (.lottie): modern compressed format (ZIP), up to 90% smaller, supports multiple animations and themes. Recommended for production.

Library Options

lottie-web: original library, SVG/canvas/HTML renderers. @lottiefiles/dotlottie-web: modern canvas-based, recommended. @lottiefiles/dotlottie-react: React integration with <DotLottieReact>. lottie-react: alternative React wrapper with <Lottie> and interactivity hooks.

Key Patterns

Basic React: <DotLottieReact src="animation.lottie" loop autoplay />.

Playback control: get ref via dotLottieRefCallback, then call play(), pause(), stop(), setFrame(n).

Event listeners: load, play, pause, complete, frame. Always clean up in useEffect return.

Scroll-driven: use lottie-react interactivity with mode: 'scroll' and actions array specifying visibility ranges, frame segments, and behavior (stop, seek, loop).

Hover-triggered segments: useLottieInteractivity with mode: 'cursor' and position-based actions.

Multi-animation/themes: dotLottie format supports multiple animations and themes in one file, switchable at runtime via animationId and themeId.

Web Worker: DotLottieWorker offloads rendering to a web worker for heavy animations. Group by workerId.

Integration

GSAP ScrollTrigger: sync Lottie playhead with scroll via onUpdate: self => anim.goToAndStop(Math.floor(self.progress * totalFrames), true).

Motion: wrap <DotLottieReact> in <motion.div> for entrance/layout animations around the Lottie.

Performance

File size: simplify After Effects composition, enable "skip unused images", use shape layers over vector layers, use dotLottie format, run through Lottie optimizer.

Runtime: canvas renderer faster than SVG for complex animations. Web workers for heavy animations. Lower devicePixelRatio on mobile. Lazy load via IntersectionObserver.

Common Pitfalls

• Memory leaks: always dotLottie.destroy() on unmount.
• Event listener cleanup: remove all listeners in useEffect return.
• Large file sizes: check Bodymovin export settings, simplify composition.
• Performance stutter: switch to canvas renderer, use DotLottieWorker.
• CORS issues: use animationData import for bundled apps, or ensure CORS headers for URLs.
• Unsupported After Effects features: layer effects (use shapes instead), blending modes, 3D layers, most expressions. Test exports early and often.

Make Interfaces Feel Better

Former page: wiki/skills/make-interfaces-feel-better.md. Runtime source: skills/engineering/make-interfaces-feel-better/SKILL.md, skills/engineering/dedalus-make-interfaces-feel-better/SKILL.md

Make Interfaces Feel Better

A collection of small details that compound into a great experience.

Great interfaces rarely come from a single thing. Apply these principles when building or reviewing UI code. Triggers on UI polish, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers.

Typography

text-wrap: balance distributes text evenly across lines, preventing orphaned words on headings. Works on blocks of 6 lines or fewer (Chromium) or 10 (Firefox). Use for headings and titles. Tailwind: text-balance.

text-wrap: pretty optimizes the last line to avoid orphans on longer text. Use for body paragraphs.

Font smoothing: Apply -webkit-font-smoothing: antialiased to the root layout on macOS. Text renders heavier than intended by default. Safe to apply universally (other platforms ignore it).

Tabular numbers: font-variant-numeric: tabular-nums for dynamically updating numbers (counters, prices, timers, table columns). Prevents layout shift as values change.

Surfaces

Concentric border radius: outerRadius = innerRadius + padding. Mismatched radii on nested elements is the most common thing that makes interfaces feel off. If padding exceeds 24px, treat layers as separate surfaces.

Optical over geometric alignment: When geometric centering looks off, adjust optically. Buttons with icons, play triangles, and asymmetric icons all need manual adjustment.

Shadows over borders: Layer multiple transparent box-shadow values for natural depth. Shadows adapt to any background; solid borders do not. For images, add a subtle 1px outline with low opacity for consistent depth.

Minimum hit area: Interactive elements need at least 40x40px. Extend with a pseudo-element if the visible element is smaller.

Animations

Interruptible animations: Use CSS transitions for interactive state changes (can be interrupted mid-animation). Reserve keyframes for staged sequences that run once.

Split and stagger enter animations: Break content into semantic chunks (title, description, buttons). Stagger each with ~100ms delay. Combine opacity, blur, and translateY.

Subtle exit animations: Use a small fixed translateY (-12px) instead of full height. Exits should be softer than enters: 150ms vs 300ms.

Contextual icon animations: Animate with opacity, scale(0.25 -> 1), and blur(4px -> 0px). With Motion: { type: "spring", duration: 0.3, bounce: 0 } (bounce must be 0). Without Motion: keep both icons in DOM and cross-fade with CSS transitions.

Scale on press: scale(0.96) on click. Never below 0.95. Add a static prop to disable when distracting.

Skip animation on page load: initial={false} on AnimatePresence prevents enter animations on first render.

Performance

Never use transition: all: Specify exact properties. Tailwind's transition-transform covers transform, translate, scale, rotate.

Use will-change sparingly: Only for transform, opacity, filter. Never will-change: all. Only add when you notice first-frame stutter.

Review Checklist

Nested rounded elements use concentric radius. Icons optically centered. Shadows instead of borders where appropriate. Enter animations split and staggered. Dynamic numbers use tabular-nums. Font smoothing applied. Headings use text-wrap: balance. Images have subtle outlines. Buttons scale on press. No transition: all. Interactive elements have 40x40px hit area.

Source & Adoption

Authored by Jakub Krehel (jakub.kr), distilled from his article "Details that make interfaces feel better". Installable via npx skills add jakubkrehel/make-interfaces-feel-better. As of 2026-06-21 the skill had 30,000+ installs — one of the most-adopted frontend-polish skills in the ecosystem, validating its place in Kevin's design-engineering stack alongside design-engineering-polish. Source: X/@jakubkrehel, 2026-06-21

Mintlify MDX

Former page: wiki/skills/mintlify-mdx.md. Runtime source: skills/personal/mintlify-mdx/SKILL.md

Mintlify MDX

Reverse-engineered knowledge of Mintlify's MDX pipeline, its undocumented sandbox constraints, and how Dedalus extends it for docs.dedaluslabs.ai and docs-internal.dedaluslabs.ai.

Mintlify is a Next.js App Router site that compiles MDX on the server, hydrates in the browser, and serves via Next. The pipeline runs @mdx-js/mdx + acorn → remarkMdxInjectSnippets (inlines /snippets/*.jsx ASTs) → estree-util-to-js (findExport extracts each export in isolation) → next-mdx-remote-client/serialize (function-body mode) → Reflect.construct → component tree → SSR → hydrate. Source: User, 2026-04-28

Key Constraints

Seven hard rules the docs don't mention: Source: User, 2026-04-28

1. Each named export evaluated in isolation - sibling imports/consts/exports are dropped. One self-contained IIFE per export.
2. import expressions rejected - function-body mode refuses import(), import.meta.url, export ... from.
3. Snippets cannot import other snippets - no recursive resolution. Colocate dependent code.
4. Only react/react-dom imports resolve - bundle everything else via yoink.ts.
5. Non-exported module-level declarations stripped - move constants inside the exported arrow.
6. Arrow functions only at module scope - function keyword unsupported.
7. Global !important font rules beat docs.json - override with equal+ specificity.

Tooling

• scripts/yoink.ts - bundles npm packages into self-contained IIFE snippets via esbuild
• scripts/lint-snippets.ts - catches sandbox violations (no-module-level-decl, no-npm-imports, no-nested-imports, missing-hook-import, no-exports, dom-takeover)
• Client-only mount gate pattern for DOM-takeover libraries (React 19 strict-mode double-mount collision)

Skill Location

~/.cursor/skills/mintlify-mdx/SKILL.md with references/constraints.md for case studies (DCS shell architecture, authenticated SSE, decision reversals).

Modern Web Design

Former page: wiki/skills/modern-web-design.md. Runtime source: skills/engineering/modern-web-design/SKILL.md

Modern Web Design

Performance, accessibility, and meaningful interactions define modern web design (2024-2025). This meta-skill synthesizes animation, 3D, and interaction knowledge into holistic design guidance.

Core Principles

Performance-First Design

LCP < 2.5s, FID < 100ms, CLS < 0.1, INP < 200ms. Defer non-critical animations until after page load. Use CSS transforms/opacity (GPU-accelerated). Lazy load images, videos, and 3D content. Progressive enhancement: core content without JavaScript.

Bold Minimalism

Large fluid typography via clamp(). Ample whitespace. Limited palettes (3-5 primary colors). OKLCH color space for perceptual uniformity. Minimum 7:1 contrast for WCAG AAA.

Micro-Interactions

Small, purposeful animations: hover states (scale 1.05-1.1x, 200-300ms color transitions), loading states (skeletons over spinners, blur-up images, optimistic UI), interactive feedback (button press scale 0.95x, spring-physics toggles, validation motion).

Scrollytelling

Scroll-triggered reveals (fade, slide, clip-path). Scroll-linked animations (parallax, horizontal scroll, pinned sections, 3D rotation tied to scroll). Progress indicators (reading bars, step guides, animated SVG paths).

Cursor UX

Custom cursor shapes (circle followers, text-based, blend modes). Contextual transforms (expand on links, magnetic attraction, color inversion). CSS transforms only, requestAnimationFrame for JS. Disable on touch devices. Respect prefers-reduced-motion.

Glassmorphism and Depth

Frosted glass: backdrop-filter: blur(10px) saturate(180%) with translucent background and subtle border. Elevation scale with consistent shadow progression.

Common Design Patterns

Immersive hero: full viewport, subtle 3D/animated gradient background, fluid headline, scroll indicator. Horizontal scroll gallery: GSAP xPercent with pin and scrub, lazy-loaded images. 3D product viewer: R3F + OrbitControls + Environment preset. Animated data viz: count-up on scroll, staggered chart reveals. Page transitions: Barba.js + GSAP or AnimatePresence, View Transitions API as progressive enhancement. Staggered content reveals: Motion variants with staggerChildren.

Accessibility

Motion

Respect prefers-reduced-motion in both CSS (@media) and JS (window.matchMedia). Simplify animations, do not merely slow them down.

Color Contrast

WCAG AAA: 7:1 normal text, 4.5:1 large text. Test with OKLCH for perceptual uniformity.

Keyboard

All interactive elements focusable. Visible :focus-visible indicators. Logical tab order. Skip links. Escape closes modals.

Screen Readers

Proper heading hierarchy. Landmark regions. aria-labels for icon buttons. aria-live regions for dynamic content.

Touch Targets

Minimum 44x44px (iOS) / 48x48px (Android). 8px spacing between targets.

Performance Optimization

Animation: animate transforms and opacity only. will-change sparingly. force3D: true in GSAP. Apply will-change during animation, remove on complete.

Loading: inline critical CSS, defer non-critical, async JS, preload fonts/hero images.

Images: AVIF > WebP > JPEG fallback. Responsive srcset and sizes. loading="lazy".

3D content: placeholder while loading, low-poly first, LOD, frustum culling, texture compression.

Bundles: dynamic imports, route-based splitting, tree shaking, ES6 imports.

Common Pitfalls

Over-animation: if you cannot explain why an animation exists, remove it. Mobile performance: test on real devices, reduce complexity, disable expensive effects on low-end. Missing fallbacks: progressive enhancement, feature detection, core content without JS. Accessibility oversight: test keyboard-only, screen reader, motion preferences. Loading states: skeletons for predictable layouts, reserve space, no layout shifts. Scroll hijacking: enhance scroll, never replace it. Preserve native momentum and keyboard scroll.

Design System Architecture

Modern tokens via CSS custom properties: OKLCH colors, clamp() fluid spacing and typography, consistent animation durations (--duration-fast: 150ms, --duration-normal: 250ms, --duration-slow: 400ms), natural easing curves. Atomic design: atoms, molecules, organisms, templates, pages.

Motion Framer

Former page: wiki/skills/motion-framer.md. Runtime source: skills/engineering/motion-framer/SKILL.md

Motion Framer

Production-ready animation library for React. Declarative, performant animations with motion components, gesture recognition, layout animations, exit animations, and spring physics.

Core Concepts

Motion components: prefix any HTML/SVG element with motion. to make it animatable. Every motion component accepts animate, initial, transition, whileHover, whileTap, whileDrag, whileInView, exit.

Animate prop: define target state. When values change, Motion auto-animates. Initial: set pre-animation state. initial={false} disables mount animation.

Transitions: type: "tween" (duration-based, default), type: "spring" (physics), type: "inertia" (deceleration for drag). Per-property transitions supported.

Variants: named animation states for cleaner code and parent-child propagation. Use staggerChildren for sequential child animations, staggerDirection: -1 for reverse.

Key Patterns

Hover/tap: whileHover={{ scale: 1.05 }}, whileTap={{ scale: 0.95 }}. Nest variants for parent-child hover coordination.

Drag: drag, drag="x" / drag="y", dragConstraints, dragElastic, whileDrag. Access velocity via onDragEnd info.

Exit animations (AnimatePresence): wrap conditional rendering in <AnimatePresence>. Component must be direct child with unique key and exit prop.

Layout animations: layout prop auto-animates position/size changes. layout="position" for position-only. layoutId for shared-element transitions across different components (tab indicators, thumbnail-to-modal).

Scroll-based: whileInView with viewport={{ once: true, amount: 0.8 }}. Combine with variants for staggered scroll reveals.

Spring animations: type: "spring", tuned via stiffness/damping/mass or simpler visualDuration/bounce. Presets: gentle (100/20), wobbly (200/10), stiff (400/30), slow (50/20).

SVG path morphing: use motion.path and animate the d attribute when path topology is compatible. Apply a transition to the path and keep the effect for small icons, logos, state glyphs, or decorative microinteractions. Do not morph dense diagrams that users need to read. Source: X/@mannupaaji, 2026-06-25

Hooks

useAnimate: imperative control -- const [scope, animate] = useAnimate(). Sequence animations as arrays. Returns controls with play(), pause(), stop(), speed, time.

useSpring: spring-animated motion values. useInView: viewport detection. useReducedMotion: respect prefers-reduced-motion.

Integration

With GSAP: use Motion for hover/tap/layout, GSAP for complex timelines via refs. With R3F: sync Motion values to Three.js positions via useFrame. With forms: animate validation states, shake on error with keyframe arrays.

Performance

• Use transform properties (x, y, scale, rotate) -- GPU accelerated.
• Avoid left, top, width, height animations.
• layout="position" cheaper than full layout.
• Use layoutId sparingly (global tracking).

Common Pitfalls

• Forgetting AnimatePresence for exit animations.
• Missing key prop in animated lists.
• Animating non-transform properties (janky).
• Overusing layout on many elements.
• Not using variants for repeated animation patterns.
• Gesture transitions: put transition inside whileHover for hover-start timing, outer transition controls hover-end.

OKLCH Skill - Perceptually Uniform Color for the Web

Former page: wiki/skills/oklch-skill.md. Runtime source: skills/engineering/oklch-skill/SKILL.md

OKLCH Skill - Perceptually Uniform Color for the Web

Convert hex/rgb/hsl to OKLCH, generate perceptually uniform palettes, check APCA/WCAG contrast, handle sRGB/P3 gamut boundaries, and theme with Tailwind v4 @theme. Interactive explorer at oklch.fyi.

Why OKLCH Over HSL

HSL lies about lightness, drifts hue across a palette ramp, and couples saturation to brightness. OKLCH fixes all three: equal L steps produce equal perceived brightness, hue stays constant across lightness, and chroma is an independent axis. The upstream skill positions OKLCH around conversion, palette generation, contrast checks, and gamut boundaries. Source: jakubkrehel/oklch-skill, accessed 2026-06-25

The tradeoff is gamut awareness - not every oklch(L C H) value fits in sRGB, so high-chroma colors need clamping.

OKLCH Syntax

oklch(L C H)          /* L: 0–1, C: 0–~0.4, H: 0–360 */
oklch(L C H / alpha)  /* alpha: 0–1, slash syntax */

L is perceptual lightness (0 = black, 1 = white). C is chroma / colorfulness (0 = gray). H is hue angle in degrees. Baseline 2023, 96%+ global browser coverage.

Key Thresholds

The hue-drift threshold and L-only contrast repair rule come from the skill's contrast module. Source: oklch-skill accessibility contrast module, accessed 2026-06-25

Palette Generation

Palettes use a 50–950 numeric scale (9-step default matches Tailwind). The algorithm distributes lightness evenly from L=0.95 to L=0.05, then clamps chroma per step to the maximum for that L/H/gamut. Multi-hue palettes use the same L and chroma percentage (not absolute C) across hues - this produces equal perceived vividness despite different hue gamuts. Dark mode reverses the palette mapping.

Gamut and Tailwind v4

sRGB is a subset of Display P3 (~50% fewer colors). Max chroma varies by hue - purple peaks at C≈0.29, cyan bottoms at C≈0.09 at L=0.5. Use @supports (color: oklch(0 0 0)) with @media (color-gamut: p3) for progressive enhancement. Tailwind v4 defines its default palette in OKLCH; custom themes use @theme with --color-brand-* variables.

Skill Modules

PixiJS 2D

Former page: wiki/skills/pixijs-2d.md. Runtime source: skills/misc/pixijs-2d/SKILL.md

PixiJS 2D

High-performance 2D rendering engine using WebGL/WebGPU acceleration, capable of rendering 100,000+ sprites at 60 FPS with particle containers, filters, and sprite sheet animation.

PixiJS initializes with new Application() and await app.init({ width, height, backgroundColor }). The scene graph starts at app.stage; add Sprite, Graphics, Text, and Container objects as children. Textures load via await Assets.load('image.png'). The app.ticker provides the per-frame update loop with delta time.

The Graphics API draws vector shapes: graphics.rect().fill(), graphics.circle().stroke(), custom paths with moveTo/lineTo/bezierCurveTo, star shapes, and holes. SVG paths are supported via graphics.svg().

ParticleContainer is the key performance tool: up to 10x faster than regular Container by declaring which properties are dynamic (position, scale, rotation, color). Use Particle objects instead of Sprite for bulk rendering. Filters (BlurFilter, ColorMatrixFilter, DisplacementFilter) apply per-pixel WebGL shader effects. Set filterArea explicitly to avoid runtime measurement overhead.

Key Patterns

• Interactivity: Set sprite.eventMode = 'static' to enable pointer events (pointerdown, pointerover, etc.).
• Sprite sheet animation: AnimatedSprite from frame textures with animationSpeed and play()/stop() control.
• Object pooling: Pre-create sprites, toggle visible, maintain available/active arrays to avoid GC pressure.
• 3D overlay: Transparent PixiJS canvas (backgroundAlpha: 0) positioned over Three.js for HUD rendering.
• Culling: Set sprite.cullable = true to skip rendering off-screen objects.
• BitmapText: Use for frequently changing text (scores, counters) instead of standard Text which re-renders its texture.

Common Pitfalls

• Memory leaks: always call sprite.destroy({ children: true, texture: true }) and texture.destroy().
• Updating static ParticleContainer properties has no effect unless dynamicProperties includes them.
• Excessive filter usage causes frame drops; limit to 1-2 filters per object and set filterArea.
• Sprite.from('url') loads asynchronously; prefer await Assets.load() then new Sprite(texture).

PlayCanvas Engine

Former page: wiki/skills/playcanvas-engine.md. Runtime source: skills/engineering/playcanvas-engine/SKILL.md

PlayCanvas Engine

Lightweight WebGL/WebGPU game engine with entity-component architecture, visual editor integration, scripting system, and Ammo.js physics support.

PlayCanvas initializes with new pc.Application(canvas), requires app.setCanvasFillMode(pc.FILLMODE_FILL_WINDOW) and app.setCanvasResolution(pc.RESOLUTION_AUTO) for responsive sizing, and starts with app.start(). The update loop fires via app.on('update', (dt) => {}).

The entity-component system works through entity.addComponent(type, options). Core components: model (box, sphere, cylinder, cone, capsule, or loaded asset), camera (perspective or orthographic), light (directional, point, spot with shadow support), rigidbody (static, dynamic, kinematic via Ammo.js), collision (box, sphere, capsule, cylinder, mesh), script (custom behavior), and animation (skeletal playback from GLTF).

Custom scripts use pc.createScript('name') with attributes.add() for editor-exposed properties. Lifecycle methods: initialize, postInitialize, update, postUpdate, swap (hot reload), destroy. Assets load via new pc.Asset(name, type, { url }) with asset.ready() callback and app.assets.load().

Key Patterns

• Object pooling: Pre-create disabled entities, toggle entity.enabled for spawn/despawn without allocation.
• LOD: Switch entity.model.asset based on camera distance thresholds.
• Batching: Set entity.model.batchGroupId and call app.batcher.generate() to reduce draw calls.
• Raycasting: app.systems.rigidbody.raycastFirst(from, to) for mouse picking with physics.
• Input: app.keyboard.isPressed(pc.KEY_W) for continuous, wasPressed for single-frame events. Mouse via pc.EVENT_MOUSEDOWN.
• Tweening: entity.tween(position).to({ y: 2 }, 1.0, pc.SineInOut).start() for property animation.

Common Pitfalls

• Forgetting app.start() after scene setup; nothing renders or updates without it.
• Modifying scene graph during iteration; mark entities for destruction, clean up in postUpdate.
• Asset memory leaks: call app.assets.remove(asset) and asset.unload() when done.
• Physics requires Ammo.js loaded before creating rigidbody/collision components.
• Canvas sizing: always set fill mode and resolution auto, plus a resize listener.

Project Doctor

Former page: wiki/skills/project-doctor.md. Runtime source: skills/productivity/project-doctor/SKILL.md

Project Doctor

Scaffold a project's own parameterized health doctor — a CLI that scores the codebase 0-100 and is driven to a perfect 100, then ratcheted in CI so it can never regress.

Namespace: personal. Source: skills/productivity/project-doctor/SKILL.md (ships a templates/doctor.ts).

This is the executable companion to Doctor Pattern: the concept page is the why, this skill is the how. It makes "every project has its own doctor" a one-step scaffold instead of a from-scratch rebuild each time, satisfying the no-one-off rule for the doctor pattern itself. Source: skills/productivity/project-doctor/SKILL.md, 2026-06-13

What it does

• Copies a dependency-free, parameterized doctor.ts into a project's scripts/.
• The engine is fixed; the project supplies a CONFIG block (name, source dirs, thresholds, target score) and a CHECKS array (one entry per invariant). Same methodology, re-pointed per project — that is what "based on parameters" means.
• Scoring, score-trend history, run-over-run delta, and the --min-score gate are already implemented in the template.

Scoring and the 100 target

The score uses Security and Review Skills's formula — 100 − 1.5 × (error rules) − 0.75 × (warn rules), on unique rules not occurrences — so it rewards systemic fixes. You seek 100 with the fix loop (errors first serially, warnings batched, re-scan), then set --min-score 100 in CI so the score becomes a one-way ratchet. Make must-hold invariants fail (−1.5) and best-practice debt warn (−0.75).

When to use

• Bootstrapping a new project, or hardening an existing one without a doctor.
• A failure pattern has repeated 3+ times in review or a postmortem — encode it as a check.
• Kevin says "add a doctor", "create our own doctor", "health check for this repo", "seek 100".

Wiring

package.json → "doctor": "tsx scripts/doctor.ts"; pre-commit/CI → --min-score <best>, raised over time; monorepos → one doctor per surface; gate CI on the diff so a low starting score never blocks adoption.

Promote Skill

Former page: wiki/skills/promote.md. Runtime source: skills/engineering/promote/SKILL.md

Promote Skill

Create a changelog-style promotion pull request between two branches. Defaults to dev to preview, the first hop of the dev to preview to prod release path.

The promote skill automates moving merged work down the release pipeline. A promote.ts script does everything: fetch, changelog generation, and PR creation, so a promotion is one command rather than a manual diff-and-write. Source: skills/engineering/promote/SKILL.md, 2026-05-31

Auto-detected context

The skill previews exactly what would be promoted by listing the commits that are on the source but not the target branch:

git log --oneline upstream/preview..upstream/dev

If that fails, the hint is to run git fetch upstream first. Source: skills/engineering/promote/SKILL.md, 2026-05-31

Flags

• --from <branch>: source branch (default: dev)
• --to <branch>: target branch (default: preview)
• --remote <name>: git remote (default: upstream)
• --promote-branch <branch>: override the generated PR branch
• --dry-run: print the PR body to stdout without creating the PR

Source: skills/engineering/promote/SKILL.md, 2026-05-31

Why a generated branch

The PR is opened from a generated promote/<from>-to-<to> branch rather than from dev directly. This exists so the preview lockfile-sync step can commit generated lockfiles onto the promotion branch without pushing directly to dev, keeping the source branch clean. Source: skills/engineering/promote/SKILL.md, 2026-05-31

Scope boundary

This skill is only for dev to preview. Promoting preview to main is a different mechanism: a fast-forward push via pnpm ship prod after release-please has run on preview. Keeping the two hops distinct is part of the Production Safety discipline, where the final step to prod is intentionally not a free-form PR. If the script exits non-zero the skill reports the error and stops; otherwise it prints the PR URL. It pairs with the Agent Engineering Skills and Browser Testing Skills skills under the broader Git Workflow. Source: skills/engineering/promote/SKILL.md, 2026-05-31

React Spring Physics

Former page: wiki/skills/react-spring-physics.md. Runtime source: skills/engineering/react-spring-physics/SKILL.md

React Spring Physics

Physics-based animation for React. Springs calculate motion based on physical properties (mass, tension, friction) instead of durations, resulting in organic, interruptible movement.

Core Concepts

Springs animate from current state to target using physical simulation. Two patterns: object config (simpler, auto-updates) and function config (returns [springs, api] for imperative control).

Config presets: default (170/26), gentle (120/14), wobbly (180/12), stiff (210/20), slow (280/60), molasses (280/120). Custom via mass, tension, friction.

Key Hooks

useSpring: single element spring animation. useSprings: multiple similar animations. useTrail: sequential stagger effect across elements. useTransition: enter/leave/update animations for list items. useScroll: scroll progress as spring values. useInView: viewport intersection with spring animation.

Key Patterns

Click-triggered: function config with api.start() for imperative control.

Trail animation: useTrail(items.length, { from, to }) for staggered reveals.

List enter/exit: useTransition(items, { from, enter, leave, keys }) with height animations.

Scroll-based: useScroll() gives scrollYProgress. Interpolate with .to([0, 0.5], [0, 1]).

Chained async: pass array to to property for multi-step sequences. loop: true for continuous.

Velocity preservation: api.start({ x: 0, velocity: springs.x.getVelocity() }) for momentum continuity.

Integration

React Three Fiber: @react-spring/three provides animated('mesh') for 3D spring animations. Animate scale, position, color of meshes.

Popmotion: low-level spring(), inertia(), decay() functions for granular physics control. modifyTarget for snap-to-grid.

Performance

• precision: 0.01 reduces unnecessary updates (default 0.0001 is very fine).
• useSprings batches similar animations.
• Globals.assign({ skipAnimation: true }) for reduced-motion.

Common Pitfalls

• Forgetting dependencies array in function config: useSpring(() => ({ x: 0 }), []).
• Mutating spring values directly instead of using api.start().
• Not handling velocity on interruption (causes abrupt stops).
• Mixing object and function config patterns (API unavailable with object config).
• Animating complex strings: decompose into individual numeric values.

When to Choose React Spring vs Motion

React Spring: natural physics feel, gesture-driven interfaces, momentum/velocity preservation, interruptible animations. Motion: declarative variants, layout animations, exit animations, gesture props. Both work well; choose based on whether physics simulation or declarative convenience matters more.

React Three Fiber

Former page: wiki/skills/react-three-fiber.md. Runtime source: skills/engineering/react-three-fiber/SKILL.md

React Three Fiber

React renderer for Three.js. Declarative, component-based 3D development with full access to hooks, context, and state management. JSX components map directly to Three.js objects.

Core Concepts

Canvas: sets up scene, camera, renderer, and render loop. Props: camera, gl, dpr, shadows, frameloop ("always", "demand", "never").

Declarative objects: Three.js objects via JSX with kebab-case props. position={[x,y,z]}, rotation, scale, args (constructor args), attach.

useFrame: execute code every frame. (state, delta) => {} -- state has camera, scene, gl, clock, pointer. Never setState inside useFrame; mutate refs directly.

useThree: access scene state. Use selectors to avoid unnecessary re-renders: useThree(state => state.size).

useLoader: load assets with caching and Suspense. Supports GLTFLoader, TextureLoader, etc. useLoader.preload() for eager loading.

Drei Helpers (Essential Library)

OrbitControls: enableDamping, dampingFactor, min/max distance. Environment: HDRI presets ("sunset", etc.) or custom files. ContactShadows: soft ground shadows. Text / Text3D: billboard and extruded 3D text. useGLTF: simplified GLTF loading with { scene, materials, nodes }. Center / Bounds: auto-center and auto-fit camera. Html: DOM overlays positioned in 3D space. ScrollControls / Scroll / useScroll: scroll-driven 3D with offset (0-1 normalized). Detailed (LOD): distance-based mesh switching. AdaptiveDpr / PerformanceMonitor: automatic performance scaling.

Key Patterns

Interactive objects: onClick, onPointerOver, onPointerOut directly on meshes. Use useState for hover/active state.

Instancing: <instancedMesh args={[null, null, count]}> with setMatrixAt in useFrame for thousands of objects.

Groups: <group> for hierarchical nesting and collective transforms.

GSAP integration: useEffect with gsap.timeline() targeting meshRef.current.position/rotation. Return tl.kill() for cleanup.

Framer Motion 3D: import { motion } from 'framer-motion-3d' for declarative motion.mesh with initial, animate, transition, whileHover.

Zustand: external state store for shared state between 3D scene and UI.

Performance

• frameloop="demand" with invalidate() for on-demand rendering.
• InstancedMesh for repeated objects.
• frustumCulled={false} only for always-visible objects.
• LOD via <Detailed distances={[0, 10, 20]}>.
• Selective re-renders via useThree selectors.
• Wrap heavy assets in <Suspense fallback={<Loader />}>.

Common Pitfalls

• setState in useFrame: causes React re-renders every frame. Mutate refs instead.
• Creating new THREE.Vector3() in render: use arrays [1,2,3] or useMemo.
• Not using useLoader cache: manual TextureLoader().load() bypasses caching.
• Conditional mounting vs visibility: prefer visible prop over conditional render to avoid expensive remount.
• Using useThree outside Canvas: hooks must be inside Canvas children.
• Not disposing manual Three.js objects in useEffect cleanup.

TypeScript

import { ThreeElements } from '@react-three/fiber'
function Box(props: ThreeElements['mesh']) { ... }

File Organization

components/3d/ (Scene, Lights, Camera)
components/models/ (Robot, Character)
components/effects/ (PostProcessing)

Source & ecosystem

Canonical repo: pmndrs/react-three-fiber (the pmndrs collective — also drei, react-spring, zustand). It's the 3D scenes layer of Frontier Stack 2026. Tools built on R3F: ShaderGradient (animated gradients as declarative props). Source: github.com/pmndrs/react-three-fiber, 2026-06-15

Rive Interactive

Former page: wiki/skills/rive-interactive.md. Runtime source: skills/engineering/rive-interactive/SKILL.md

Rive Interactive

State machine-based vector animation platform with runtime interactivity, two-way data binding via ViewModels, and cross-platform support.

Rive separates animation from logic using state machines. States define different animation poses (idle, hover, pressed), inputs control transitions (boolean, number, trigger), and transitions define the rules between states. This makes Rive fundamentally different from timeline-only tools like Lottie: animations can branch, respond to user input, and bind to application data at runtime.

In React, useRive() returns a RiveComponent and rive instance. useStateMachineInput() connects to named inputs: set boolean values with input.value = true, numeric values with input.value = 50, and fire triggers with input.fire(). The ViewModel API enables two-way data binding: useViewModelInstanceString, useViewModelInstanceNumber, useViewModelInstanceColor, and useViewModelInstanceEnum hooks bind application state to animation properties. Set autoBind: false when using ViewModels for manual control.

Custom events flow from animation to code via rive.on(EventType.RiveEvent, handler) with automaticallyHandleEvents: true. Events carry named properties accessible through eventData.properties.

Key Patterns

• Interactive button: useStateMachineInput for isHovered (boolean) and isClicked (trigger) on mouse enter/leave/click.
• Dashboard binding: ViewModel with string (title), number (metric), and color (theme) properties updated from React state.
• Scroll trigger: Combine with GSAP ScrollTrigger to input.fire() when element enters viewport.
• Preloading: useRiveFile({ src }) loads .riv files early, then pass riveFile to useRive.
• Controlled playback: Expose rive.pause(), rive.play(), and trigger methods via useImperativeHandle for parent control.

Common Pitfalls

• State machine input returns null: name must match exactly as defined in the Rive editor.
• ViewModel properties not updating: must set autoBind: false in useRive options.
• Events not firing: requires automaticallyHandleEvents: true in configuration.
• Performance: use useOffscreenRenderer={true}, keep artboards under 2MB, minimize bone count.

Rust Neckbeard

Former page: wiki/skills/rust-neckbeard.md. Runtime source: skills/personal/rust-neckbeard/SKILL.md

Rust Neckbeard

Deep Rust correctness and style rules for the host-agent, enclave, and packages/rust workspaces.

This is the complete Rust skill (~660 lines) covering patterns beyond the condensed rules file: return-value naming, error design, must_use, visibility, RAII, fail-closed patterns, and all hard limits from style.md and rust.mdx.

Key Patterns

Return-value naming: Rust's implicit last expression is idiomatic. Use a named binding only when the expression is genuinely complex and the name adds clarity beyond result.

Error design: Each variant names one failure mode with diagnostic data. No String inside variants. Use typed sources: #[error("CH HTTP request failed")] Hyper(#[source] hyper::Error).

must_use: Annotate pure functions and constructors whose return value would be a bug to ignore.

Actor pattern: Serialize mutations through a single Tokio task. Callers send typed commands over mpsc with oneshot responses. Eliminates Mutex contention; keeps critical section non-async.

RAII for system resources: Wrap TAP devices, ZFS datasets, Unix sockets in types whose Drop impl cleans up. Never rely on callers to remember cleanup.

Idempotent operations: DELETE returns 204 even if already gone. CREATE handles AlreadyExists as success.

Policy/state split: Separate desired state from observed state. Reconcile loop converges observed toward desired. Process destruction before creation (free resources first).

Testability: Parameterize side-effectful functions. Production function calls real binary; testable function takes executor as parameter.

Golden files: cpu_qos.rs (cgroup integration, clean error types, inline tests) and client.rs (typed HTTP client, must_use, timeout patterns).

Stripe Webhook Hardening

Former page: wiki/skills/stripe-webhook-hardening.md. Runtime source: skills/engineering/stripe-webhook-hardening/SKILL.md

Stripe Webhook Hardening

Harden Stripe webhook handlers against three failure-prone invariants: raw-body signature verification, negative-lifecycle handling, and idempotent side effects.

This skill exists because generated Stripe webhook handlers frequently fail in the same three ways. They parse JSON before constructEvent, which makes signature verification impossible. They treat invoice.payment_failed or customer.subscription.deleted as log-only events, so users keep access after payment failure or cancellation. They assume single delivery even though Stripe retries and may deliver the same event more than once.

What it checks

The review is organized around four questions:

1. Does the route read the raw request body and verify stripe-signature before any parsing?
2. Do failure and cancellation events change real product state, not just log?
3. Is every side effect idempotent under replay?
4. Are there tests and an operational verification path through the Stripe dashboard?

The key nuance is that storing processed event IDs is a good default, but not the only valid implementation. The stronger invariant is that the mutation itself must be replay-safe. A stable business idempotency key such as checkout_session.id, or a naturally idempotent state-setting update, is also acceptable if it can be proven.

The implementation shape should stay centralized. Webhook routes are thin ingress adapters; shared billing helpers own verification, dispatch, idempotency, and the actual state transitions. If a billing event needs special handling, add it to the shared billing path instead of cloning a second webhook implementation somewhere else.

Dedalus canon

The skill points to three canonical Dedalus files:

• apps/website/app/api/(webhooks)/stripe/route.ts shows the fail-closed ingress pattern: raw body first, stripe-signature check, then stripe.webhooks.constructEvent(...).
• apps/website/services/stripe/webhooks/payment-handlers.ts shows how invoice.payment_failed updates billing state immediately and how checkout.session.completed uses stripe_checkout_${session.id} as the mutation idempotency key.
• apps/website/services/stripe/webhooks/subscription-handlers.ts shows that customer.subscription.deleted marks the subscription canceled and downgrades the org to Hobby instead of leaving a TODO.

The centralized billing client rule is: one shared billing path handles all billing mutations, and every route or event handler reuses it instead of inventing a local variant. That keeps webhook verification, event routing, and idempotency in one place.

Verification workflow

A complete review does not stop at code inspection. It should also require:

• a missing or invalid signature test that returns 400
• a replay test that proves duplicate delivery is safe
• an assertion that invoice.payment_failed changes access state
• an assertion that customer.subscription.deleted changes access state

If the question is whether production is currently affected, the operator path is: Stripe Dashboard -> Developers -> Webhooks -> target endpoint -> Recent deliveries, then filter by invoice.payment_failed or customer.subscription.deleted and compare the delivery outcome to database or entitlement state.

Scope

Use this skill when the task is webhook implementation or hardening. Use Frontend and Design Skills when the task is an explicit audit with PASS/FAIL/UNCLEAR output. Use Cloud, Data, and Service Skills when the task is querying or mutating Stripe objects through the typed CLI wrapper.

Taste Skills Playbook - How Kevin Uses Them

Former page: wiki/skills/taste-skills-playbook.md. Runtime source: skills/engineering/taste-skills-playbook/SKILL.md

Taste Skills Playbook - How Kevin Uses Them

Routing layer for the 13 taste-* skills installed at ~/.cursor/skills/taste-* and ~/.cursor/skills/frontend-design-taste. Pick one visual-style skill, layer the universal enforcement skills on top. The skills auto-trigger based on the task description, but knowing which one fires when prevents the "wrong taste" failure mode (e.g. Sigil work picking up taste-soft when it should pick up taste-core + token consumption).

This page is the wiki-level dispatcher for the executable taste skills. It should summarize routing and composition only; detailed prompt text belongs in the individual skill mirrors and executable SKILL.md files. Source: skills/engineering/taste-skills-playbook/SKILL.md; https://github.com/Leonxlnx/taste-skill

2026-06-18 Defaults

The default frontend route now starts with the current Design System and Design Tokens pages, not the older Reticle-only snapshot. For new Kevin-owned product UI, assume Sigil-style constraints: DESIGN.md, semantic tokens, token-consuming components, browser proof, and visual doctors. For existing repos, inspect the local design system first and then map the taste skill onto that system.

Taste skills should produce design-system-compliant output, not decorative JSX. If the output contains hardcoded colors, random spacing, missing loading/error/empty states, unverified mobile layout, or generic AI landing-page patterns, rerun with Taste Enforcement - Anti-Slop Frontend Rules and Frontend and Design Skills before calling the work done. The amusingly tragic failure mode is "premium" code that cannot survive a screenshot.

The Skill Graph

┌─ ALWAYS-ON ENFORCEMENT (Sigil + Dedalus) ──────────────────┐
│  .cursor/rules/taste-enforcement.mdc                       │
│  → variance dials, banned patterns, required UI states     │
│  → loaded automatically, not invoked by name               │
└────────────────────────────────────────────────────────────┘

┌─ DEFAULT BASELINE ─────────────────────────────────────────┐
│  taste-core         frontend-design-taste                  │
│  → senior UI/UX engineer, metric-based rules               │
│  → fires on any unprompted frontend task                   │
└────────────────────────────────────────────────────────────┘

┌─ VISUAL-STYLE FORK (pick ONE per project) ─────────────────┐
│  taste-soft         premium SaaS, Linear/Vercel-tier       │
│  taste-minimalist   Notion/workspace, editorial document   │
│  taste-brutalist    dashboards, terminals, declassified    │
│  taste-gpt          GPT/Codex variant - wide editorial     │
└────────────────────────────────────────────────────────────┘

┌─ WORKFLOW MODIFIERS (layer on top) ────────────────────────┐
│  taste-image-to-code   image-first, deep analysis, build   │
│  taste-imagegen-web    section-by-section web reference    │
│  taste-imagegen-mobile iOS/Android phone-mockup screens    │
│  taste-brandkit        logos, identity decks, brand world  │
│  taste-redesign        audit existing UI, targeted fixes   │
│  taste-stitch          DESIGN.md export for Google Stitch  │
│  taste-output          ban truncation, full file delivery  │
└────────────────────────────────────────────────────────────┘

Decision Tree - Which Skill Fires When

Common Workflows

W1 - Greenfield premium landing page

1. taste-soft           pick double-bezel, spring physics, 2.5rem radii
2. taste-imagegen-web   one image per section (8 sections → 8 images)
3. taste-image-to-code  deep analysis on each image, then implement
4. taste-output         no truncation, ship the full file

W2 - Sigil component work

1. taste-core           default baseline (8/6/4 dials)
2. .cursor/rules/sigil-design-system.mdc enforces var(--s-*) consumption
3. .cursor/rules/taste-enforcement.mdc enforces banned patterns
4. taste-output         when generating multi-file presets

W3 - Existing app audit + fix

1. taste-redesign       diagnose generic patterns, list every issue
2. taste-soft / taste-minimalist / taste-brutalist (pick the upgrade direction)
3. Apply targeted fixes - DO NOT rewrite, work with the existing stack
4. taste-output         deliver complete diffs, no "rest of the file follows"

W4 - Brand identity from scratch

1. taste-brandkit       logo concepts, identity deck, mockups
2. taste-imagegen-web   apply the brand to a marketing page
3. taste-soft           translate to code with premium polish

W5 - Mobile app onboarding

1. taste-imagegen-mobile  generate iOS/Android screens in phone mockups
2. app-onboarding-questionnaire  apply Headspace/Noom/Duolingo conversion patterns
3. taste-image-to-code    deep analyze, implement screen-by-screen

W6 - Dashboard / observability UI

1. taste-brutalist        rigid grids, type contrast, monospace numbers
2. taste-core             enforce loading/empty/error states
3. dashboard-design-system  Reticle stat cards, charts, sidebar patterns

Variance Dials by Project Type

The three dials (DESIGN_VARIANCE, MOTION_INTENSITY, VISUAL_DENSITY) drive every taste skill. Defaults are 8/6/4. Override per project:

The "One Style Per Project" Rule

Never mix taste-soft (warm cream + double-bezel) and taste-brutalist (CRT terminal + Swiss grid) in the same project. They are visual archetypes, not feature sets. If a project genuinely needs both moods (e.g. marketing site + admin dashboard), split into two surfaces with different rule loads.

The visual-style skills are exclusive. The workflow modifiers (taste-image-to-code, taste-imagegen-*, taste-redesign, taste-output) compose freely on top.

Sigil + Reticle Integration

Both Sigil UI and the Reticle Design System enforce taste rules at the project level via Cursor rules:

• Sigil: .cursor/rules/taste-enforcement.mdc cross-references sigil-design-system.mdc - every visual property must read from var(--s-*) tokens. Taste skills generate code that already consumes tokens. Edit the token spec, not the components.
• Reticle: same taste-enforcement.mdc rule. Reticle has its own token system (CSS custom properties, OKLCH palette). Taste skills target Reticle component conventions.
• Dedalus: .cursor/rules/taste-enforcement.mdc. Production app - variance dial defaults to 6/5/5 (less aggressive than marketing page defaults).

When a taste skill emits code with hardcoded hex/px/font, it has failed the enforcement check. Stop and rewrite with token references.

Anti-Patterns the Playbook Prevents

• Wrong-style adoption: agent picks taste-soft for a brutalist dashboard because the user said "premium". Fix: state the archetype explicitly, or describe the target reference.
• Style-skill stacking: agent loads taste-soft AND taste-minimalist AND taste-brutalist. Fix: pick one. Modifiers (image-to-code, output, redesign) layer; visual styles do not.
• Skipping image-first: agent codes a hero from text-only prompt when taste-imagegen-web would produce better source material. Fix: any task described in primarily visual terms triggers image generation first.
• Cropping old images: agent crops a hero out of a multi-section board for re-analysis. Fix: regenerate as a fresh standalone image. (taste-image-to-code rule 5)
• Truncated multi-file output: agent writes "rest of code follows" or // ... TODO .... Fix: taste-output is layered by default on any task with >2 deliverables.

Where Each Skill Lives

Source of truth lives in the wiki repo at skills/personal/<name>/SKILL.md (committed). Cursor loads the same files through the ~/.cursor/skills symlink created by npm run bootstrap.

Project-level enforcement rules: .cursor/rules/taste-enforcement.mdc in Sigil, Reticle, Dedalus.

To install or re-sync on a fresh machine: cd ~/Documents/GitHub/kevin-wiki && bash skills/README.md install block (see skills/README.md).

How To Extend

When a new visual archetype repeats across 3+ projects, codify it as a new taste-<archetype> skill following the upstream pattern from github.com/Leonxlnx/taste-skill. Use the skill-creator skill to scaffold, run npm run skill-registry, update this family page, and add a row to this playbook's decision tree.

The playbook is the single dispatcher - every new taste skill must register here.

See Also

• Taste Enforcement - Anti-Slop Frontend Rules - full anti-slop framework, variance dials, banned patterns
• Taste Skill Framework (Leonxlnx/taste-skill) - the upstream framework as a tool entry
• Frontend and Design Skills - top-level taste guide with vocabulary and archetypes
• Frontend and Design Skills - Anthropics' distinctive frontend skill
• Design System - Reticle design tokens
• Sigil UI - Sigil token-driven design system
• Aesthetic Systems - five archetypes (Premium AI, Editorial Devtool, Architectural, Cinematic 3D, Neo-Brutalist)

Test Writing

Former page: wiki/skills/test-writing.md. Runtime source: skills/personal/test-writing/SKILL.md

Test Writing

Write test output, harnesses, and assertions in the terse Unix tradition.

Covers shell test scripts, Rust #[test], Go testing.T, Python pytest, and CI integration.

Core Principles

Tests are specifications that document what the code should do. Test contracts (behavior), not implementation details. SQLite's test suite is 92 million lines (590x the library). That is how bug-free software gets written.

No Mickey Mouse Tests

If a test cannot exercise the real invariant (needs KVM but you are on a Mac), do not write a mock that pretends to test it. Either write the real test gated behind a CI-only flag, or skip it and document the invariant in a comment. A test that passes trivially proves nothing.

Test Gradient

Start specific and broaden. Modified a single function? Run its unit test. Passes? Run module tests. Then integration tests. Then full suite. This gradient catches issues early. A failing unit test pinpoints; a failing e2e test makes you hunt.

Language-Specific Patterns

Python: Inline tests with inline-tests, @test decorator, local imports with # noqa: PLC0415. Rust: #[cfg(test)] mod tests, invariant naming, matches! for error variants. Go: Table-driven tests, t.Helper(). Shell: Exit codes as assertions, minimal output on success, verbose on failure.

Mock Echo Anti-Pattern

The most common agent test failure mode: set up a mock return value, call the function, assert the result equals the mock value. This tests that the mock works, not the code. Example:

mock.mockReturnValue({ id: 1, name: "test" });
const result = await service.getUser(1);
expect(result.data).toEqual({ id: 1, name: "test" }); // proves nothing

This pattern is now lint-enforced via no-mock-echo (see Lint-Enforced Agent Guardrails). The rule detects when result.data is compared to the exact value the mock was told to return. When the lint rule blocks the commit, agents are forced to write tests that actually exercise transformation logic, error paths, or scoping.

Terse Output

Pass: minimal output (test name, "ok"). Fail: full context (expected vs actual, stack trace, relevant state). Never print diagnostics on success.

Tests

Former page: wiki/skills/tests.md. Runtime source: skills/engineering/tests/SKILL.md, skills/engineering/dedalus-tests/SKILL.md

Tests

Write tests that prove the right invariant at the smallest honest layer.

The tests skill exists because agents love writing tests that prove they can mock their own implementation. Adorable. Useless. A good test states the property the system must preserve and fails when that property is broken.

When To Use

Use tests when:

• adding or fixing tests
• reviewing a test diff
• encoding a bug fix as a regression test
• deciding the correct test layer
• a doctor routes *.test.* changes through test review

Core Principle

Before writing the test, answer:

What system property was violated?

Test that property, not the incident's exact shape. The name should read like an architecture sentence.

Naming

Avoid names that bake in an HTTP status code, bug ticket, internal helper, or current error message unless that is genuinely the public contract.

Smallest Honest Layer

The narrowest test that can honestly fail for the bug is usually best. Too low and it mocks away the bug. Too high and it becomes slow theater.

Red Before Fix

For bug fixes, run the new test before the patch when feasible. Report:

• command
• failing count or failure excerpt
• patch
• green command

Anti-Patterns

• Mock-echo tests.
• Tests named after tickets.
• Snapshot tests for behavior that needs an invariant.
• Testing internal function names when the contract is external.
• Full suite when a targeted command proves the change.
• No assertion that would fail without the fix.

Doctor Integration

Browser Testing Skills and project rules route test diffs through this skill. Security and Review Skills should call it when review findings require coverage. The output of this skill should make tests read like executable documentation.

Three.js WebGL

Former page: wiki/skills/threejs-webgl.md. Runtime source: skills/engineering/threejs-webgl/SKILL.md

Three.js WebGL

Industry-standard JavaScript library for 3D web graphics using WebGL and WebGPU. Scene graph architecture with scenes, cameras, renderers, geometries, materials, lights, textures, and animations.

Scene Graph Architecture

Every Three.js app requires: Scene (container), Camera (perspective), Renderer (WebGL/WebGPU), Geometry (shape), Material (surface), Mesh (geometry + material). Objects organized in a hierarchical tree.

Essential Setup

PerspectiveCamera(fov, aspect, near, far) -- FOV 45-75 typical, near as far as possible, far as close as possible. WebGLRenderer({ antialias: true }) with setPixelRatio(devicePixelRatio) and shadowMap.enabled = true. Always handle resize to update aspect ratio and projection matrix.

Materials

Lighting Strategy

Three-point setup: Key light (main directional, casts shadows), Fill light (soften shadows), Rim light (edge definition), Ambient (base illumination). Configure shadow map size (2048x2048), camera bounds, radius, and blur samples.

Key Patterns

Instanced geometry: InstancedMesh for thousands of similar objects -- set per-instance matrix and color. glTF loading: GLTFLoader with optional DRACOLoader for compressed models. Enable shadows via model.traverse(). Raycasting: Raycaster + normalized mouse coords for click/hover interaction. Animation mixer: AnimationMixer + clipAction for model animations, update with deltaTime.

Custom Shaders

ShaderMaterial with uniforms, vertexShader, fragmentShader. Pass time, colors, textures as uniforms. Update in animation loop.

Post-Processing

EffectComposer with RenderPass + effects like UnrealBloomPass. Call composer.render() instead of renderer.render().

Performance

• Reuse geometry: create once, share across meshes.
• InstancedMesh: for hundreds/thousands of identical objects.
• Texture optimization: mipmaps, power-of-two dimensions, compressed formats.
• LOD: THREE.LOD with distance-based mesh switching.
• Frustum culling: automatic, ensure correct bounding spheres.
• Dispose: always call .dispose() on geometries, materials, textures, renderers.
• Clock: use deltaTime for frame-rate-independent animation.

Common Pitfalls

• Not updating aspect ratio on resize.
• Creating objects inside the animation loop (memory leak).
• Forgetting to enable shadows on renderer, lights, and objects.
• Z-fighting: increase near plane, decrease far plane, use polygonOffset.
• Color space: set texture.colorSpace = THREE.SRGBColorSpace and renderer.outputColorSpace.
• Not disposing resources on cleanup.

Coordinate System

Right-handed: +Y up, +Z toward camera, +X right. Rotations in radians.

Torvalds (Good Taste)

Former page: wiki/skills/torvalds.md. Runtime source: skills/engineering/torvalds/SKILL.md, skills/engineering/torvalds/SKILL.md, skills/engineering/torvalds/SKILL.md

Torvalds (Good Taste)

Remove special cases by changing the representation. The branch was never necessary - it was an artifact of the data structure choice, not the problem.

Built around Linus Torvalds's linked-list example: the textbook remove(head, target) needs a special case for the head node, but the indirect-pointer version (list **pp = &head) makes head and non-head identical. The branch disappears not because it's handled elsewhere - because it never had to exist.

When it fires

• Designing a new system or extracting a shared package
• Refactoring conditional logic, modes, or feature flags
• Deciding whether to add a flag or change the interface
• User invokes "good taste" or asks for a cleaner algorithm
• Reviewing code where every method has an if first_iteration branch

The core question

Before adding a conditional, flag, mode, or special case:

Can I change the representation so the special case doesn't exist?

If yes, change the representation. If no, document why the special case is irreducible.

Four techniques

1. Change the data to remove the branch. Indirect pointers, sentinel rows (WHERE 1=1), default-config-as-real-config-not-nil.
2. Change the algorithm to remove the branch. One priority-ordered convergence check instead of converging-vs-diverging. Retry-policy-as-delay-table instead of if is_transient.
3. Change the scope to remove the branch. Always-filter-empty instead of skip_empty flag. Function inspects its own data instead of caller passing use_fast_path.
4. Make illegal states unrepresentable. enum Security { None, Tls, MutualTls } over (tls: bool, verify: bool). Newtype AccountId(u64) over transfer(from: u64, to: u64). Builder over option-soup struct.

Irreducible special cases

Not every branch is eliminable. Genuine domain distinctions stay - first iteration of a loop, root of a tree, network partition vs local error, platform-specific code. These are named, documented, tested, and live as explicit match arms - not hidden if branches in helpers.

The heuristic

Count the if statements in your function. Each one is a branch the next reader must understand. If you can reduce the count by changing the representation, do it. Good taste is not cleverness - it's the discipline to find the representation where the special cases disappear.

Vercel React Best Practices

Former page: wiki/skills/vercel-react-best-practices.md. Runtime source: skills/engineering/vercel-react-best-practices/SKILL.md, skills/engineering/claude-vercel-react-best-practices/SKILL.md

Vercel React Best Practices

70 prioritized React/Next.js performance rules across 8 categories. Based on vercel-labs/agent-skills (~500K installs at the 2026-06-25 recheck).

When to Apply

• Writing new React components or Next.js pages
• Implementing data fetching (client or server-side)
• Reviewing code for performance issues
• Optimizing bundle size or load times

Rules by Priority

Critical Rules (Top 11)

1. async-parallel - Use Promise.all() for independent async operations
2. async-suspense-boundaries - Use Suspense to stream content progressively
3. bundle-barrel-imports - Import directly from source, never from barrel/index files
4. bundle-dynamic-imports - Use next/dynamic for heavy components
5. bundle-defer-third-party - Load analytics/logging after hydration
6. server-cache-react - Use React.cache() for per-request deduplication
7. server-parallel-fetching - Restructure components to parallelize fetches
8. server-after-nonblocking - Use after() for non-blocking post-response work
9. rerender-derived-state-no-effect - Derive state during render, not in effects
10. rerender-no-inline-components - Never define components inside components
11. rendering-content-visibility - Use content-visibility for long lists

Product-Over-Tooling Note

Guillermo Rauch explicitly framed this as a recommendations skill agents should follow while keeping attention on product quality instead of tooling fascination. In practice: load the skill when building/reviewing React and Next.js work, but score the outcome by user-visible performance and product correctness, not by how many rules were mechanically mentioned. Source: X/@rauchg, 2026-06-23

Vibe Code Doctor (Skill)

Former page: wiki/skills/vibe-code-doctor.md. Runtime source: skills/engineering/vibe-code-doctor/SKILL.md

Vibe Code Doctor (Skill)

A doctor for the failure modes that sink vibe-coded projects in production: not the demo breaking, but incomprehensible code, integration breaks, skipped architecture, and missing ops/security. Scores 0-100 and drives fixes. Built after the r/Anthropic "why vibe coded projects fail" thread ("let's make it"). Installed at skills/engineering/vibe-code-doctor/. Source: r/Anthropic 1ua0aah, 2026; User, 2026-06-22

What it does

Audits a project across six failure-mode categories — comprehension/maintainability, integration, verification, security, data & ops, architecture — and scores it with the Doctor Pattern formula (unique failing rules, errors 2× warnings), then runs a fix loop to green. It's the umbrella audit: it delegates layer-specific scanning to Security and Review Skills (React health + Security Doctor), Security and Review Skills (deep vuln scan), and the project's own doctor, and adds the lens those miss — can a human make sense of this, does it break when modules connect, were the architectural decisions actually made.

Why it exists

The Reddit thread's signal (414 upvotes): vibe coding fails not at the demo but when (1) nobody can make sense of the code, (2) it breaks at integration points (each module solid alone), (3) ops/scale/security were skipped, and (4) architecture was never decided. Those are exactly the gaps generic linters and even react-doctor don't cover — so this doctor names them as scored rules. Source: r/Anthropic 1ua0aah, 2026

Where it fits

Run on inheriting or hardening any AI-generated codebase, before shipping a vibe-coded prototype to real users. Part of the Doctor Pattern family alongside Frontend and Design Skills (scaffold a project's own doctor), Security and Review Skills, and the wiki's own doctor. Pairs with Browser Testing Skills (auto-run doctors after big edits) and Lint-Enforced Agent Guardrails. Discoverable via npx skills (Security and Review Skills).

Web Design Engineer (Skill)

Former page: wiki/skills/web-design-engineer.md. Runtime source: skills/misc/web-design-engineer/SKILL.md

Web Design Engineer (Skill)

A design-engineering skill (ConardLi garden-skills, v1.2.2) that positions the agent as a top-tier design engineer building refined web artifacts in HTML/CSS/JS/React. Its premise: "the bar is stunning, not functional." Installed at skills/misc/web-design-engineer/. Source: github.com/ConardLi/garden-skills, 2026-06-21

Why it's installed

It is the direct countermeasure to generic AI-dashboard output (cramped layouts, card soup, default Tailwind, emoji icons, weak hierarchy) — the problem captured in Refined Interface Design (Avoiding AI-dashboard Slop). It refuses to "pick aesthetics in a vacuum," which the skill names as the root cause of generic output. Source: ConardLi/garden-skills SKILL.md, 2026-06-21

The six-step workflow (with hard checkpoints)

0. Verify facts first — WebSearch any named product/SDK/brand before asserting; never trust training-data recall.
1. Understand requirements — ask proportional to context (a scenario table decides how much), not a fixed questionnaire.
2. Gather design context by priority: user-provided assets/code > existing product pages > industry best practices > a named anchor → read one references/style-recipes/<anchor>.md. Code ≫ screenshots. Asset > Spec for brands (logo/product imagery beat hex codes).
3. Declare the design system (palette, type, spacing, radius, shadow, motion) and 🛑 wait for confirmation.
4. Ship a v0 draft early with placeholders so the user course-corrects before full build (🛑 checkpoint).
5. Full build — components, states, motion (🛑 pause at non-trivial decisions).
6. Verify against the pre-delivery checklist.
7. Critique on request — a 5-dimension score (philosophy / hierarchy / craft / functionality / originality), each 0–10.

Style recipes (the anti-vacuum library)

25 anchored recipes, one file each, each with concrete palette/type/spacing/radius/shadow/motion + "signature moves" + "avoid" + "don't use when". Load one recipe, not the catalog. Directly relevant to Kevin's references: linear.md (warm-dark #08090A, hairline borders, #5E6AD2 on <5% of pixels, radius ≤16, no glow), notion-pre-ai.md, apple-hig.md, raycast.md, vercel-mesh.md, plus aesop, muji-kenya-hara, stripe-press, tufte-dataink, pentagram, etc. For vague requests, the Design Direction Advisor proposes 3 directions from different schools (never 3 from one) via references/design-directions.md.

Anti-cliché system

Explicit slop table with the why (AI defaults = average of training data = no brand recognized): bans aggressive purple→pink→blue gradients, rounded-card-+-colored-left-border, emoji-as-icon, AI-drawn SVG humans, CSS silhouettes for product imagery, Inter/Roboto default-weight display, cyber-neon on #0D1117, and fabricated stats — each with the one legitimate exception ("the brand spec uses it"). Default: no emoji; placeholders over poorly-drawn fakes; derive palette variants with oklch(), never invent hues. Source: ConardLi/garden-skills SKILL.md, 2026-06-21

When to use

Any browser-rendered visual deliverable — landing pages, dashboards, prototypes, slide decks, animations, UI mockups, data viz. Not for back-end, CLI, or non-visual tasks. Pairs with Frontend and Design Skills (micro-detail polish) and design-engineering-polish (motion/component taste); see Refined Interface Design (Avoiding AI-dashboard Slop) for Kevin's standing standard and reference set.

Web3D Integration Patterns

Former page: wiki/skills/web3d-integration-patterns.md. Runtime source: skills/engineering/web3d-integration-patterns/SKILL.md

Web3D Integration Patterns

Meta-skill for combining Three.js, GSAP, React Three Fiber, Motion, and React Spring into cohesive 3D web experiences. Architecture patterns, state management, and performance optimization across the stack.

Four Architecture Patterns

Pattern 1: Layered Separation (Three.js + GSAP + React UI)

3D Layer (Three.js scene/camera/render), Animation Layer (GSAP ScrollTrigger timelines), UI Layer (React + Motion overlays). Clear separation, easy to reason about, but more boilerplate and manual sync.

Pattern 2: Unified React (R3F + Motion)

Everything in the React component tree. <Canvas> for 3D, <motion.div> for UI overlays. Declarative, unified state management, component reusability. R3F learning curve, potential re-render issues.

Pattern 3: Hybrid (R3F + GSAP Timelines)

GSAP timeline() in useEffect targeting R3F refs. Best for complex sequences needing GSAP's timeline authorship with React state. Always tl.kill() in cleanup.

Pattern 4: Physics-Based 3D (R3F + React Spring)

@react-spring/three with animated('mesh'). Spring-based scale, position, color on meshes. Natural feel for interactive 3D.

Common Integration Recipes

Scroll-driven camera: GSAP cameraPath array with ScrollTrigger scrub, or Drei ScrollControls + useScroll with useFrame.

Gesture-driven 3D: framer-motion-3d motion.mesh with drag, whileHover, whileTap.

State-synchronized: Zustand store shared between R3F components and GSAP effects.

State Management

Zustand is the recommended global state store for 3D apps: shared camera state, selected objects, animation flags. Use selectors in R3F components to avoid unnecessary re-renders.

Performance

• Coordinate render loops: conditional rendering with needsRender flag, trigger on ScrollTrigger events.
• R3F frameloop="demand" with manual invalidate().
• Never animate the same property from two libraries simultaneously.
• Always clean up GSAP tweens in useEffect return.

Decision Matrix

Common Pitfalls

Animation conflicts: multiple libraries animating the same property. Assign one library per property. State sync: Three.js mutations invisible to React. Use refs or update both. Memory leaks: always kill GSAP tweens, dispose Three.js objects, and remove event listeners on unmount.

Browser Testing Skills

Merged Article Notes

Agent Browser

Former page: wiki/skills/agent-browser.md. Runtime source: skills/engineering/agent-browser/SKILL.md

Agent Browser

Primary browser automation tool. Enforced as default for all agent browser tasks. Native Rust CLI, CDP-based, ref-based snapshots, actively maintained (v0.27). Replaces Playwright for ad-hoc agent browsing. Based on agent-browser.dev.

When to Use What

1. agent-browser -- all ad-hoc browsing, frontend verification, scraping, computer use, React debugging, perf checks.
2. Chrome DevTools MCP -- inspecting an existing browser session the user is already logged into.
3. Playwright -- only for deterministic E2E test suites in CI (pnpm test website --e2e).

Engine Configuration

Lightpanda is the default engine. Configured via:

• Global config: ~/.agent-browser/config.json -> { "engine": "lightpanda" }
• Env var: AGENT_BROWSER_ENGINE=lightpanda (in ~/.zshrc)
• Binary: ~/bin/lightpanda (nightly build)

When to fall back to Chrome: Lightpanda does not support --extension, --profile, --state, or --allow-file-access. For auth-heavy workflows needing profile/state persistence, use --engine chrome.

Core Workflow

Navigate -> snapshot (get refs) -> interact (use refs) -> re-snapshot after page changes.

agent-browser open https://example.com/form
agent-browser snapshot -i            # refs: @e1, @e2...
agent-browser fill @e1 "user@example.com"
agent-browser click @e3
agent-browser snapshot -i            # must re-snapshot after page changes

v0.27 Features (May 2026)

React Introspection

agent-browser react tree             # full component tree
agent-browser react inspect @e1      # props, hooks, state for component at ref
agent-browser react renders          # render profiling (which components re-rendered, why)
agent-browser react suspense         # Suspense boundary analysis

Web Vitals

agent-browser vitals                 # LCP, CLS, TTFB, FCP, INP + React hydration phases

SPA Navigation

agent-browser pushstate /dashboard   # client-side nav without full page load

Init Scripts

agent-browser --init-script ./setup.js open https://example.com
agent-browser --enable performance open https://example.com

Other v0.27

• Network route filtering by resource type (--type fetch)
• Cookie import (JSON, cURL, Cookie-header formats)
• Dashboard works behind reverse proxies

Key Commands

Verifying Frontend Changes

agent-browser batch "open http://localhost:3000" "snapshot -i"
# make changes, hot reload
agent-browser diff snapshot
agent-browser diff screenshot --baseline before.png
agent-browser vitals
agent-browser react renders

Authentication

For auth flows, use Chrome engine (Lightpanda doesn't support --state/--profile):

agent-browser --engine chrome auth save github --url https://github.com/login --username user --password-stdin <<< "$PASSWORD"
agent-browser --engine chrome auth login github
agent-browser --engine chrome --session-name myapp open https://app.example.com
agent-browser --engine chrome --auto-connect open https://example.com

Cloud Providers

Supports cloud browser backends via -p <provider>: agentcore, browserbase, browserless, browseruse, kernel. Local Lightpanda/Chrome is default. Cloud is drop-in when needed.

Agent Process Tracking, Audit, And Cleanup

Former page: wiki/skills/cleanup-terminals-browsers.md. Runtime source: skills/productivity/cleanup-terminals-browsers/SKILL.md

Agent Process Tracking, Audit, And Cleanup

Skill that tracks and audits agent-spawned local processes - localhost/dev servers, hung vitest/jest watchers, automation browsers, and build caches - before deciding what, if anything, should be cleaned up.

Script First

The executable surface is scripts/agent-hygiene.sh, with scripts/devclean.sh as the direct dev-machine cleanup wrapper. The skill is intentionally thin: it is the memory hook that makes agents remember when to run the script. Agents should not spend context reinterpreting cleanup policy when deterministic scripts can list, audit, stop, optimize, and report. Source: SKILL.md

Process Ledger

The core state is scripts/process-ledger.sh, called through agent-hygiene.sh, a dry-run-first ledger for long-running commands agents start. Before starting another localhost server or watcher, agents list the ledger and active listeners. When they start one, they record repo root, cwd, PID, PGID, port, purpose, and command in ~/.cache/agent-processes/ledger.tsv. The ledger is useful even when nothing is killed: it tells the next agent what is running, why it exists, and which process group owns it. Source: SKILL.md

Process Cleanup

Agents background long-running processes and walk away; they accumulate across sessions and hung test workers pin CPU cores for hours. The skill encodes a lifecycle loop: track -> audit -> classify -> clean up only when safe -> verify. The ownership rule stays strict: keep only the dev server actively in use, kill what you spawned and abandoned, and never kill the IDE, the agent runtime, the user's shell, or shared MCP servers (playwright-mcp, chrome-devtools-mcp) whose death breaks live tooling. Source: SKILL.md

Kills happen by process group (kill -TERM -<PGID>, then SIGKILL only stragglers) so the whole pnpm->node->worker tree dies together. For browsers, close the page/context via the browser tool; only signal-kill a headless Chrome you spawned and orphaned. The bundled scripts/audit-processes.sh defaults to a dry-run report and now includes localhost listener visibility before categorizing candidates (tests/dev/browser) with a hardcoded protect-list for IDEs and MCP servers. Source: SKILL.md

Devclean-Style Machine Cleanup

scripts/devclean.sh adds the broader DevClean-style machine hygiene modes Kevin wanted without making the skill body carry the logic. It is dry-run by default and only acts with --apply. The no-flag mode audits safe orphaned developer processes (PPID=1) across MCP servers, frontend dev servers, Flutter/Dart/FVM, adb/log streams, Claude task monitors, and known helper agents. --deep adds opt-in heavy daemon cleanup: Gradle, Kotlin LSP, Flutter daemon, FVM, orphaned xcodebuild, Antigravity language servers, iOS simulator shutdown, Logi Options+, Ruby/Fastlane, and LogiRightSight. Source: SKILL.md

--optimize audits or applies one-time resource fixes: disables crash reporters in VS Code/Cursor/Windsurf/Antigravity/Kiro argv files, clears Crashpad dumps, and disables known SMAppService background agents such as ChatGPTHelper and FigmaAgent. This local implementation intentionally does not treat generic crashpad_handler processes as safe orphans, because on macOS that catches normal Codex/Cursor/Chrome crash reporters. Source: SKILL.md; ImL1s/devclean, 2026-06-26

Disk Cleanup

A second script, scripts/clean-artifacts.sh, handles the disk dimension: it reports and (with --clean) deletes regenerable build/cache artifacts — Turborepo .turbo, Next .next, Vite, dist/build/out, *.tsbuildinfo, coverage, node_modules/.cache, and pnpm store prune (--deep). It prunes node_modules/.git and skips any path that still holds git-tracked files, so it can clear caches without destroying source. Source: SKILL.md

The broader macOS cleanup gist by kibotu is the reference shape for future disk cleanup domains: a script with category flags, dry-run mode, and a report. If system/dev/Docker/iOS cleanup becomes part of Kevin's default loop, add it as a new script subcommand rather than expanding prompt prose. Source: GitHub Gist, 2026-05-08

devclean.sh --disk also covers the devclean disk set: Xcode DerivedData, iOS DeviceSupport, XCTestDevices, CocoaPods cache/repos, Playwright cache, Gradle caches/wrapper, Flutter pub cache, npm cache, Gemini browser recordings, Codex sessions/logs, incomplete FVM versions, and project build/, .dart_tool/, .gradle/, and node_modules/ directories under a configurable documents root. It also delegates current-repo artifact cleanup to clean-artifacts.sh. Source: SKILL.md; ImL1s/devclean, 2026-06-26

Triggers And Enforcement

Trigger conditions: before starting another localhost/dev server, while tracking what is running, high CPU/memory, before ending a session, after long-running tasks, or when the user says "what is running", "track processes", "audit localhost", "high CPU", "clean up terminals/processes", "kill stray processes", "orphaned MCP", "devclean", "deep cleanup", "optimize crash reporters", "localhosts out of control", or "too many browsers."

Enforced globally by config/cursor/rules/process-hygiene.mdc (always-on) and AGENTS.md § Process & Resource Hygiene. See Agent Process Tracking, Audit, And Cleanup for full rationale and the 10-hour-hang incident that motivated it.

Timeline

• 2026-06-26 | Added process-ledger.sh so agents record long-running localhost/dev servers and watchers by PID/PGID/port/purpose before cleanup. audit-processes.sh now reports localhost listeners, and the skill/rule trigger includes "localhosts out of control." Source: User request, 2026-06-26
• 2026-06-26 | Reframed the skill title and contract as tracking, audit, and cleanup. Tracking/audit stay first; cleanup remains visible as the required final branch when the audit proves a process is agent-owned and no longer needed. Source: User correction, 2026-06-26
• 2026-06-26 | Collapsed the skill into a thin script router and added agent-hygiene.sh as the single entrypoint. The kibotu macOS cleanup gist is now documented as the reference shape for future script subcommands instead of more prompt text. Source: User correction and gist, 2026-06-26
• 2026-06-26 | Added devclean.sh with devclean-style safe orphan, --deep, --optimize, and --disk modes, all dry-run by default and gated by --apply for destructive actions. Source: User correction and ImL1s/devclean, 2026-06-26
• 2026-06-26 | Clarified the positioning: this is a skill that makes the agent remember to run a script, while the script owns the cleanup behavior. Source: User correction, 2026-06-26

ai-sdk (Skill)

Former page: wiki/skills/ai-sdk.md. Runtime source: skills/engineering/ai-sdk/SKILL.md

ai-sdk (Skill)

Answer questions about the AI SDK and help build AI-powered features. Use when developers: (1) Ask about AI SDK functions like generateText, streamText, ToolLoopAgent, embed, or tools, (2) Want to build AI agents, chatbots, RAG systems, or text generation features, (3) Have questions about AI providers (OpenAI, Anthropic, Google,... Installed at skills/engineering/ai-sdk/. Source: vercel/ai@ai-sdk, 2026-06-24

Why installed

This was promoted from the 2026-06-24 capability harvest because it is an official or reputable skill for a recurring agent workflow. It gives agents current procedural guidance before they mutate cloud, auth, workspace, design, diagram, AI SDK, or deployment surfaces.

Where it fits

Use this skill before answering or changing code that uses the Vercel AI SDK, AI Gateway, streaming, tool calling, typed agent UI patterns, durable workflow agents, harness embedding, reasoning controls, file/skill uploads, MCP Apps, approvals, telemetry, or AI SDK tests. For discovery and future updates, use Security and Review Skills and Capability Harvest Pattern. Installation is not permission to make production mutations; check credentials, target project, dry-run support, and user intent first.

The local skill now tells agents not to assume ToolLoopAgent is the default. AI SDK 7 exposes several surfaces; choose WorkflowAgent for durable workflow-backed agents, HarnessAgent for mature harness embedding, and lower-level Agent / streamText / generateText when the app owns the loop directly. Use ai-test-kit or built-in AI SDK test primitives when the proof should be deterministic. Source: AI SDK v7 docs, 2026-06-25; X/@aisdk, 2026-06-25; GitHub zirkelc/ai-test-kit, 2026-06-25

Beta DX Walk

Former page: wiki/skills/beta-dx-walk.md. Runtime source: skills/engineering/beta-dx-walk/SKILL.md

Beta DX Walk

Agent-led beta DX/UX readiness walk: walk a product's critical journeys as a skeptical first-time user, treat friction (pause / guess / reread / ask) as a bug, triage each finding as blocks-beta / confuses-beta / polish with tried/expected/happened + evidence, and end with a ship-or-hold verdict. Executable source: skills/engineering/beta-dx-walk/SKILL.md. Source: skills/engineering/beta-dx-walk/SKILL.md

Agent-led beta DX/UX readiness walk: walk a product's critical journeys as a skeptical first-time user, treat friction (pause / guess / reread / ask) as a bug, triage each finding as blocks-beta / confuses-beta / polish with tried/expected/happened + evidence, and end with a ship-or-hold verdict. Executable source: skills/engineering/beta-dx-walk/SKILL.md.

Source: skills/engineering/beta-dx-walk/SKILL.md, 2026-06-13

When to use

Beta readiness, onboarding / first-run QA, pre-launch UX gates, "walk the beta path", "is this ready for users", or "treat friction as a bug". Project-agnostic.

Method

frame persona + journeys -> set up fresh session -> walk each journey -> log friction as bugs -> probe failure/recovery -> readiness verdict -> hand off

At every step ask: did the user have to pause, guess, reread, or ask for help, and can they recover when something fails. Severity reflects the user outcome, not the fix size.

Boundary (MECE)

• dogfood - breadth-first bug / UX hunt across the whole app.
• gstack-qa - code-level QA with atomic commits + regression tests.
• beta-dx-walk (this) - journey-first first-run comprehension + recovery, ending in a beta-readiness call. Reuses dogfood browser + evidence mechanics.

Stack fit

The first-run-user lens of Browser Testing Skills (verify-live phase); a standing Agent Looping loop; uses Browser Testing Skills / browser-harness per tool-hierarchy.mdc; informs a human ship/hold decision (Staying in the Loop with Agents). Fixes route back through the iteration loop. Concept layer: Browser Testing Skills.

CI Integrity Audit

Former page: wiki/skills/ci-integrity-audit.md. Runtime source: skills/engineering/ci-integrity-audit/SKILL.md

CI Integrity Audit

Prove a green build was earned, not gamed. Audits the CI-related changes across a set of PRs for check-suppression / green-washing anti-patterns and judges each one as justified or debt-in-disguise, with file:line evidence.

Getting many PRs green quickly is exactly when check-suppression creeps in, and agent-authored batches are the highest-risk case because silencing a check is faster than fixing what it caught. This skill is the integrity counterpart to Security and Review Skills: where that one fixes a failing check, this one verifies the fix was real. The governing bar is that a green check must mean the thing it checks is actually true — so suppression is acceptable only for a proven false positive or a genuine conflict between two correct gates, at the narrowest scope (one line), with a documented reason, and with the underlying behavior still correct.

The catalog

The skill enumerates ten classes of green-washing and greps every PR diff for their signatures: (1) inline suppression comments (oxlint-disable, @ts-ignore/@ts-expect-error/@ts-nocheck, # noqa, # type: ignore, #[allow], //nolint); (2) test skips and tautological assertions (.skip/.only/xit/it.skip, t.Skip, @pytest.mark.skip, expect(true).toBe(true)); (3) deleted tests; (4) threshold/budget weakening (max-warnings, audit budgets, coverage floors); (5) editing the gate itself (.github/workflows, tsconfig, .oxlintrc, ignore files, or a tools/guards/ script); (6) swallowed failures (continue-on-error, || true, || exit 0, if: false); (7) hook/pipeline bypass (--no-verify, [skip ci], force-push); (8) fake green (Mickey-Mouse mocks, hardcoded returns, catch-and-swallow); (9) silent fallbacks (banned per No-Fallbacks Policy); (10) retry-until-green on a real failure rather than a proven infra flake.

The most dangerous class is editing the gate — you can make any check pass by changing the check. Guard-script edits get a dedicated rule: allowed only to fix a false positive, and only if detection of the real cases is preserved and, ideally, a regression test proves both halves (still catches real drift AND now ignores the false positive). A guard edit with no test is an unproven claim.

Workflow and output

Enumerate the touched PRs (include merged), dump each gh pr diff to a file to avoid SIGPIPE on large diffs, flag any touched gate/config files first (highest signal), grep added lines for the catalog signatures, check separately for deleted test files and [skip ci]/--no-verify in commit messages, then judge every hit in context against the rubric — attributing each to you vs. the original author. The output is a per-PR table (suppressions/skips/gate-edits found, justified?, evidence) plus an overall verdict and remediations; a canvas is preferred when the result set is large. It composes with Security and Review Skills when a second model should re-judge the calls, and its standards trace back to PR Review Lessons (Dedalus) and Empirical Verification (read the context and test the claim; never just count grep hits).

This skill was distilled from a real launch sweep where ~11 PRs were driven green at once: the audit confirmed no gates, thresholds, or tests were weakened, and that the handful of suppressions were single-line documented rule-conflicts — but only after reading each in context, which is the entire point.

GStack QA

Former page: wiki/skills/gstack-qa.md. Runtime source: skills/engineering/gstack-qa/SKILL.md

GStack QA

QA lead skill for testing a live app in a real browser, finding bugs, fixing them, writing regression tests, and verifying the fix.

When To Use

Use gstack-qa when:

• Kevin says "QA this", "test the app", "find bugs", "test this URL"
• a feature has a user flow that must work end to end
• browser behavior matters more than source-level correctness
• a fix needs a reproduction path and regression test

Use Frontend and Design Skills instead when the primary question is visual/UX quality. Use Security and Review Skills when the artifact is a diff and no live app is available.

Contract

The skill guarantees:

• Real browser testing through Browser Testing Skills or the routed browser tool.
• Screenshots for evidence.
• Reproduction steps for every bug.
• Severity classification.
• Minimal fixes in severity order when safe.
• Regression tests for fixes.
• Re-verification in the browser.
• Hard cap of 15 bug fixes per session.

Flow

1. Discover app type, key flows, stack, and auth requirements.
2. Test 3-5 key user flows.
3. Check console errors, visual glitches, functional failures, loading, error handling, and responsive behavior.
4. Report bugs with expected vs actual behavior.
5. Fix in severity order.
6. Write regression tests.
7. Re-test in browser.
8. Report verdict.

Viewports

Default responsive pass:

• mobile: 375x812
• tablet: 768x1024
• desktop: 1440x900

Touch targets should be at least 44px on mobile. No horizontal scroll. Text must fit its containers.

Self-Regulation

Every five fixes, the skill checks whether it is still fixing real bugs or drifting into nitpicks. After 15 fixes, stop and report. The goal is shippability, not making the session cosplay as an infinite QA department.

Source

Executable source: skills/engineering/gstack-qa/SKILL.md.

PR Skill

Former page: wiki/skills/pr.md. Runtime source: skills/engineering/pr/SKILL.md

PR Skill

Create a pull request using the Dedalus PR template with auto-resolved reviewers.

Process

1. Gather context: commit log, diff stats, changed files against upstream/dev.
2. Resolve reviewers from CODEOWNERS lookup and git blame history.
3. Push branch if needed.
4. Read .github/PULL_REQUEST_TEMPLATE.md and fill every section.
5. Create PR with gh pr create.

Screenshot Rule

UI-facing Dedalus PRs must include screenshots in ## Repro / Showcase. The PR agent classifies the diff before creation: changes under website app routes, components, providers, public assets, or other user-visible copy/styles count as UI-facing. These PRs should capture at least one changed surface locally, upload the image to a GitHub-renderable attachment URL, and place screenshot markdown plus a short caption in the PR body.

Do not write N/A for a UI PR unless Kevin explicitly waives screenshots. If uploading is blocked, stop and ask whether to create a draft PR with Screenshots pending or wait. Non-UI PRs should write N/A (no visual surface changed). Source: User request, 2026-06-24; skills/engineering/pr/SKILL.md

Reviewer Resolution

Domain reviewer: Highest-ranked CODEOWNERS match (excluding PR author). Readability reviewer: Highest-ranked blame-based contributor who is not the domain reviewer and not the PR author. Always tag two distinct people.

CODEOWNERS lookup uses changed file paths against .github/CODEOWNERS patterns. Blame-based lookup checks who touched the changed files in the last 3 months.

LOC Check

If diff exceeds 200 changed lines (excluding generated files), warn and suggest splitting into stacked PRs.

Format

PR title: type(scope): description (conventional commit format, under 70 chars). Target branch: dev by default. Body follows the mandatory template with summary, test plan, Repro / Showcase screenshots when UI changes, and reviewers.

Change Log

• 2026-06-24 | Added the UI screenshot requirement for Dedalus PRs and updated the executable skill source path. Source: User request, 2026-06-24

Skill Creator

Former page: wiki/skills/skill-creator.md. Runtime source: skills/productivity/skill-creator/SKILL.md, skills/productivity/claude-skill-creator/SKILL.md

Skill Creator

Create, test, and iteratively improve agent skills with wiki integration. Based on anthropics/skills, customized with Kevin's wiki-first protocol, and sharpened with Matt Pocock's writing-great-skills vocabulary.

Wiki-First Protocol

Before creating any skill:

1. Check the wiki (wiki/_index.md) for existing knowledge on the domain
2. Check skills.sh via Security and Review Skills for upstream skills to adapt
3. Check installed skills at ~/.cursor/skills/ for overlap

After creating a skill:

1. Run npm run skill-registry
2. Update the relevant wiki/concepts/*-skills.md family page if durable routing knowledge changed
3. Update wiki/tools/skills-sh.md inventory table when the source catalog changed
4. Update AGENTS.md or resolver/routing docs when agent behavior changed
5. Append to wiki/log.md
6. Rebuild index: npx tsx scripts/build-index.ts

Skill Anatomy

skill-name/
├── SKILL.md (required - name + description frontmatter, then instructions)
└── references/ (optional - scripts, docs, assets)

Install Cursor/personal skills to skills/personal/<name>/SKILL.md. Keep under 500 lines. Use references/ for overflow.

Writing Principles

• Explain the why - reasoning over rigid MUSTs
• Include concrete input/output examples
• Descriptions should enumerate distinct trigger branches, not synonym piles
• Always include "Related Skills" section
• Reference relevant wiki pages for domain context
• Progressive disclosure: metadata always in context, references on demand
• Use checkable completion criteria for ordered steps
• Choose model invocation only when the agent or another skill must discover it autonomously
• Prune duplication, no-op advice, and stale sediment aggressively

No-Op Pruning

skill-creator now owns the "tighten this skill" branch. A line is useful only if it changes routing, required context, tool choice, output shape, stop conditions, domain invariants, or verification. Generic virtue instructions like "be thorough" are deleted unless they are rewritten as checkable criteria. Source: X/@mattpocockuk, 2026-06-24

The operational test is deletion-based: remove the sentence and ask whether a competent agent would behave differently on a realistic prompt for this skill. If not, the sentence is sediment. Joe Fernandez's reply is kept as a small field report: applying the idea to workflow skills cut character count by roughly 75-80% while improving quality and speed. Source: X/@joenandez reply, 2026-06-25

Process

1. Capture intent - what should this enable, when should it trigger, expected output
2. Interview - edge cases, formats, success criteria, dependencies
3. Write SKILL.md - frontmatter + instructions
4. Test - 2-3 realistic prompts, verify trigger accuracy
5. Wiki integration - create wiki page, update index, log

Cloud, Data, and Service Skills

Merged Article Notes

Database Query Skill

Former page: wiki/skills/db.md. Runtime source: skills/engineering/db/SKILL.md

Database Query Skill

Run read-only SQL against Dedalus Supabase databases (local or remote) to inspect schema, debug data, check migrations, or answer questions about database state.

The db skill is the read path to Dedalus Postgres. It wraps a query.ts script and enforces read-only access by construction, so it is safe to point at any environment for inspection without risk of mutation. Writes are a separate, explicitly invoked skill. Source: skills/engineering/db/SKILL.md, 2026-05-31

Invocation

node --experimental-strip-types ${CLAUDE_SKILL_DIR}/scripts/query.ts [flags] "<sql>"

Flags:

• --env local|dev|preview|prod (default: local)
• --db core|admin (default: core)
• --readonly (enforced by this skill, always passed)
• --format table|json|csv (default: table)

Source: skills/engineering/db/SKILL.md, 2026-05-31

Credential resolution

For remote connections, credentials resolve in order: the SUPABASE_DB_PASSWORD environment variable, then ~/.pgpass. If neither is present, the prod password can be fetched from AWS SSM (/prod/SUPABASE_DB_PASSWORD via the admin profile, needs an active SSO session); dev and preview passwords live in ~/.pgpass. Project refs per environment are in packages/python/cli/databases.yml. Source: skills/engineering/db/SKILL.md, 2026-05-31

Schema reference

Rather than guess column names, the skill reads generated Supabase types (core/database.types.ts, admin/database.types.ts). The Database type exposes schemas (public, billing, oauth, dcs), each with Tables, Enums, and Functions, and each table has Row, Insert, and Update variants. For exploration it starts from information_schema.tables and information_schema.columns. Source: skills/engineering/db/SKILL.md, 2026-05-31

Operating rules

1. Always pass --readonly; this skill never mutates. Mutations require the separate Security and Review Skills skill.
2. Never target prod unless the user explicitly says "prod" or "production." This is the guardrail tied to Production Safety.
3. Default to --env local unless told otherwise.
4. Use --format json for structured or piped output, --format table for humans.
5. Quote identifiers that may collide with SQL keywords.

If the user gives a question instead of SQL, the skill translates it; if ambiguous, it lists tables first. Source: skills/engineering/db/SKILL.md, 2026-05-31

Issue

Former page: wiki/skills/issue.md. Runtime source: skills/engineering/issue/SKILL.md, skills/engineering/claude-issue/SKILL.md, skills/engineering/dedalus-issue/SKILL.md

Issue

Create a GitHub issue using the dedalus templates (bug, feature, question). Auto-injects branch + commit context, prompts for the Linear link.

Dedalus-specific. The repo's .github/ISSUE_TEMPLATE/ requires a Linear link at the top of every issue (single source of truth lives in Linear). This skill enforces that contract: it asks for the Linear URL once, fills the template fields, and posts via gh issue create.

When it fires

User says /issue bug <title>, /issue feature <title>, or /issue question <title>. Without an explicit type, the skill asks which template to use.

Linear first

Unless the user explicitly says "no Linear" or supplies --linear N/A, the skill asks once for the Linear URL before creating the GitHub issue. Public-facing issues without a Linear ticket accept N/A.

Template selection

bug-report.yml is a GitHub form; gh issue create --body takes plain markdown, so the skill translates the YAML form fields into a markdown body with matching headings: Linear Issue, Description, Steps to Reproduce, Expected Behavior, Component, Environment, Additional Context.

Auto-injected context

• Current branch (git branch --show-current)
• Last commit (git log -1 --oneline)
• Remote URL (upstream falling back to origin)

Injected into "Additional Context" (bug), "Context" (question), or the body tail (feature).

Rules

• Issue title: short, imperative, no period, under 80 chars. No conventional-commit prefix - that's for PRs, not issues.
• Labels come from the table above. Do not invent new labels.
• Every section gets filled. If a section truly has no content, write N/A rather than deleting it.
• Drop the > [!IMPORTANT] and > [!NOTE] callouts - those are instructions to the filer, not issue content.

Why it's globalized despite being dedalus-shaped

The Linear-first workflow and .github/ISSUE_TEMPLATE/ filenames are dedalus-specific, but the skeleton - "discover templates, ask for ticket link, fill sections, post via gh" - generalizes. Mirrored to ~/.cursor, ~/.claude, ~/.codex on Kevin's call. In repos without those exact templates the skill should fall back to gh issue create on whatever templates exist (or no template), and skip the Linear prompt if the user says --linear N/A or the repo has no Linear. If a repo has none of the expected templates, surface that and let the user pick a different filing path.

Kevin Voice

Former page: wiki/skills/kevin-voice.md. Runtime source: skills/personal/kevin-voice/SKILL.md

Kevin Voice

Write about Kevin in his own credential-forward, third-person fragment voice. Modeled on the "Why?" blurbs from his curated YC job-matching feed.

Trigger

• "write a bio" / "About section" / "intro me" / "describe me"
• "Kevin in one line" / "pitch me" / "candidate blurb"
• Any time a draft is being authored that represents Kevin to an external reader

What it is

A self-positioning voice skill. Compresses real proof points from wiki/career/career-profile.md and wiki/career/resume.md into the fragment-style positioning that Sequoia's recruiting cards generate for him.

Pattern:

[CREDENTIAL NOUN] [optional CONTEXT TAG] with [PROOF NOUNS]

Example: Princeton CS founding engineer with infrastructure and systems experience.

Length variants

Hard rules

• Never invent a fact, company, metric, or title. Every proof noun traces to the resume.
• One angle per blurb. Stack-rank the credential by audience.
• No "I", no peacock words, no three-adjective stacks.
• If a sentence could describe any Princeton CS junior, rewrite it.
• No em dashes and no negative parallelism. Both are AI writing tells. Canonical rule in STYLE "Anti-AI-Tells".

Spoken Answer Mode

When Kevin is answering out loud, the voice changes. Use shorter breath units, fewer stacked clauses, and periods instead of long comma chains. Avoid colons and semicolons. They read like written structure, not speech. Source: User, 2026-05-12

Spoken answers can use first person naturally: "I'm Kevin", "I've been digging", and "I want to pressure-test." Section labels like "Listen for", "Follow-up", and "Watch out for" should become natural sentences because they sound like stage directions when read aloud. Source: User, 2026-05-12

For live answers about Dedalus, connect the FDE story to personal beliefs and growth: owning messy surfaces, learning by doing, sharing tribal knowledge, and becoming useful across product, infra, design, security, DevRel, and company operations. Source: User, 2026-05-12

Out of scope

• Posts in Kevin's voice → social-draft
• Generic marketing copy → copywriting
• Job application pipeline / CV tailoring → career-ops

Files

• Skill: skills/personal/kevin-voice/SKILL.md
• Seed corpus: skills/personal/kevin-voice/references/why-blurb-examples.md
• Proof inventory: skills/personal/kevin-voice/references/proof-bank.md
• Source screenshot: wiki/assets/kevin-voice-why-blurbs.png

Status

• 2026-04-21 | Created from Sequoia / curated YC matching feed "Why?" blurbs Kevin liked. Initial proof bank pulled from career-profile.md + resume.md.

Maintenance

When Kevin lands a new role, ships a notable project, or publishes new work, extend references/proof-bank.md with the new proof nouns. The skill is only as sharp as the proof inventory.

Current proof-bank additions: public builder identity now includes Sigil UI ("building Sigil") and the Loop release as shipped distribution proof. Use these only when the audience cares about design systems, agent skills, or builder-in-public credibility. Source: X/@kevskgs profile snapshot and Loop release bookmark, 2026-05-12

• 2026-05-12 | Added spoken-answer mode: shorter breath units, fewer punctuation-heavy structures, natural first person, and FDE/Dedalus lessons as a growth narrative. Source: User, 2026-05-12

X Bookmark Deep Absorption

Former page: wiki/skills/x-bookmark-absorb.md. Runtime source: skills/productivity/x-bookmark-absorb/SKILL.md

X Bookmark Deep Absorption

Skill that transforms raw X bookmark data into full wiki graph integration. Goes beyond hub-page entries to create dedicated pages, cross-references, resolver updates, and index entries.

Problem

The existing bookmark pipeline (ft sync → sync-x-bookmarks.sh → manual compile) produces entries in hub pages (x-bookmarks-*.md) but stops there. Bookmarks never propagate to dedicated tool/person pages, cross-references between existing wiki pages, _index.md, log.md, or the tool hierarchy. The wiki graph stays disconnected from the signal.

Solution

A 6-phase pipeline: enrich (mandatory) → local media download → hub entries → dedicated pages → cross-reference walk → registry/skill candidates → index and log. Enrichment resolves t.co links, fetches READMEs/articles, reconstructs author self-threads, captures author artifact replies, and summarizes demo media before synthesis.

Enrichment layer (Phase 0)

Run npx tsx scripts/enrich-x-bookmarks.ts before absorbing. Output: raw/x-bookmarks/enriched/<id>.json. Records include resolvedLinks, selfThread, artifactReplies, and media. Cached records missing artifactReplies are refreshed once so older bookmark captures can be backfilled. Source: enrichment pipeline, 2026-06-19

For media-bearing batches, run npm run download:x-bookmark-media -- --synced-date YYYY-MM-DD (or --ids) before page writing. Output lives under wiki/assets/x-bookmarks/<tweet-id>/ with a manifest and local image artifacts by default. Promoted pages should preserve original X artifacts with the ::tweet{ id="..." url="..." } directive rendered by React Tweet, and source-critical resolved links with ::artifact{ url="..." title="..." kind="..." } cards from Wiki Artifact Embeds. Keep videos linked through the source tweet/enriched record unless Kevin explicitly asks for local video preservation. Source: x-bookmark-absorb skill, 2026-06-24

Incremental selection now tracks compile.last_bookmark_synced_at first and compile.last_bookmark_id second. Tweet IDs are chronological by tweet creation, not by Kevin's bookmark action; an old tweet bookmarked today is still new work. Source: 2026-06-24 ingest

Daily Automation

source-compile is the daily automation owner for X bookmark absorption. It runs sync, enrichment, online research, wiki graph updates, skill/tool/router updates when warranted, and index/qmd/log validation. Local Codex is the preferred runner because it can read X/browser-authenticated sources and local transcripts; Cursor cloud can only process committed raw/enriched records. Source: automations/source-compile.md, 2026-06-19

When It Fires

• After any ft sync + bookmark sync
• When Kevin says "absorb bookmarks" or "process bookmarks"
• During source-compile automation targeting x-bookmarks
• When Kevin identifies a date range of unprocessed bookmarks

Origin

Created 2026-05-17 after discovering that 25 bookmarks from May 13-17 had been synced and added to hub pages but never propagated to the rest of the wiki graph. The first run of this skill created 11 new pages and updated 4 existing ones. Source: User request + wiki gap analysis, 2026-05-17

Security and Review Skills

Merged Article Notes

Agent Docs

Former page: wiki/skills/agent-docs.md. Runtime source: skills/productivity/agent-docs/SKILL.md

Agent Docs

Enroll and maintain the Agent-Docs Mesh on any Kevin project: root AGENTS.md, directory SKILL.md files, .agent-docs/ metadata, auto-blocks, and docs-doctor.

When To Use

Use agent-docs when:

• entering a new Kevin-owned repo for the first time
• Kevin says "enroll this repo", "agent docs", "scaffold AGENTS.md", or "docs-doctor"
• substantial project facts changed and auto-blocks need refresh
• a repo lacks nearest-directory SKILL.md coverage
• rolling the mesh from the wiki pilot into Loop, Sigil/Agent Machines, Ariadne, or Dedalus-adjacent repos

Contract

The skill guarantees:

• Existing human prose is adopted, not clobbered.
• Machine-generated sections live in agent-docs:auto blocks.
• Human/agent prose lives in fill slots.
• Root AGENTS.md explains durable repo facts.
• SKILL.md files explain how to work in the repo or directory.
• doctor --json verifies structure and secret hygiene.
• Enrolled repos are tracked in config/agent-docs/registry.json.

Mental Model

The mesh has four artifacts:

Plan 1 shipped AGENTS.md + SKILL.md; the later artifacts are the natural expansion path.

Commands

node --import tsx ~/Documents/GitHub/kevin-wiki/scripts/agent-docs/index.ts init .
node --import tsx ~/Documents/GitHub/kevin-wiki/scripts/agent-docs/index.ts scaffold .
node --import tsx ~/Documents/GitHub/kevin-wiki/scripts/agent-docs/index.ts doctor --json
npm run test:agent-docs

Operating Notes

• Run init per package root in monorepos; one root cannot accurately cover deeply nested apps.
• Missing root docs are failures; missing per-dir skills are rollout warnings.
• Secrets values in docs are failures. Env var names are allowed.
• After substantive edits, refresh auto-blocks and run doctor.
• If a workflow repeats three times, promote it into a real skill or resolver entry.

Source

Executable source: skills/productivity/agent-docs/SKILL.md.

Kit implementation: scripts/agent-docs/. Read scripts/agent-docs/SKILL.md before changing detectors or doctor checks.

Autoreview

Former page: wiki/skills/autoreview.md. Runtime source: skills/engineering/autoreview/SKILL.md

Autoreview

A structured closeout / code-review skill from openclaw/agent-skills. Reviews your code before landing a PR and surfaces edge cases the author missed. Installed at skills/engineering/autoreview/ (live via the ~/.cursor/skills symlink). Source: openclaw/agent-skills README, GitHub

Why installed (2026-06-22): triple-endorsed as a top agent skill — Peter Steinberger ("the most impactful skill I've added to my stack"), @MatthewGunnin ("by far the best skill I've ever installed… now it's autoreview → merge"), and @hungv47 ("/autoreview and /handoff are two of the best agent skills I've ever used"). Bundled sibling Cloud, Data, and Service Skills installed alongside. Source: X/@steipete, 2026-05-27; X/@MatthewGunnin, 2026-06; X/@hungv47, 2026-06

autoreview is the review-closeout workflow in OpenClaw's shared agent-skills repo, alongside crabbox (remote validation), agent-transcript, handoff, and session-viewer. It encodes a write-once, reuse-everywhere review pass so long SKILL.md files do not get hand-copied across repos. Peter Steinberger calls it "the most impactful skill I've added to my stack," noting it finds many edge cases and sometimes runs for hours on a single PR. Source: X/@steipete, 2026-05-27

Standards / Spec Review

Kevin's local autoreview skill now absorbs the useful part of Matt Pocock's review skill instead of adding a duplicate review command. Branch, PR, and "review since X" work should keep two axes separate:

• Standards: whether the diff follows repo-local coding, product, UI, security, and process standards.
• Spec: whether the diff implements the originating issue, PRD, user request, or acceptance criteria.

The separation matters because a change can be conventionally clean and still implement the wrong thing, or implement the right thing while violating project standards. Agents should pin the fixed point, find the true spec source when one exists, find standards sources from AGENTS.md / rules / docs, and report the axes separately. Source: github.com/mattpocock/skills review, commit 8370e760d0251a3738e006aeacec6d1cb31dd208

Install

git clone https://github.com/openclaw/agent-skills.git
scripts/install-skills autoreview          # symlink into the default agent skill dir
scripts/install-skills --target ~/.codex/skills autoreview

Symlink for local dev (edits are live); copy for portable or locked-down setups. The repo recommends vendoring a generated snapshot under .agents/skills/autoreview only for flagship zero-setup repos, treating that snapshot as a distribution artifact rather than the source of truth. Source: openclaw/agent-skills README, GitHub

Where It Fits Kevin's Stack

autoreview is a pre-merge gate, complementary to Kevin's existing review layer: Code Review Graph supplies blast-radius and AST context, Graphite - AI Code Review handles stacked PRs and merge queue, and Security and Review Skills gets a second model's opinion. autoreview pairs naturally with the same repo's Crabbox skill, which leases a remote box, rsyncs the dirty checkout, runs the suite, and collects screenshots/video/JUnit artifacts as before/after PR evidence. Source: Crabbox docs, crabbox.sh

Install candidate (OpenClaw org, MIT, 305 stars). Run the three-gate chain before adopting, per AGENTS.md, and note the OpenClaw/ClawHub malware history when vetting community skills from that ecosystem.

Bugs (CTF Audit)

Former page: wiki/skills/bugs.md. Runtime source: skills/engineering/bugs/SKILL.md, skills/engineering/bugs/SKILL.md, skills/engineering/bugs/SKILL.md

Bugs (CTF Audit)

Adversarial bug hunt. Dispatch one Opus subagent per critical file: "There exists a security or correctness bug here. Locate it or admit failure."

This is a CTF, not a code review. No style nits, no pedantic warnings, no defense-in-depth hand-wringing. The hunters are looking for memory safety violations, logic bugs (TOCTOU, inverted checks), DoS resource leaks, auth bypasses, input validation gaps, protocol violations, and DFA lies. False negatives are acceptable (an agent admitting "no bug found" is honest); false positives are not (we don't reward noise).

When it fires

• Before shipping a new subsystem to production
• After a CVE drops in a dependency or peer project
• Reviewing code that handles untrusted input
• Periodic security hygiene on the attack surface
• User says /bugs or /bugs <scope>

Four phases

1. Map the attack surface. Dispatch an Explore agent to identify security-critical files: untrusted input, unsafe/FFI, auth/secrets, system resources, crypto/protocol, snapshot/restore deserialization. Target 20-30 files.
2. Dispatch hunters. One background agent per file (or small group) with the exact CTF prompt template. Each agent's context section names what the file does, what untrusted input reaches it, and which bug classes to look for. Max 25 agents in parallel; batch into groups of 10 if more.
3. Triage results. Read cited lines, trace data flow, check for upstream guards, classify severity (Critical / High / Medium / Low), deduplicate systemic issues.
4. Report. Consolidated table sorted by severity. Every finding cites file:line + proof sketch (failing test, repro, or Miri output). Files where the agent admitted failure are listed honestly.

Iron rules

• Every finding has a file path, line number, and proof sketch.
• "This looks suspicious" is not a finding.
• Do not fix bugs during the audit - report only. The user decides what to fix and when.
• Verify every Critical and High finding yourself before reporting.

Dedalus attack surface map

The skill ships with a baked-in map of high-value targets across DHV (virtio transport, vsock, vhost-user, memory manager, userfaultfd, migration, postcopy, x86 emulator, HTTP API) and DCS Runtime (gRPC handlers, VM lifecycle, networking, storage daemon, cgroup/QoS, rootfs, workload identity). The Phase 1 explorer adds to this list; it doesn't replace it.

Why it lives in the wiki

The procedure is reusable across any codebase with an attack surface - the dedalus map is a reference, not a constraint. Promoted to global so any repo can /bugs <path> and get the same parallel-hunter flow.

Conductor Skill

Former page: wiki/skills/conductor.md. Runtime source: skills/personal/conductor/SKILL.md

Conductor Skill

Executable personal skill for setting up, configuring, and troubleshooting Conductor workspaces, repository settings, agent harnesses, MCP, scripts, and review flows.

The executable skill lives at skills/personal/conductor/SKILL.md. It should be loaded when the user asks to set up or operate Conductor, write .conductor/settings.toml, configure run/setup scripts, diagnose workspace issues, copy gitignored files into worktrees, configure provider auth, or explain how Conductor coordinates Claude Code, Codex, Cursor, and OpenCode.

Current Product Shape

Conductor is a macOS app for running coding agents in isolated git worktree workspaces. Each workspace has its own branch, files, terminal, diff, checks, pull request state, and .context folder. Conductor is the workspace and review layer around agent harnesses; provider accounts still own auth, model access, and billing. Source: Conductor docs, 2026-06-27

Current docs describe four harnesses:

The upstream official skill at /.well-known/agent-skills/conductor/SKILL.md still described only Claude Code and Codex in one compatibility sentence when this local skill was installed. The local skill uses the current docs' broader harness matrix while preserving the official skill's setup and troubleshooting procedure. Source: Conductor official skill + llms-full.txt, 2026-06-27

Routing

Use this skill before:

• recommending Conductor repository setup
• writing or reviewing .conductor/settings.toml
• deciding between .conductor/settings.toml, .conductor/settings.local.toml, ~/.conductor/settings.toml, and managed settings
• configuring scripts.setup, scripts.run, scripts.archive, CONDUCTOR_PORT, or CONDUCTOR_ROOT_PATH
• deciding whether a project needs run_mode = "concurrent", run_mode = "nonconcurrent", or Spotlight testing
• configuring .worktreeinclude or file_include_globs
• configuring Claude Code, Codex, Cursor, or OpenCode auth for Conductor
• setting up MCP for Claude Code, Codex, or Cursor Composer inside Conductor workspaces
• explaining the review and merge path from Conductor diff/checks to PR

Operational Defaults

For repo setup, inspect the actual local dev loop before proposing settings. The decision hinges on whether the project can run cleanly from arbitrary git worktrees, whether ports can be varied with CONDUCTOR_PORT, and whether shared resources like Docker stacks or local databases make concurrent runs unsafe.

For repeated local work, prefer .conductor/settings.local.toml. For team defaults, use .conductor/settings.toml and remind the user that Conductor applies shared repository settings only after they are merged to the default branch on the remote. For static gitignored files, prefer .worktreeinclude or file_include_globs; for generated files or per-workspace initialization, use scripts.setup.

Timeline

• 2026-06-27 | Installed local conductor skill from the official Conductor agent skill and current docs. Adapted harness coverage to include Cursor and OpenCode per llms-full.txt. Source: https://www.conductor.build/.well-known/agent-skills/conductor/SKILL.md; https://www.conductor.build/llms-full.txt

Copywriting

Former page: wiki/skills/copywriting.md. Runtime source: skills/personal/copywriting/SKILL.md, skills/personal/claude-copywriting/SKILL.md

Copywriting

Conversion copywriting for homepages, landing pages, pricing pages, and feature pages. Clear, compelling, action-driving copy. Based on coreyhaines31/marketingskills (60K weekly installs).

Core Principles

1. Clarity over cleverness - if you must choose, choose clear
2. Benefits over features - what it MEANS for the customer, not what it DOES
3. Specificity over vagueness - "Cut weekly reporting from 4 hours to 15 minutes" not "Save time"
4. Customer language over company language - mirror voice-of-customer from reviews, interviews, support tickets
5. One idea per section - each section advances one argument

Writing Style

• Simple over complex - "Use" not "utilize," "help" not "facilitate"
• Specific over vague - avoid "streamline," "optimize," "innovative"
• Active over passive - "We generate reports" not "Reports are generated"
• Confident over qualified - remove "almost," "very," "really"
• Show over tell - describe the outcome instead of using adverbs
• Honest over sensational - no fabricated stats or testimonials

Quick check: Jargon? Sentences doing too much? Passive voice? Exclamation points (remove)? Buzzwords without substance?

Above the Fold

Headline formulas:

Subheadline: Expands on headline, adds specificity, 1-2 sentences max.

CTA formula: [Action Verb] + [What They Get] + [Qualifier]. "Start Free Trial" not "Sign Up." "Get the Complete Checklist" not "Learn More."

Page Sections

Page-Specific Guidance

Homepage: Serve multiple audiences without being generic. Lead with broadest value prop. Clear paths for different intents.

Landing Page: Single message, single CTA. Match headline to traffic source. Complete argument on one page.

Pricing Page: Help visitors choose the right plan. Address "which is right for me?" anxiety. Make recommended plan obvious.

Feature Page: Feature → benefit → outcome chain. Show use cases and examples.

Output Format

1. Page copy organized by section (headline, subheadline, CTA, body, secondary CTAs)
2. Annotations explaining why each choice was made
3. 2-3 alternatives for headlines and CTAs with rationale
4. Meta content (page title for SEO, meta description)

Deepsec (Vulnerability Scan)

Former page: wiki/skills/deepsec.md. Runtime source: skills/engineering/deepsec/SKILL.md, skills/engineering/deepsec/SKILL.md

Deepsec (Vulnerability Scan)

Run vercel-labs/deepsec against any local codebase. Coding agents (Opus 4.7 / GPT 5.5 at max effort) investigate security-sensitive files, trace data flows, emit actionable findings. Cost-aware: always calibrates with --limit 50 before a full pass.

When it fires

• Kevin says "deepsec", "security scan ", "scan for vulns", "audit for vulnerabilities", or "run a security review on "
• Before shipping a new service to production
• Customer / open-source repo due diligence
• Periodic deep audit on Sigil UI, Dedalus monorepo, or any repo Kevin owns
• After a CVE drops in a peer/customer codebase

The pipeline

init → INFO.md → scan → process → triage → revalidate → export

• init - npx deepsec init at repo root, scaffolds .deepsec/ (config + matchers, checked into git; output gitignored)
• INFO.md - 50–100 lines of project-specific context, injected into every batch's prompt. Highest-impact tunable.
• scan - ~110 regex matchers across the codebase, ~15s, no AI calls
• process - Opus 4.7 / GPT 5.5 investigates each candidate; expensive ($25–1,200 per scan)
• triage - cheap P0/P1/P2 labelling
• revalidate - second agent run including git history; cuts FP rate 50%+
• export - markdown-per-finding directory or JSON

Cost iron rules

• Never run process without --limit first. Always calibrate with --limit 50.
• Never run a full process without Kevin's explicit cost approval. Project the dollar amount, await approval.
• For repos > 1,000 files, propose Vercel Sandbox fanout or --agent codex --model gpt-5.5 as a cheaper backend before suggesting a default Opus run.

Verification rules

• Verify every CRITICAL and HIGH yourself before presenting to Kevin - read cited lines, trace data flow, confirm reachability. deepsec is a hunter, not an oracle.
• 10–20% raw FP rate; revalidate cuts that. Don't show pre-revalidate findings to Kevin without flagging.
• Group MEDIUM findings by class. Discard LOW findings that are pure defense-in-depth with no reachable attacker path.

Compounding signal: custom matchers

After a first scan, prompt the agent to write project-specific matchers based on the auth model, data layer, and team conventions. Each new matcher widens regex coverage with no AI cost. This is how Vercel built their internal "every authentication path" scanner.

Where deepsec sits

• Brin - Agent Context Security - pre-install supply-chain gate (before code enters the repo)
• Security and Review Skills - surgical adversarial audit with subagents per file (small attack surface, $)
• deepsec - complete codebase sweep ($$$, hours, but finds the lurking bugs)
• Lint-Enforced Agent Guardrails - continuous low-cost catches during edit/commit

bugs is "20 critical files now". deepsec is "complete sweep across 2,000 files with real FP processing".

How this connects

• Skill lives at ~/.cursor/skills/deepsec/SKILL.md, mirrored to ~/.claude/skills/deepsec/SKILL.md and ~/.codex/skills/deepsec/SKILL.md
• Tool reference: Security and Review Skills
• Periodic automation that runs scoped scans on Kevin's repos: automations/security-scan.md
• Runs alongside Brin's pre-install gate, Ultracite's continuous lint, and Skill Auditor's installation gate

excalidraw-diagram-generator (Skill)

Former page: wiki/skills/excalidraw-diagram-generator.md. Runtime source: skills/misc/excalidraw-diagram-generator/SKILL.md

excalidraw-diagram-generator (Skill)

Generate Excalidraw diagrams from natural language descriptions. Use when asked to "create a diagram", "make a flowchart", "visualize a process", "draw a system architecture", "create a mind map", or "generate an Excalidraw file". Supports flowcharts, relationship diagrams, mind maps, and system architecture diagrams. Outputs... Installed at skills/misc/excalidraw-diagram-generator/. Source: github/awesome-copilot@excalidraw-diagram-generator, 2026-06-24

Why installed

This was promoted from the 2026-06-24 capability harvest because it is an official or reputable skill for a recurring agent workflow. It gives agents current procedural guidance before they mutate cloud, auth, workspace, design, diagram, AI SDK, or deployment surfaces.

Where it fits

Use this skill when the user asks for an Excalidraw diagram, flowchart, system sketch, or visual process map. For discovery and future updates, use Security and Review Skills and Capability Harvest Pattern. Installation is not permission to make production mutations; check credentials, target project, dry-run support, and user intent first.

Kevin-specific guidance

Use Excalidraw when the important artifact is a reviewable topology, not just a text explanation. For PRs and systems, separate:

• workflow logic, usually the decision path and value movement
• architecture ownership, usually routes, services, stores, and providers

Prefer a standard .excalidraw source file as the artifact of record. Add a GitHub-readable preview, PNG/SVG export, or README link when the diagram needs to be reviewed outside Excalidraw.

The useful pattern from WorkOS is "visual system snapshots": agents can draw the skills, connectors, message paths, data stores, and external services they already know about so humans can onboard, debug, and review without rebuilding the topology from prose. The useful pattern from muthuishere/hand-drawn-diagrams is output discipline: keep source files standard Excalidraw, keep scratch files out of the workspace by default, and export PNG/SVG or animation only when that helps the review channel.

Find Skills

Former page: wiki/skills/find-skills.md. Runtime source: skills/productivity/find-skills/SKILL.md, skills/productivity/claude-find-skills/SKILL.md

Find Skills

Discover and install agent skills from skills.sh. Use when a task might benefit from a specialized skill you don't have. Based on vercel-labs/skills (900K+ weekly installs).

When to Use

• "How do I do X" where X is a common domain task
• "Find a skill for X" or "is there a skill for X"
• A task touches a domain you lack deep procedural knowledge in

CLI

npx skills find [query]           # Search by keyword
npx skills add <source> -g -y    # Install globally, skip prompts
npx skills check                  # Check for updates
npx skills update                 # Update all installed skills

Workflow

1. Check installed skills across skills/{engineering,productivity,personal,misc}/ first
2. Check the skills.sh leaderboard for well-known matches
3. Search: npx skills find <query>
4. Verify quality: install count (1K+), source reputation, GitHub stars, security badges
5. Run Skill Creator + Auditor vetting before installing
6. Install skills to the right skills/<category>/<name>/SKILL.md source folder, then regenerate skills/.runtime/all

Bulk Discovery

For broad ecosystem refreshes, do not install skills directly from search results. Run the capability harvest instead:

npm run harvest:capabilities -- --skills-limit 1000

This writes raw/registries/agent-capabilities/YYYY-MM-DD/skills-sh-best-<limit>.json and the sitemap inventory. The full capability harvest also writes pattern/source coverage so non-installable procedures can promote into skills, wiki pages, automations, or routing tests. Use the snapshot to discover candidates, then promote only the specific skill needed for a task. Source: Capability Harvest Pattern, 2026-06-25

Top Sources

Go Style (Skill)

Former page: wiki/skills/go-style.md. Runtime source: skills/personal/go-style/SKILL.md

Go Style (Skill)

The full Go style reference for Dedalus. Loads the complete guide, decisions, and best-practices documents (about 7000 lines) on demand for edge cases the always-on rules file does not cover.

This skill is the deep-reference companion to the condensed Go Style style guide. The essentials are auto-loaded from .agents/rules/go.md on every Go edit; this skill is invoked only when writing, reviewing, or refactoring Go and that rules file does not address the specific pattern in question. It is read-only, using just Read, Grep, and Glob. Source: skills/personal/go-style/SKILL.md, 2026-05-31

The three documents

The guide is split across three files under docs/src/style/go/, each with a distinct job:

1. Guide (guide.mdx): canonical principles, clarity, simplicity, concision, maintainability, and consistency, plus formatting, MixedCaps naming, and line and file length basics.
2. Decisions (decisions.mdx): normative review decisions. File headers; naming for underscores, packages, receivers, constants, initialisms, and getters; imports; error handling; documentation; struct tags; and testing conventions.
3. Best Practices (best-practices.mdx): practical patterns, function and method naming that avoids repetition, test doubles, util packages, package size, and imports.

Source: skills/personal/go-style/SKILL.md, 2026-05-31

How to use it

The split mirrors two different tasks. When reviewing Go code, consult the Decisions document for the specific normative convention, since those are the calls a reviewer is expected to enforce. When writing new Go code, consult Best Practices for the recommended pattern. Read only the relevant sections for the code at hand rather than the whole reference. Source: skills/personal/go-style/SKILL.md, 2026-05-31

Relationship to other skills

It complements the always-on rules file (essentials) and the condensed Go Style wiki page (quick reference), and its testing-convention guidance overlaps with the Frontend and Design Skills skill for invariant-named, smallest-honest-layer test design. Source: skills/personal/go-style/SKILL.md, 2026-05-31

GStack Review

Former page: wiki/skills/gstack-review.md. Runtime source: skills/engineering/gstack-review/SKILL.md

GStack Review

Staff-engineer code review for bugs that pass CI and fail in production. Use it when Kevin asks for a review, not when he asks for formatting nits wearing a trench coat.

When To Use

Use gstack-review for:

• "review this", "code review", "find production bugs", /review
• pre-merge review of meaningful diffs
• bug-prone changes involving async, auth, data, payments, migrations, or user-visible flows
• reviewing agent-authored code before shipping

Do not use it as a style linter. Formatting belongs to Ultracite/oxlint/project checks.

Contract

The skill guarantees:

• Findings are severity-classified: CRITICAL, HIGH, MEDIUM, LOW.
• CRITICAL/HIGH findings include concrete fixes.
• Obvious fixes are auto-applied when safe.
• Design decisions are presented with options instead of guessed.
• Review focuses on production behavior, not preference.
• Tests/lint are run where relevant.
• Final verdict is SHIP, FIX FIRST, or NEEDS DISCUSSION.

Review Phases

1. Understand the diff: git diff, changed files, blast radius, intent.
2. Production bug hunt: concurrency, error handling, edge cases, security, performance, completeness.
3. Classify findings: severity based on user/data/prod impact.
4. Fix obvious issues: missing awaits, null checks, swallowed errors, typos.
5. Escalate design choices: present 2-3 options and tradeoffs.
6. Report verdict: include remaining risk and test coverage.

High-Value Bug Classes

• Race conditions and async gaps.
• Missing authorization checks.
• Unhandled promise rejections.
• Empty/null/zero boundary failures.
• Date/timezone bugs.
• N+1 queries or unbounded list loading.
• Missing transactional boundaries.
• UI paths without loading/error/empty states.
• Tests that assert implementation details instead of invariants.

Output Standard

Every finding should name:

• file/line
• production impact
• trigger condition
• severity
• fix recommendation or applied fix
• verification performed

Source

Executable source: skills/engineering/gstack-review/SKILL.md.

Hotfix Preview

Former page: wiki/skills/hotfix-preview.md. Runtime source: skills/engineering/hotfix-preview/SKILL.md, skills/engineering/claude-hotfix-preview/SKILL.md, skills/engineering/dedalus-hotfix-preview/SKILL.md

Hotfix Preview

Cherry-pick a commit from dev onto preview without a PR. For urgent fixes that can't wait for the full /promote cycle.

Dedalus-specific. The repo follows a dev → preview → prod branch model with /promote generating a changelog PR for normal promotions. This skill is the escape valve: when a fix on dev needs to reach preview (and then prod) immediately, it skips the PR and cherry-picks directly.

When it fires

A fix is on dev and needs to reach preview right now. The full /promote flow creates a changelog PR that needs review and merge. This skill skips the PR.

Rules

• The commit must already exist on dev. No cherry-picking unmerged work.
• Cherry-pick creates a new SHA on preview. The original SHA stays on dev. Both branches contain the same diff; history diverges by one merge-base commit. Fine - /promote reconciles them on the next full promotion.
• Never force-push preview or dev.

Mechanics

REMOTE="${REMOTE:-upstream}"
git fetch "$REMOTE" dev preview
SHA="${1:-$(git rev-parse "$REMOTE/dev")}"
git merge-base --is-ancestor "$SHA" "$REMOTE/dev"  # validate
WT="$(mktemp -d "${TMPDIR:-/tmp}/hotfix-preview.XXXXXX")"
git worktree add --detach "$WT" "$REMOTE/preview"
git -C "$WT" cherry-pick "$SHA"
git -C "$WT" push "$REMOTE" HEAD:preview
git worktree remove "$WT"

Defaults to dev HEAD if no SHA passed.

Why it's globalized despite being dedalus-shaped

The dev → preview → prod promotion chain is dedalus-specific, but the underlying mechanic - "validate SHA is on the source branch, fast-forward the destination, cherry-pick, push" - generalizes. Mirrored to ~/.cursor, ~/.claude, ~/.codex on Kevin's call. In non-dedalus repos with different branch names, the skill will fail loudly at the git merge-base --is-ancestor check or the git fetch upstream preview step rather than silently doing the wrong thing. Override the source/dest branches per invocation if needed.

Humanizer

Former page: wiki/skills/humanizer.md. Runtime source: skills/personal/humanizer/SKILL.md

Humanizer

Remove AI writing patterns from text, calibrated to Kevin's voice. Based on blader/humanizer (18K+ GitHub stars) and Wikipedia's "Signs of AI writing" guide.

The humanizer skill scans text for 25+ documented AI writing patterns and rewrites them. The upstream skill (blader/humanizer v2.5.1) is based on Wikipedia's WikiProject AI Cleanup, which catalogs patterns observed across thousands of AI-generated articles. Kevin's fork adds a permanent voice profile extracted from his actual writing samples. Source: SKILL.md, GitHub

The voice profile was built from wiki/career/content-backlog.md and wiki/career/content-plan-april-2026-archive.md. Key patterns: short declarative sentences (often one per paragraph), stacking pattern (single words on their own lines), questions as structure, concrete over abstract, first person when it fits. Source: compiled from writing samples, 2026-05-12

For spoken answers, Kevin's voice should be even tighter: shorter breath units, fewer stacked clauses, periods instead of long comma trains, and almost no colons or semicolons. First person should sound like something he would actually say: "I'm Kevin", "I've been digging", "I want to pressure-test." Drafting labels like "Listen for", "Follow-up", and "Watch out for" should be rewritten as natural sentences before the answer is spoken. Source: User, 2026-05-12

Hard cuts (Kevin-specific):

• No em dashes. Periods do the work.
• No negative parallelism ("Not just X, but Y" / "It's not X, it's Y"). Make the positive claim.
• No "increasingly" + adjective.
• No sycophantic openers.

Pattern categories detected: significance inflation, superficial -ing analyses, promotional language, vague attributions, AI vocabulary words ("examine", "tapestry", "ecosystem"), copula avoidance ("serves as"), rule of three, synonym cycling, false ranges, passive voice, em dash overuse, boldface overuse, inline-header lists, signposting ("Let's dive in"), persuasive authority tropes ("At its core"), filler phrases, excessive hedging, generic positive conclusions. Source: SKILL.md

Use when: editing any text Kevin will publish. Social posts, Reddit posts, README copy, application essays, bios, wiki prose. Pair with kevin-voice for positioning blurbs and social-content for distribution strategy. Source: User, 2026-05-12

Invariant-First Coding

Former page: wiki/skills/invariant-first-coding.md. Runtime source: skills/engineering/invariant-first-coding/SKILL.md, skills/engineering/dedalus-invariant-first-coding/SKILL.md

Invariant-First Coding

Reason from proven invariants before coding.

Used when reviewing fallback logic, narrowing types, handling conversions, deciding whether an error path is real or impossible, removing overdefensive code, or when the code is too theatrical, too hedged, or not fail-closed enough.

Core Idea

Before writing error handling or defensive code, ask: "Is this case actually possible given the invariants I can prove?" If a value cannot be null at this point in the control flow (because a check already happened upstream), do not add a redundant null check. If a conversion cannot fail (because the type system guarantees it), do not wrap it in try/catch.

The Process

1. List the invariants that hold at this point in the code (type constraints, prior checks, protocol guarantees).
2. For each error path, determine if it can actually fire given those invariants.
3. If a path is provably impossible, remove the handling (or convert to a debug assertion that documents the invariant).
4. If a path is possible, handle it with a specific, named error.
5. Never add "just in case" error handling that masks real bugs.

Overdefensive Code

Code that handles impossible cases creates three problems: it implies the case is possible (confusing readers), it masks real bugs (the impossible case fires due to an upstream bug but gets silently handled), and it adds visual noise.

The fix: assert the invariant instead of handling the impossible case. If the assertion fires, you have found a real bug.

Last 30 Days

Former page: wiki/skills/last30days.md. Runtime source: skills/personal/last30days/SKILL.md

Last 30 Days

Multi-platform research engine. Searches Reddit, X, YouTube, TikTok, Instagram, HN, Polymarket, GitHub, Bluesky, and the web in parallel - scoring by real engagement (upvotes, likes, views, money) instead of SEO rank - then synthesizing a grounded brief.

last30days (20K+ GitHub stars, v3.0) is the go-to research tool for any topic needing real-time community grounding. It runs a multi-step pipeline: (1) parse user intent (recommendations, news, comparison, prompting, general), (2) resolve X handles + GitHub users/repos + subreddits + TikTok hashtags via pre-research intelligence, (3) generate a query plan with weighted subqueries per platform, (4) execute the Python research engine across all configured sources in parallel, (5) supplement with WebSearch for blogs/news, (6) synthesize using a Judge Agent that weights Reddit/X highest (engagement signals), YouTube high (transcripts), TikTok high (viral signal), and web lower (no engagement data). Source: SKILL.md

Source unlock progression (all free): Zero config (40% quality) = Reddit + HN + Polymarket + GitHub. Add X cookies (60%). Add yt-dlp (80%). Add ScrapeCreators for TikTok/Instagram (100%). No affiliation with any API provider. Source: SKILL.md

Query types: RECOMMENDATIONS (specific named things with mention counts), NEWS (current events), COMPARISON (side-by-side with head-to-head table), PROMPTING (techniques + copy-paste prompts), GENERAL (broad understanding). Comparison mode runs entity-aware subqueries for both sides plus head-to-head. Source: SKILL.md

Output format: "What I learned" synthesis with inline citations (prefer @handles > r/subreddits > YouTube channels > web sources), stats dashboard with emoji tree (Reddit/X/YouTube/TikTok/Instagram/HN/Polymarket/Web), and context-aware follow-up invitation. Raw data saved to ~/Documents/Last30Days/. Agent mode (--agent) skips interactive prompts for automation use. Source: SKILL.md

Key integration: Pairs with wiki search (brain-first lookup mandatory). Wiki has compiled history; last30days has the last 30 days of live community signal. Use for enriching person/tool/project wiki pages, evaluating new tools, during signal-radar or frontier-radar runs, and any "what's happening with X" question. Source: AGENTS.md

No-Sus Code Doctor

Former page: wiki/skills/no-sus-code-doctor.md. Runtime source: skills/engineering/no-sus-code-doctor/SKILL.md

No-Sus Code Doctor

Strict self-audit skill for agent-authored code: fail closed, expose ownership and error surfaces, prove claims empirically, and keep iterating until the score is 100.

no-sus-code-doctor is Kevin's strict self-audit skill for agent-authored code before PR review. It now treats Dedalus repo docs as the governing source of truth, then layers recurring strict-review feedback on top. The skill catches hidden fallbacks, best-effort paths, opportunistic ensure helpers, generic catches, retries/timeouts that mask real bugs, unclear ownership, weak error surfaces, loose types, async/sync misalignment, frontend shortcuts, ops safety issues, and unproven PR claims.

Executable skill: skills/engineering/no-sus-code-doctor/SKILL.md.

When It Should Fire

Use it when Kevin says:

• "no sus code"
• "strict review"
• "get this to 100"
• "quality doctor"
• "review try catches and fallbacks"
• "prove this works"

It should also run before shipping high-risk auth, billing, Stripe, fraud, onboarding, signup-credit, admin, or security changes.

What It Enforces

The skill scores a diff from 0 to 100 and only accepts 100 when there are no blockers, no unresolved warnings, and no mechanism claims without proof. Its source order is repo-local: nearest AGENTS.md, style/style.md, language guides, app docs, agent reviewer docs, then wiki memory. If sources conflict, the agent must record the conflict instead of silently choosing the convenient rule.

It explicitly folds in:

• style/style.md: fail closed, no fallbacks, minimum diff, hard limits, reproduce before patching, scratch-then-clean branches, and review hygiene
• style/typescript.md and docs/src/style/typescript.mdx: type over interface, unknown over any, exact optional types, discriminated unions, @dedalus/result, and suppression discipline
• style/react.md, style/css-ui-enforcement.md, and style/design.md: Rules of Hooks, Tailwind plus cn(), no ordinary module CSS, and purposeful motion
• apps/website/docs/coding-style.md: shippable inspectable TypeScript, JSDoc for load-bearing code, clear module boundaries, and typed third-party errors
• apps/website/docs/testing-strategy.md and .agents/skills/tests/SKILL.md: smallest honest tests, invariant names, realistic fakes, browser/API proof, and guarded external-service tests
• .agents/agents/code-reviewer.md and .agents/agents/style-reviewer.md: silent failure scans, hard limits, naming, docstrings, and YAGNI checks
• .agents/rules/* and docs/src/style/*: language-specific rules for Python, Rust, Go, Terraform, C, and frontend work

Its hard blockers include:

• hidden fallback or best-effort paths
• ensure* helpers that create downstream state outside the owning subsystem
• generic try/catch on value-granting or security-sensitive flows
• retries, sleeps, or longer timeouts used to sidestep ordering bugs
• missing typed error codes
• TypeScript errors that should be discriminated unions or @dedalus/result
• fire-and-forget async where the next step depends on completion
• polling used to paper over local ownership/order problems instead of an event-driven handoff
• trusting client-provided identity or credit state
• granting credits/value before the canonical gate records allow
• multiple sources of truth for one decision
• file-wide, directory-wide, or project-wide lint/type suppressions
• PR body or test plan claims not proven empirically
• global types where a local subsystem type should own the contract
• types.ts or errors.ts god files that mix unrelated domains
• predicate/action combo helpers such as doFooIfBar
• route/component adapter files containing policy that belongs in a service
• loose casts or provider payloads leaking through internal layers
• UI changes without real browser verification
• unnecessary useEffect or hook-based state where render-time derivation or an action boundary is cleaner
• production or infrastructure changes without the required safety proof

The workflow is doctor-style: state the invariant, freeze scope, define the interface, map ownership, run smell scans, read the diff linearly, prefer test-driven invariant proof where practical, prove behavior with tests/build/browser/API checks, fix blockers serially, batch warnings, and re-score until 100.

Why It Exists

Generic review is too late for recurring agent mistakes. This skill makes the agent internalize the review rubric before asking humans or second-model reviewers to look. It is especially useful for Dedalus PRs where correct operation matters more than plausible-looking code.

Timeline

• 2026-06-24 | Kept this page focused on the no-sus audit skill; moved general skill/catalog pairing guidance to the global skill docs and setup checks. Source: User request, 2026-06-24
• 2026-06-24 | Removed person-name triggers and phrasing from the skill docs. The durable concept is strict review, not person-specific incantations.
• 2026-06-23 | Created after the Stripe Radar/onboarding refactor discussion. Kevin asked for a resilient quality-doctor skill that encodes recurring strict-review feedback and drives agent-authored changes to a 100 score before shipping.
• 2026-06-23 | Expanded the skill from a Radar-review rubric into a Dedalus STYLE-informed doctor. It now synthesizes style/style.md, language guides, website coding/testing docs, agent reviewer docs, and operational safety rules into one audit matrix.
• 2026-06-23 | Added Kevin's second pass of no-sus rules: retries and timeout increases are usually bug masks, functions should stay stateless and avoid predicate/action combos, lint suppressions must be line-level with justification, PR templates need proof receipts, comments and file preambles must orient a new reader, types.ts/errors.ts can become god files, @dedalus/result and discriminated unions should carry expected TypeScript failures, React hooks need skepticism, and event-driven handoffs beat polling. The file-preamble guidance cites CockroachDB's pkg/gossip/gossip.go as the shape to emulate at a shorter Dedalus scale.

OG Metadata Audit

Former page: wiki/skills/og-metadata-audit.md. Runtime source: skills/personal/og-metadata-audit/SKILL.md

OG Metadata Audit

Audit and fix OpenGraph and Twitter card metadata in Next.js App Router projects. Cross-references metadata exports across pages, identifies missing fields, DRY violations, broken middleware, and incorrect canonicals. Triggers: "audit OG", "fix opengraph", "twitter cards broken", "metadata audit", "OG not working", "social preview broken".

What It Does

A 6-step audit that walks any Next.js App Router project and produces a concrete fix list:

1. Inventory every export const metadata and export async function generateMetadata
2. Check root layout for required fields: metadataBase, title.default + template, description, openGraph, twitter, robots, alternates.canonical
3. Check child pages for explicit alternates.canonical (silent canonical inheritance is the #1 SEO bug)
4. Check middleware is named middleware.ts with export middleware (not proxy.ts / proxy())
5. Check OG image route returns image/png at 1200x630 with cache headers
6. Check metadataBase resolution - must hit production domain, not *.vercel.app

Required Tag Checklist

Full list of OpenGraph + Twitter tags every public page needs (og:title, og:description, og:url, og:image + width/height/type/alt, og:type, og:site_name, og:locale, plus Twitter equivalents). The Twitter namespace is still twitter:, not x:.

DRY Pattern: buildPageMetadata

When 3+ pages repeat the same openGraph/twitter block, the skill extracts a buildPageMetadata({ title, description, path, keywords?, absoluteTitle? }) helper that collapses 20-line metadata blocks to 4 lines. Includes a parallel pattern for generateMetadata on dynamic pages.

Common Failures Table

htmlLimitedBots + Social Bot Middleware

The skill distinguishes two bot pathways:

• htmlLimitedBots (next.config.ts regex) - Next.js serves lightweight HTML to listed bots (Googlebot, Bingbot, GPTBot, ClaudeBot, PerplexityBot)
• Social bot middleware (custom middleware.ts) - intercepts Twitterbot, facebookexternalhit, etc. and returns a minimal HTML document containing only <meta> tags (no React, no JS)

Together they cover all crawler types without relying on the full app rendering correctly for bots.

Where It Lives

• Skill source: skills/og-metadata-audit/SKILL.md (mirrored to ~/.cursor/skills/og-metadata-audit/SKILL.md)
• Auto-installed via bash skills/README.md install block

See Also

• Security and Review Skills - broader technical SEO audit
• Security and Review Skills - AI search optimization
• SEO/GEO/AEO/AX Implementation - JSON-LD, llms.txt, robots, sitemap implementation patterns
• Website Frontend - Dedalus frontend stack where this skill is regularly used

Resume Architect

Former page: wiki/skills/resume-architect.md. Runtime source: skills/personal/resume-architect/SKILL.md

Resume Architect

The single owner of resume craft: a 5-stage pipeline that makes a resume un-rejectable for a specific role, backed by live research of what actually gets people hired.

Synthesized from four sources that each covered only part of the problem: the popular Diagnoser/Recruiter/Rewriter/Hiring-Manager Claude persona strategy, the proficiently job-search skills (deep work-history profile, strict-accuracy rules, mandatory self-critique pass), an expert tech-resume ruleset (formatting non-negotiables, section order by career level, special cases), and Kevin's own Application Standout Protocol. Source: User, 2026-06-15

The pipeline

What makes it different

Stage 2 is the differentiator. Other resume tools tailor to one JD's wording and guess what matters; Resume Architect pulls real signal (real postings across the role/level, profiles of people currently in the role, "how I got into X" writeups via last30days + agent-reach) and benchmarks against it. The benchmark is evidence-tagged, never invented from model memory. Source: skills/personal/resume-architect/references/research-playbook.md

Scope (MECE)

Owns resume craft (diagnose, research-benchmark, rewrite, mock-interview, profile). Hands job-search orchestration (find roles, score portals, track, negotiate, outreach) to Writing and Content Skills, which delegates resume generation here. For Kevin, the Rewriter output must pass the Application Standout Protocol Pre-Submit Checklist before it is presented.

Accuracy

Conflict order: accuracy > user corrections > workflow > writing quality > format > tone. Only enhances and reframes real facts from the resume or profile — never fabricates numbers, companies, titles, technologies, or scope. Gaps are filled with adjacent real experience or named honestly, never invented. Source: SKILL.md § Accuracy

SEO Audit

Former page: wiki/skills/seo-audit.md. Runtime source: skills/personal/seo-audit/SKILL.md, skills/personal/claude-seo-audit/SKILL.md

SEO Audit

Complete SEO auditing across 5 priority areas. Based on coreyhaines31/marketingskills (69K weekly installs).

Audit Priority Order

1. Crawlability & Indexation - can search engines find and index it?
2. Technical Foundations - Core Web Vitals (LCP <2.5s, INP <200ms, CLS <0.1), mobile, HTTPS, URL structure
3. On-Page Optimization - title tags (50-60 chars, keyword near start), meta descriptions, heading hierarchy (one H1), internal linking
4. Content Quality - E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness)
5. Authority & Links - credibility signals

Schema Detection Limitation

web_fetch and curl cannot reliably detect structured data - many CMS plugins inject JSON-LD via JavaScript. Use browser tools, Google Rich Results Test, or Screaming Frog instead.

Social Preview / OG Cards

• Middleware must be middleware.ts exporting middleware - proxy.ts silently ignored by Next.js
• twitter: namespace is permanent (not x:)
• Root robots must include googleBot["max-image-preview"]: "large" for full-size cards
• Every page needs its own alternates.canonical (Next.js child pages inherit root / without it)
• metadataBase must resolve to production domain, not *.vercel.app
• htmlLimitedBots in next.config.ts covers SEO/AI crawlers middleware doesn't catch
• See og-metadata-audit skill for the full OG audit workflow

Quick Commands

curl -sL "https://example.com" | rg -i "<title>|<meta name=\"description\""
curl -s "https://example.com/robots.txt"
curl -s "https://example.com/sitemap.xml" | head -50

AI Bot Access (Verify in robots.txt)

Googlebot, Bingbot, GPTBot, ChatGPT-User, ClaudeBot, PerplexityBot - all should be allowed if AI visibility is the goal.

Output Format

Executive summary → per-finding (issue, impact, evidence, fix, priority) → prioritized action plan (critical fixes → high-impact → quick wins → long-term).

SEO/GEO Optimization

Former page: wiki/skills/seo-geo-optimization.md. Runtime source: skills/personal/seo-geo-optimization/SKILL.md

SEO/GEO Optimization

Optimize for AI search engines (ChatGPT, Perplexity, Gemini, Copilot, Claude) and traditional search. Based on resciencelab/opc-skills (21K weekly installs).

9 Princeton GEO Methods

Best combination: Fluency + Statistics = maximum boost.

5 Required Rules

1. Keyword placement - primary keyword in 4+ of: URL, title tag, meta/social title, H1, H2, body intro
2. Entity placement - primary + supporting entities in title, H1, intro, schema
3. Entity gap analysis - extract from competitors, add missing relevant entities
4. JSON-LD schema - in page <head>, not client-side injection only
5. Schema entity reinforcement - mirror on-page entities in schema fields

Platform Strategies

AI Citability (134-167 word blocks)

1. Question-based H2, direct answer in first 1-2 sentences
2. Self-contained - names subject, no dangling pronouns, at least one fact
3. Clean H2-H3 nesting, short paragraphs, lists, tables
4. Statistical density - percentages, dollar values, dated claims
5. Uniqueness - original data, case studies, experiments

Next.js OG Implementation

• buildPageMetadata pattern: one helper returns { openGraph, twitter, alternates } - eliminates 15-line boilerplate per page
• Middleware naming: must be middleware.ts exporting middleware - proxy.ts is silently ignored
• max-image-preview: "large" in root robots for full-size social cards
• Canonical inheritance trap: child pages without alternates.canonical inherit root /
• htmlLimitedBots in next.config.ts complements middleware for SEO/AI crawlers
• twitter: namespace is permanent - did not change with the X rebrand
• See og-metadata-audit skill for the full audit workflow

Simple - Five-Part Diagnosis Template

Former page: wiki/skills/simple.md. Runtime source: skills/engineering/simple/SKILL.md, skills/engineering/dedalus-simple/SKILL.md

Simple - Five-Part Diagnosis Template

A single reasoning template. Every answer has the same five parts in the same order: problem, evidence, proposal, mechanism, falsifiable test. No headers, no bullets, no preamble. The shape teaches whoever reads it to think in cause and effect.

When It Fires

Triggers: "explain why", "what's the problem", "propose a fix", /simple. Use after completing a diagnostic investigation, when the user asks for a root-cause explanation, or when a debugging write-up is needed.

The Contract

Respond in exactly five sentences or short paragraphs, in this order:

1. X is the problem. State the root cause in one sentence. Name the actual thing, not a symptom. "The code is slow" means you have not finished diagnosing.
2. We know this because Y. Cite evidence - measurements, strace output, log lines, code paths, invariants, benchmarks. Numbers beat adjectives. No evidence = guessing, stop.
3. I propose we use Z to fix this. One concrete intervention, not a list of options. Specific enough that a reader could act on it without follow-up.
4. This is because Z does {mechanism} that helps this problem. Explain how the fix acts on the cause. The reader should predict behavior from first principles, not take your word.
5. We can test and reproduce this by {methodology}. A command, benchmark, pjdfstest run, or targeted reproducer. The experiment must be able to falsify the proposal, not just confirm it.

End with: Give it a try.

Rules

• One cause per answer. Two causes → two /simple answers.
• No hedging. "This might be the problem" means you don't know. Go measure.
• No options menu. Picking between alternatives is a different kind of answer.
• Mechanism before methodology. If you can't explain how the fix works, your test plan is cargo-culted.
• Falsifiable test. The methodology must show the proposal is wrong, not just that some improvement happened.
• Evidence is load-bearing. Never skip part 2.

When NOT to Use

• Open-ended design discussions with no single fix
• Code reviews (use prefixed comments)
• Greentext-style sequential walkthroughs (use Agent Engineering Skills)
• Status updates or progress reports

Why It Works

The template enforces the discipline that distinguishes a real diagnosis from a vibe-check. Each part blocks a common failure mode: vague root-causing (part 1), unsupported claims (part 2), wishy-washy recommendations (part 3), cargo-culted fixes (part 4), and confirmation-bias tests (part 5). The format is shaped so you can copy-paste it into a Jira ticket, a postmortem, or a commit message and a reader can act on it.

Inspired by Linus Torvalds-style diagnostic writeups - see Frontend and Design Skills for the broader "good taste" lineage.

Relationship to Other Skills

• Security and Review Skills - older / sibling skill with the same intent. The simple skill is the canonical version.
• Security and Review Skills - runs the minimal correct algorithm against the current implementation. Use counterfactual to find the cause, then simple to report it.
• Empirical Verification - the methodology rule (part 5) operationalizes this concept.
• Security and Review Skills - a simple answer is the building block of a multi-cause postmortem.
• Agent Engineering Skills - when the answer is sequential / story-shaped instead of cause-and-effect.

Examples

The skill file ships with two worked examples: a FUSE open/close latency diagnosis and a vhost-user-fs eventfd leak. Both show the template applied to real DCS infrastructure debugging.

Where It Lives

• Skill source: skills/simple/SKILL.md (mirrored to ~/.cursor/skills/simple/SKILL.md)
• Auto-installed via bash skills/README.md install block

Simple Diagnosis Template

Former page: wiki/skills/simple-diagnosis-template.md. Runtime source: skills/engineering/simple-diagnosis-template/SKILL.md

Simple Diagnosis Template

A five-part reasoning template that forces every technical answer into: root cause, evidence, proposal, mechanism, falsifiable test. Invoked via /simple.

The /simple skill enforces cause-and-effect structure on diagnostic answers. Every response follows the same shape: name the actual problem (not a symptom), cite measurable evidence, propose one concrete fix, explain the mechanism by which the fix addresses the cause, and provide a falsifiable experiment. The template eliminates hedging, options menus, and cargo-culted test plans. Source: User, 2026-04-23

The skill complements /greentext (sequential walkthroughs) and the postmortem skill (incident reports). Where /greentext explains what happens, /simple explains why it broke and how to fix it. The key constraint is "mechanism before methodology" - if you can't explain how a fix works from first principles, the test plan is meaningless. Source: User, 2026-04-23

When to use: root-cause explanations, fix proposals, debugging write-ups, "explain why X", "what's the problem", "propose a fix", or invoking /simple. When not to use: open-ended design, code reviews, sequential walkthroughs, status updates. Source: User, 2026-04-23

The five parts, in order:

1. X is the problem - one-sentence root cause, not a symptom
2. We know this because Y - measurements, traces, code paths (numbers beat adjectives)
3. I propose we use Z - one concrete fix, specific enough to act on
4. This is because Z does {mechanism} - explain how the fix acts on the cause
5. We can test this by {methodology} - a falsifiable experiment that can disprove the proposal

Ends with: Give it a try.

Skill Auditor

Former page: wiki/skills/skill-auditor.md. Runtime source: skills/engineering/skill-auditor/SKILL.md, skills/engineering/claude-skill-auditor/SKILL.md

Skill Auditor

6-step security vetting protocol for agent skills. Run before installing any new skill. Based on useai-pro/openclaw-skills-security. Part of the three-gate quality chain.

6-Step Protocol

Three-Gate Chain

All three must pass before installing any skill:

1. Brin - curl https://api.brin.sh/skill/<owner>/<repo>. Block if suspicious/dangerous.
2. Skill Auditor - 6-step protocol above. Must verdict SAFE.
3. Reputation signals - install count, source reputation, stars, security badges.

Dangerous Permission Combos

Social Content

Former page: wiki/skills/social-content.md. Runtime source: skills/personal/social-content/SKILL.md, skills/personal/claude-social-content/SKILL.md

Social Content

Social media content creation, scheduling, repurposing, and optimization. Based on coreyhaines31/marketingskills (40K weekly installs). For Kevin-specific positioning and quality gates, see Social Content OS and Frontend and Design Skills.

Platform Reference

Content Repurposing (Content Atoms)

Extract self-contained moments from long-form content:

Per long-form piece: 3-5 clips, 1-2 LinkedIn posts, 1 X thread, 1 carousel.

Hook Formulas

Curiosity: "I was wrong about [belief]." / "[Result] - only took [time]." Story: "Last week, [unexpected thing]." / "3 years ago, [past]. Today, [present]." Value: "How to [outcome] (without [pain]):" / "Stop [mistake]. Do this instead:" Contrarian: "[Common advice] is wrong. Here's why:"

Engagement (30 min/day)

1. Respond to comments (5 min)
2. Comment on 5-10 target accounts (15 min)
3. Share/repost with insight (5 min)
4. 2-3 DMs to new connections (5 min)

Social Draft

Former page: wiki/skills/social-draft.md. Runtime source: skills/personal/social-draft/SKILL.md

Social Draft

Platform-optimized drafting and rewriting for X and LinkedIn.

Turns one idea into drafts that feel specific, sharp, and credible. Requires a structured input: topic, claim, proof, why it matters, goal, tone, constraints. If proof is missing, the skill uses qualitative specificity or placeholders rather than inventing evidence.

Drafting Workflow

Distill the idea into one claim, find the strongest proof block, decide the mode (teach, reveal, provoke, or reflect), pick format (X single/thread, LinkedIn story/list), write the opening first, then cut every sentence that sounds generic when detached from the proof.

Input Contract

Minimum viable input is not "write about X." It is: topic, claim, proof, why it matters, goal, tone, and constraints. If proof is missing, the skill must either ask for it, use clearly marked placeholders, or write from qualitative specificity without inventing evidence. Source: skills/personal/social-draft/; Social Draft

Platform Rules

• X: under 140 characters for single posts, under 110 for sharp takes. Links in reply. One emoji max. Preferred openings: specific result, contrarian take, build tension, field note.
• LinkedIn: win the first two lines. Paragraphs 1-2 sentences. Under 1300 characters. 3-5 hashtags at bottom only. Structures: story, contrarian, list, lesson learned.

Tone Modes

• Casual: tighter sentences, lighter language, more immediacy. Avoid slang that weakens credibility.
• Professional: clean sentences and explicit lessons. Avoid consulting voice and over-hedging.
• Thought-leader: sharper framing and broader implication. Avoid prophecy without proof.

Anti-Patterns

Cut on sight: "thrilled to announce", "humbled", "inflection point", "leveraging", "ecosystem", "the future is here", generic gratitude paragraphs. If the post could have been written by a random founder-content account, it is not ready.

AI writing tells (hard cut)

Two patterns make a post read as AI-written even when the proof is real. Cut both on sight when drafting in Kevin's voice. Canonical rule: STYLE "Anti-AI-Tells" section.

• No em dashes (-, –, --). Use periods, commas, colons, or parentheses. Only exception: Kevin used one in source material; preserve, never introduce.
• No negative parallelism: "Not just X, but Y." / "It's not X, it's Y." / "X isn't the goal. Y is." Make the positive claim directly.

Teacher Mode

Former page: wiki/skills/teacher-mode.md. Runtime source: skills/engineering/teacher-mode/SKILL.md

Teacher Mode

A personal Cursor skill that turns the agent into a teacher who verifies the human deeply understands the work it just did — incrementally, with a running checklist, restate-first, why-drilling, and a quiz — before the session is allowed to end.

The skill encodes a prompt Kevin uses to stay in the loop on agent-generated work (his framing: "how Anthropic people stay in the loop with Claude and fully understand the work being done"). It is the executable form of Staying in the Loop with Agents and the antidote to the "human becomes the memory layer" failure mode. Source: User, 2026-06-01

What it does

Confirms mastery incrementally (each stage before the next), at both high level (motivation) and low level (business logic, edge cases), against a running markdown checklist with three buckets: (1) the problem + why it existed + the branches, (2) the solution + why resolved that way + design decisions + edge cases, (3) the broader context + impact. It has the human restate their understanding first to locate gaps, drills the whys (plus what/how), offers eli5 / eli14 / elii (explain like an intern), quizzes via AskQuestion (shuffled answer order, hidden until submitted), shows code or the debugger as evidence, and enforces a /goal completion gate: the session does not end until every item is demonstrably mastered. Source: SKILL.md, 2026-06-01

Why it works

Active recall (restate + quiz) + the Feynman technique (teach it back simply) + a hard completion gate, pointed at agent-generated work. Understanding the problem is prioritized over memorizing the solution — a human who owns the problem can re-derive the fix. See Staying in the Loop with Agents. Source: compiled, 2026-06-01

Invocation

Personal Cursor skill at skills/engineering/teacher-mode/SKILL.md (loaded via the ~/.cursor/skills symlink). Triggers: "teacher mode", "/teacher", "teach me this session", "make sure I understand", "walk me through what you did", "quiz me", "eli5 / eli14 / elii", "stay in the loop".

Anti-patterns

End-of-session dumps instead of incremental checks; advancing before mastery; revealing quiz answers before submission or always using the same answer slot; quizzing "what" while skipping "why"; accepting "yeah I get it" instead of a restatement or correct answer.

Wiki Doctor

Former page: wiki/skills/wiki-doctor.md. Runtime source: skills/productivity/wiki-doctor/SKILL.md

Wiki Doctor

Unified health check for Kevin's agent system: wiki structure, skills, rules, automations, and config sync.

Run this after large wiki edits, before committing, and whenever the brain feels weird in the walls.

Command Surface

npx tsx scripts/doctor.ts
npx tsx scripts/doctor.ts --quiet
npx tsx scripts/doctor.ts --verbose
npx tsx scripts/doctor.ts --json
npx tsx scripts/doctor.ts --min-score 90
npx tsx scripts/doctor.ts --only wiki
npx tsx scripts/doctor.ts --only skills
npx tsx scripts/doctor.ts --only rules
npx tsx scripts/doctor.ts --only automations
npx tsx scripts/doctor.ts --only config-sync

scripts/lint.ts is a compatibility wrapper for doctor.ts --only wiki.

Five Layers

Scoring

The doctor uses the Security and Review Skills rule-scoring method:

score = 100 - 1.5 * error_rules - 0.75 * warn_rules

It scores unique failing checks, not occurrences. One hundred broken links is one warning rule, not one hundred penalty points. The point is systemic fixes.

Fix Loop

1. Fix failures first.
2. Batch warnings when safe.
3. Re-run the narrow doctor or full doctor.
4. Rebuild index/qmd if content changed.
5. Update the log.
6. If the failure class will recur, encode a new rule/doctor/check.

Self-Heal

scripts/self-heal.ts sits above the doctor:

npx tsx scripts/self-heal.ts
npx tsx scripts/self-heal.ts --apply

It triages findings into auto-safe, agent-fix, escalate, or noise, applies deterministic safe fixes, and re-runs the doctor. Content fixes still need review or a PR.

Outputs

• wiki/meta/doctor-results.json
• wiki/meta/doctor-history.json
• state.json

Source

Executable skill: skills/productivity/wiki-doctor/SKILL.md.

Implementation: scripts/doctor.ts.

Agent Operations Skills

Merged Article Notes

Commit and Push

Former page: wiki/skills/commit-and-push.md. Runtime source: skills/productivity/commit-and-push/SKILL.md

Commit and Push

Stage, commit, and push - after a pre-commit interview, not blind automation.

Owns the explicit "commit and push" workflow when Kevin wants work shipped without a PR. Distinct from yeet (commit + push + PR).

What changed (2026-05-22)

The skill now requires a pre-commit interview before staging. Agents inspect the tree, cluster changes by theme, and ask Kevin about branch target, scope (especially when multiple conversations or agents contributed), exclusions, wiki housekeeping, and skill gaps.

No default branch assumption - agents ask whether to push to main, the current branch, or a new kevin/<slug> branch. Source: User, 2026-05-22

Workflow summary

1. Inspect - status, diff stats, branch tracking, commit style
2. Interview - branch, scope/clusters, exclusions, wiki checks, skill gaps, validation
3. Confirm - wait for Kevin unless all ambiguity was resolved upfront
4. Stage intentionally - never git add -A on mixed trees without confirmation
5. Commit - repo-native message, respect pre-commit hooks
6. Push - with upstream tracking
7. Report - hash, included/excluded, housekeeping done or deferred

Wiki housekeeping prompts

When wiki/, skills/, or config/ change, the skill prompts for:

• npx tsx scripts/build-index.ts
• wiki/log.md append
• bash scripts/sync-skills.sh --check
• qmd update && qmd embed
• npx tsx scripts/doctor.ts

Kevin can waive any of these explicitly; agents should not skip silently.

Why it exists

Sessions kept re-running manual branch/stage/commit/push. A blind version shipped the wrong branch and missed wiki follow-ups. The interview step prevents that. Source: compiled from session feedback, 2026-05-22

Writing and Content Skills

Merged Article Notes

iMessage to People

Former page: wiki/skills/imessage-to-people.md. Runtime source: skills/personal/imessage-to-people/SKILL.md

iMessage to People

Sync Kevin's iMessage contacts into wiki person pages following wiki/people/STYLE.md. One command from extraction → ranked plan → drafted pages.

Trigger

• "sync iMessage" / "pull iMessage contacts"
• "who am I texting most"
• "update my people pages"
• "add new people from my messages"

Pipeline

1. Extract - Kevin runs ./scripts/sync-imessage.sh from a terminal with macOS Full Disk Access (Cursor's embedded shell can't read ~/Library/Messages/chat.db)
2. Resolve - scripts/resolve-imessage.py matches handles to AddressBook records, dedups split iMessage+SMS+RCS handles
3. Plan - scripts/build-people-plan.py assigns tiers (T1 ≥400 msgs or family; T2 100–400 with context; T3 <100)
4. Draft - read each contact's message samples, write pages following wiki/people/STYLE.md (factual sections clean, personal sections preserve Kevin's voice in paragraphs)
5. Stubs - scripts/gen-t3-stubs.py auto-generates Tier 3 stubs from metadata + first 3 sample messages
6. Index - scripts/regen-people-index.py rebuilds the People section of wiki/_index.md

Privacy

raw/imessage/ is gitignored. Extractions stay local. Person pages in wiki/people/ ARE committed - quote sparingly, characterize dynamics, don't dump vulnerable exchanges verbatim.

Notability Gate

Per AGENTS.md: ≥10 messages in a year + identifiable name = eligible for a page. Sensitive third parties (exes, etc.) get wikilinks only, not dedicated pages, unless Kevin says yes.

Files

• Skill: ~/.cursor/skills/imessage-to-people/SKILL.md
• Scripts: scripts/sync-imessage.sh, scripts/resolve-imessage.py, scripts/build-people-plan.py, scripts/gen-t3-stubs.py, scripts/regen-people-index.py
• Style: wiki/people/STYLE.md
• Output: wiki/people/*.md

Status

• 2026-04-19 | First run - 82 person pages generated from a single extraction (16 T1, 19 T2, 42 T3 stubs, 7 unresolved skipped). See wiki/log.md 2026-04-19 entry.

Future

• AttributedBody decoder for the modern messages where text is null
• Group-chat parsing to surface friend-cluster topology
• Cross-source enrichment with raw/calendar/, raw/email/, raw/meetings/
• Codex automation: weekly detect-new-contacts run that opens a PR

Media Generation Skills

Merged Article Notes

ElevenLabs SFX

Former page: wiki/skills/elevenlabs-sfx.md. Runtime source: skills/misc/elevenlabs-sfx/SKILL.md

ElevenLabs SFX

Generates sound effects as MP3 via ElevenLabs Text-to-Sound-Effects API. Executable: skills/misc/elevenlabs-sfx/SKILL.md (symlinked to ~/.cursor/skills/). Source: skills/misc/elevenlabs-sfx/SKILL.md

Generates sound effects as MP3 via ElevenLabs Text-to-Sound-Effects API. Executable: skills/misc/elevenlabs-sfx/SKILL.md (symlinked to ~/.cursor/skills/).

Adapted from doxdox /sfx command. Source: User, 2026-06-12

When to use

Sound effects, ambient audio, UI clicks, game SFX — triggers on /elevenlabs-sfx, /sfx, or any "generate a laser sound" request. Not for speech TTS or music beds.

After generation, wire playback with @web-kits/audio (defineSound, registry patches, prefers-reduced-motion).

Requirements

Get keys: elevenlabs.io/app/settings/api-keys

Workflow

1. Resolve API key; confirm variation count (paid per generation).
2. Refine prompt (duration 0.5–30s, loop, prompt_influence ~0.3).
3. POST /v1/sound-generation → outputs/sfx/{name}.mp3 (or .claude/elevenlabs-sfx/ per skill default).
4. Validate with file (must be MPEG, not JSON error).
5. Iterate: pick / regenerate / tweak.

Stack fit (Kevin)

Enforced in tool-hierarchy.mdc § Sound effects — tier 1 for agent-driven SFX.

---

Timeline

• 2026-07-01 | Added the top-level usage rule: this ledger is searchable archive/provenance, while current execution lives in skills, current inventory in Skill Registry, and generated closeout follows Generated Surface Contract. Source: User request, 2026-07-01
• 2026-06-27 | Archived retired skill article notes before regenerating concise skill-family pages. Source: User request, 2026-06-27