jwilger

Use when preparing local changes, a branch, pull request, merge request, or merge-to-main for final review before publishing, opening a PR, merging, or claiming readiness.

Use when implementing any feature, bugfix, behavior change, or refactor before writing production code.

Use when the user asks to shape fuzzy planning, product/design/engineering tradeoffs, scope/spec/ticket plans, or says "challenge this/help me think"; delegate to an advisor subagent. Good for rough ideas, second opinions, load-bearing decisions, or scope cuts. Skip scoped implementation, narrow bugs, reviews, and "just build" requests.

Use when setting up a project-local eval harness for prompts, agents, judges, RAG, tools, or other LLM behavior, especially when the default should be free/OSS promptfoo with repo-owned artifacts.

Use when a pull request or merge request needs to be driven to merge — watching CI, responding to review feedback, and merging once green and approved, across GitHub, Forgejo, or GitLab.

Use when the user wants repository task tracking, shared agent task state, cross-worktree coordination, tiber setup/install/scaffold guidance, or task create/list/show/prioritize/validate/close workflows. Plugin install and session start are non-mutating; setup integration starts with dry-run previews.

Use when the user asks to add, capture, file, or record a new repository task or backlog ticket through Tiber from chat.

Use when a plugin, skill, prompt, tool, command, or agent behavior was surprising, wrong, partial, unsafe, brittle, or worth preserving as a future eval fixture; also use when the user asks to report, submit, capture, or file an eval case.

Multi-agent coordination discipline: one-message-then-wait (send complete context, wait for reply before sending again), idle notifications are heartbeats (no action unless extended + blocking + user asked), no polling loops (event-driven only), never fabricate agent responses (wait for real system events), sequential agent spawning (acknowledge between each), and proper shutdown protocol (request, wait, respect rejection). Activate when orchestrating multiple agents, coordinating handoffs between agents, spawning subagents, or building multi-agent workflows. Triggers on: "coordinate agents", "spawn multiple agents", "manage agents", "agent keeps sending messages", "polling loop", "agent idle", "shut down agent", "multi-agent workflow", "agent handoff", "coordinate parallel work", "stop bothering the other agent". Also relevant when an agent is fabricating responses, sending follow-up messages before replies arrive, or reacting to idle notifications unnecessarily.

Architecture Decision Records with a four-phase lifecycle (RESEARCH -> DRAFT -> HOLD -> MERGE). Use this skill whenever the user needs to make a technology choice, choose a database, select a framework, define system boundaries, record architectural decisions, review or evaluate an existing ADR, create or update ARCHITECTURE.md, or inventory decision points for a new project. Triggers on: "choose a database", "architecture decision", "ADR", "which technology should we use", "is this ADR ready to merge", "review this architecture decision", "what decisions do we need to make", "tech stack decision", "define system boundaries", "record this decision". Enforces research-before-writing and explicit merge authorization. NOT for: code review (use code-review), implementation decisions within established patterns, or design system choices (use design-system).

Trigger this skill immediately when the user says "bootstrap" in any form. Also trigger it for any request about initializing a project's workflow, configuring development practices, or setting up a codebase for the first time. Key signals: "bootstrap", "set up workflow", "configure TDD", "generate AGENTS.md", "recommend skills", "onboard to project", "what tools should I use", "greenfield", "just cloned", "new developer joining". Detects the project environment, recommends skills by phase, configures TDD strategy, and generates instruction files. Project-level onboarding -- NOT for writing code, tests, or performing specific dev tasks.

Deterministic CI/CD interaction patterns with structured evidence output. Push-and-wait discipline (one pending run at a time), five-category failure triage (test-failure, lint-failure, build-failure, flaky-test, infra-failure) with classification-specific fix strategies, self-healing for lint/format/infra failures, flaky test detection, and CI_RESULT JSON evidence packets for every run. Use when pushing code to CI, triaging CI failures, waiting for pipeline results, classifying build errors, dealing with flaky tests, or producing CI evidence for quality gates. Triggers on: "CI failed", "push and wait for CI", "triage build failure", "flaky test", "CI pipeline", "build broke", "CI evidence". NOT for: individual test debugging (use debugging-protocol), code review (use code-review).

Three-stage code review protocol covering spec compliance, code quality, and domain integrity. Use this skill whenever the user asks to review code, prepare or check a PR, assess implementation quality, verify code against a spec or acceptance criteria, or audit for security and domain modeling issues. Triggers on: "review this code", "review my PR", "check implementation against spec", "code quality audit", "does this match the requirements", "review for security issues", "check for primitive obsession", "monetary precision review", "review test coverage gaps". Also activates when the user wants structured PASS/FAIL verdicts per requirement, severity-rated findings, or a gated review that blocks on critical issues. NOT for: style/formatting linting, debugging runtime errors, writing new code, or automated CI checks.

