Idiomatic Python 3.12+ development. Use when writing Python code, CLI tools, scripts, or services. Emphasizes stdlib, type hints, fast pytest feedback, uv/ruff/pyright toolchain, optional project-adopted ty, and minimal dependencies. NOT for Go, Rust, TypeScript, or shell-only tasks.
Idiomatic Rust development. Use when writing Rust code, Cargo crates/workspaces, Rust tests, or rustfmt/clippy/cargo workflows. Emphasizes ownership, Result errors, small APIs, stdlib-first dependencies, fast cargo feedback, and behavior tests. NOT for Go, Python, TypeScript, shell scripts, or infra-only work.
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing .sh, .bash, .zsh, .fish, .bats, shell functions, shell pipelines, CI run: shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling…
Create, split, slim, or rewrite repository skills. Use when adding a new src/skills/ / skill, editing a skill description, frontmatter, references, overlays, or plugin placement, or tightening routing between neighboring skills. NOT for score-only instruction review; use reviewing-instructions. NOT for broad…
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered…
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
Diagnose cc-thingz plugin installations with the bundled read-only doctor. Use for missing installed skills, helpers, or hook files, stale package versions, duplicate packages, or migration from old cc-thingz packages. NOT for broad agent configuration audits or config edits; use evolving-config.
Prepare, publish, or repair a software release and write its release notes. Use for cutting a versioned release or editing release notes. NOT for updating an installed package, publishing articles, or discussing a release; for general documentation use documenting-code.
Write or edit commit messages, PR/MR descriptions, issues, review comments, and technical discussions. Use for concise, clear engineering communication grounded in facts, without filler or boilerplate. NOT for creating commits (committing-code), project docs (documenting-code), release notes (releasing-code), or AI…
Design a modular architecture from requirements, intended architecture notes, or an approved redesign brief. Use when asked to create architecture docs, define module boundaries, integration contracts, test specifications, or a target architecture before implementation. Blends Balanced Coupling, architecture-fitness…
Turn approved architecture-design artifacts, with supporting review findings when present, into an incremental implementation/refactoring plan. Use when asked to plan a refactor, sequence remediation, or implement an approved target architecture. Produces a task-runner-compatible, verifiable plan that cites source…
Run a repeatable, evidence-based architecture review of an existing codebase. Use when asked to assess modularity, coupling, cohesion, dependency direction, circular dependencies, blast radius, fragile seams, shallow modules, testability, ownership boundaries, architectural drift, structural risk, or fit between…
Assign architecture scores against the fixed rubric. Use when scoring or re-scoring architecture dimensions, choosing a band, setting confidence, or checking that a score is defensible. Enforces band-matches-value, evidence-per-score, and low-confidence caps. NOT for gathering evidence (use architecture-review) or…
Treat architecture intent as executable checks (fitness functions), not prose. Use when scoring the architecturefitness dimension, recommending how to keep a boundary from re-rotting, or turning a finding into an enforceable check. Distinguishes checks that already run from checks you only recommend. NOT for judging…
Assess coupling with the Balanced Coupling model (integration strength, distance, volatility). Use when judging whether coupling is balanced or risky, scoring the couplingbalance dimension, or deciding what to flag as structural risk. Highest risk is high strength + high distance + high volatility together. NOT…
Gather deterministic architecture-fitness evidence with archfit: full checks, scorecards, deltas, SARIF/JSON findings, tool coverage, and agenttasks. Use when a repo has .archfit.yaml or the user wants architect to combine its review with archfit. Produces hard facts for architecture-review to calibrate, not a…
Gather local codebase evidence with fd, rg, git grep, git log, and targeted file reading. Use when starting an architecture review, building the system map, finding entrypoints, locating module boundaries, tracing exact text or config keys, or collecting file:line evidence for modularity, coupling, dependency…
Gather persistent code-knowledge-graph evidence from the codebase-memory-mcp MCP server: architecture overview, type-resolved call edges, cycles, blast radius, module clusters, dead code, and cross-session ADR memory. Use when mcpcodebase-memory-mcp tools are available and you need graph-shaped structure, coupling, or…
Gather whole-repo dependency and semantic graph evidence with codegraph: definitions, references, call edges, cycles, hubs, fan-in/out, and blast radius. Use when assessing module boundaries, dependency direction, coupling, impact of change, or fragile graph shape at architecture-review scale. Index staleness is a…
Gather change-coupling and volatility evidence with GitNexus git-history graphs: files that change together, churn hotspots, historical blast radius, and impact over time. Use when scoring changelocality, corroborating Balanced Coupling volatility (domain role sets it; churn only supports it), or checking whether…
★not rated 2 3mo agoA120 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: