patryks-treadmill-claude-plugins

Self-evaluation loop for the treadmill Claude plugins pack. Runs cursor-plugin-evals against bundled skills, tracks quality over time, and escalates recurring failures via PAMS. Use periodically or before publishing plugin updates.

Autonomously implement technical plans from context/changes/<change-id>/plan.md under Codex's /goal — no human interaction at any point. Sibling of /shape-implement for unattended runs, in an interactive /goal session or headless via Codex -p. Flips the plan's Automated Progress rows, verifies each phase through an automatic quality-gate stack (plan success criteria, deliberate-break check, full suite), commits each phase on green with Conventional Commits, and surfaces pending Manual rows as a closing human checklist. Use when the user wants autonomous or unattended plan execution, pairs /goal with a plan, asks to "run the plan under /goal", or needs headless implementation.

Review implementation against plan for drift, dangerous decisions, and pattern compliance

Implement technical plans from context/changes/<change-id>/plan.md with verification

Review implementation plans for substance, feasibility, and architectural fitness. Use when user asks to review a plan, says "is this plan good", "check my plan", "review this plan", mentions plan review, or references a plan file and asks for feedback. Also trigger when user finishes /shape-plan and wants validation before starting /shape-implement.

Drive an approved implementation plan to completion phase by phase, test-first, through the red→green→refactor cycle, but only for phases whose implementation does not exist yet. Reads a plan from context/changes/<change-id>/plan.md and the canonical Progress section, and for each phase first checks whether the phase is TDD'able and still unimplemented — if it is, you write a failing test (RED), make it pass with the minimal code (GREEN), then clean up (REFACTOR); if it is not TDD'able, you redirect that phase to /shape-implement; if implementation is already present, you stop and explain that TDD does not work for already existing code, then suggest /shape-implement for that phase. Mirrors /shape-implement (same plan, same Progress source of truth, same phase-end commit ritual and clipboard handoffs) but flips the order so the failing test always comes before the code. Assumes test infrastructure is already in place — it does NOT set up runners, configs, fixtures, or CI. Use this skill when the user says "td

Run implementation review non-interactively in CI against a PR: discovers the plan, checks drift/safety/patterns/test coverage, writes context/changes/<change-id>/reviews/impl-review.md, commits it to the PR branch, and posts a summary comment. Use whenever the request mentions CI, GitHub Actions, GHA, Codex Action, automated PR review, or "review this PR in CI".

Generate context/foundation/roadmap.md from a PRD as an ordered set of vertical, end-to-end slices. Use AFTER /shape-prd (and after the tech-stack selection / bootstrap step, when applicable) to turn a holistic PRD into a sequence of user-visible milestones a programmer can pick off and hand to /shape-plan. Trigger phrases: "write the roadmap", "generate roadmap", "create the roadmap from PRD", "stwórz roadmapę", "turn PRD into a roadmap", "what should I build first". Do NOT use for per-change planning — that's /shape-plan's job.

Archive a completed change by moving its folder into context/archive/ and stamping change.md with archived status

Drive an approved plan's browser-level (E2E) phases against the running app, one risk at a time — plan → generate → review → verify. The E2E sibling of /shape-implement and /shape-tdd, sharing the same plan and Progress. Only drives risks that genuinely need a browser and whose feature is already built; redirects the rest to /shape-tdd or /shape-implement. Use when the user says "e2e", "write/generate a Playwright test", "browser test this risk", or "drive the plan's E2E phases".

Challenge framing assumptions about WHAT to build before planning HOW. Use when input is a "bug + proposed fix", a scope question, a design choice, or any case where the observation and the stated cause (or the problem and the solution) are presented as one. Trigger phrases: "fix", "bug", "broken", "root cause", "should we even", "is this the right", "challenge the assumption", "rethink", "before I plan". Use BEFORE /shape-plan, not in place of it.

Initialize a new change folder under context/changes/<change-id> with a change.md identity file

Create detailed implementation plans with thorough research and iteration

Research codebase comprehensively using parallel sub-agents

Stateful, phased test-rollout orchestrator for existing products. Writes a durable phased rollout document at `context/foundation/test-plan.md` BEFORE handing off, then drives each rollout phase into /shape-new → /shape-research → /shape-plan → /shape-implement. Re-running the skill re-derives state from which artifacts exist and resumes from the next pending rollout phase. Once a rollout change is opened, follow the established research → plan → implement process: after each major phase, suggest the next natural command unless there is a clear blocker. Use when the user says "create test plan", "plan tests", "test strategy", "phased test rollout", "continue test rollout", "risk map for testing", "QA spec", "AI-native testing strategy", "stwórz plan testów", "strategia jakości". Use AFTER /shape-prd and /shape-roadmap. Brownfield only; greenfield needs a PRD first.

