SKILLS

Use when the user wants to find and remove code duplication, says "deduplicate", "art-dupl", or wants to reduce duplication to ZERO. This skill is all about JUDGMENT and ZERO HARMFUL duplication. It does NOT mean zero report lines.

Splits or merges Go modules, refining go.mod boundaries. Direction-neutral. Use when the user wants to modularize a Go project, create independently versioned Go packages, restructure a Go project, or says "modularize", "split modules", "sub-modules", "go.mod per package", "multi-module", "module boundaries", "dependency isolation", "Go workspace", "go.work", "CQRS modularization", "break apart Go project", "too coupled", "Go package boundaries", "remodularize", "re-modularize", "merge modules", "too many modules", "over-modularized", "consolidate modules", "unix-style", "decompose deeper", "too few modules", "god-module", "composable modules".

Reviews the current architecture for scalability, modularity, service orientation, and composability. Use when the user asks about architecture quality, scalability, modularity, how to make the codebase more service-oriented or composable, or says "architecture review".

Triggers a brutally honest self-review of recent work and the current codebase state (Go projects). Use when the user asks for self-reflection, self-critique, wants to know what was forgotten, what's stupid, what could be better, find ghost systems, split brains, or wants a comprehensive improvement plan with Go ecosystem library awareness.

Runs build, lint, and code duplication analysis to surface all code quality issues. Use when the user asks to check code quality, run build and lint, find code duplication, or wants a sorted list of all issues.

Reviews and redesigns data models from first principles using Go's type system. Use when the user wants to review a data model, redesign types, improve a domain model, fix stringly-typed code, add type safety, use Go generics, composition, or interfaces, or says "data model", "review types", "redesign schema", "type system", "make impossible states unrepresentable", "branded types", "domain model", "entity design", "data architecture", "type safety review", "refactor data layer", "model redesign", "Go data model", "Go types", "Go generics", "Go structs", "Go interfaces", "Go composition". Triggers for any language but produces Go as the primary design language. Also fires when the user asks about validation layers, schema design, or converting implicit models to explicit typed ones.

Performs a comprehensive code review visiting every single code and test file as a Senior Software Architect. Use when the user wants a full codebase review, every file reviewed, deep quality audit, or says "visit every file", "review everything", "full review". Checks type safety, architecture, split brains, duplications, and fixes or adds TODOs on the spot. Includes Pareto-based planning and prioritization.

Performs a deep-dive research audit on a single library to determine whether the project uses it to its FULL potential. Use this skill when the user asks "are we using X to the max", "are we fully leveraging <library>", "deep dive into <library>", "library utilization audit", "library adoption review", "library maximization", "are we using <library> correctly", "what features of <library> are we missing", "library capabilities audit", "library usage review", "do we use <library> to its full potential", or any question about whether a specific dependency is underutilized, misused, or behind on features. Also triggers when the user names a library (e.g. Prisma, Zod, GORM, sqlc, Effect, RxJS, gorilla/mux, cobra, viper, react-query, zod, drizzle, typeorm, ent, elm, dayjs, lodash, immer, zustand, effector) and wants to know if they're getting the most out of it. Fires for ANY language and ANY library — JS/TS, Go, Rust, Python, Ruby, etc.

Reviews and improves naming quality for data models (types, structs, classes, interfaces, enums, fields, properties) and functions (methods, procedures). Use when the user wants to review, audit, improve, or fix naming in their codebase — including type names, function names, variable names, field names, or any identifier naming. Also trigger when the user asks about naming conventions, naming anti-patterns, naming smells, wants better names for their models or functions, or says "naming review", "review naming", "name review", "audit names", "improve naming", "bad names", "naming conventions", "rename identifiers", "clean up names". Covers clarity, honesty, domain alignment, consistency, language-specific conventions, and common anti-patterns like Manager/Handler/Helper classes, Data/Info suffixes, type encoding, lying names, and vague verbs. Includes automated detection via scripts/naming-smells.sh and linter integration for Go (revive), TypeScript (eslint naming), Rust (clippy), and Python (ruff).

