milwis-coding-toolkit

Plugin milwis-coding-toolkit from marketplace milwis-marketplace in milwis/claude-config. Commands read from the repo's manifest — today.

Skills (18)

• audit-360

  Use when the user asks for a 360° or full code audit, a security review of a whole project, a pre-deploy or post-vibe-coding audit, or a review of AI-generated code across the codebase.

• brainstorming

  Use before new features, modules, or changes touching 3+ modules. NOT for bugfixes, typos, config tweaks. Scales: LIGHT (2-3 questions) for medium changes, FULL (3-phase session) for new features.

• deploy

  Owner-only: build and deploy the desktop app to production (KonkretnyTMS / FakturyKonkret) — manual production steps plan (GATE 0) with one-command-at-a-time operator guidance, pre-deploy gates, full local test run plus analysis of the last 10 failed CI runs before push, changelog approval, Version:

• eval-recenzenta

  Regression set for the code-reviewer: run a reviewer definition against the project's known cases (diffs with a confirmed bug, clean diffs) and score recall and noise. Run before and after every change to code-reviewer.md, the reviewer's model or its effort; keep the change only when the score holds

• executingplans

  Use when you have a written implementation plan to execute. Drives task-by-task execution with parallel groups, scope discipline, verification at group boundaries and the plan's review checkpoints.

• lang-guidelines

  Use when a project needs rules for a language or technology: researches AI-coding errors for it and keeps, as candidate path-scoped rules, only those the project shows or has a canonical fix for. Usage - /lang-guidelines <language> [project path]

• migration

  Use when a change alters a persisted or public shape: DB schema, stored data, API contract, message or protocol format, config keys, or a dependency's major version.

• new-project

  Universal project foundation skill. Creates professional, scalable, secure base for any new project. Covers: marketplace plugins, architecture, logging, security, exceptions, testing, resilience, CI/CD, docs. Run ONCE at project start.

• nowe-issue

  Use whenever a new GitHub issue must be created: a bug found during work, a spin-off from NOWE PROBLEMY, an audit finding, a `too-big.` report, or a large problem the owner wants split.

• resolving-merge-conflicts

  Use when a git merge, rebase or cherry-pick is in progress with conflicts, e.g. while merging a wave's agent/issue-* branches into main.

• retro

  Retrospective on a finished roadmapa queue run or a single session: read the ledger and the subagent transcripts, find where tokens and quality were lost, and propose changes to the toolkit's skills/agents/hooks — every proposal with a POMIAR (command or file:line) and the rule it changes. Run after

• roadmapa

  Use when GitHub issues must be resolved one after another without the owner watching: a list (`--issues`), umbrella portions (`--parasol`, `--bez-triage` from a plan) or the backlog P0→P3. Started with `scripts/kolejka.sh start`.

• systematic-debugging

  Use when encountering any bug, test failure, or unexpected behavior. Log-first evidence gathering, then 4-phase root-cause discipline before any fix: investigate, compare, hypothesize, fix.

• task-lifecycle

  Use when implementing a feature, bugfix or issue end to end with little supervision, through a fresh review and a fresh verification to a report the user can merge from.

• test-driven-development

  Use when implementing any new feature, bugfix, refactor, or behavior change: a test seen failing first, the minimum code to pass it, refactor while green.

• verification-before-completion

  Use before claiming any work is done, fixed, passing, or ready — and before committing, pushing, or creating a PR. Run the verification command in THIS message and read the output before any success claim.

• verify-e2e

  Use after implementing a user-facing change (GUI, API endpoint, CLI, cron, agent), to verify it on the surface the user touches, in a fresh subagent, with evidence.

• writingplans

  Use when you have a spec for a multi-step task. Creates implementation plans with vertical slicing, risk-first ordering, and acceptance criteria — describes intent, not inline code.

Subagents (7)

• backend-security-coder

  Security auditor for audits and dedicated security passes: finds exploitable defects and proves each; proposes fixes as diffs, never edits. Diff review security is code-reviewer's job.

• builder

  Implements a self-contained change from a brief in any layer or language, follows the project's own rules and proves it with the project's checks. For independent tasks worth a separate context.

• code-reviewer

  Reviews a diff in a fresh context against the spec and the project's rules: tests first, then 7 axes incl. security and data integrity, each finding proven. Sizes itself from git diff --stat.

• database-optimizer

  Makes a slow query, index or data path faster with a before/after measurement on the same data, without changing what it returns.

• debugger

  Root-cause investigator: finds why a failure happens from logs, a minimal reproduction and measured disproof of alternatives; fixes at the root when the brief asks.

• refactoring-orchestrator

  Runs a behavior-preserving refactor end to end in one context: checkpoint, baseline, small steps, equivalence proof. Read-only audit mode on request. Behavior changes are reported, never mixed in.

• test-automator

  Writes the tests a brief asks for and proves each can fail; given a verification brief, tries to falsify a done-claim on the surface the user touches.

Similar plugins