Facilitate a structured discovery conversation that turns an idea — greenfield or brownfield — into shape-notes.md, the input to /shape-prd. Auto-detects context type from project markers in cwd (brownfield) or absence thereof (greenfield) and adapts all six discovery phases accordingly. Use when the user is starting a new project from scratch OR shaping a meaningful change to an existing system (new module, significant feature, architectural improvement). Trigger phrases: "new project", "from scratch", "starting an app", "od pomysłu", "shape an idea", "brainstorm a product", "greenfield", "I have an idea", "existing project", "brownfield", "istniejący projekt", "zmiana w projekcie". Use BEFORE /shape-prd, not in place of it.

Validate any idea — product, feature, internal tool, service, or workflow — using The Mom Test principles before building. Use after someone has a draft idea or supporting notes (user interviews, tickets, or a shape/PRD/roadmap/ opportunity-map) and wants to check whether the problem is real. Produces a non-leading critique, an interview guide, survey questions, and go/no-go decision criteria grounded in past behavior and concrete pain, not opinions about the solution.

Turn recurring friction or an unmet need into a build-vs-buy-vs-complement-vs-wait decision artifact: an opportunity map with the existing/default response, a thin complement, a first useful version, and a data-risk caveat, plus one recommended candidate to try. Works for any idea — product, feature, internal tool, service, or automation — with a worked internal-builder lens. Use when someone wants to classify pain or signals, decide whether something is worth building before writing code, or sort a "let's build a dashboard / agent / app / automation" idea into build, buy, complement, or wait.

Invoke this skill when the user asks how to USE the product-shaping plugin day-to-day — which /shape-* command to run next, where artifacts land, how to switch between greenfield and brownfield workflows, troubleshooting errors, or working on a specific OS (Windows, Linux, macOS). Covers all /shape-* slash commands, artifact locations, pipeline stages, common errors, and platform-specific tips. Excludes: first-time installation (use shape-cli-setup instead), developing or contributing to the plugin source code, and general programming help.

Invoke this skill when the user asks how to INSTALL or SET UP the product-shaping plugin for the first time — adding skills to Claude Code, Cursor, GitHub Copilot, Codex CLI, or another AI tool. Covers first-time installation, updating skills, verifying the setup, and configuring for the user's specific tool. Excludes: daily usage questions (use shape-cli-guide instead), writing product artifacts, and general programming help.

Orient a user through the product-shaping pipeline. Use when the user asks "where do I start", "how does this work", "what should I run first", "I have an idea but don't know where to begin", or any variant of asking for a tour of the shape-* skills. Auto-detects whether the project is greenfield or brownfield from cwd, asks 1-2 orienting questions, then names the exact next slash command to run. Also use when the user invokes any /shape-* command without context (e.g. running /shape-bootstrap with no tech-stack.md on disk) — this guide redirects them to the right starting point.

Intelligently decide if a task requires OpenSpec and orchestrate the full spec-driven workflow. OpenSpec is MANDATORY for all change-level specs, planning, and design work -- no exceptions EXCEPT product-level shaping (PRD, tech-stack selection, initial bootstrap), which is upstream of OpenSpec and lives in the product-shaping plugin (/shape-idea, /shape-prd, /shape-tech-stack, /shape-bootstrap). When no context/foundation/prd.md exists yet and the user is shaping a new product, defer to product-shaping. Once a PRD exists and the user is implementing changes against it, OpenSpec takes over. Auto-evaluates complexity signals and seamlessly guides through OpenSpec or direct implementation. Also handles installation guidance when OpenSpec CLI is missing. Triggers on "implement X", "plan this feature", "add feature X", "build Y", "should I use OpenSpec?", "design X", "spec this out".

Scaffold a project into the current working directory after the tech stack has been picked. Reads context/foundation/tech-stack.md (the hand-off written by /shape-tech-stack), looks up the chosen card in the starter registry, and runs its CLI through one of three cwd strategies (subdir-then-move, native-cwd, git-clone) with a strict conflict policy that always preserves context/. Two verification slots flank the scaffold: a light pre-scaffold recency check and a deeper post-scaffold audit. Writes a verification log to context/changes/bootstrap-verification/verification.md. Use when the user says "bootstrap the project", "scaffold the app", "set up the codebase", "let's start the project", or naturally follows /shape-tech-stack. Use AFTER /shape-tech-stack.

Generate context/foundation/prd.md from shape-notes.md (or raw notes) against the locked PRD schema. Auto-routes to greenfield (10 sections) or brownfield (11 sections) template based on context_type in shape-notes.md or cwd auto-detection. Use when the user has shaping notes ready and wants a schema-conformant PRD written to disk. Trigger phrases: "write the PRD", "generate PRD", "create the PRD from notes", "stwórz PRD", "turn notes into a PRD", "PRD from shape-notes". Use AFTER /shape-idea, not in place of it.

Generate an AGENTS.md onboarding document for AI coding agents working in this repository. Inspects the repo (package manifest, README, scripts, lint/test config, layout, commit history) and writes a concise contributor guide titled "Repository Guidelines". Use when the user invokes /shape-agents-md, asks to "create AGENTS.md", "write an agent onboarding doc", "generate contributor guide for agents", or similar. The output is optimized to be small, precise, reference-heavy, and ordered with critical rules at the top — so a future agent reads it once and stays unblocked.

