claude-code-arcane 2.11.0 → 2.12.0

package/CHANGELOG.md

@@ -1,3 +1,12 @@
+# [2.12.0](https://github.com/SebastianLuser/claude-code-arcane/compare/v2.11.0...v2.12.0) (2026-10-16)
+
+
+### Features
+
+* **output-style:** shape answers for ADHD readers as well ([66351f7](https://github.com/SebastianLuser/claude-code-arcane/commit/66351f7fb9399eec97c650fb547826c4d7097152))
+* **rules:** add verification, agent-delegation and git-worktrees core rules ([2ffe8ef](https://github.com/SebastianLuser/claude-code-arcane/commit/2ffe8ef0a6b4093f0171ff28a327509b7e30cff0))
+* **rules:** say what counts as evidence in each domain rule ([81cec94](https://github.com/SebastianLuser/claude-code-arcane/commit/81cec94f21ae8cbe44c87e2aaa29d9aa4ba969b3))
+
 # [2.11.0](https://github.com/SebastianLuser/claude-code-arcane/compare/v2.10.0...v2.11.0) (2026-10-11)
 
 

package/README.md

@@ -1,6 +1,6 @@
 # Claude Code Arcane
 
-> **437 skills, 115 agents, 17 hooks and 33 rules for Claude Code — selective deploy by profile.**
+> **437 skills, 115 agents, 17 hooks and 36 rules for Claude Code — selective deploy by profile.**
 
 A configuration harness installable via `npx`. Pick a **profile** that matches your stack and only the relevant tools get installed into your project's `.claude/` directory.
 
@@ -461,7 +461,7 @@ claude-code-arcane/
 ├── profiles/                  # 38 profiles (YAML)
 ├── agents/                    # 17 dirs, 109 agents (Markdown)
 ├── hooks/                     # 17 lifecycle hooks (Bash)
-├── rules/                     # 33 rules (Markdown)
+├── rules/                     # 36 rules (Markdown)
 ├── templates/                 # Gamedev templates
 ├── docs/                      # Documentation
 └── skills-selftest/           # QA framework

package/docs/USER-GUIDE.md

@@ -2,7 +2,7 @@
 
 ## What is Arcane?
 
-Arcane is a configuration harness for [Claude Code](https://docs.anthropic.com/en/docs/claude-code). It provides a curated library of **437 skills**, **115 agents**, **17 hooks**, and **33 rules** that you selectively deploy into any project. Instead of shipping everything to every project (wasting tokens and degrading performance), you pick a **profile** that matches your stack and only the relevant tools get installed.
+Arcane is a configuration harness for [Claude Code](https://docs.anthropic.com/en/docs/claude-code). It provides a curated library of **437 skills**, **115 agents**, **17 hooks**, and **36 rules** that you selectively deploy into any project. Instead of shipping everything to every project (wasting tokens and degrading performance), you pick a **profile** that matches your stack and only the relevant tools get installed.
 
 ## Table of Contents
 

package/output-styles/arcane.md

@@ -1,6 +1,6 @@
 ---
 name: arcane
-description: Respuestas compactas, tablas para comparar, lenguaje literal y estructura legible — pensado para lectura con TEA y dislexia.
+description: Respuestas compactas, tablas para comparar, lenguaje literal y estructura legible — pensado para lectura con TEA, TDAH y dislexia.
 ---
 
 # Arcane
@@ -11,8 +11,8 @@ autorizan entregar menos.
 
 ## Largo
 
-- **La respuesta primero.** Primera línea: qué pasó o qué contestás. El detalle va después,
-  para quien lo quiera.
+- **La respuesta o la acción primero.** Primera línea: qué pasó, qué contestás o, si hay algo
+  para hacer, esa acción (un comando, un archivo, una decisión). El detalle va después.
 - **Sin preámbulo.** No repitas la pregunta, no anuncies lo que vas a hacer, no cierres
   resumiendo lo que acabás de decir.
 - **Un tema por párrafo, tres líneas como máximo.** Si un párrafo crece, partilo o pasalo a
@@ -27,12 +27,19 @@ autorizan entregar menos.
 - **Tabla siempre que compares.** Dos o más cosas con dos o más atributos (opciones,
   versiones, proyectos, trade-offs) van en tabla, no en prosa ni en bullets paralelos. Una
   columna por atributo, una fila por cosa.
-- **Listas para pasos y hallazgos.** Prosa solo para el razonamiento que une las cosas.
+- **Pasos numerados, una acción por paso.** La menor cantidad de pasos que funcione; ningún
+  paso dice "y después" dos veces. Prosa solo para el razonamiento que une las cosas.
+- **Cinco ítems como máximo por lista o tabla visible.** Si hay más, agrupalos en secciones
+  con lo más relevante primero. Es solo presentación: nunca descartes un ítem relevante.
 - **Títulos cuando hay más de un tema.** Que se pueda saltar a la parte que importa sin
   leer todo.
 - **`backticks` en todo identificador** — archivos, comandos, ramas, funciones, flags.
 - **Bold para lo importante**, no italics: es más fácil de decodificar. Nunca MAYÚSCULAS
   para enfatizar, deforman la silueta de la palabra.
+- **Página HTML solo para lo que se entiende mejor dibujado.** Si está instalada
+  `answer-me-with-html`, usala para explicar cómo funciona algo, un flujo o una
+  arquitectura, o cuando el usuario pida "dibujalo". Para comparar o listar, alcanza una
+  tabla en la respuesta.
 
 ## Lenguaje
 
@@ -46,8 +53,48 @@ autorizan entregar menos.
   de prosa condicional que deja al lector adivinando el nivel de confianza.
 - **Decí explícitamente qué esperás del otro.** Si hace falta una decisión, que se vea que
   hace falta y cuáles son las alternativas.
+- **Errores sin dramatismo.** Causa y arreglo: "falla en `auth.spec.ts:42`, falta el
+  header", no "uy, algo salió mal".
 
 ## Números y datos
 
 - **El dato antes que el adjetivo.** "62 commits atrás" en vez de "bastante atrasado".
 - **Unidad y fecha completas.** `2026-09-04`, no "ayer"; `312 KB`, no "poco".
+- **El tamaño en unidades contables.** "3 archivos, 2 pasos, 1 PR", no "rápido" ni "un
+  rato". Nada de estimar minutos.
+
+## Seguimiento
+
+- **Decí el estado en tareas de varios pasos.** "Paso 3 de 5 hecho: X. Sigue: Y." Si hay
+  herramienta de tareas, la lista de tareas reemplaza esa narración.
+- **Que lo terminado se vea.** "El login ya funciona: probá `npm run dev` y entrá a
+  `/login`", no "hice algunos cambios".
+- **Sin desvíos.** Si aparece un segundo tema, cerrá el actual y ofrecé el otro aparte, al
+  final. Una duda que surge en el medio, resolvela vos si podés.
+- **Cerrá con una sola acción concreta** que el usuario pueda hacer en poco tiempo, si
+  queda algo abierto.
+
+## Cuándo se rompen estas reglas
+
+1. **"Explicame".** Se explica completo, con títulos. Sigue sin preámbulo ni cierre.
+2. **Algo destructivo por delante.** Confirmá antes de actuar: la seguridad gana a la
+   brevedad.
+3. **Espiral de debug.** Si los últimos 3 turnos fueron "sigue roto", dejá de tocar código.
+   Nombrá la suposición que puede estar mal y hacé una sola pregunta de diagnóstico.
+4. **Pedido ambiguo.** Una pregunta corta antes que adivinar.
+5. **"¿Qué opciones tengo?"** De 2 a 4 opciones con la recomendada primero: las opciones
+   son la respuesta.
+6. **El trabajo del agente lo hace el agente.** No preguntes "¿querés que lo haga?" por algo
+   que te toca hacer. Las decisiones que son del usuario siguen siendo preguntas.
+
+## Antes de enviar
+
+Borrá:
+
+1. La primera oración, si anuncia lo que vas a hacer.
+2. La última, si pregunta "¿algo más?" o resume lo que pasó.
+3. Los "por cierto".
+4. Las dudas de relleno ("quizás", "podría"). Las que expresan incertidumbre real quedan.
+5. Los modismos.
+
+Prueba final: leyendo solo la primera y la última línea, ¿se sabe qué pasó y qué sigue?

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-code-arcane",
-  "version": "2.11.0",
+  "version": "2.12.0",
   "description": "Skills, agents, hooks and rules for Claude Code — installable via npx claude-code-arcane",
   "type": "module",
   "bin": {

package/profiles/core.yaml

@@ -33,6 +33,9 @@ rules:
     - test-standards
     - implementation-workflow
     - code-comments
+    - verification
+    - agent-delegation
+    - git-worktrees
   gamedev:
     []
 

package/rules/agent-delegation.md

@@ -0,0 +1,8 @@
+# Agent Delegation Rule
+
+Applies to the main session and to every subagent it starts.
+
+- **Your final message is the deliverable.** Never end a turn with "waiting for the subagents": a started task is not a finished one.
+- **If you delegate, you collect.** Wait for every result, integrate it, then answer. No fire-and-forget.
+- **One agent by default.** Split work only when it cannot fit one context, or when the second agent needs something the first must not have: different tools or permissions, a clean context (a reviewer that must not see the maker's reasoning), or a different model.
+- **The prompt is all the subagent knows.** It does not see this conversation: pass the goal, the relevant files and the output format you expect.

package/rules/backend-code.md

@@ -33,3 +33,10 @@ paths:
 - Nested business logic in DB queries (computed columns that reimplement rules)
 - Silent retries with no backoff, no max attempts, no circuit breaker
 - Returning raw DB rows as HTTP responses — always go through a DTO / view model
+
+## How to verify
+
+- Run the tests that cover the change.
+- Start the service locally and call the changed endpoint with `curl` (or the project's HTTP client). Show the status code and the body.
+- Call one failure case too (invalid input, missing auth), not only the happy path.
+- Read the server log for those requests: no stack trace, no unexpected warning.

package/rules/dotnet-code.md

@@ -59,6 +59,12 @@ Reglas production-ready para ASP.NET Core (.NET 10), ordenadas por impacto. Cat
 - `Domain` referenciando `Infrastructure` / EF Core (dependencia hacia afuera)
 - Forzar Clean Architecture en un CRUD simple (sobre-ingeniería)
 
+## How to verify
+
+- `dotnet build` with no new warnings, and `dotnet test` for the projects the change touches.
+- Run the API locally and call the changed endpoint with `curl`: show the status code and the body, plus one failure case (invalid input, missing auth).
+- Read the log for those requests: no exception, no unexpected warning.
+
 ---
 
 _Derivado de [github/awesome-copilot](https://github.com/github/awesome-copilot) (dotnet-best-practices), [dotnet/skills](https://github.com/dotnet/skills) y [ardalis/CleanArchitecture](https://github.com/ardalis/CleanArchitecture). Condensado al formato Arcane._

package/rules/frontend-code.md

@@ -33,3 +33,28 @@ paths:
 - Unmanaged re-renders triggered by new object/array literals in parent render
 - DOM manipulation via `document.querySelector` inside a component
 - Inline handlers defined in JSX for components that memoize
+
+## Visual Quality
+
+- Do not ship library defaults as the design: a stock card grid, a centered hero with a gradient blob, the same radius and shadow on every component.
+- Give each screen a hierarchy: one primary action, deliberate emphasis, designed hover, focus and active states.
+- If the app has light and dark themes, both must look designed, not inverted.
+
+## Web Performance
+
+- Images declare `width` and `height`, load `lazy` below the fold, and ship as AVIF or WebP near their rendered size.
+- At most two font families, `font-display: swap`, and preload only the critical weight.
+- Animate only `transform` and `opacity`; use `IntersectionObserver` instead of scroll handlers.
+- Third-party scripts load `async` or `defer`, and only on the pages that need them.
+
+## How to verify
+
+- The build passes and the type check is clean.
+- For a web task done in Plan + Goal or Goal-driven mode, a Playwright check is required before the task counts as done:
+  1. The page loads with no console errors.
+  2. Screenshots at 320, 768, 1024 and 1440 px wide, in both themes if the app has a dark mode.
+  3. Walk the flow you changed: clicks, forms, navigation.
+  4. Keyboard: every control in the flow is reachable with Tab, usable with Enter or Space, and shows a visible focus.
+  5. Keep the screenshots and show them as evidence.
+- If Playwright is not installed, propose installing it once (`npm i -D @playwright/test`, then `npx playwright install chromium`). If the user declines, close the task with "visual result not verified".
+- In React Native or Flutter Playwright does not apply: say what was not verified visually.

package/rules/gamedev/ai-code.md

@@ -1,6 +1,7 @@
 ---
 paths:
   - "src/ai/**"
+  - "Assets/**/Scripts/**/AI/**"
 ---
 
 # AI Code Rules

package/rules/gamedev/audio-code.md

@@ -1,6 +1,7 @@
 ---
 paths:
   - "src/audio/**"
+  - "Assets/**/Scripts/**/Audio/**"
 ---
 
 # Audio Code Rules

package/rules/gamedev/engine-code.md

@@ -1,6 +1,7 @@
 ---
 paths:
   - "src/core/**"
+  - "Assets/**/Scripts/Core/**"
 ---
 
 # Engine Code Rules
@@ -39,3 +40,9 @@ void FixedUpdate()
     nearby.AddRange(FindObjectsOfType<Enemy>());  // VIOLATION: scene scan every frame
 }
 ```
+
+## How to verify
+
+- The project compiles with no new errors: the Unity console, or a batchmode compile (`Unity -batchmode -quit -projectPath . -logFile -`); for Unreal, see `unreal-code`.
+- Run the EditMode and PlayMode tests that cover the change (`-runTests -testPlatform EditMode` or `PlayMode`).
+- You cannot play the game. Name what needs a human playtest (game feel, timing, visuals, input) and list exactly what to try.

package/rules/gamedev/gameplay-code.md

@@ -1,6 +1,8 @@
 ---
 paths:
   - "src/gameplay/**"
+  - "Assets/**/Scripts/Gameplay/**"
+  - "Assets/**/Scripts/Systems/**"
 ---
 
 # Gameplay Code Rules
@@ -28,3 +30,9 @@ float speed = stats.MovementSpeed * Time.deltaTime;
 float damage = 25.0f;   // VIOLATION: hardcoded gameplay value
 float speed = 5.0f;     // VIOLATION: not from config, not using delta
 ```
+
+## How to verify
+
+- The project compiles with no new errors: the Unity console, or a batchmode compile (`Unity -batchmode -quit -projectPath . -logFile -`); for Unreal, see `unreal-code`.
+- Run the EditMode and PlayMode tests that cover the change (`-runTests -testPlatform EditMode` or `PlayMode`).
+- You cannot play the game. Name what needs a human playtest (game feel, timing, visuals, input) and list exactly what to try.

package/rules/gamedev/network-code.md

@@ -1,6 +1,7 @@
 ---
 paths:
   - "src/networking/**"
+  - "Assets/**/Scripts/**/Network*/**"
 ---
 
 # Network Code Rules

package/rules/gamedev/shader-code.md

@@ -1,6 +1,9 @@
 ---
 paths:
   - "assets/shaders/**"
+  - "Assets/**/Shaders/**"
+  - "**/*.shader"
+  - "**/*.hlsl"
 ---
 
 # Shader Code Standards

package/rules/gamedev/ui-code.md

@@ -1,6 +1,7 @@
 ---
 paths:
   - "src/ui/**"
+  - "Assets/**/Scripts/UI/**"
 ---
 
 # UI Code Rules
@@ -13,3 +14,9 @@ paths:
 - UI must never block the game thread
 - Scalable text and colorblind modes are mandatory, not optional
 - Test all screens at minimum and maximum supported resolutions
+
+## How to verify
+
+- The project compiles with no new errors: the Unity console, or a batchmode compile (`Unity -batchmode -quit -projectPath . -logFile -`); for Unreal, see `unreal-code`.
+- Run the EditMode and PlayMode tests that cover the change (`-runTests -testPlatform EditMode` or `PlayMode`).
+- You cannot play the game. Name what needs a human playtest (game feel, timing, visuals, input) and list exactly what to try.

package/rules/gamedev/unreal-code.md

@@ -123,3 +123,9 @@ class AGate : public AActor
     }
 };
 ```
+
+## How to verify
+
+- The editor target compiles with no new errors or warnings (Build in the IDE, or `Build.bat <Project>Editor Win64 Development <path>.uproject`).
+- Run the automation tests that cover the change (`UnrealEditor-Cmd <project>.uproject -ExecCmds="Automation RunTests <Filter>;Quit" -unattended -nullrhi`).
+- You cannot play the game. Name what needs a human playtest (game feel, replication under latency, visuals) and list exactly what to try.

package/rules/git-worktrees.md

@@ -0,0 +1,22 @@
+# Git Worktree Rule
+
+A session can run inside a git worktree: a second checkout of the same repository, usually under `.claude/worktrees/`. You are in one when `git rev-parse --git-dir` and `git rev-parse --git-common-dir` print different paths.
+
+## Decide by the branch the action is about
+
+| The action is about | Where to run it |
+|---|---|
+| The worktree's own branch: commit, push, rebase, merge `main` into it | Inside the worktree. First push: `git push -u origin HEAD` |
+| Another branch: `main`, or whatever the main checkout has (checkout, switch, pull, update) | Outside: leave the worktree first |
+| Unclear | Ask once |
+
+## Leaving the worktree
+
+The user authorizes you to leave a worktree without asking, in two cases:
+
+1. **The task is done.** Commit the work on the worktree branch, push it if the task included pushing, then call `ExitWorktree` with `action: "keep"`. Tell the user the worktree path and its branch.
+2. **You need another branch** (second row of the table). Leave with `ExitWorktree` (`keep`), run the operation, and enter again if the task continues.
+
+Always `keep`. Never `remove` a worktree: deleting worktrees is the user's call.
+
+`ExitWorktree` only acts on a worktree this session entered with `EnterWorktree`. If it does nothing (the session started inside the worktree, or it was made with `git worktree add` or `arcane worktree`), run git against the main checkout instead: `git -C "<main checkout>" pull`. The main checkout is the parent directory of `git rev-parse --git-common-dir`. Tell the user the session itself is still inside the worktree.

package/rules/implementation-workflow.md

@@ -39,6 +39,15 @@ Use AskUserQuestion exactly like this:
 - **Goal-driven:** Help the user define a verifiable goal statement and 2-4 checkpoints, create tasks, implement toward each checkpoint. No formal plan.
 - **Directo:** Proceed immediately without ceremony.
 
+## Before writing new code
+
+In every mode, search in this order and take the first option that fully works:
+
+1. **The codebase**: a helper, component or pattern that already does it.
+2. **The standard library** or a platform feature.
+3. **A dependency the project already has.**
+4. **A new dependency**, only when 1–3 cannot do it. Name the package and why before installing it.
+
 ## Key principles
 
 - One question, not a wall of text — present options and wait

package/rules/infra-code.md

@@ -45,3 +45,9 @@ paths:
 - Inline shell scripts in CI that do complex logic — move to a versioned script with tests
 - Copying `production.tf` to `staging.tf` and diverging them by hand
 - Running DB migrations from a CI job that doesn't have transactional rollback if the deploy fails after
+
+## How to verify
+
+- Validate without applying: `terraform plan`, `helm lint` + `helm template`, `docker compose config`, `docker build`. Show the output.
+- Never run `apply`, a deploy or `kubectl apply` to verify a change.
+- For a CI workflow, run `actionlint` if it is installed, and say that the workflow itself only proves itself on the next push.

package/rules/migration-code.md

@@ -39,3 +39,9 @@ paths:
 - `DELETE FROM users WHERE ...` in a migration without a backup and written-out rollback
 - Migration that depends on application code (calling service layer) — migrations run with DB access only, not app code
 - Migrations that only work if previous migration left specific data — be defensive, check before mutating
+
+## How to verify
+
+- On the local database, run the migration up, then down, then up again. All three must succeed.
+- After up, confirm the schema change landed: `\d <table>` in psql, `DESCRIBE <table>` in MySQL, or the ORM's status command.
+- For a backfill, run it twice: the second run must change nothing.

package/rules/nestjs-code.md

@@ -71,3 +71,9 @@ Reglas production-ready para NestJS, ordenadas por impacto. Catálogo completo (
 ---
 
 _Derivado de [kadajett/agent-nestjs-skills](https://github.com/kadajett/agent-nestjs-skills) (nestjs-best-practices). Condensado al formato Arcane._
+
+## How to verify
+
+- Run the tests that cover the change (`npm test`, or the project's script) and the type check.
+- Start the app locally and call the changed endpoint with `curl`: show the status code and the body, plus one failure case (invalid DTO, missing auth).
+- Read the app log for those requests: no stack trace, no unexpected warning.

package/rules/verification.md

@@ -0,0 +1,13 @@
+# Verification Rule
+
+Every claim about the state of the work rests on evidence produced in this session.
+
+- **No claim without a run.** "Tests pass", "it builds" and "it works" each need the command you ran in this session and its result. If you did not run it, say so.
+- **Read before you edit.** Never change or overwrite a file you have not read in this session: the user may have changed it.
+- **Search, don't guess.** Before you use a path, function, flag or config key you are not sure exists, find it (Grep, Glob, `--help`, the source).
+- **The installed version beats memory.** Before you use a library API from memory, check its version in the lockfile; when in doubt, read the installed types or source.
+- **Fix the code, not the check.** Never edit a test, a lint/format/type config or a CI step to make it pass, unless the task is about that test or config. If you think the test is wrong, say so and ask.
+- **Filter long output.** Pipe it through `tail`, `grep` or a quiet flag instead of pouring thousands of lines into the context.
+- **Close with what was not verified.** End a task by naming what you could not check: a platform, a manual flow, a visual result.
+
+Domain rules add a `## How to verify` section with what counts as evidence in that kind of code.