thoroughness
- Repo stars 113
- License MIT
- Author updated Live
- Author repo prpm
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 94 / 100 · audit passed
- Author / version / license
- @pr-pm · MIT
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: thoroughness
description: Use when implementing complex multi-step tasks, fixing critical bugs, or when quality and comple…
category: other
runtime: no special runtime
---
# thoroughness output preview
## PART A: Task fit
- Use case: Use when implementing complex multi-step tasks, fixing critical bugs, or when quality and completeness matter more than speed - ensures comprehensive implementation without shortcuts through systematic analysis, implementation, and verification phases This skill ensures comprehensive, complete implementation of complex tasks without shortcuts. Use this wh….
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Purpose / When to Use / Methodology” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Use when implementing complex multi-step tasks, fixing critical bugs, or when quality and completeness matter more than speed - ensures comprehensive implementation without shortcuts through systematic analysis, implementation, and verification phases This skill ensures comprehensive, complete implementation of complex tasks without shortcuts. Use this wh…”.
- **02** When the source has headings, the agent prioritizes “Purpose / When to Use / Methodology” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; may access external network resources; usually needs no extra API key.
## Running Rules
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Purpose / When to Use / Methodology”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: thoroughness
description: Use when implementing complex multi-step tasks, fixing critical bugs, or when quality and comple…
category: other
source: pr-pm/prpm
---
# thoroughness
## When to use
- Use when implementing complex multi-step tasks, fixing critical bugs, or when quality and completeness matter more tha…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Purpose / When to Use / Methodology” and keep inference separate from source facts.
- read files, write/modify files; may access external network resources; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "thoroughness" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Purpose / When to Use / Methodology
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | may access external network resources
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Thoroughness
Purpose
This skill ensures comprehensive, complete implementation of complex tasks without shortcuts. Use this when quality and completeness matter more than speed.
When to Use
- Fixing critical bugs or compilation errors
- Implementing complex multi-step features
- Debugging test failures
- Refactoring large codebases
- Production deployments
- Any task where shortcuts could cause future problems
Methodology
Phase 1: Comprehensive Analysis (20% of time)
Identify All Issues
- List every error, warning, and failing test
- Group related issues together
- Prioritize by dependency order
- Create issue hierarchy (what blocks what)
Root Cause Analysis
- Don't fix symptoms, find root causes
- Trace errors to their source
- Identify patterns in failures
- Document assumptions that were wrong
Create Detailed Plan
- Break down into atomic steps
- Estimate time for each step
- Identify dependencies between steps
- Plan verification for each step
- Schedule breaks/checkpoints
Phase 2: Systematic Implementation (60% of time)
Fix Issues in Dependency Order
- Start with foundational issues
- Fix one thing completely before moving on
- Test after each fix
- Document what was changed and why
Verify Each Fix
- Write/run tests for the specific fix
- Check for side effects
- Verify related functionality still works
- Document test results
Track Progress
- Mark issues as completed
- Update plan with new discoveries
- Adjust time estimates
- Note any blockers immediately
Phase 3: Comprehensive Verification (20% of time)
Run All Tests
- Unit tests
- Integration tests
- E2E tests
- Manual verification
Cross-Check Everything
- Review all changed files
- Verify compilation succeeds
- Check for console errors/warnings
- Test edge cases
Documentation
- Update relevant docs
- Add inline comments for complex fixes
- Document known limitations
- Create issues for future work
Anti-Patterns to Avoid
- ❌ Fixing multiple unrelated issues at once
- ❌ Moving on before verifying a fix works
- ❌ Assuming similar errors have the same cause
- ❌ Skipping test writing "to save time"
- ❌ Copy-pasting solutions without understanding
- ❌ Ignoring warnings "because it compiles"
- ❌ Making changes without reading existing code first
Quality Checkpoints
- Can I explain why this fix works?
- Have I tested this specific change?
- Are there any side effects?
- Is this the root cause or a symptom?
- Will this prevent similar issues in the future?
- Is the code readable and maintainable?
- Have I documented non-obvious decisions?
Example Workflow
Bad Approach (Shortcut-Driven)
1. See 24 TypeScript errors
2. Add @ts-ignore to all of them
3. Hope tests pass
4. Move on
Good Approach (Thoroughness-Driven)
1. List all 24 errors systematically
2. Group by error type (7 missing types, 10 unknown casts, 7 property access)
3. Find root causes:
- Missing @types/tar package
- No type assertions on fetch responses
- Implicit any types in callbacks
4. Fix by category:
- Install @types/tar (fixes 7 errors)
- Add proper type assertions to registry-client.ts (fixes 10 errors)
- Add explicit parameter types (fixes 7 errors)
5. Test after each category
6. Run full test suite
7. Document what was learned
Time Investment
- Initial: 2-3x slower than shortcuts
- Long-term: 10x faster (no debugging later, no rework)
- Quality: Near-perfect first time
- Maintenance: Minimal
Success Metrics
- ✅ 100% of tests passing
- ✅ Zero warnings in production build
- ✅ All code has test coverage
- ✅ Documentation is complete and accurate
- ✅ No known issues or TODOs left behind
- ✅ Future developers can understand the code
Mantras
- "Slow is smooth, smooth is fast"
- "Do it right the first time"
- "Test everything, assume nothing"
- "Document for your future self"
- "Root causes, not symptoms"
Decide Fit First
Design Intent
How To Use It
Boundaries And Review