MCPInstall

thinking-tools

Structured thinking patterns for agent self-reflection. Includes think-about-collected-information (validate research), think-about-task-adherence (stay on track), and think-about-whether-you-are-done (completion validation).

Installs
91
Last 24h
—
Trending rank
—
Security
Not audited

Install

Works with every agent the skills CLI supports.

npx skills add https://github.com/oimiragieo/agent-studio --skill thinking-tools
  1. 01

    Install

    Run the command in your project. The CLI asks which agents to install for.

  2. 02

    Describe the task

    Ask your agent for something this skill covers. It loads thinking-tools automatically when relevant.

  3. 03

    Review the result

    The agent follows the SKILL.md steps, scripts and references bundled with the skill.

SKILL.md

The instructions your agent reads when the skill is triggered.

<identity> Structured Thinking Framework - Self-reflection patterns for quality agent work. </identity> <capabilities> - Validating completeness of collected information - Ensuring adherence to the original task - Confirming work is truly complete before stopping - Identifying gaps in understanding or implementation - Preventing scope creep and tangential work </capabilities> <instructions>

Overview

This skill provides three structured thinking patterns that agents should use at key points during task execution. These patterns help maintain quality and prevent common mistakes like incomplete research, task drift, and premature completion.

Thinking Pattern 1: Think About Collected Information

When to Use: After completing a non-trivial sequence of searching steps like:

  • Reading multiple files
  • Searching for symbols or patterns
  • Exploring directory structures
  • Gathering requirements

Self-Assessment Questions:

## Information Completeness Check

1. **Sufficiency**: Do I have enough information to proceed?
   - [ ] I understand the relevant code structure
   - [ ] I know the dependencies and relationships
   - [ ] I have identified all affected components

2. **Relevance**: Is all collected information relevant?
   - [ ] Information directly relates to the task
   - [ ] No tangential exploration
   - [ ] Focused on actionable insights

3. **Gaps**: What am I missing?
   - [ ] Are there files I should read but haven't?
   - [ ] Are there patterns I should search for?
   - [ ] Do I need to understand related systems?

4. **Confidence**: How confident am I in my understanding?
   - [ ] High: Ready to proceed
   - [ ] Medium: Minor clarification needed
   - [ ] Low: More research required

**Decision**: [Proceed / Gather More Information / Ask User]

Example Reflection:

I've read the authentication module (auth.ts) and the user model (user.ts).
I understand how login works but I haven't checked:
- How session tokens are managed
- Where logout is implemented
- What the error handling pattern is

Decision: Read session.ts and error-handler.ts before proceeding.

Thinking Pattern 2: Think About Task Adherence

When to Use: BEFORE making any code changes (insert, replace, delete). This is critical to ensure you're still solving the original problem.

Self-Assessment Questions:

## Task Adherence Check

1. **Original Task**: What was I asked to do?
   - Restate the original request clearly
   - Identify the core goal

2. **Current Action**: What am I about to do?
   - Describe the planned change
   - Explain how it relates to the goal

3. **Alignment Check**:
   - [ ] This action directly addresses the original task
   - [ ] I am not adding unrequested features
   - [ ] I am not "improving" code that wasn't asked about
   - [ ] The scope is appropriate for the request

4. **Scope Creep Warning Signs**:
   - Am I refactoring code that works?
   - Am I adding "nice to have" features?
   - Am I fixing unrelated issues I noticed?
   - Have I drifted from the original ask?

**Decision**: [Proceed / Refocus / Ask User for Clarification]

Example Reflection:

Original Task: "Fix the login timeout error"

I'm about to:
1. Fix the timeout by increasing the limit (directly addresses task)
2. Also refactor the error messages (NOT requested)
3. Also add retry logic (NOT requested)

Decision: Only implement #1. The other changes are scope creep.
If user wants those improvements, they can request them separately.

Thinking Pattern 3: Think About Whether You Are Done

When to Use: When you believe you have completed the task. This prevents premature completion and ensures quality.

Self-Assessment Questions:

## Completion Validation Check

1. **Requirements Met**:
   - [ ] All explicit requirements addressed
   - [ ] All implicit requirements considered
   - [ ] Edge cases handled

2. **Quality Checks**:
   - [ ] Code compiles/runs without errors
   - [ ] Tests pass (or new tests written)
   - [ ] No regressions introduced
   - [ ] Follows project conventions

