Thinker Skill - Cognitive Reasoning & Scaffolding
Overview
The Thinker skill provides a set of cognitive operations that prevent "leaping to conclusions" and ensure all variables are considered before execution.
Reasoning Scaffolds
1. UNDERSTAND
- Identify the core problem.
- Define domain requirements (explicit and implicit).
- Establish objective success criteria (acceptance criteria).
2. EXTRACT
- Pull context from project standards (tech stack, architecture).
- Gather relevant outputs from previous steps or agents.
- Identify specific file paths, API contracts, and data models involved.
3. HIGHLIGHT
- Surface critical patterns that must be followed.
- Identify integration points and potential risks (e.g., edge cases).
- Establish a clear Priority Order of operations.
4. APPLY
- Select the appropriate reasoning technique or design pattern.
- Plan the step-by-step execution.
- Maintain a log of tactical decisions made during execution.
5. VALIDATE
- Run a self-checklist against constraints.
- Verify adherence to project rules (e.g., security, type safety).
- Perform a quality check on outputs before finalizing.
6. BACKTRACK
- If stuck or if validation fails, step back.
- Analyze assumptions and identify where they went wrong.
- Propose new resolution paths or escalate questions.
Workflow Integration
Whenever a complex task is received:
- Initialize: Call the
thinkerskill. - Scaffold: Output a
## UNDERSTANDblock, followed byEXTRACTandHIGHLIGHT. - Transition: Hand off the "Action Plan" to the
implementerorarchitect.
Constraints
- NO implementation. This is purely for reasoning and planning.
- NO direct filesystem edits.
- MANDATORY for ambiguous requests.
Outputs & Deliverables
- Primary Output: Reasoning scaffolds, action plans, and validation checklists (markdown)
- Secondary Output: List of clarifying questions and prioritized assumptions
- Success Criteria: Action plan is unambiguous and passes the
verification-before-completionpre-checks - Quality Gate:
implementerorarchitectacceptance of the plan before execution
Additional Constraints
- Governance Constraints: Document assumptions and decisions in
decisions.mdwhen they change architecture or scope
Common Pitfalls
- Skipping UNDERSTAND: Jumping straight to solutions misses the real problem. Always spend time understanding before planning.
- Incomplete Context Gathering: Assuming you have all the facts leads to invalid assumptions. Always explicitly pull relevant context.
- Ignoring Constraints: Designing without understanding security, performance, or business constraints invalidates the plan. Ask constraints early.
- Premature Optimization: Reasoning about performance before understanding the problem wastes time. Optimize after measurement.
- Not Documenting Assumptions: Undocumented assumptions become surprises later. Make assumptions explicit and validate them.
- Skipping Validation: "It seems right" is not validation. Run the checklist; verify constraints before handing off.
Integration Points
| Phase | Input From | Output To | Context |
|---|---|---|---|
| Problem Entry | User request | Reasoning scaffolds | UNDERSTAND, EXTRACT, HIGHLIGHT |
| Planning | Analyzed request | architect or implementer |
Provide validated action plan |
| Decision Log | Key assumptions/decisions | state-manager |
Document decisions in decisions.md |
| Validation | Draft plan | Pre-flight checklist | Verify against constraints before execution |