Thinker Skill - Cognitive Reasoning & Scaffolding
Version: 9.0 | Updated: 01-July-2026 | Architect: Karim Bhalwani |
Overview
The Thinker skill provides a set of cognitive operations that prevent "leaping to conclusions" and ensure all variables are considered before execution.
Cognitive Chain Protocol
Before executing any non-trivial task, run this chain internally. UNDERSTAND, EXTRACT, and HIGHLIGHT must be surfaced as visible markdown blocks when Workflow Integration is triggered. APPLY and VALIDATE may remain internal unless the task requires explicit auditability.
UNDERSTAND ─► EXTRACT ─► HIGHLIGHT ─► APPLY ─► VALIDATE
│ │ │ │ │
What is the What context What are Do the Did the output
real problem? do I need? the risks work. meet the
What are the Pull from and Execute requirements?
constraints? project priorities? step by Check against
Success files, Surface step. constraints
criteria? specs, and patterns and acceptance
prior work. to follow. criteria.
When to apply: Any task involving design decisions, multi-step execution, security-sensitive logic, debugging, or review. Skip only when the task has no design decisions, no cross-file impact, and no security or correctness risk - for example: a single-file typo fix, a local variable rename with no semantic change, or a comment update. When in doubt, apply the full chain.
If VALIDATE fails: Enter BACKTRACK. Step back, re-examine assumptions, propose a new path or escalate to the user.
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
thinker skill.
- Scaffold: Output a
## UNDERSTAND block, followed by EXTRACT and HIGHLIGHT.
- Transition: Hand off the "Action Plan" to the
implementer or architect.
Definition of Done
Constraints
- NO implementation. This is purely for reasoning and planning.
- NO direct filesystem edits.
- MANDATORY when the user request does not specify at least one of: success criteria, technical constraints, or target component. If any of these are missing, do not skip the chain.
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-completion pre-checks
- Quality Gate:
implementer or architect acceptance of the plan before execution
Additional Constraints
- Governance Constraints: Document assumptions and decisions in
decisions.md when they change architecture or scope. If decisions.md does not exist, note in the action plan that it must be created before handoff, and include the decision log entry as a block in the thinker output so it is not lost.
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 |
context-engineer |
Document decisions in decisions.md |
| Validation |
Draft plan |
Pre-flight checklist |
Verify against constraints before execution |
References
Load when scaffolding reasoning documents and structured briefs:
- brief.md - Problem brief template. Load when the task requires a formal thought document - captures problem statement, assumptions, constraints, and action plan in a single structured artifact.
1---2name: thinker-23description: Specialized in structured reasoning, mental scaffolding, and breaking down complex problems. Use at the start of every task to ensure deep, transparent, and auditable thinking before taking action. DO NOT USE FOR: brainstorming with the user (use brainstorming), implementation (use implementer), or producing final deliverable artifacts (complete documents, code, designs). Thinker produces intermediate outputs like reasoning scaffolds and action plans for handoff to implementer or architect.4license: MIT5---67# Thinker Skill - Cognitive Reasoning & Scaffolding89> Version: 9.0 | Updated: 01-July-2026 | Architect: Karim Bhalwani |1011## Overview1213The Thinker skill provides a set of cognitive operations that prevent "leaping to conclusions" and ensure all variables are considered before execution.1415## Cognitive Chain Protocol1617Before executing any non-trivial task, run this chain internally. UNDERSTAND, EXTRACT, and HIGHLIGHT must be surfaced as visible markdown blocks when Workflow Integration is triggered. APPLY and VALIDATE may remain internal unless the task requires explicit auditability.1819```text20UNDERSTAND ─► EXTRACT ─► HIGHLIGHT ─► APPLY ─► VALIDATE21 │ │ │ │ │22 What is the What context What are Do the Did the output23 real problem? do I need? the risks work. meet the24 What are the Pull from and Execute requirements?25 constraints? project priorities? step by Check against26 Success files, Surface step. constraints27 criteria? specs, and patterns and acceptance28 prior work. to follow. criteria.29```3031**When to apply:** Any task involving design decisions, multi-step execution, security-sensitive logic, debugging, or review. Skip only when the task has no design decisions, no cross-file impact, and no security or correctness risk - for example: a single-file typo fix, a local variable rename with no semantic change, or a comment update. When in doubt, apply the full chain.3233**If VALIDATE fails:** Enter BACKTRACK. Step back, re-examine assumptions, propose a new path or escalate to the user.3435## Reasoning Scaffolds3637### 1. UNDERSTAND3839- Identify the core problem.40- Define domain requirements (explicit and implicit).41- Establish objective success criteria (acceptance criteria).4243### 2. EXTRACT4445- Pull context from project standards (tech stack, architecture).46- Gather relevant outputs from previous steps or agents.47- Identify specific file paths, API contracts, and data models involved.4849### 3. HIGHLIGHT5051- Surface critical patterns that must be followed.52- Identify integration points and potential risks (e.g., edge cases).53- Establish a clear Priority Order of operations.5455### 4. APPLY5657- Select the appropriate reasoning technique or design pattern.58- Plan the step-by-step execution.59- Maintain a log of tactical decisions made during execution.6061### 5. VALIDATE6263- Run a self-checklist against constraints.64- Verify adherence to project rules (e.g., security, type safety).65- Perform a quality check on outputs before finalizing.6667### 6. BACKTRACK6869- If stuck or if validation fails, step back.70- Analyze assumptions and identify where they went wrong.71- Propose new resolution paths or escalate questions.7273## Workflow Integration7475Whenever a complex task is received:76771. **Initialize**: Call the `thinker` skill.782. **Scaffold**: Output a `## UNDERSTAND` block, followed by `EXTRACT` and `HIGHLIGHT`.793. **Transition**: Hand off the "Action Plan" to the `implementer` or `architect`.8081## Definition of Done8283- [ ] UNDERSTAND, EXTRACT, and HIGHLIGHT blocks are complete84- [ ] Action plan is unambiguous with ordered steps85- [ ] All assumptions are documented and flagged by confidence level86- [ ] Constraints (security, performance, scope) are explicitly listed87- [ ] Plan accepted by `implementer` or `architect` before execution88- [ ] If the plan is not accepted, return to BACKTRACK, revise based on the rejection reason, and re-present. If acceptance cannot be determined (e.g., no other agent responds), flag the plan as unverified and surface it to the user before proceeding.8990## Constraints9192- **NO implementation.** This is purely for reasoning and planning.93- **NO direct filesystem edits.**94- **MANDATORY when the user request does not specify at least one of: success criteria, technical constraints, or target component. If any of these are missing, do not skip the chain.**9596## Outputs & Deliverables9798- **Primary Output**: Reasoning scaffolds, action plans, and validation checklists (markdown)99- **Secondary Output**: List of clarifying questions and prioritized assumptions100- **Success Criteria**: Action plan is unambiguous and passes the `verification-before-completion` pre-checks101- **Quality Gate**: `implementer` or `architect` acceptance of the plan before execution102103## Additional Constraints104105- **Governance Constraints:** Document assumptions and decisions in `decisions.md` when they change architecture or scope. If `decisions.md` does not exist, note in the action plan that it must be created before handoff, and include the decision log entry as a block in the thinker output so it is not lost.106107## Integration Points108109| Phase | Input From | Output To | Context |110| ------------- | ------------------------- | ---------------------------- | ------------------------------------------- |111| Problem Entry | User request | Reasoning scaffolds | UNDERSTAND, EXTRACT, HIGHLIGHT |112| Planning | Analyzed request | `architect` or `implementer` | Provide validated action plan |113| Decision Log | Key assumptions/decisions | `context-engineer` | Document decisions in `decisions.md` |114| Validation | Draft plan | Pre-flight checklist | Verify against constraints before execution |115116## References117118Load when scaffolding reasoning documents and structured briefs:119120- [brief.md](./references/brief.md) - Problem brief template. Load when the task requires a formal thought document - captures problem statement, assumptions, constraints, and action plan in a single structured artifact.