From mz-dev-pipe
Orchestrates iterative polish of existing code against specific completion criteria. Unlike `build` which builds from scratch, polish works with what's already there — running tests, diagnosing failures, fixing issues with review loops, and optimizing.
npx claudepluginhub doctormozg/claude-pipelines --plugin mz-dev-pipeThis skill uses the workspace's default tool permissions.
Orchestrates iterative polish of existing code against specific completion criteria. Unlike `build` which builds from scratch, polish works with what's already there — running tests, diagnosing failures, fixing issues with review loops, and optimizing.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Guides code writing, review, and refactoring with Karpathy-inspired rules to avoid overcomplication, ensure simplicity, surgical changes, and verifiable success criteria.
Share bugs, ideas, or general feedback.
Orchestrates iterative polish of existing code against specific completion criteria. Unlike build which builds from scratch, polish works with what's already there — running tests, diagnosing failures, fixing issues with review loops, and optimizing.
build.debug.debug to fix the root cause first, then return to polish for quality criteria.verify.optimize.$ARGUMENTS — The completion criteria. This can be:
If empty, ask the user what needs to be polished.
See skills/shared/scope-parameter.md for the canonical scope modes (branch, global, working) and their git commands. Document any skill-specific overrides or restrictions below this line.
scope:): all project files eligible for edits.scope: controls which files agents may edit. Tests and linters always run on the full project. Criteria determine what to verify; scope determines where fixes may be applied..mz/task/ in the project root| Phase | Goal | Details |
|---|---|---|
| 0 | Setup | Inline below |
| 1 | Initial Assessment | phases/assess_and_fix.md |
| 1.5 | User Approval Gate | Inline below |
| 2 | Quick Fixes | phases/assess_and_fix.md |
| 3 | Research (if needed) | phases/assess_and_fix.md |
| 4 | Fix-Test-Review Loop | phases/fix_review_and_finalize.md |
| 5 | Optimization | phases/fix_review_and_finalize.md |
| 6 | Final Verification | phases/fix_review_and_finalize.md |
Read the relevant phase file when you reach that phase. Do not read both phase files upfront.
scope: extracted, resolve to a concrete file list and save to .mz/task/<task_name>/scope_files.txt. Otherwise all project files eligible.<YYYY_MM_DD>_polish_<slug> where <YYYY_MM_DD> is today's date (underscores) and slug is snake_case of criteria (max 20 chars); on same-day collision append _v2, _v3..mz/task/<task_name>/, write state.md with Status, Phase, Started, Iteration (0), and the criteria checklist.phases/assess_and_fix.md and proceed to Phase 1.This orchestrator (not a subagent) must present to the user via AskUserQuestion. This step is interactive and must not be delegated.
Mandatory pre-read: Read .mz/task/<task_name>/assessment.md with the Read tool. Capture the full file contents (criteria checklist showing which items are failing, proposed quick-fix plan with one line per fix target, estimated file count in scope) into context.
Mandatory inline-verbatim presentation: The AskUserQuestion question body must contain the verbatim contents of assessment.md. Never substitute a path, status summary, line count, or <failing criteria list> / <proposed quick-fix plan> / <estimated file count> placeholders — the user must review the actual assessment in the question itself, not have to open the file separately.
Before invoking AskUserQuestion, emit a text block to the user:
**Assessment Ready for Review**
Initial assessment complete. The checklist below shows which criteria are passing and which are failing, along with the proposed quick-fix strategy.
- **Approve** → proceed to Phase 2 (Quick Fixes)
- **Reject** → mark task aborted, stop here
- **Feedback** → incorporate changes, re-run Phase 1, loop back to this gate
Invoke AskUserQuestion with this body (where <verbatim assessment.md contents> is replaced by the bytes you just read):
Phase 1 assessment complete. Please review:
<verbatim assessment.md contents>
Type **Approve** to proceed, **Reject** to cancel, or type your feedback.
Response handling:
aborted_by_user and stop. Do not proceed.assessment.md, return to this gate, re-read assessment.md, and re-present via AskUserQuestion with the full new contents — never diff-only, never summary-only, since context compaction may have destroyed the user's memory of earlier iterations. This is a loop — repeat until the user explicitly approves. Never proceed to Phase 2 without explicit approval.Techniques: delegated to phase files — see Phase Overview table above.
| Rationalization | Rebuttal |
|---|---|
| "good enough, ship" | "polish is the last line of defense before users see it" |
| "edge cases are rare" | "every bug report you've ever gotten is an edge case" |
| "tests are green, refactor can wait" | "green-test refactor debt compounds" |
Output the final criteria checklist with every item checked, along with the test run status, lint status, and iteration count. Any unchecked item blocks completion.
After each phase/iteration, update .mz/task/<task_name>/state.md with:
Track cumulative file changes across iterations so the optimizer knows the full scope.