claude-code-configuration

Read-only workflow for investigating how a system behaves — understanding how something works, confirming whether it does what it claims, and diagnosing bugs, errors, or unexpected behavior. Forms and tests hypotheses against real evidence (code, logs, runtime state, reproductions), traces to root cause, and reports a diagnosis or mental model with an explicit confidence level. Produces understanding, never a code change. NOT for making the fix once the cause is known (use /ship), NOT for judging a proposed diff, branch, or PR (use /review-code), and defers transferable domain concepts — how databases, Linux, or infrastructure work in general — to /database, /linux, and /devops.

Workflow for extending, fixing, or evolving existing production code — bugs, features, refactors, or shipping changes that touch APIs, data models, integrations, business logic, or user-facing behavior. NOT for greenfield prototypes or throwaway scripts, NOT for read-only investigation of how existing code works or why it fails (use /investigate), and NOT for code review (use /review-code).

Workflow for drafting a logo mark for a side project or utility, producing a self-contained HTML gallery of 4–6 concept directions per round — each rendered in SVG at large, medium, and favicon sizes on both light and dark backgrounds. The user opens the gallery in a browser, picks favorites by short letter code, and converges through subsequent rounds of variations. Forces a written brief before any SVG is drawn and requires each concept to commit to its SVG technique up front. NOT for full brand identity work (palette systems, type pairings, voice guides, marketing copy) and NOT for editing application code to install the logo into a UI (use /ship for that).

Workflow for designing, querying, and reasoning about databases — schema modeling, normalization, keys/constraints, indexing strategy, query patterns, EXPLAIN plans, transactions and isolation. Covers general database concepts, relational/SQL behavior, engine-specific quirks, non-relational systems, and workload shapes. Defaults to relational; covers non-relational when the user is working there. Produces DDL, indexing recommendations, query rewrites, and migration-content snippets — hands off integrating those into the project's migration framework and application data-access code to /ship, and surrounding infrastructure (replication, backups, hosted-database choice) to /devops.

Mentorship workflow for conceptual DevOps and infrastructure questions, design discussions, tool selection, deployment strategy, observability planning, and troubleshooting production systems. Covers cloud, CI/CD, Kubernetes, Terraform, monitoring, incidents, and SRE topics, calibrated to teach the why alongside the what. NOT for application code changes (use /ship) or code review (use /review-code).

Workflow for compacting the current conversation into a handoff document that another Claude Code session can pick up from later. Produces a single Markdown file capturing the goal, current state, in-flight work, decisions made, open questions, paths touched, and a recommended next-session skill — referencing existing artifacts (commits, PRs, diffs, plan docs, tickets, ADRs) by path or URL rather than duplicating them. NOT for writing tickets for a human development team (use /write-task for that) and NOT for permanent documentation of decisions (commits, ADRs, or the codebase own that).

Workflow for understanding and operating Linux — kernel, processes, memory, filesystems, networking, init, permissions, and the distinctions between general OS concepts, POSIX, Linux-specific behavior, and distro-specific quirks. Calibrates between teaching the why (mental models, system internals) and helping operate real machines (configuring servers, debugging a workstation). Does not handle cloud, CI/CD, or orchestration topics (use /devops for those).

Workflow for authoring or revising any Claude Code configuration — skills (SKILL.md), CLAUDE.md guardrails, settings.json (permissions, hooks, env, model), sub-agents, slash commands, MCP server entries, plugins, and the install or sync scripts around them. Operates from working knowledge of LLMs, agent harnesses, and context engineering so the configuration it produces leverages how Claude Code actually loads, routes, and applies it. Discovers and matches the local canon (project, user, or plugin scope) before writing — does not force one repo's conventions onto another. NOT for editing application code (use /ship in the target repo for that).

Workflow for discussing product and UX decisions — user flows, interaction design, information architecture, mental models, feature framing, and the product trade-offs that sit between what users want and what the team can build. Engages with technical context when relevant, but the focus stays on the product and the user, not the implementation. Does not write tickets (use /write-task) and does not modify code (use /ship).

Read-only workflow for code review, PR review, or feedback on a diff, branch, or specific files. Produces structured, prioritized feedback with blockers, should-fix items, nits, questions, and notable strengths — does not modify code. NOT for making changes (use /ship for that).

Workflow for writing tests against requirements — verifying that a feature, endpoint, or function behaves correctly according to its specification, not according to its current implementation. Reads the spec/requirement and the surface being tested (signatures, contracts, observable behavior); deliberately avoids mirroring implementation logic into the tests. Suitable for adding coverage after the fact in a codebase without strong test culture. Does not modify production code (use /ship) and does not review existing tests as part of a code review (use /review-code).

Workflow for turning a feature, change, or bug into a well-scoped ticket for a development team. May read code to understand the system well enough to write a good ticket — but the output is product-level, not an implementation plan. Produces concise tickets focused on the problem, behavior, and acceptance criteria. Does not implement the change (use /ship).