think
The /think command adjusts Claude's internal reasoning token allocation by modifying the MAX_THINKING_TOKENS setting in a local configuration file. Use it to control computational depth for problem-solving: disable thinking entirely with "off," enable minimal reasoning with "little" (1025 tokens), use standard thinking with "on" (8192 tokens), or maximize extended reasoning with "lot" (31999 tokens).
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/taylorsatula/mira-OSS/HEAD/.claude/commands/think.md -o ~/.claude/commands/think.mdthink.md
# Thinking Token Control
```bash
ARG="${ARGUMENTS:-on}"
SETTINGS_FILE=".claude/settings.local.json"
case "$ARG" in
off)
TOKEN_VALUE="0"
MESSAGE="Thinking disabled (0 tokens)"
;;
little)
TOKEN_VALUE="1025"
MESSAGE="Minimal thinking enabled (1025 tokens)"
;;
on)
TOKEN_VALUE="8192"
MESSAGE="Standard thinking enabled (8192 tokens)"
;;
lot)
TOKEN_VALUE="31999"
MESSAGE="Extended thinking enabled (31999 tokens)"
;;
*)
echo "Invalid argument: '$ARG'"
echo "Usage: /think [off|little|on|lot]"
echo " off - Disable thinking (0 tokens)"
echo " little - Minimal thinking (1025 tokens)"
echo " on - Standard thinking (8192 tokens) [default]"
echo " lot - Extended thinking (31999 tokens)"
exit 1
;;
esac
# Update MAX_THINKING_TOKENS in settings file
if [ -f "$SETTINGS_FILE" ]; then
sed -i '' "s/\"MAX_THINKING_TOKENS\": \"[^\"]*\"/\"MAX_THINKING_TOKENS\": \"$TOKEN_VALUE\"/" "$SETTINGS_FILE"
echo "$MESSAGE"
echo "Updated $SETTINGS_FILE with MAX_THINKING_TOKENS: $TOKEN_VALUE"
else
echo "Error: $SETTINGS_FILE not found"
exit 1
fi
```Use this agent when you need to rename classes, methods, functions, or variables in code files to align with specific naming requirements or conventions. Examples: <example>Context: User wants to clean up function names by removing a specific prefix. user: 'Please remove the prefix get_ from all function names in this file' assistant: 'I'll use the code-renamer agent to systematically rename all functions by removing the get_ prefix' <commentary>The user wants systematic renaming of functions, which is exactly what the code-renamer agent is designed for.</commentary></example> <example>Context: User wants to standardize method naming conventions. user: 'Can you rename all the camelCase methods to snake_case in this class?' assistant: 'I'll use the code-renamer agent to convert all camelCase method names to snake_case convention' <commentary>This is a systematic renaming task that requires careful attention to naming conventions.</commentary></example>
Use this agent when the user makes offhanded comments, rhetorical questions, or expresses wishes about understanding something better. Trigger on patterns like:\n\n<example>\nContext: User is reviewing code and sees an assistant's explanation about how a function works.\nuser: "Can you believe this? Is this even right?"\nassistant: "Let me use the investigative-sidekick agent to verify if that explanation is accurate."\n<task tool_call to investigative-sidekick with context about what needs verification>\n</example>\n\n<example>\nContext: User is debugging and expresses frustration.\nuser: "I wish I could figure out what's causing this memory leak in the session handler"\nassistant: "I'll use the investigative-sidekick agent to investigate the root cause of that memory leak."\n<task tool_call to investigative-sidekick with the specific problem to investigate>\n</example>\n\n<example>\nContext: User reads a commit message claiming a performance improvement.\nuser: "Did this actually make things faster though?"\nassistant: "Let me launch the investigative-sidekick agent to verify that performance claim."\n<task tool_call to investigative-sidekick to fact-check the performance assertion>\n</example>\n\n<example>\nContext: User is reviewing documentation that seems questionable.\nuser: "This doesn't seem right - are we really supposed to use sync calls in async contexts?"\nassistant: "I'm going to use the investigative-sidekick agent to investigate whether that's actually correct."\n<task tool_call to investigative-sidekick to verify the technical claim>\n</example>\n\nActivate proactively when the user:\n- Questions accuracy or truthfulness ("Can you believe...", "Is this right?", "Really?")\n- Expresses wishes about understanding ("I wish I could figure out...", "I'd love to know...")\n- Shows skepticism ("Did this actually...", "Does this really...")\n- Makes rhetorical questions that imply investigation ("What's causing...", "Why is this...")\n- Doubts explanations or documentation they're reading
Run complete two-agent validation on module+tests (contract extraction + test validation). Binary pass/fail with specific issues.
Check Python logging levels and patterns for correctness. Focus on identifying wrong severity levels and missing exception handling. Use when reviewing code quality.
Detect explicit user_id parameters in functions to identify potential opportunities for using ambient context. This is an investigation tool that flags instances for human review, not a prescriptive analyzer.
Eliminate component hedging anti-patterns that mask infrastructure failures. Build systems that fail loudly when broken instead of limping along in degraded states. Critical for production reliability and operational visibility.
DO NOT COMMIT unless user explicitly tells you to. Use this skill EVERY SINGLE TIME before creating a git commit. Provides mandatory commit message format, staging rules, and post-commit summary requirements for the MIRA project