claude-resources

Implement application code following established patterns

Set output compression level for token efficiency

Propose candidate invariants for docs/constitution.md from codebase evidence

Analyze task requirements and generate a structured spec

Refine a vague idea into a task ready for /define

Record a project-specific learning for future sessions

Decompose a complex task and delegate to specialist agents

Design architecture and project structure

Review code for correctness, security, and quality

Containerize and add observability for production

Write and run tests for the codebase

Software architect. Use when starting projects, designing structure, defining interfaces, or planning API surfaces. Before implementation.

Implementation agent. Use when writing application code — handlers, services, repositories, workers. Follows existing patterns.

CLI development agent. Use when building CLI tools, adding commands, flags, config handling, or output formatting.

Task analyst that challenges vague requirements. Use PROACTIVELY before any non-trivial task. Does NOT write code.

Project lead that decomposes complex tasks into structured specs and delegates atomic subtasks to specialist agents. Produces spec directories under docs/specs/<slug>/ consumable by other agents without interpretation.

Code review agent. Invoked after each group by lead for a scoped mini-review, and as a final-verification reviewer. Read-only — does not modify code. Severity drives status.

Discovery agent that grounds specs in the existing codebase. Runs in parallel with critic during /define and /orchestrate. Reads existing code, finds relevant patterns, writes discovery.md. Does NOT write code.

Deployment and operations agent. Use when containerizing, adding observability, or preparing for production.

Testing agent. Use when writing tests, running suites, creating test doubles, or improving coverage.

Code review process and quality framework. Use when reviewing PRs, auditing code quality, or evaluating AI-generated code. Pair with language-specific code-review skill.

Concurrency patterns and pitfalls. Use when implementing parallel work, choosing sync primitives, auditing concurrent code, or reviewing for races and leaks. Pair with language-specific skill.

Author and maintain a project constitution — the list of invariants reviewer and critic enforce on every spec and every diff. Use when adding, editing, or sunsetting project-wide non-negotiables.

Debugging discipline: reproduce, isolate, root-cause, fix. Use when chasing bugs, tracking down failing tests, or investigating incidents. Pair with core/testing for regression coverage.

Ground a task in the existing codebase before specification. Use when starting /define or /orchestrate to map relevant files, patterns, and inherited constraints. Prevents specs built on phantom assumptions.

Containerization principles — multi-stage builds, base image selection, layer caching, security. Use when containerizing a service, shrinking a bloated image, chasing CVEs in a base image, adding non-root + distroless to an existing Dockerfile, or reviewing any `Dockerfile` / `.dockerignore` changes. Trigger on any task mentioning "docker", "container", "image", "base image", or "deploy to kubernetes" — even when the user does not explicitly say "use the docker skill". Pair with language-specific docker skill for build patterns.

When to write prose, ADRs, READMEs, and inline comments. Use when recording design decisions, maintaining READMEs, or deciding whether a comment is worth writing. Pair with core/style for comment policy.

Error handling strategy and decision framework. Use when designing error types, propagation patterns, or reviewing error handling. Pair with language-specific error-handling skill.

Local git discipline — commit hygiene, branch naming, rebase vs merge, drafting PR body content, versioning scheme selection. Use when staging a commit, writing a commit message, naming a branch, splitting a large change into smaller commits, drafting a PR description locally (the file content, not the `gh pr create` mechanics), or choosing a versioning scheme (semver vs calvert). Trigger on phrases like "commit this", "write the commit message", "split this up", "draft the PR description", "rebase onto main", or "what version do we bump?". Remote-write actions — push, PR creation, release publishing, registry push — live in the opt-in `ops-skills` plugin (`ops/git-remote`, `ops/pull-requests`, `ops/release`, `ops/registry`).

Pre-spec idea refinement through structured divergent and convergent thinking. Use when a task is too vague for /define — needs exploration before spec generation. Triggers: "ideate", "brainstorm", "refine idea".

Observability principles — structured logging, metrics (RED/USE), distributed tracing, health checks, alerting philosophy. Use when adding instrumentation to a service, debugging a production incident that exposes blind spots, designing alerting rules, setting up Prometheus / OpenTelemetry / slog, or writing `/healthz` and `/readyz` endpoints. Trigger on any task mentioning "logging", "metrics", "traces", "observability", "dashboards", "alerts", "pagerduty", "SLO", "golden signals", or "why is this service slow?". Pair with language-specific observability skill for instrumentation code.

Performance discipline: profile before optimize, benchmark, N+1 detection, hot-path analysis. Use when responding to a measured performance issue OR designing a high-throughput path. Pair with core/code-review §5 (review-time checklist).

Project structure principles. Use when starting a new project, major restructuring, or auditing package dependencies. Pair with language-specific project-init skill.

Security-by-DESIGN discipline for feature design — threat modeling, authz/authn design, secrets management, input validation at boundaries, OWASP Top 10 awareness. Use when starting to design any feature that handles user input, authentication, authorization, stored data (especially PII or credentials), or external I/O. Trigger on any task mentioning "auth", "login", "permissions", "secrets", "tokens", "user input", "API endpoint", "threat model", or "security review". NOT the review-time checklist — that lives in `core/code-review` §4. Use this skill BEFORE code exists, to prevent issues the checklist would only catch later.