Systematic 4-phase debugging: (1) understand the failure by reading the complete error and reproducing it, (2) find working examples to compare against, (3) test one hypothesis at a time with a single change, (4) fix the root cause and verify with tests. Includes the Three Strikes Rule (escalate after 3 failed fix attempts) and the Iron Law (no fixes without investigation). Activate when tests fail unexpectedly, errors occur, behavior is wrong, something that worked before is now broken, or a user reports a bug. Triggers on: "debug", "why is this failing", "test failure", "unexpected error", "bug", "broken", "investigate this error", "fix this bug", "tests are failing", "weird behavior", "something broke", "track down this issue". Also activates when multiple bugs need systematic investigation (one at a time, not batch-fixed). NOT for: writing new tests from scratch (use tdd), or general code review (use code-review).

Collaborative design system creation using Atomic Design methodology with a structured seven-phase process (Philosophy, Tokens, Atoms, Molecules, Organisms, Templates, Assembly). Produces a specification artifact with philosophy traceability, named design tokens, and full component hierarchy. Use when creating a design system, defining a visual language, specifying UI tokens (colors, typography, spacing), building a component catalog, or planning component architecture before implementation. Triggers on: "create a design system", "define design tokens", "component library spec", "visual language", "atoms and molecules", "style guide", "UI philosophy", "component hierarchy". NOT for: implementing components in code (use atomic-design), choosing frameworks (use architecture-decisions).

Use this skill when the user asks about domain modeling, primitive obsession, parse-don't-validate, semantic types, value objects, or making invalid states unrepresentable. Triggers on: "review for domain issues", "primitive obsession", "design domain types", "value object", "newtype wrapper", "semantic type", "make invalid states unrepresentable", "bool-as-state", requests to replace raw strings/ints with proper types, requests to fix swappable parameters, or any code review focusing on type safety and domain integrity. Also activates during TDD domain review phases. NOT for general code review (style, formatting), debugging, database schema design, or design patterns unrelated to domain type modeling.

Drive one Union Square GitHub issue through the Codex BDD/TDD workflow.

Draft architecture decision records while keeping current guidance in ARCHITECTURE.md.

Review system architecture for alignment with documented patterns, consistency, and scalability

Review code design for maintainability, coupling, cohesion, and clarity

Validate event sourcing implementation against EventCore patterns and event modeling best practices

Process CodeRabbit and human PR feedback without bypassing project gates.

Review a Union Square PR against deterministic checks and architecture guardrails.

Audit code for security vulnerabilities, unsafe practices, and data exposure risks

This skill should be used when running the Claude-Factory conductor loop, understanding how cf_next_step output should be interpreted, or troubleshooting why the loop is not advancing. It explains the dispatcher pattern, how to interpret kernel step responses, and how to dispatch Claude agents vs codex GPT executors.

This skill should be used when configuring linters for a new project stack, understanding why the factory starts with the strictest linter config, or deciding whether a lint rule relaxation is justified. It explains the principle that strictness is the default and relaxation requires narrow scope and documented justification.

This skill should be used when the user or an agent is creating or reviewing an event model, understanding event modeling methodology, decomposing a workflow into slices, or learning how to use emc for event modeling. It explains the event modeling methodology as practiced in Claude-Factory — Given/When/Then scenarios, slice decomposition, transition types, and workflow composition.

This skill should be used when implementing event-sourced systems, choosing how to project state from events, designing read models, or handling performance/consistency trade-offs in event-sourced applications. It covers the eight core implementation patterns from Martin Dilger's methodology.

This skill should be used when the user or an agent is designing functions that need I/O, deciding where to put business logic, or implementing the effects pattern for requesting I/O from the functional core. It explains functional-core/imperative-shell architecture and the effects (or step/trampoline) pattern for languages that do not natively support algebraic effects.

This skill should be used when the user or an agent is designing error handling, writing functions that can fail, chaining operations that may fail, or reviewing code for error-handling correctness. It explains Scott Wlaschin's railway-oriented programming approach — using Result/Either types to make the error path explicit and composable without exceptions or defensive coding.

