design

Plugin design from marketplace zadykian in zadykian/toolkit. Commands read from the repo's manifest — today.

Skills (20)

• atomic-commits

  Use when implementing code changes in a git repo - deliver small, self-contained Conventional Commits, and split any change over 500 diff lines into a stack of up to 5 independently mergeable PRs.

• banned-terms

  Keep vague names and fillers, such as helper, utils, misc and simply, out of new code and prose. Use when naming a file, type, function or variable, and when writing a comment, a doc, a commit message, or a pull request's title and body. - "**/*.md" - "**/*.go" - "**/*.py" - "**/*.sh" - "**/*.js" -

• ci

  Write a repository's GitHub Actions workflows: short jobs that run on every pull request, long jobs that wait for a ready stack on the default branch, and what every job sets. Use when writing or editing a workflow, or when CI's runners queue.

• codebase-design

  Give the shared vocabulary for deep modules: a lot of behaviour behind a small interface, at a clean seam. Use when designing or improving a module's interface, finding where to deepen, placing a seam, or making code easier to test, or when another skill needs the terms.

• context

  Keep a long session's context small: how to read, how to bound output, when to write a checkpoint and compact, and how long a report runs. Use in a session that reads many files, runs many commands, or has run for a long time.

• cost

  Report what Claude Code sessions cost, from their transcripts: by tier, model and context size, cache writes by idle gap, the largest tool results, foreground polls, and each workflow's real tokens. Run by hand, to measure a baseline and the change after.

• delegate

  Decide whether to hand work to a subagent, which agent takes it, how to write its brief, and how to read what it returns. Use before each spawn of an agent, and before a batch of them.

• domain-modeling

  Build and sharpen a project's domain model: challenge its terms, keep its glossary, and record its hard decisions. Use when discussing a codebase's terminology, or writing or editing a glossary or a decision record.

• fan-out

  Size review by risk, tier a workflow's agents, and keep its results small. Use when writing a Workflow script, or when planning to review, verify or fix a change with several agents.

• grill-me

  Interview the user, round by round, until a plan, decision or idea is understood by both. Use when the user asks to be grilled, or wants to stress-test their thinking.

• grill-with-docs

  Interview the user to sharpen a plan or design, and keep the glossary and the decision records as the talk goes. Use when the user asks to be grilled and to have the terms and decisions written down.

• improve-codebase-architecture

  Scan a codebase for deepening opportunities, write them up as a Markdown report, then grill through the one the user picks. Use when the user asks to improve the architecture, or to find shallow modules to deepen.

• issue

  Plan a change, then file it as a GitHub issue in a compact house style once the maintainer approves the plan. Use when asked to file, open or write up an issue, or to plan a change as one.

• land

  Land a stack of approved pull requests on main, bottom first, by GitHub's merge commits, and tag a release if asked.

• repo-settings

  Check a GitHub repository's merge settings, rulesets and Actions permissions against those that stacked pull requests land by, report each difference, and apply them once approved.

• split-file

  Split a source file over the line cap into files by responsibility, in its package or module and with its API unchanged. Use when a size check reports a file over its cap.

• tdd

  Build a feature or fix a bug test-first, in red-green slices at agreed seams, with tests that state behaviour and survive a refactor. Use when asked to work test-first, to run red-green-refactor, or to add integration-style tests.

• trim

  Trim a repository's code comments or Markdown docs to the writing policy and its Vale rules, keeping every fact. Use on files that fail Vale or the policy's caps, or that restate the code or the help.

• wait

  Wait on work without holding the turn or the cache: run it in the background, watch for a change of state, and bound a foreground wait. Use when starting a build, a test run, a CI run or a deploy, when about to poll, or when scheduling a wake-up.

• writing

  The writing policy for code comments and docs: a comment gives a purpose or a reason, each fact lives in one place, and short sentences pass Vale's rules. Use when writing or editing comments, Markdown or other prose in a repository. - "**/*.md" - "**/*.go" - "**/*.py" - "**/*.sh" - "**/*.js" - "**/

Similar plugins