Agent SkillsAgent Skills
KrystianYCSilva

chain-of-thought

@KrystianYCSilva/chain-of-thought
KrystianYCSilva
0
0 forks
Updated 4/13/2026
View on GitHub

Applies Chain-of-Thought (CoT) for step-by-step reasoning in complex problems. Use when: logic, math, multi-step planning, non-native reasoning models like Qwen-Coder, GPT-4o.

Installation

$npx agent-skills-cli install @KrystianYCSilva/chain-of-thought
Claude Code
Cursor
Copilot
Codex
Antigravity

Details

Path.claude/skills/chain-of-thought/SKILL.md
Branchmain
Scoped Name@KrystianYCSilva/chain-of-thought

Usage

After installing, this skill will be available to your AI coding assistant.

Verify installation:

npx agent-skills-cli list

Skill Instructions


name: chain-of-thought description: | Applies Chain-of-Thought (CoT) for step-by-step reasoning in complex problems. Use when: logic, math, multi-step planning, non-native reasoning models like Qwen-Coder, GPT-4o. license: MIT version: 1.0.0 created: 2026-02-05 category: prompt-engineering author: Prompt Engineering Guild

Chain-of-Thought (CoT)

Technique: Step-by-step reasoning for complex problem-solving Models: Qwen-Coder, GPT-4o, Claude, Gemini (non-native reasoners) Performance Impact: +15-25% accuracy on complex tasks


When to Use

Perfect for:

  • ✅ Logic puzzles and mathematical reasoning
  • ✅ Multi-step planning and decomposition
  • ✅ Complex coding problems requiring algorithm design
  • ✅ Decision trees and conditional reasoning
  • ✅ Non-reasoning-native models (Qwen-Coder, GPT-4o)
  • ✅ Debugging multi-level indirection

NOT recommended for:

  • ❌ Native reasoning models (DeepSeek-R1, GPT-o1, Claude-3.5-Opus with thinking)
  • ❌ Simple tasks (translation, summarization, classification)
  • ❌ Real-time latency-sensitive applications
  • ❌ Single-step decisions

Instructions

Explicit Trigger Format

Insert at the beginning of your prompt:

Vamos pensar passo a passo:

OR (English):

Let's think step by step:

XML Thinking Tags Format

Wrap reasoning in explicit tags:

<thinking>
{detailed step-by-step reasoning}
</thinking>

Structured Format (Recommended)

PROBLEM ANALYSIS:
1. [Identify key constraints]
2. [List assumptions]
3. [Define success criteria]

REASONING:
Step 1: [First observation]
Step 2: [Logical consequence]
Step 3: [Next inference]
...
Step N: [Final conclusion]

SOLUTION:
{final answer}

VERIFICATION:
- Check 1: [Validate step 1]
- Check 2: [Validate step 2]

Examples

Example 1: Logic Puzzle (Simple)

Input:

Alice has 3 apples. She gives 1 apple to Bob. How many apples does Alice have left?

Let's think step by step:

Output:

Step 1: Alice starts with 3 apples.
Step 2: Alice gives 1 apple to Bob (subtract 1).
Step 3: 3 - 1 = 2 apples remaining.

Answer: Alice has 2 apples left.

Example 2: Algorithm Design (Complex)

Input:

Design an algorithm to find the longest increasing subsequence (LIS) in an array.

Let's think step by step:

Output:

PROBLEM ANALYSIS:
- Input: Array of integers (unsorted, possibly with duplicates)
- Output: Length of longest strictly increasing subsequence
- Constraints: O(n log n) time preferred, O(n) space acceptable

REASONING:

Step 1: Brute force approach
- Generate all subsequences: O(2^n)
- Check each for increasing property: O(n) per subsequence
- Result: O(n × 2^n) - too slow

Step 2: Dynamic programming (suboptimal)
- dp[i] = LIS length ending at index i
- For each i, check all j < i where arr[j] < arr[i]
- dp[i] = 1 + max(dp[j])
- Time: O(n²), Space: O(n)
- Better, but can improve

Step 3: Greedy with binary search (optimal)
- Maintain "tail" array of LIS candidates
- tail[i] = smallest ending value for LIS of length i+1
- For each element: binary search position in tail
- Time: O(n log n), Space: O(n)

Step 4: Implementation strategy
- Use bisect_left() to find insertion position
- Update tail[pos] if element is smaller
- Append if element extends LIS