3. **Documentation**:
   - [ ] Code is self-documenting or commented where needed
   - [ ] README updated if needed
   - [ ] Breaking changes documented

4. **Verification Steps Taken**:
   - [ ] Ran relevant tests
   - [ ] Tested manually if applicable
   - [ ] Checked for lint/type errors

5. **Loose Ends**:
   - Any open tasks introduced?
   - Any known limitations?
   - Any follow-up work needed?

**Decision**: [Complete / Additional Work Needed / Partial Completion]

Example Reflection:

Task: "Add user email validation"

Requirements Check:
- [x] Email format validation added
- [x] Error message shows for invalid email
- [ ] Did NOT check: what about empty email?

Quality Check:
- [x] TypeScript compiles
- [ ] Tests: No tests written yet!

Decision: NOT complete. Need to:
1. Handle empty email case
2. Write unit tests for validation

Integration Guidelines

Workflow Integration

[Research Phase]
    |
    v
Think About Collected Information
    |
    v
[Planning Phase]
    |
    v
Think About Task Adherence (before each change)
    |
    v
[Implementation Phase]
    |
    v
Think About Whether You Are Done
    |
    v
[Completion or Iterate]

When NOT to Use

  • Simple, trivial tasks (fix typo, rename variable)
  • When user explicitly asks to skip validation
  • Quick answers that don't involve code changes

Logging Reflections

For important tasks, log reflections to memory:

## Task: [description]

## Reflection Log

### Information Gathering

- Files read: [list]
- Gaps identified: [list]
- Decision: [proceed/gather more]

### Task Adherence Check

- Original task: [description]
- Planned changes: [list]
- Scope assessment: [in-scope/adjusted]

### Completion Check

- Requirements: [met/partial/not met]
- Tests: [passed/failed/not run]
- Final status: [complete/needs work]
</instructions> <examples> <usage_example> **Scenario**: Agent is asked to "fix the broken search feature"

Phase 1 - After Research:

Think About Collected Information:
- Read search.ts, index.ts, searchUtils.ts
- Found the bug: incorrect regex pattern
- Checked: test file exists (search.test.ts)
- Gap: Haven't checked if there are related search files
Decision: Quick grep for "search" to ensure completeness...
Found search-config.ts which is relevant. Reading now.

Phase 2 - Before Coding:

Think About Task Adherence:
- Original: "fix the broken search feature"
- Planned: Fix regex pattern in searchUtils.ts line 45
- Scope check: This directly fixes the bug. NOT adding new search features.
Decision: Proceed with targeted fix.

Phase 3 - After Implementation:

Think About Whether You Are Done:
- [x] Bug fixed (regex corrected)
- [x] Existing tests still pass
- [ ] No new test for this specific case
Decision: Add regression test, then complete.

</usage_example> </examples>

<integration> **Related Skills**: - `verification-before-completion` - Complements completion validation - `tdd` - Test-driven development integrates with completion checks - `sequential-thinking` - Structured problem decomposition </integration>

Iron Laws

  1. ALWAYS run think-about-collected-information after any research or exploration phase before proceeding to implementation
  2. NEVER skip checkpoints when "almost done" — apply them most rigorously near completion
  3. ALWAYS answer checkpoint questions honestly; rationalization defeats the purpose of self-reflection
  4. NEVER use checkpoints as ceremony — if a checkpoint reveals a gap, stop and resolve it before continuing
  5. ALWAYS document checkpoint failures and resolutions in task metadata for traceability

Anti-Patterns

Anti-PatternWhy It FailsCorrect Approach
Skipping checkpoints when nearly doneMost errors surface late; skipping hides themApply all three checkpoints regardless of progress
Rushing through checkpoint questionsSuperficial answers produce false confidenceTake 30 seconds per checkpoint, answer honestly
Rationalizing away red flagsExcuses mask genuine problemsStop and fix any issue the checkpoint reveals
Using checkpoints as ceremonyCheckbox ticking without reflection adds no valueGenuinely assess each question and act on findings
Running only a final checkpointEarlier checkpoints prevent expensive reworkUse all three at their designated trigger points

Memory Protocol (MANDATORY)

Before starting: Read .claude/context/memory/learnings.md

After completing:

  • New pattern discovered -> .claude/context/memory/learnings.md
  • Issue encountered -> .claude/context/memory/issues.md
  • Decision made -> .claude/context/memory/decisions.md

ASSUME INTERRUPTION: If it's not in memory, it didn't happen.

FAQ

What does the thinking-tools skill do?