This skill should be used when the user or an agent is defining domain types, writing function signatures, creating data structures, or reviewing code for type safety in a Claude-Factory managed project. It explains the "semantic types everywhere" constraint — the rule that every value in the system must carry its meaning in its type, not just its structure, including values used only within a single function body.

This skill should be used when the user or an agent is building UI components, designing the design system, or understanding how UI components are organized in a Claude-Factory managed project. It explains Brad Frost's Atomic Design methodology with the Claude-Factory extension adding a 'quarks' level below atoms.

Process Forgejo PR feedback with reflection, guardrail-gap classification, and inline thread replies.

Fine-grained outside-in RED-GREEN-REFACTOR microcycles with specialist agents and single-diagnostic implementation.

UI-first BDD for event-model slices, RGR sequence, observed-failure evidence, drill-down unit tests, and non-behavioral exemptions for eddy.

Write implementation plans as test-addressed red-green-refactor cycles, with UI-first Cucumber REDs for event-model slices, rather than component waterfalls.

eddy Rust workspace conventions, Nix toolchain use, error handling, env parsing, tests, and docs coupling.

Event Modeling pattern advice; use when deciding whether something is an event, command, read model, state change, state view, automation, or translation.

Sandbox, LLM/tool trust boundaries, red-team tests, metrics/docs coupling, and threat-model update triggers.

Eddy event-model JSON authoring; use when creating or editing docs/event-model/workflows/*.eventmodel.json or event model schema-like content.

Use this skill for ADRs, architecture choices, technology selection, boundaries, and updates to `docs/ARCHITECTURE.md`. It keeps research ahead of prose and requires explicit approval before a decision is treated as merged.

Use this skill to discover workflows, map events, commands, read models, automations, and Given/When/Then scenarios before implementation. It keeps discovery separate from architecture and implementation decisions.

Review local changes before a trunk commit or push. Use when the user asks for review, a final preflight pass, or a regression check focused on correctness, risks, and missing tests.

Use this skill whenever the user wants test-first implementation. It runs a Codex-native RED -> DOMAIN -> GREEN -> DOMAIN -> COMMIT loop, with optional subagent delegation when explicitly useful.

Bootstrap a repository for Codex-first, trunk-based development. Use when the user asks to set up AGENTS.md, Codex workflow guidance, or repo-local SDLC defaults without centering Claude-specific conventions.

Keep Codex delegation explicit, sparse, and well-scoped. Use when the user asks for subagents, parallel work, or a multi-agent approach, or when a sidecar task is clearly parallelizable without changing the main workflow default.

Use this skill for semantic types, primitive obsession, parse-don't-validate, invalid-state prevention, and domain-focused review. It is also the domain review lens for the TDD cycle.

Set up repository policy and local Codex configuration for trunk-based development. Use when the user wants GitHub branch-protection guidance, `.codex/config.toml` direction, or a repo-local operating model aligned with direct trunk commits.

Multi-agent orchestration patterns for delegation, coordination, and conflict resolution

Event Modeling facilitation methodology for event-sourced system design

Local task management using the dot CLI with file-based markdown storage, parent-child hierarchies, and blocking dependencies. Use when managing tasks, creating stories or epics, tracking work items, breaking down features, writing acceptance criteria, or querying task status. Triggers on: "create a task", "add a story", "break down this feature", "what's ready to work on", "show task status", "dot add", "dot ls", "dot ready", "dot tree", or any reference to the dot CLI or .dots/ directory.

Knowledge accumulation and retrieval patterns for file-based agent memory

Red-green-domain TDD cycle with strict phase boundaries and domain modeling review

Brad Frost's Atomic Design methodology for building UI component hierarchies

Systematic 4-phase debugging methodology for finding and fixing root causes

One-line description of what this skill teaches

Fine-grained outside-in RED-GREEN-REFACTOR microcycles with specialist agents and single-diagnostic implementation.

RGR sequence, observed-failure evidence, drill-down unit tests, and non-behavioral exemptions for Phoenix/Commanded work.

Phoenix 1.8, Postgres, Commanded, Ecto, ExUnit, Dialyzer, and strict static-check conventions.

Phoenix auth/session/CSRF, command authorization, event data sensitivity, Postgres, dependency, secret, and threat-model review triggers.

Process Forgejo PR feedback with reflection, guardrail-gap classification, and inline thread replies.

Classify review feedback and choose proportionate guardrails without inflating default context cost.

Write implementation plans as test-addressed red-green-refactor cycles rather than component waterfalls.

Record new knowledge to memento knowledge graph for future retrieval

Retrieve relevant memories from memento knowledge graph at task start