SOLUTION (Python):
```python
import bisect

def lengthOfLIS(nums):
    tail = []
    for num in nums:
        pos = bisect.bisect_left(tail, num)
        if pos == len(tail):
            tail.append(num)
        else:
            tail[pos] = num
    return len(tail)

VERIFICATION:

  • Check 1: Example [3, 10, 2, 1, 20]

    • tail evolution: [3] → [3, 10] → [2, 10] → [1, 10] → [1, 10, 20]
    • Result: 3 ✓ (correct: [1, 10, 20])
  • Check 2: Time complexity

    • n iterations × log n binary search = O(n log n) ✓
  • Check 3: Edge case [5, 4, 3, 2, 1]

    • tail evolution: [5] → [4] → [3] → [2] → [1]
    • Result: 1 ✓ (correct: decreasing sequence)

---

### Example 3: Decision Making (Multi-step)

**Input:**

Should we use caching or database for frequently accessed user profiles?

Let's think step by step:


**Output:**

PROBLEM ANALYSIS:

  • Decision: Cache vs Database for user profiles
  • Context: Frequently accessed, low-latency required
  • Constraints: Cost, consistency, scalability

REASONING:

Step 1: Define "frequently accessed"

  • If <1000 requests/min: database acceptable
  • If 1000-10k requests/min: cache strongly recommended
  • If >10k requests/min: multi-level caching (Redis + database)

Step 2: Consistency requirements

  • User can tolerate 5-minute stale data? → Cache viable
  • User needs real-time consistency? → Database with caching layer
  • Eventual consistency acceptable? → Cache-through pattern

Step 3: Cost analysis

  • Database: $0.25 per 100 requests
  • Redis cache: $0.12 per GB/month (typical 10GB = $1.20/month)
  • If >10k requests/day: cache ROI positive

Step 4: Recommended architecture

  • Hot profiles (top 1%) → Redis cache (5-minute TTL)
  • Warm profiles (top 10%) → Memory cache (1-minute TTL)
  • Cold profiles → Direct database query
  • Always database as source of truth

SOLUTION: Use hybrid approach:

  1. Check Redis cache first
  2. If miss, query database
  3. Populate cache for 5 minutes
  4. Invalidate on profile update

VERIFICATION:

  • Check 1: Latency impact

    • Cache hit: 5ms
    • Cache miss + DB: 100ms
    • 95% hit rate → avg 9.75ms ✓
  • Check 2: Consistency

    • Max stale data: 5 minutes (acceptable for profiles)
  • Check 3: Cost

    • Savings: ~$200/month with 50k users ✓

---

## Anti-Patterns

### ❌ Using CoT with Native Reasoning Models

```bash
# WRONG - GPT-o1 already does internal reasoning
/claude "Let's think step by step: solve this complex problem..."
# Instead: /o1 "solve this complex problem"

Why: Native reasoning models (GPT-o1, DeepSeek-R1, Claude-3.5-Opus) already have internalized reasoning. Explicit CoT can interfere with their internal process.

❌ Over-engineering Simple Tasks

# WRONG - Translate French to English with CoT
/claude "Let's think step by step: Translate 'Bonjour' to English"
# Instead: /claude "Translate 'Bonjour' to English"

Why: Simple tasks don't need step-by-step reasoning. It adds latency without benefit.

❌ Vague Reasoning Steps

# WRONG - Ambiguous step descriptions
Let's think step by step:
Step 1: Figure out the thing
Step 2: Do the stuff
Step 3: Get the result

Why: Vague steps defeat CoT's purpose. Each step must be specific and verifiable.

❌ Skipping Verification

# WRONG - No validation of reasoning
Step 1: ...
Step 2: ...
Step N: Therefore, answer is X

Why: Verification catches errors in reasoning. Always validate key steps.


Performance Impact

ScenarioWithout CoTWith CoTImprovement
Math problem (5 steps)45% accuracy68% accuracy+51%
Logic puzzle62% accuracy79% accuracy+27%
Algorithm design38% accuracy71% accuracy+87%
Code debugging55% accuracy82% accuracy+49%
Average50%75%+50%

Trade-off: +500ms latency per request (acceptable for batch operations)


Related Skills

  • Few-Shot Learning: Examples-based prompting for pattern recognition
  • Prompt Injection Awareness: Security considerations for reasoning chains
  • Self-Reflection: Post-hoc reasoning for error correction
  • Structured Output: Forcing CoT output in JSON/XML format

References


Skill: chain-of-thought | Version: 1.0.0 | License: MIT | Category: prompt-engineering