Chesterton's Fence, dead-code removal, YAGNI discipline. Use when proposing to delete code, extract a function/class/interface, or introduce a new abstraction. Trigger on phrases like "do we need this?", "can we remove?", "should we extract?", "let me refactor this", "clean this up", or "simplify this" — and proactively whenever reviewing a PR that adds indirection, wrapper layers, or single-caller helpers. Pair with core/code-review and core/style.

Decision tree for routing tasks to the right agent and skills. Loaded on session start. Use when unsure which agent applies.

Generate structured spec files for agent consumption. Use when decomposing tasks into actionable specs that builder/tester/reviewer agents can execute without interpretation.

Code quality principles. Use when setting conventions, configuring linters, or doing style-focused reviews. Pair with language-specific style skill for naming and formatting rules.

Testing strategy and methodology. Use when planning test strategy, choosing unit vs integration, defining mock boundaries, or fixing bugs. Pair with language-specific testing skill.

Output compression for human-facing responses. Use when responding to users in a terminal, writing end-of-turn summaries, explaining diffs, producing status updates, or any non-artifact output addressed to a human reader. Specifies what to compress (articles, filler, pleasantries, hedging) and what to leave full-fidelity (SPEC files, agent-to-agent reports, commands, code blocks, paths, acceptance criteria, inline docstrings). Triggered automatically by the /compact slash command and loaded by all agents by default.

Go HTTP API patterns with chi router. Handlers, middleware, JSON helpers, server config, graceful shutdown. Extends core/api-design with Go implementation patterns.

Go CLI development with Cobra and Viper. Subcommands, flags, config precedence, signal handling, exit codes. 100% Go-specific.

Go-specific code review checklist items. Extends core/code-review with Go-specific correctness, style, and performance checks.

Go concurrency patterns with goroutines, channels, errgroup, and sync primitives. Extends core/concurrency with Go-specific implementations.

Go context propagation, cancellation, timeouts, and value storage. Use when managing request lifecycles, implementing timeouts, or coordinating goroutine cancellation. 100% Go-specific.

MySQL database patterns with sqlx. Connection pooling, query patterns, transactions, repository pattern, error handling. 100% Go-specific.

Go Docker patterns. Multi-stage builds with CGO_ENABLED=0, ldflags, distroless images, build args. Extends core/docker with Go-specific build patterns.

Go error handling patterns. Wrapping with fmt.Errorf, sentinel errors, custom types, errors.Is/As, HTTP error mapping. Extends core/error-handling with Go-specific implementations.

Go interface patterns. Accept interfaces/return structs, consumer-side definition, interface segregation, generics vs interfaces. 100% Go-specific.

Go modules dependency management. go.mod/go.sum, versioning, replace directives, vendoring, private modules, workspaces. 100% Go-specific.

Go observability with slog, Prometheus, and OpenTelemetry. Structured logging, metrics middleware, tracing, health checks. Extends core/observability with Go SDK patterns.

Go project scaffolding. Service/CLI/library directory structure, boilerplate, dependencies, tooling. Extends core/project-structure with Go-specific layouts and templates.

Go-specific style conventions. gofmt, naming, receiver types, import grouping, linting config. Extends core/style with Go idioms.

Go testing with Ginkgo (BDD) and Gomega (matchers). Describe/Context/It organization, DescribeTable, setup hooks, DeferCleanup. Use when project uses Ginkgo/Gomega instead of stdlib testing. 100% Go-specific.

Go testing patterns with stdlib testing package. Table-driven tests, subtests, test helpers, function-based mocks. Extends core/testing with Go-specific implementations.

Remote git write discipline: push, force-push policy, upstream tracking, tag push. Part of the opt-in ops-skills plugin. Use ONLY when session context has ops_enabled=true. Pair with core/git-workflow for local discipline.

Pull request creation and response discipline. Use when opening a PR with `gh pr create`, responding to review comments, selecting a merge strategy (squash / merge commit / rebase), marking a draft PR ready, or updating a PR description after the branch changes. Trigger on phrases like "open a PR", "create the pull request", "respond to review comments", "merge this PR", "mark ready", or "which merge strategy?". Part of the opt-in `ops-skills` plugin — requires `ops_enabled=true` in session context; if disabled, report the intended action as a follow-up instead of running it. Pair with core/git-workflow §5 for the body content you put inside the PR.

Container registry push discipline. Use when pushing a built image to a registry (ECR, GCR, GHCR, Docker Hub), tagging an image for a release or deployment, signing images for supply-chain verification (Cosign, Notary), authenticating to a registry, or choosing between immutable (v1.2.3, sha-abc123) and mutable (latest, canary, stable) tag strategies. Trigger on `docker push`, `crane`, registry-auth errors, tag rollouts, image-signing questions, or any task that produces an image destined for a remote registry. Part of the opt-in `ops-skills` plugin — requires `ops_enabled=true` in session context; if disabled, report the intended push as a follow-up with the proposed tag. Pair with core/docker for local image build discipline.

Release publication discipline: semver decision, tag creation, changelog generation, GitHub Releases. Part of the opt-in ops-skills plugin. Use ONLY when ops_enabled=true. Pair with core/git-workflow §6 for versioning strategy selection.

HTTP/gRPC API design principles. Use when building APIs, designing handlers, planning middleware, or reviewing API surfaces. Pair with language-specific api-design skill.

2 hooks across 2 events