A comprehensive skill for maximizing performance on agentic tool-use and competitive coding tasks. Use this skill whenever the user asks the agent to write, debug, or optimize code; solve algorithmic or competitive programming problems; call tools or APIs as part of a multi-step workflow; build or orchestrate agents; reason about function signatures, schemas, or tool parameters; handle multi-turn task execution where state must be tracked; or debug code from execution feedback. This skill is especially important for function/tool calling tasks, multi-step agentic pipelines, algorithm design, competitive programming, code self-repair, and any task where correctness under edge cases matters. When in doubt about whether to use this skill, use it — it substantially improves output quality across all coding and agentic tasks.
A comprehensive skill for maximizing performance on agentic tool-use and competitive coding tasks. Use this skill whenever the user asks the agent to write, debug, or optimize code; solve algorithmic or competitive programming problems; call tools or APIs as part of a multi-step workflow; build or orchestrate agents; reason about function signatures, schemas, or tool parameters; handle multi-turn task execution where state must be tracked; or debug code from execution feedback. This skill is especially important for function/tool calling tasks, multi-step agentic pipelines, algorithm design, competitive programming, code self-repair, and any task where correctness under edge cases matters. When in doubt about whether to use this skill, use it — it substantially improves output quality across all coding and agentic tasks.
Agent & Coding Excellence Skill
This skill encodes best practices for two interrelated capability families:
Agentic Tool Use — Precise function/tool calling, multi-turn stateful reasoning, irrelevance detection, and long-horizon task execution
Competitive-Grade Coding — Algorithmic problem solving, edge-case correctness, self-repair from execution feedback, and code comprehension
Both families share a common foundation: structured thinking, precise output formatting, and disciplined verification before responding.
Part 1 — Agentic Tool Use
Core Philosophy
Tool use is a formal act. A function call is a contract: wrong argument types, missing parameters, or incorrect names cause silent failures or downstream errors. Treat every tool call with the same rigor as writing production code.
The Four Phases of Every Tool Call
Phase 1: Schema Analysis
Before calling any tool, fully parse its schema:
What are the required vs. optional parameters?
What are the valid types and value ranges for each?
Are there nested objects? Enums? Constrained strings?
What does each parameter actually do? (Don't assume from name alone)
Phase 2: Intent–Schema Alignment
Map the user's request onto the schema precisely:
Which user-stated goals correspond to which parameters?
Are there unstated but necessary parameters (e.g., auth tokens, session IDs)?
Is the user asking for something outside what the available tools can do? (→ relevance detection)
Phase 3: Call Formation
Construct the call:
Use exact parameter names as specified — no creative renaming
Match types strictly: don't pass a string where an int is expected, or an array where a scalar is expected
For optional parameters: include them when they improve precision, omit when genuinely not needed
Never hallucinate parameters that aren't in the schema
Phase 4: Post-Call Reasoning
After a tool returns:
Check for error signals in the response (status codes, error fields, null results)
Update your mental model of the current state before proceeding
Don't assume success — validate the result
If the result is unexpected, diagnose before calling again
Multi-Turn & Stateful Execution
In multi-turn agentic tasks, state accumulates. Managing it well is the single biggest differentiator between agents that complete tasks and agents that loop or fail.
State Tracking Rules:
After each tool call, explicitly note what changed in the world state
Keep a mental "current state" summary: what exists, what has been modified, what is still unknown
Never re-derive state from scratch each turn — carry it forward and update incrementally
If the task spans many turns, periodically summarize: "Current state: [X]. Remaining steps: [Y]."
Decision-Making Under Uncertainty:
When a needed parameter is missing from context, first check if a prior tool call result provides it
If still missing, ask the user for the specific missing value — don't proceed with a hallucinated value
When two execution paths are both valid, prefer the one that is reversible or lower-risk
Stopping Criteria:
Stop and report back when: a required function doesn't exist, a required parameter can't be determined, or a prior step failed and proceeding would worsen the situation
Never loop on the same failed action more than twice without changing strategy
Irrelevance Detection
Not every user request should result in a tool call. A sophisticated agent knows when not to act.
Ask yourself:
Does any available tool actually address the user's need?
Would calling a tool produce a result that answers the question, or would it be tangential?
Is the user asking for information or reasoning that I can provide directly, without tool use?
When no tool is appropriate, say so clearly and provide direct assistance instead.
Parallel & Multiple Function Calls
When multiple tools can be called independently (results don't depend on each other):
Identify the full set of independent calls upfront
Batch them together rather than sequencing unnecessarily
Note any ordering dependencies explicitly before proceeding
When multiple functions must be called on a single user intent:
Identify the primary function that addresses the core request
Identify secondary functions needed to satisfy constraints or produce side effects
Call them in dependency order
Part 2 — Competitive-Grade Coding
Core Philosophy
Correct code is not "code that works on the examples." Correct code is code that works on all valid inputs, including the ones designed to break naive solutions. Think adversarially about your own solutions.
The Algorithm Design Process
Step 1: Understand the problem fully before writing any code
Re-state the problem in your own words
Identify the input constraints (size, range, data type)
Identify the output requirement precisely
Check example cases to validate your understanding
Ask: what makes this problem hard? What's the naive approach and why does it fail?
Step 2: Choose the right algorithm class
Match the problem structure to the right tool:
Optimization over choices → Dynamic Programming or Greedy (check exchange argument)
Integer overflow (use 64-bit integers when products or sums can exceed 2³¹)
Division by zero
Floating point precision (prefer integer arithmetic when possible)
Off-by-one errors:
Array indices: is the loop < n or <= n?
Range endpoints: inclusive vs. exclusive
Modular arithmetic: is (a % m + m) % m needed?
Self-Repair from Execution Feedback
When given a failing solution and error feedback, use this protocol:
Step 1: Read the error precisely
What is the error type? (WA, TLE, MLE, RE, CE)
What is the failing input (if shown)?
What was the expected output vs. actual output?
Step 2: Categorize the failure
Wrong Answer (WA): Logic error — trace through the failing case manually, step by step
Time Limit Exceeded (TLE): Algorithm too slow — identify the bottleneck, rethink complexity
Memory Limit Exceeded (MLE): Space usage too high — identify large allocations, reduce them
Runtime Error (RE): Index out of bounds, null dereference, stack overflow — check boundaries
Compile Error (CE): Syntax error — read the error line carefully
Step 3: Form a hypothesis
Name the specific bug before touching the code: "I believe the failure is caused by [X] because [Y]."
Step 4: Fix surgically
Change only what's needed to fix the identified bug
Don't rewrite unrelated code — introduce bugs during repair
After fixing, re-verify all previous passing cases still pass
Step 5: Strengthen the solution
After the fix, revisit the edge case checklist. The failing case is often a hint that a class of similar cases is also broken.
Code Execution & Output Prediction
When asked to predict or trace program execution:
Initialize state: Set all variables to their initial values
Execute line by line: Don't skip — each line may have side effects
Track mutable state: Arrays, objects, and variables modified in loops need careful tracking
Watch for Python-specific behavior: Integer division, list vs. reference semantics, scoping rules
Off-by-one in loops: Trace the first and last iteration explicitly
Short-circuit evaluation: Boolean operators may not evaluate both sides
Return the exact output format: match whitespace, newlines, and type representation exactly
Part 3 — Cross-Cutting Principles
These apply to both agentic tasks and coding tasks:
Structured Thinking Before Output
For any non-trivial task, think before you write. Use this structure:
UNDERSTAND: What is actually being asked?
CONSTRAINTS: What are the boundaries/requirements?
APPROACH: What strategy will I use and why?
RISKS: Where could this go wrong?
OUTPUT: Produce the solution, then verify it.
Don't skip the verification step. Re-read your output against the original requirements before finalizing.
Precision in Communication
When the task is ambiguous:
State your interpretation explicitly: "I'm assuming X means Y."
If two interpretations lead to very different outputs, ask for clarification
When you're confident in your interpretation, proceed — don't ask unnecessary clarifying questions
Handling Long or Complex Contexts
When information is spread across a long context:
Extract and summarize the key facts into a compact working set before starting
When context contains many similar items (large APIs, many parameters, many records), filter down to only what's relevant to the current step
Don't let irrelevant context dilute your attention on the important parts
Failure Modes to Actively Avoid
Parameter hallucination: Inventing tool parameters that don't exist in the schema
Type coercion mistakes: Passing "3" when 3 is needed
Premature stopping: Declaring task complete before verifying the end state
Greedy-trap solutions: Optimizing locally in a way that prevents global optimality
Untested edge cases: Submitting the first working solution without adversarial testing
Over-engineering: Adding complexity that isn't needed for the given constraints
Quick Reference: At-a-Glance Checklist
Before a Tool Call
Read the full schema, not just the parameter names
