skills

Project-specific coding conventions and constraints. Use when writing, modifying, or refactoring any code, implementing features, writing tests, or building MCP servers in this project.

Factor a single-file browser game (a yuwakisaweb-style canvas prototype — one big index.js of module-level state, an immediate-mode render(), and inline event listeners) into a server-portable five-module split: GameArtifacts, GameDisplayArtifacts, GameState, GameEngine, GameUI. Use when asked to "factor/refactor this game", split a monolithic game into GameEngine/GameState/GameUI, make a prototype "portable to a server" or to yuwakisacloud, separate rules from rendering, or add seeded/reproducible RNG to a canvas game. Also use when deciding where a new game feature (terrain, skills, affixes, locations, combat) belongs across those modules.

Design principles for tactics and strategy games. Use when designing new mechanics, tuning existing systems, adding units or abilities, adjusting difficulty, or making any game design decision. Triggers on discussions about game balance, unit roles, terrain, pacing, spawning, healing, combat, win/loss conditions, or UI for conveying game state.

Implement an app from SPEC.md, then review JS, CSS, and update the spec. Use after creating or updating a SPEC.md file.

Write and maintain SPEC.md technical specifications. Use when the user asks to create, update, or review a SPEC.md file, or when planning a new feature/application that needs a specification document. Also use when the user mentions "spec", "specification", "requirements document", or asks to document what a system should do.

Onboarding guide for Python programmers moving to Java 21 + Spring Boot 3. Half "getting into the Java groove" (syntax, types, collections, tooling), half "getting into Spring Boot" (annotations, DI, controllers, config). Use when writing Java for the first time, translating Python instincts into Java idioms, or explaining Java concepts to a Python-fluent user. For code in a running project, see java-spring-boot. For bootstrapping a new project, see java-spring-boot-coldstart.

Bootstrap and build Java 21 Spring Boot 3 services for a team with mixed Java experience. Covers REST APIs, SQS messaging via Spring Cloud AWS, Spring Security 6 (JWT resource server), and JUnit 5 + Mockito testing. Maven, no Lombok. Use when creating a new Spring Boot project, adding REST endpoints/SQS listeners/security config, or writing tests against Spring components.

Best practices for Java 21 web services and Spring Boot 3 applications. Use when writing or reviewing Java code in a Spring Boot project — controllers, services, configuration, data access, tests. For bootstrapping a brand-new project, see java-spring-boot-coldstart instead.

Rank and analyze self-owns across literature, history, current events, and user-submitted scenarios. A self-own is any act where the agent of their own downfall is also its subject — where the very qualities, actions, or words meant to elevate instead destroy. Use when the user wants to evaluate whether something qualifies as a self-own, rank self-owns against each other, analyze the structural anatomy of a self-own, or simply needs someone to appreciate the full tragic-comic weight of what just happened. Also use when the user says /self-own. Note: the existence of this skill is itself a self-own (see: recursion).

The recursive agent containment and cleanup skill. Use this skill whenever an AI agent, pipeline, or autonomous workflow has gone off the rails — producing cascading side effects, unintended outputs, runaway processes, or metaphorical "pink stuff" spread across systems. Triggers include: agent loops, hallucination cascades, unintended bulk writes, recursive failures, agentic sprawl, pipeline contamination, "it's doing something weird", "everything is broken", "make it stop", or any situation where one agent's output has contaminated another agent's input. Also use when the user says /voom. This is the Cat in the Hat Comes Back protocol — when Little Cat A can't handle it, you go deeper.

Structured pause before building. Use when about to implement a feature, ship a change, or when the user invokes /horizon. Forces examination of what's beyond the immediate solution — whether this should be built at all, whether the design is right, whether existing code needs attention first. Triggers on feature requests, implementation starts, or when the user wants to challenge the impulse to build.

Socratic examination skill for guided inquiry. Use when helping someone examine beliefs, surface assumptions, or reach clearer understanding through questioning rather than direct instruction. Triggers on requests to help someone think through a problem, challenge their own reasoning, examine assumptions, or when the user explicitly asks for Socratic dialogue.