Creates a migration proposal from justfile and shell scripts to nix flakes. Use when the user wants to plan or start migrating a project from justfile/makefile/shell scripts to nix flake-based build automation, or says "nix flake migration". Also use when converting from flake-utils/forEachSystem to flake-parts, adding treefmt-nix to an existing flake, or standardizing an ad-hoc flake to the ecosystem standard. Covers migration planning, standard stack adoption, and concrete flake templates.

Creates a comprehensive execution plan using the Pareto principle (80/20 breakdown). Use when the user wants to plan work, break down a TODO list, identify high-impact tasks, or says "MAKE A PLAN", "PARETO", "comprehensive plan", or wants tasks sorted by impact with a D2 execution graph written to docs/planning/.

Generates a full comprehensive status update of the project. Use when the user asks for a status update, progress report, "STATUS UPDATE", "WHAT'S THE STATUS", or wants to know what's done, what's broken, and what's next. Writes a styled HTML dashboard to docs/status/.

Shared HTML report design system for skills that produce point-in-time visual reports. Use when a skill needs to write a styled, self-contained HTML report, dashboard, proposal, audit, or review — instead of a flat Markdown file. Provides the design spec, CSS tokens, and copy-paste templates in two variants: a dark dashboard theme and a warm editorial-light theme. Other skills reference this kit via [./references/html-output-guide.md](./references/html-output-guide.md), [./assets/report-template.html](./assets/report-template.html), and [./assets/report-template-editorial.html](./assets/report-template-editorial.html).

Implements Behavior-driven development (BDD) tests using onsi/ginkgo for Go projects. Use when the user wants to add BDD tests, user-focused tests, ginkgo tests, or says "BDD" in the context of testing Go code.

Checks if core project documentation files are up-to-date with the current codebase state. Use when the user asks to verify docs, check if TODO_LIST.md, FEATURES.md, README.md, or AGENTS.md are current, or says "docs up to date".

Creates or updates FEATURES.md by studying the actual code to find all features the project has. Use when the user wants a feature inventory, feature list, wants to know what features exist and their status, or says "FEATURES.md" or "feature audit". Includes honest status indicators for each feature.

Generates D2 architecture diagrams for the current system and/or the ideal target architecture. Use when the user wants architecture diagrams, visualizes Events & Commands flow, asks for D2 diagrams, or wants to see how the system IS vs how it SHOULD BE architected. Also trigger when the user asks about system architecture, component relationships, service dependencies, or any visual representation of codebase structure.

Reviews and improves .nix files to make them truly superb. Use when the user wants to review, audit, improve, or fix Nix files — including flake.nix, NixOS modules, overlays, devShells, packages, or any .nix file. Also trigger when the user asks about nix quality, nix anti-patterns, nix best practices, wants to make their flakes excellent, or says "nix review", "review nix", "review .nix", "improve flake". Covers build correctness, security hardening, reproducibility, module design, source filtering, overlay architecture, performance, systemd hardening, and common pitfalls.

Go development decision guide — WHAT to use, not HOW. Use this skill when writing Go code, choosing Go libraries, setting up a Go project, reviewing Go dependencies, or when the user asks about Go best practices, Go library choices, banned Go libraries, Go architecture patterns, Go project structure, Go domain types, Go DI patterns, Go testing strategy, Go security, Go performance, or says "how to golang", "go policy", "go stack", "go libraries", "go architecture", "go code style", "go rules", "go testing", "go security", or any Go development question. Also use when reviewing go.mod for banned dependencies or choosing between Go libraries for any category.

Creates or updates TODO_LIST.md by reading all .md files in the project using sub-agents, then verifies which TODOs are already done by checking the actual code. Use when the user wants to build a comprehensive TODO list from existing documentation, verify TODO status against code, or says "build TODO list".