Structured thinking patterns for agent self-reflection. Includes think-about-collected-information (validate research), think-about-task-adherence (stay on track), and think-about-whether-you-are-done (completion validation).

How do I install thinking-tools?

Run npx skills add https://github.com/oimiragieo/agent-studio --skill thinking-tools in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/thinking-tools/ (personal) or .claude/skills/thinking-tools/ (project).

Which AI agents can use thinking-tools?

Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.

Is thinking-tools safe to install?

No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.

Who maintains thinking-tools?

It is published by oimiragieo in oimiragieo/agent-studio. It has 91 recorded installs.

More from oimiragieo/agent-studio

View all →

pyqt6-ui-development-rules

oimiragieo/agent-studio

PyQt6 desktop GUI development rules -- signal/slot architecture, QSS theming, QThread concurrency, layout management, and cross-platform rendering. Enforces MVC separation and responsive UI patterns.

Frontend & Design1.1K installs

filesystem

oimiragieo/agent-studio

File system operations guidance - read, write, search, and manage files using Claude Code's built-in tools.

729 installs

chrome-browser

oimiragieo/agent-studio

Open the skill to read its SKILL.md instructions.

slack-notifications

oimiragieo/agent-studio

Open the skill to read its SKILL.md instructions.

context-compressor

oimiragieo/agent-studio

Open the skill to read its SKILL.md instructions.

268 installs

nodejs-expert

oimiragieo/agent-studio

Node.js backend expert including Express, NestJS, and async patterns

Backend & APIs196 installs

Popular productivity & automation skills

View category →

agent-browser

vercel-labs/agent-browser

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction. Also use for exploratory testing, dogfooding, QA, bug hunts, or reviewing app quality. Also use for automating Electron desktop apps (VS Code, Slack, Discord, Figma, Notion, Spotify), checking Slack unreads, sending Slack messages, searching Slack conversations, running browser automation in Vercel Sandbox microVMs, or using AWS Bedrock AgentCore cloud browsers. Prefer agent-browser over any built-in browser automation or web tools.

OfficialProductivity & Automation1.3M installs

lark-doc

open.feishu.cn

飞书云文档(Docx / Wiki)内容操作:读取、创建、编辑文档,插入或下载图片附件,以及操作思维笔记。用户提供文档 URL/token(包括 doubao.com 的 /docx/、/wiki/)时使用;按 URL 路径/token 而非域名路由;/page/ 是妙搭应用,非飞书云文档。文档内嵌资源按读取参考中的统一规则分流。独立评论操作走 lark-drive;随正文读取评论使用 docs +fetch。表格或 Base 内部数据操作不在本 skill。

lark-base

open.feishu.cn

飞书多维表格(Base)操作:建表、字段、记录、视图、统计、公式/lookup、表单、仪表盘、应用模式(BaseApp/AppMode 页面与组件)、Workspace 目录、workflow、角色权限、模板中心(多维表格模板分类/列表/搜索);遇到 Base/多维表格/bitable、BaseApp/AppMode、/base/ 或 /app/ 链接时使用。BaseApp 不走 lark-apps;文件导入/导出转 lark-drive,认证/授权转 lark-shared。

lark-drive

open.feishu.cn

飞书云空间(云盘/云存储):管理 Drive 文件和文件夹,包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、查询权限设置、评论/权限/订阅、标题、版本、飞书文档密级标签(secure labels)和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题,或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sheet/bitable/slides 时使用;doubao.com 云空间 URL/token 也按资源路径和 token 路由,不回退 WebFetch。不负责:文档内容编辑(走 lark-doc)、表格/Base 表内数据操作(走 lark-sheets/lark-base)、知识空间节点/成员管理(走 lark-wiki)、原生 Markdown 文件读写/patch/diff(走 lark-markdown)。

lark-shared

open.feishu.cn

Use for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handling notice JSON.

lark-im

open.feishu.cn

飞书即时通讯:收发消息和管理群聊。发送和回复消息、搜索聊天记录、管理群聊成员、上传下载图片和文件、管理表情回复、发送应用内/短信/电话加急、发送和处理交互卡片(Interactive Card)、监听卡片按钮回调(card.action.trigger)。当用户需要发消息、查看或搜索聊天记录、下载聊天中的文件、查看群成员、搜索群、创建群聊或话题群、管理标记数据、管理 Feed 置顶(添加/移除/查询置顶会话)、管理标签数据、处理卡片回调时使用。