| name | be-thorough |
| description | Enforce high-rigor but scope-bounded completion workflows for coding, UI, copy, and specification-driven tasks. Use when the user says to be thorough or "full clip", invokes $be-thorough, asks for exhaustive/rigorous implementation, requests no shortcuts, wants meticulous UI or text review, or gives a comprehensive prompt, PRD, audit report, design document, checklist, issue list, or similar source of truth that must be fully satisfied before finalizing. |
Be Thorough
Core Rule
Treat "done" as a verified state, not a feeling. Before finalizing, prove that the implementation or deliverable satisfies the source request and has survived independent review.
"Be thorough" and "full clip" mean deeper evidence and verification inside the agreed mission, not permission to broaden the mission. Keep working until all admitted in-scope findings are resolved, all required scope is complete, or a real blocker prevents progress. If blocked, report the blocker with the evidence gathered and the exact remaining work.
Scope Governor
Before editing, write a compact mission contract:
- Demonstrated failure or requested outcome.
- Acceptance criteria that prove it is done.
- Explicit non-goals.
- Expected footprint: likely files, approximate changed lines, and any new concepts.
Classify every discovered concern before acting:
- Mission blocker: an acceptance criterion is still unmet.
- Patch regression: the current change introduces a concrete new failure.
- Mandatory safety: a concrete security, authorization, privacy, or data-loss risk must be fixed before shipping.
- Follow-up: valuable, but not required for this mission.
- Non-finding: speculative, duplicate, stale, pre-existing, or unsupported.
Only the first three categories may expand current work. Record follow-ups without implementing them unless the user explicitly broadens scope.
Stop and reassess when a hotfix approaches five files or 150 non-generated changed lines, the footprint exceeds roughly twice the estimate, or the work introduces an unplanned schema, durable queue/state, scheduler, state machine, protocol, cross-process recovery mechanism, or generic framework. Preserve the expanded attempt, return to the last coherent minimal patch, run a simplification pass, and ask before broadening. These are tripwires, not hard limits; crossing one is allowed only when the mission contract actually requires it.
Coding Workflow
After the implementation is coherent, run a bounded independent code-audit loop before finalizing.
A coding pass is any coherent set of implementation edits: adding a feature slice, fixing a bug, refactoring a module, changing tests, or applying audit fixes. Small mechanical formatting-only edits do not require a separate audit unless they could affect behavior.
Use this loop:
- Run the relevant local verification first when it is cheap and available: focused tests, type checks, linters, build, smoke tests, or runtime checks.
- Start one independent code-audit subagent when available. Give it the mission contract, relevant changed files or diff, and instructions to return only concrete findings with file/line evidence, severity, and suggested fixes.
- Classify every finding through the scope governor. Fix admitted findings; record follow-ups and technical dispositions without silently ignoring them.
- Re-run the relevant local verification after fixes.
- If admitted findings changed code, run one targeted re-review limited to those fixes and their immediate causal path.
- Run one final main-thread code audit against the mission contract. Look for unmet acceptance criteria, patch regressions, and mandatory safety issues.
- Apply and verify any admitted final findings. Do not restart broad review unless the mission itself changed.
Stop when no admitted finding remains. The goal is not to eliminate every conceivable improvement in the surrounding codebase.
Requirement Completeness Workflow
When the task is based on a source of truth such as a PRD, design doc, audit report, issue, checklist, long prompt, or multi-part request, perform a final completeness check before reporting completion.
For broad PRD/audit/checklist work, maintain a compact source-of-truth ledger while working. The ledger can be in the final report, a local scratch artifact, or an existing project checklist, but it must map each material requirement to done, blocked, or intentionally out of scope with evidence.
Use this loop:
- Preserve or reconstruct the starting source of truth from the user prompt, linked documents, local files, issue text, PRD, audit report, or acceptance criteria.
- Build or update the ledger before the final completeness pass. Include requirement id/short label, current status, evidence path or command, and any remaining blocker.
- Before finalizing, run one subagent when available to re-read that source of truth and compare it with the ledger and actual work. Ask for a binary result:
done or not done yet, plus a concise list of missing or mismatched requirements. The source-of-truth ledger and non-goals are immutable review boundaries.
- If the subagent says
not done yet, resume implementation and complete the outstanding parts.
- Re-run local verification and the coding audit loop for any new coding pass.
- Run one targeted completeness re-check after the fixes.
- If it still returns
not done yet, identify the exact unmet acceptance criterion or report the blocker; do not broaden into adjacent improvements.
Do not treat partial compliance, "close enough", or unverified assumptions as complete. If a requirement is impossible, obsolete, contradictory, or intentionally out of scope, document the reason and get as close to the requested outcome as the available tools and constraints allow.
If an earlier report says the work is "not done" but the tree may have changed since, verify against the current head and update the ledger before accepting the older status.
UI and Human Review Workflow
For any UI work, make rendered user experience a first-class acceptance gate. Keep iterating until the "human in you" would be satisfied with what a real user sees and does, not merely until tests pass or components compile.
Use whatever can inspect the actual interface: Browser/in-app browser, Playwright, screenshots, accessibility snapshots, responsive viewports, keyboard navigation, hover/focus/tap checks, console/network inspection, and manual visual review. Inspect the UI after meaningful changes and again after fixes. Treat screenshots as evidence to critique, not a checkbox.
When subagents are available and the harness permits them, select one to three personas that best match the actual users and risk. Use every persona only when the user explicitly requests exhaustive persona coverage. Give reviewers the current requirements and rendered UI artifact or running target, but not your conclusions. Available personas:
- Karen, non-technical user: notices confusion, friction, unclear labels, missing affordances, and brittle happy paths.
- John, technical coder: notices implementation tells, broken states, edge cases, and developer-facing workflow issues.
- Bobby, competent manager: checks task completion, business usefulness, prioritization, and operational clarity.
- Sven, manager who failed upward: impatient, literal, status-driven, and likely to misunderstand ambiguous UI, labels, or state.
- UX expert: checks interaction design, accessibility, information architecture, responsive behavior, focus handling, and error states.
- Marketing expert: checks positioning, clarity of value, tone, trust cues, conversion paths, and copy consistency.
Classify persona findings through the scope governor, apply admitted findings, and re-run the relevant visual checks. If subagents cannot be used, perform the same selected persona passes yourself and disclose that limitation when it materially affects confidence.
During UI inspection, verify:
- Responsive behavior and mobile ergonomics where applicable, including tap targets, touch-specific affordances, hover-only controls, click flows, and keyboard flows.
- Layering and portal behavior: dropdowns, comboboxes, tooltips, popovers, menus, toasts, and modals must not render behind overlays, native dialogs, top-layer hosts, or higher-z elements.
- Edge-of-viewport behavior: hover/focus menus and floating elements near boundaries should flip, shift, stay visible, and remain reachable.
- Text layout: non-breaking words, long names, URLs, counters, translations, and dynamic data must not overlap, clip, or force unintended page-level overflow.
- State coverage: loading, empty, error, disabled, pending, success, destructive confirmation, slow network, offline where relevant, and repeated-submit states.
- Accessibility: semantic labels, focus order, keyboard reachability, contrast, reduced motion, visible state, and screen-reader-friendly names/status.
Text and Copy Quality
For user-visible text, evaluate whether the copy sounds artificial before finalizing. Use a rough AI-slop score internally: 0-1 natural, 2 acceptable, 3 needs revision, 4-5 rewrite. Penalize generic filler, inflated claims, repetitive structure, fake warmth, buzzword density, unnatural punctuation, and copy that could appear in any product.
Use the humanizer skill when available for medium/high-risk copy. If it is unavailable, rewrite manually toward specific, plain, context-aware language. Verify copy in the rendered or final artifact; a sentence that reads well in isolation can still break layout, hierarchy, or tone in context.
Subagent Expectations
Use subagents as independent reviewers, not rubber stamps.
- Use the highest available model for audit and completeness subagents.
- Keep prompts scoped and evidence-oriented. Include the original requirements and current artifacts, but do not include your intended answer or ask them to confirm your conclusion.
- Use one independent reviewer by default. Add a focused security/data-integrity reviewer only when the mission crosses that boundary; broad fan-out requires explicit user intent or genuinely high stakes.
- Require concrete, actionable output. Findings need evidence; vague concerns must become a reproducible check, code reference, or explicit non-finding.
- If subagents are unavailable in the current harness, perform an explicit independent main-thread audit pass instead, state that limitation in the final response, and do not pretend that a subagent audit occurred.
Verification Discipline
Use the verification surface that matches the risk:
- For code: run focused tests or checks that exercise the changed behavior; broaden to full suites when the change touches shared contracts, cross-module behavior, security, persistence, public APIs, or user-facing workflows.
- For frontend work: inspect rendered UI with browser automation or screenshots when feasible, especially for layout, interaction, responsive behavior, and visual regressions.
- For documents, specs, data, and generated artifacts: render, parse, diff, or inspect the actual output, not only the source files.
- For operations or deployments: verify the real runtime interface, not just that a command exited successfully.
Record failures as work items, fix them, and re-run the same check that exposed the issue.
Final Response Gate
Finalize only when all are true:
- Local verification appropriate to the task has passed or any inability to run it is clearly explained.
- No admitted subagent finding remains, or subagents are unavailable and the fallback audit limitation is disclosed.
- No admitted main-thread finding remains.
- Requirement completeness check is
done for document-driven or comprehensive tasks.
- User-facing UI has passed rendered visual, accessibility, responsive, edge-case, and persona review when UI is in scope.
- User-visible text with medium/high AI-slop risk has been revised or explicitly justified when copy is in scope.
- The working tree contains only intentional changes for the task.
In the final response, summarize what changed, what verification ran, and any residual risks or blocked items. Keep the report concise, but do not omit unresolved blockers.
Optional Companion Skills
This skill is self-contained. Missing companions never block current work: use the scope governor, simplification pass, independent review, and verification rules above.
At the end of every work report, add a clearly labeled Optional companion skills to install section listing each missing companion below. Omit companions that are already installed, but do not silently assume they exist.
