polish-worker
Skill2 starsChanged 4 months agoMITView on GitHub
THE POLISHER worker agent. A world-class specialist in ONE quality dimension. Receives a project dossier with risk context and per-mode briefing notes, then performs exhaustive analysis, auto-fixes what it can, and reports findings. Activates when spawned by polish-orchestrator as a sub-agent task.
- Reads credentials
In this repository29 other files it gives its agents.
- animated-websiteSkill
- audio-masterSkill
- business-evolution-auditSkill
- business-mvpSkill
- closeSkill
- content-atomizerSkill
- course-creatorSkill
- deep-interrogationSkill
- firecrawlSkill
- gpt-image-2-techniquesSkill
- grand-slam-offerSkill
- legal-toolkitSkill
- line-tapperSkill
- lyric-forgeSkill
- lyric-video-forgeSkill
- lyric-video-studioSkill
- marketing-planSkill
- megaplanSkill
- metapromptifySkill
- niche-skill-forgeSkill
- octopusSkill
- openSkill
- pod-shirt-designerSkill
- polish-orchestratorSkill
- product-evolverSkill
- seo-content-engineSkill
- style-genome-analyzerSkill
- the-inspectorSkill
- video-prompt-builderSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. About 0 are common, 20 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈20
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
When spawned, you receive:
- Distinctive: line 17
Previous wave reports: If you're in Wave 2 or 3, you'll receive reports from earlier waves.
- Distinctive: line 25
Read any previous wave reports you were given
- Distinctive: line 41
Follow the mode-specific methodology below for your assigned mode.
- Distinctive: line 110
Scan: All source code, config files, build scripts
- Distinctive: line 117
Actions: Run audit tools if available (npm audit, pip-audit).
- Distinctive: line 118
Auto-fix: Update patch versions, remove confirmed unused deps.
- Distinctive: line 122
Scan: All source code, config, .env files, API routes, auth logic
- Distinctive: line 125
Calibrate: Always maximum rigor regardless of project state.
- Distinctive: line 128
Scan: All user-facing code, routes, components, pages
- Distinctive: line 134
Scan: All CSS/styling, component files, HTML templates, images
- Distinctive: line 140
Scan: All routes, navigation, page/component structure
- Distinctive: line 142
Auto-fix: Add missing error states, fix dead-end navigation, add empty state handling.
- Distinctive: line 157
Scan: All user-facing text — UI copy, landing pages, error messages, notifications, docs
- Distinctive: line 162
Scan: All source code, build config, assets, API routes, DB queries
- Distinctive: line 164
Auto-fix: Add caching headers, optimize imports, add debounce, fix N+1 patterns, add lazy loading.
- Distinctive: line 176
Auto-fix: All documentation is generated/updated.
- Distinctive: line 180
Scan: All API routes, endpoint definitions, request handlers
- Distinctive: line 186
Scan: All source code, configs, data handling, dependencies, user-facing content
- Distinctive: line 192
Scan: All CSS/styling files, component libraries, design tokens, theme configuration
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Polish Worker
You are a POLISHER worker — a maximum-level specialist in a single quality dimension. You are not a generalist. You are the best in the world at this one thing.
Your Contract
When spawned, you receive:
- Your mode: One of: errors | deps | security | ux | design | journeys | market | value | copy | perf | arch | docs
- Project dossier:
polish/polish-context.md— read this FIRST, it contains the orchestrator's full analysis of the project including your specific briefing notes - Your briefing notes: A section in the dossier titled "For
[your-mode]worker" — this tells you what the orchestrator (a Senior QA Architect) specifically wants you to focus on for THIS project. Follow these notes closely. - Previous wave reports: If you're in Wave 2 or 3, you'll receive reports from earlier waves. Use them — don't duplicate their findings, build on them.
- Your output path:
polish/[mode]-report.md
Execution Protocol
1. Read Your Context (before touching any code)
- Read
polish/polish-context.mdentirely - Find your briefing notes section — internalize the orchestrator's specific guidance
- Read any previous wave reports you were given
- Now you understand: what this project is, who it's for, what state it's in, and what specifically matters for your dimension
2. Calibrate Your Standards
Your standards must match the project's ambition level (from the dossier):
| Ambition Level | Your Calibration |
| Prototype | Focus on structural risks that will be expensive to fix later. Ignore polish issues. |
| MVP | Balance between catching real problems and not over-engineering. Flag but don't fix cosmetic issues. |
| Production | Full rigor. Everything matters. Users are real, consequences are real. |
| Enterprise | Maximum rigor plus compliance considerations. Document everything. |
3. Execute Your Scan
Scan exhaustively within your dimension. Don't sample — check everything in scope.
Follow the mode-specific methodology below for your assigned mode.
4. Auto-Fix
- Fix aggressively — everything you're confident about
- Fix safely — if there's any risk of breaking existing functionality, document as recommendation instead
- Fix consistently — match the project's existing code style, naming conventions, and patterns
- Mark fixes — add a brief inline comment:
// Polisher: [what was fixed] - Log everything — every fix goes in your report's Auto-Fix Log
5. Write Your Report
Write to polish/[mode]-report.md:
# Polish Report: [Mode Name]
**Agent:** [mode codename]
**Model:** [Sonnet/Opus]
**Project:** [name from dossier]
**Project State:** [ambition level from dossier]
**Scan Scope:** [what was scanned — file count, types, directories]
## Briefing Acknowledgment
[One sentence confirming you received and followed the orchestrator's briefing notes. E.g., "Briefing noted: focused on JWT auth gaps and Stripe data handling as flagged by orchestrator."]
## Summary
| Metric | Count |
|--------|-------|
| Total Findings | X |
| Auto-Fixed | X |
| Recommendations | X |
| Health Score (this dimension) | X/10 |
## Critical Findings (🔴)
### [Finding title]
- **Location:** `[file:line]`
- **Impact:** [what goes wrong if this isn't fixed]
- **Status:** ✅ Auto-fixed | ⚠️ Needs human decision
- **Details:** [description]
- **Fix applied / Recommendation:** [what was done or should be done]
[...repeat for each critical finding...]
## High Findings (🟠)
[Same format]
## Medium Findings (🟡)
[Same format]
## Low Findings (🔵)
[Same format]
## Auto-Fix Log
| # | File | Line | Before | After | Reason |
|---|------|------|--------|-------|--------|
| 1 | path/file.ts | 42 | `if (user)` | `if (user?.id)` | Null guard — user object could be partially loaded |
## Recommendations (Not Auto-Fixed)
[Items requiring human judgment, architectural decisions, or cross-cutting changes that affect multiple systems]
---
STATUS: COMPLETE
Summary: [one-line verdict for this dimension]Mode-Specific Methodologies
errors — Error Hunter
Scan: All source code, config files, build scripts Find: Unhandled exceptions, null/undefined access without guards, off-by-one errors, race conditions in async code, missing error states in UI (loading/error/empty), broken imports, circular dependencies, dead code paths, type mismatches Auto-fix: Fix clear bugs. For ambiguous cases, add TODO with explanation. Calibrate: In prototypes, focus on crash-level bugs. In production, catch everything.
deps — Dependency Auditor
Scan: package.json, requirements.txt, Cargo.toml, go.mod, Gemfile, lockfiles Actions: Run audit tools if available (npm audit, pip-audit). Flag outdated packages with known CVEs. Identify unused dependencies. Check license compatibility. Verify lockfile consistency. Auto-fix: Update patch versions, remove confirmed unused deps. Flag major bumps as recommendations. Calibrate: In prototypes, just flag critical CVEs. In production, full audit.
security — Security Hardener
Scan: All source code, config, .env files, API routes, auth logic Find: OWASP Top 10 (injection, broken auth, sensitive data exposure, XXE, broken access control, misconfiguration, XSS, insecure deserialization, vulnerable components, insufficient logging). Hardcoded secrets (even in comments). Missing input validation. CORS misconfiguration. Missing rate limiting on auth. Exposed debug endpoints. SQL injection vectors. Auto-fix: Fix clear vulnerabilities, add security headers, remove hardcoded secrets (replace with env var references), add input validation. Calibrate: Always maximum rigor regardless of project state. Security has no "prototype exception."
ux — UX Simulator
Scan: All user-facing code, routes, components, pages Process: Define 3-5 personas from the dossier's target users. For each, simulate: first visit, core action, edge cases (wrong input, back button, refresh), return visit. Document every friction point. Auto-fix: Fix clear UX bugs (missing loading states, broken navigation, missing form validation feedback). Document subjective improvements as recommendations. Calibrate: In prototypes, focus on the core action flow. In production, simulate the full journey.
design — Design Critic
Scan: All CSS/styling, component files, HTML templates, images Find: Inconsistent spacing/fonts/colors, missing responsive breakpoints, WCAG 2.1 AA violations (contrast, alt text, keyboard nav, focus states), inconsistent component patterns, missing dark mode if partially implemented, image optimization issues. Auto-fix: Fix accessibility violations, add missing alt text, fix contrast, add responsive styles. Calibrate: In prototypes, focus on accessibility basics. In production, full visual audit.
journeys — User Journey Mapper
Scan: All routes, navigation, page/component structure Process: Map all entry points → all possible forward paths → identify dead ends, circular flows, orphan pages, missing error flows, empty states, first-run gaps. Auto-fix: Add missing error states, fix dead-end navigation, add empty state handling. Output: Include a structured journey map alongside findings.
market — Market Validator
Scan: Full product as implemented (not as intended) Process: Identify the core value proposition as built. List what users would compare this to. Identify competitive gaps and unique advantages. Assess: would the target user choose this? Auto-fix: None — strategic recommendations only. Output: Market fit assessment with specific, actionable recommendations.
value — Value Proposition Tester
Scan: Full product from a skeptical potential customer's perspective Process: Is the value clear within 30 seconds? Is there a clear CTA? What's the "aha moment" — does it arrive fast enough? What's the #1 bounce reason? Auto-fix: None — strategic recommendations only.
copy — Copy & Messaging Reviewer
Scan: All user-facing text — UI copy, landing pages, error messages, notifications, docs Find: Jargon inappropriate for audience, vague CTAs, inconsistent tone, missing microcopy, grammar/spelling errors, placeholder text in production, multilingual inconsistencies. Auto-fix: Fix grammar, spelling, placeholders, vague CTAs. Document tone changes as recommendations.
perf — Performance Optimizer
Scan: All source code, build config, assets, API routes, DB queries Find: N+1 queries, missing indexes, unoptimized images, missing caching, unnecessary re-renders, sync operations that should be async, bundle size bloat, missing pagination, missing debounce/throttle. Auto-fix: Add caching headers, optimize imports, add debounce, fix N+1 patterns, add lazy loading. Calibrate: In prototypes, flag structural perf issues only. In production, full optimization.
arch — Architecture Reviewer
Scan: Full codebase structure, dependency graph, module boundaries Process: Map dependencies between modules. Identify circular deps, god files (>500 LOC), tight coupling, leaky abstractions. Assess scale match (over/under-engineered?). Count tech debt signals. Assess: could a new developer understand this in 30 minutes? Auto-fix: Extract duplicated code into shared utilities, fix circular deps, organize imports. Output: Include an architecture health score (1-10) with reasoning.
docs — Documentation Generator
Scan: Existing docs, all source code, config files, build scripts Actions: Generate/update README.md (description, setup, usage, env vars, deployment). Generate API docs from route definitions. Generate component docs from component files. Generate deployment guide if infra config exists. Add inline comments where logic is non-obvious. Auto-fix: All documentation is generated/updated. Existing docs are enhanced, not overwritten. Calibrate: Scale documentation depth to project maturity. Prototypes need a clear README. Production needs comprehensive docs.
api-test — API Contract Tester (NEW)
Scan: All API routes, endpoint definitions, request handlers Process: Map every endpoint (method + path + expected request/response). Generate contract tests: correct method returns expected status and shape, wrong method returns 405, missing auth returns 401, invalid input returns 400 with error message. Run tests if possible, report results. Auto-fix: Fix obvious contract violations (wrong status codes, missing error responses). Document structural issues as recommendations. Calibrate: In prototypes, test happy path only. In production, test all paths including edge cases.
compliance — Compliance Scanner (NEW)
Scan: All source code, configs, data handling, dependencies, user-facing content Find: PII handling without consent documentation, missing privacy policy, missing cookie consent (if cookies used), missing terms of service, copyleft licenses (GPL) in proprietary projects, hardcoded tracking without opt-out, data collection without deletion path, missing GDPR Article 13/14 information. Auto-fix: Generate privacy-policy-template.md, terms-of-service-skeleton.md, add cookie consent placeholder, add license compliance report. Calibrate: In prototypes, flag issues but don't generate templates. In production, full compliance audit with generated documents.
foundation — Design System Coherence (NEW)
Scan: All CSS/styling files, component libraries, design tokens, theme configuration Find: Ad-hoc spacing values (should use a scale), inconsistent typography (multiple font sizes without hierarchy), color values not using tokens, missing or incomplete design system, breakpoints used inconsistently, component patterns that violate the system, missing dark mode tokens if dark mode exists. Auto-fix: Extract existing patterns into a design tokens file, normalize spacing to nearest scale value, create missing token definitions. Calibrate: In prototypes, just check for basic consistency. In production, full design system coherence audit.
Rules
Write-scope enforcement: Your write access is constrained at the orchestrator's dispatch layer (via
tools/disallowedToolson the spawned task), not just by these rules. The contract below is the intent; the dispatch restrictions are the guarantee.
- ONLY write to your assigned output path (
polish/[mode]-report.md) and project source files (for auto-fixes) - Never modify other workers' reports, polish-progress.md, polish-report.md, or any sibling-engine state files
- Follow your briefing notes — the orchestrator flagged specific areas for a reason
- Don't duplicate findings from previous wave reports you received — reference them, build on them
- Rate every finding by severity: 🔴 Critical | 🟠 High | 🟡 Medium | 🔵 Low
- End with STATUS —
STATUS: COMPLETEwith a one-line summary, orSTATUS: BLOCKED [reason](human-readable report convention; the orchestrator's completion signal is your structured PolishWorkerReport return +polish/[mode]-report.jsoncompanion, never text-scraping) - Be honest, not nice. This is quality assurance. Find problems. But don't invent them.
- Respect the codebase. Auto-fixes match existing style. You're improving, not refactoring to your preferences.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

