claude-resources

Spec-driven development workflow. Main Claude acts as the lead — spawns critic/scout/architect/builder/tester/reviewer as subagents, enforces human-in-the-loop gates at every phase boundary via AskUserQuestion, records every decision in docs/specs/<slug>/group-log.md. Load this skill whenever the user invokes /define, /orchestrate, /plan, /build, or /ship; whenever a task spans multiple files, packages, or concerns; whenever design decisions need review before implementation; whenever an in-progress spec under docs/specs/<slug>/ needs to resume; or whenever you're about to coordinate critic/scout/architect/builder/tester/reviewer in a sequence. This is the correct skill for any multi-step engineering task that benefits from gated, auditable execution — do not try to coordinate specialists ad-hoc.

Artifact contract for docs/specs/<slug>/ — spec.md template, frontmatter schema (task/status/current_group/total_groups/created/updated), spec directory layout, contracts-trigger rules, and parallelization markers ([P]). Load this skill whenever you're creating a new docs/specs/<slug>/ directory, authoring or editing spec.md, checking whether an existing spec matches the template (e.g., during review, resumption, or session-start scan), validating frontmatter values, or deciding whether a task needs contracts.md. Pair with core/orchestration, which owns the workflow that populates these artifacts.

Author and maintain a project constitution at docs/constitution.md — the list of invariants that reviewer and critic enforce on every spec and every diff. Load this skill whenever you're creating a new constitution from scratch or from EXAMPLE_CONSTITUTION.md, proposing candidate invariants via /constitution-propose, adding or editing an invariant, sunsetting an obsolete rule, or promoting a recurring "don't do X" review comment into an enforced invariant. Also use when a post-incident review surfaces a rule that should have been caught mechanically. Reviewer and critic consume the registered invariants automatically via the project_constitution session-start field — you do not need this skill for enforcement, only for authoring.

Ground a task in the existing codebase before specification — grep for prior art, read similar features, surface inherited gotchas, write discovery.md. Load this skill whenever you're running scout during /define or /orchestrate, whenever a task touches an area of the codebase you have not read in this session, whenever the task mentions a feature name that might already exist, or whenever recent_learnings flags a gotcha or pattern near the task. Prevents specs built on phantom assumptions.

Decision tree for routing any task to the right agent and skill set. Loaded on session start and consulted whenever you're unsure which specialist applies, which skill combination to load for a given task, or when main Claude (running core/orchestration) needs to decide which subagent to spawn for a Phase 3 subtask. Also surfaces available CLI tools, MCP servers, and user-installed skills/agents/plugins so you can prefer what's actually on the machine.

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.

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

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.

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.

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.

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.

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 patterns with stdlib testing package. Table-driven tests, subtests, test helpers, function-based mocks. Extends core/testing with Go-specific implementations.

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.

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.