Run a health check on an existing project: dependency audit, security scan, test runner detection, CI/CD evaluation, and missing configuration analysis. Maps the three execution gates (pre/in/post) from /shape-bootstrap to an assessment framework for existing codebases. Reads optional context/foundation/stack-assessment.md from /shape-stack-assess to focus checks on identified gaps. Writes context/foundation/health-check.md with findings, prioritized fixes, and an agent-readiness verdict. Use when the user has an existing project and wants to verify its health before working with an agent. Trigger phrases: "health check", "check my project", "audit my project", "is my project healthy", "sprawdź projekt", "audyt projektu", "health-check", "project health". Use AFTER /shape-stack-assess (brownfield chain), BEFORE agent onboarding (m1-l4).

Research and recommend an MVP deployment platform by combining tech-stack context, a short developer interview, and parallel web research scored against five agent-friendly platform criteria. Cross-checks the top recommendation through three anti-bias lenses (devil's advocate, pre-mortem, unknown unknowns) before writing context/foundation/infrastructure.md with a scored platform comparison, rationale, and risk register. Use when the user needs to pick a hosting / deployment / maintenance platform for an MVP and wants a well-researched, bias-checked decision rather than a gut call. Trigger phrases: "choose a platform", "where should I deploy", "infra research", "deployment platform for my MVP", "wybierz platformę", "gdzie deployować", "infrastructure decision", "hosting choice", "jaka platforma do deploymentu". Use AFTER /shape-prd or /shape-tech-stack.

Initialize the /context directory in this project — scaffold context/{changes,archive,foundation}/ plus universal README.md files if absent. Worktree-aware (places context/ at the main repo root so all worktrees share it). Excludes context/ from git so artifacts never get accidentally committed or wiped.

Capture a recurring rule or pattern into context/foundation/lessons.md. Use when you spot a class of bug or design pitfall worth surfacing for future reviews and implementations.

Review the condition of an "AI rules" file (CLAUDE.md, AGENTS.md, .cursor/rules/*.mdc, .github/copilot-instructions.md, .windsurfrules, nested per-area rule files, or any other rule-for-AI markdown) and produce a 5-point scorecard with concrete, actionable fixes. Use when the user invokes /shape-rule-review with a path to a rules file, or asks to "review AI rules", "audit AGENTS.md", "check my CLAUDE.md", "score my agent instructions", "is this rules file healthy", or similar. The skill is agnostic to which tool the rules file targets — it scores the file as a rule-for-AI artifact, not as a project document.

Assess an existing project's stack for agent-friendliness using the 4 quality gates (typed, convention-based, popular in training data, well-documented) as an evaluation lens. Detects stack components from cwd, scores each against the gates, identifies compensation strategies for failures, and writes context/foundation/stack-assessment.md with per-component scores, gap analysis, and ready-to-paste CLAUDE.md/AGENTS.md entries. Use when the user has an existing project and wants to evaluate how well their stack supports AI agent workflows. Trigger phrases: "assess my stack", "evaluate my project", "is my stack agent-friendly", "oceń mój stack", "sprawdź projekt", "stack assessment", "brownfield assessment". Use AFTER /shape-prd (brownfield), BEFORE /shape-health-check.

Pick a starter and a stack for a greenfield project after the PRD is written. Reads context/foundation/prd.md, opens with a Q0 path-fork (recommended default for the (product_type, language_family) cell vs design-your-own), runs the residual interview on the custom path, reasons over a language-aware starter registry with four agent-friendly quality gates, and writes a context/foundation/tech-stack.md hand-off /shape-bootstrap consumes. Use when the user asks "what stack should I use", says "pick a stack", "choose framework", "co wybrać do projektu", or has a PRD on disk and is ready to scaffold. Use AFTER /shape-prd, BEFORE /shape-bootstrap.

Analyze Kibana bundle size and performance with webpack-bundle-analyzer, duplicate detection, and tree-shaking optimization recommendations.

Review and manage dependency updates in Kibana by analyzing Renovate PRs, checking changelogs for breaking changes, batching merges, and monitoring security advisories.

Identify and fix performance bottlenecks in Kibana build, test, and CI workflows by analyzing slow operations, diagnosing root causes, and measuring optimization impact.

Audit UI components and pages for accessibility issues and suggest fixes to ensure Kibana is usable by everyone.

Guide systematic refactoring with safety checks, metrics, and test-driven validation.

Maintain skill ecosystem quality, discoverability, and security. Auto-runs after skill creation/modification to validate conventions, check security, detect similarity overlaps, generate searchable catalog, suggest MCP tool integrations, track usage analytics, and optimize skills for token efficiency. Use when creating/reviewing skills, generating skill catalog, checking for duplicates, maintaining ecosystem health, or reducing token footprint of a skill.

Understand code history and context through git archaeology to answer "why", "who", and "when" questions about code.

Guide complex Git operations including interactive rebase, cherry-pick, conflict resolution, reflog recovery, and history rewriting with safety warnings and step-by-step guidance.