Put Claude's Built-In Skills to Work: The Power User's Field Guide*
⚡ Practitioner22 min readAug 28, 2026Updated Aug 28, 2026
Most people use Claude the same way they use a search engine — ask a question, get an answer, move on. That's leaving enormous capability on the table. Claude isn't just a text generator with a wide vocabulary. It ships with a set of built-in cognitive skills that, when you know how to deliberately invoke them, turn it into a sophisticated analytical partner rather than a fancy autocomplete.
Here's the problem: Claude's default behavior is to be helpful in the most obvious way. Ask it to summarize something, it summarizes. Ask it a question, it answers. But tucked behind that friendly, compliant surface are capabilities that require you to specifically ask for them — structured reasoning, systematic evaluation, multi-perspective critique, iterative refinement, constraint-based generation, and more. If you don't know these exist, you'll never ask for them, and you'll spend your career getting mediocre outputs from a genuinely powerful tool.
By the end of this lesson, you'll be operating Claude the way a power user does — deliberately engaging specific skills for specific tasks, chaining capabilities together, and getting outputs that are genuinely useful rather than merely adequate.
What you'll learn:
This lesson assumes you're already using Claude regularly and understand basic prompting — you know what a system prompt is, you've experimented with different phrasings, and you have a sense of how temperature and specificity affect outputs. If you're brand new to Claude, spend a week with the basics first.
You should also have access to Claude at claude.ai or via the Anthropic API. A few examples in this lesson will show API-style prompting, but all the techniques work in the standard chat interface.
Before we get into specific techniques, you need to reframe how you think about Claude. An oracle receives questions and emits answers. A skilled colleague has capabilities they can apply to problems — and you collaborate by selecting which capabilities to bring to bear.
Claude has several distinct built-in capabilities that are largely independent of each other:
| Skill | What It Does | Default Behavior |
|---|---|---|
| Chain-of-thought reasoning | Breaks complex problems into explicit reasoning steps | Off unless prompted |
| Self-critique and revision | Evaluates its own outputs against criteria, then revises | Off unless prompted |
| Constraint satisfaction | Generates outputs that meet multiple specified requirements simultaneously | Partial |
| Persona and domain framing | Adopts expert-level reasoning patterns from specific domains | Available but unfocused |
| Comparative analysis | Systematically evaluates options against consistent criteria | Partial |
| Code generation + debugging | Writes, tests mentally, and iterates on code | Available but one-shot |
| Structured extraction | Pulls structured data from unstructured text | Available but imprecise |
The "Default Behavior" column is the key insight. Several of Claude's most powerful capabilities are effectively off by default. You have to ask for them explicitly. Let's work through each one.
When you give Claude a complex analytical question without any guidance, it tends to produce a confident-sounding answer that skips most of its reasoning. This is fine for simple questions. For anything with multiple variables, it's a trap — you get an output that sounds authoritative but may have made silent assumptions that break your analysis.
Chain-of-thought reasoning forces Claude to externalize its thinking before reaching a conclusion. This serves two purposes: it catches errors in the reasoning chain before they propagate into the answer, and it shows you exactly where the reasoning might diverge from your domain knowledge.
Prompt: Should we migrate our customer_events table from PostgreSQL to
a columnar store like BigQuery, given that we have 800GB of data and
run mostly aggregation queries?
Claude's default response will be something like: "Given your aggregation-heavy workload, a columnar store like BigQuery would likely be beneficial because..." and then list reasons. This might even be correct. But you have no idea what tradeoffs it silently weighed, what it assumed about your query patterns, or what factors it didn't consider.
Prompt: I need to decide whether to migrate our customer_events table
from PostgreSQL to BigQuery. Before giving me a recommendation, walk
me through your reasoning step by step. Consider:
1. First, identify what information you'd need to make this decision
well, and what assumptions you're making about my situation
2. Then, reason through the technical tradeoffs explicitly
3. Then, reason through the operational tradeoffs
4. Finally, give me a recommendation AND tell me which of your
assumptions, if wrong, would flip your recommendation
My context: 800GB table, mostly aggregation queries, 3-person data
team, we're already paying for GCP, queries currently run in
45-90 seconds.
This prompt activates something qualitatively different. Claude will surface its assumptions (like "I'm assuming you're running these aggregations on-demand, not streaming"), reason through the decision tree explicitly, and — critically — tell you where its recommendation is fragile. That last part is the most valuable thing a decision-support tool can offer.
Pro tip: The phrase "walk me through your reasoning step by step before giving me your answer" is one of the highest-leverage phrases in prompt engineering. Use it any time the decision has more than 2-3 variables.
Use chain-of-thought reasoning any time you're making a technical architecture decision, evaluating a statistical approach, debugging unexpected behavior in a pipeline, or trying to understand why a model is producing certain outputs. Basically: any time "being wrong in a specific way" would cost you something.
Here's a capability most Claude users never discover: you can ask Claude to critique its own output against explicit criteria, and then revise it. This isn't asking Claude to "make it better" — that's vague and produces marginal improvements. This is giving Claude a rubric, asking it to score its own work, identify specific weaknesses, and then produce a revised version that addresses those weaknesses.
The practical effect is dramatic. One round of deliberate self-critique and revision typically produces better output than three or four rounds of vague "improve this" prompting.
Suppose you're writing documentation for an internal data pipeline. Here's how to use the self-critique loop:
Step 1: Generate the first draft normally
Write technical documentation for our ETL pipeline that ingests
Salesforce opportunity data, transforms it to calculate
weighted_pipeline_value by multiplying amount * probability,
and loads it into our sales_metrics data warehouse table.
The audience is data engineers who will maintain this pipeline.
Step 2: Apply the critique prompt
Now critique that documentation against these specific criteria:
1. Clarity: Would a new data engineer understand what to do when
the pipeline fails at 2am?
2. Completeness: Are there obvious failure modes or edge cases
not covered?
3. Accuracy: Are there any technical claims that might be wrong
or misleading?
4. Actionability: Can a reader actually do something with this,
or is it purely descriptive?
For each criterion, give it a score of 1-5 and explain the specific
weaknesses. Don't be generous — I'd rather have accurate criticism
than false comfort.
Step 3: Request the revision
Now rewrite the documentation addressing all the weaknesses you
identified, particularly the gaps in failure handling and the
missing information about the Salesforce API rate limits.
Keep the same structure but fix what's broken.
The reason this works better than just asking for "a better version" is specificity. When you give Claude a rubric, it has something concrete to optimize against. When you just ask it to improve something, it tends to polish the surface — adding transitions, varying sentence length — without addressing structural weaknesses.
Pro tip: The instruction "Don't be generous — I'd rather have accurate criticism than false comfort" is important. Claude has a mild tendency toward diplomatically softened critique. Explicitly giving it permission to be direct counteracts this.
The self-critique loop works exceptionally well for SQL queries and data analysis. Generate a query, then ask Claude to critique it for:
You'll catch bugs in generated SQL this way that you might otherwise deploy to production.
Claude can hold multiple constraints in tension simultaneously and generate content that satisfies all of them. This sounds obvious — "of course you can tell it what you want" — but there's a specific technique that unlocks the full capability.
The mistake most people make is listing constraints in natural language and hoping Claude weighs them appropriately. The right approach is to separate your constraints by type, explicitly prioritize them, and tell Claude what to do when constraints conflict.
Generate [output type] that must satisfy these constraints:
HARD CONSTRAINTS (must not be violated):
- [constraint 1]
- [constraint 2]
SOFT CONSTRAINTS (should be satisfied if possible, in priority order):
1. [highest priority soft constraint]
2. [medium priority]
3. [lowest priority]
CONFLICT RESOLUTION: If soft constraints 1 and 3 conflict,
prioritize [1/3]. If you cannot satisfy all hard constraints,
tell me before generating anything.
Generate a data quality report template for our monthly executive
review that must satisfy these constraints:
HARD CONSTRAINTS (must not be violated):
- Maximum 1 page when rendered (no more than ~600 words + headers)
- Must include a section for each of our four key metrics:
completeness_rate, freshness_lag_hours, schema_drift_incidents,
and duplicate_record_rate
- Must have a clear RAG (Red/Amber/Green) status indicator per metric
- Must not require any technical knowledge to interpret
SOFT CONSTRAINTS (in priority order):
1. Should make it obvious within 10 seconds whether there's a
problem requiring immediate attention
2. Should give enough context for executives to ask informed
questions in the review meeting
3. Should have a consistent visual structure that makes
month-over-month comparison easy
CONFLICT RESOLUTION: If constraint S1 and S2 conflict
(more context = more reading time), prioritize S1.
Brevity beats completeness.
This produces a qualitatively different output than "write me a data quality report template." Claude will make explicit tradeoff decisions and flag them to you, rather than silently making choices you'll discover later were wrong.
This approach shines for:
Claude has been trained on an enormous amount of domain-specific material. When you give Claude a generic prompt, it responds as a generalist. When you explicitly frame it as a domain expert and specify what that expertise looks like, you access a qualitatively different reasoning mode.
This is different from basic role-playing. The key is specificity about what the expert knows and cares about, not just their job title.
Generic prompt:
Review this Python function that calculates customer lifetime value.
Domain-framed prompt:
You are reviewing this code as a senior data engineer who has been
burned by LTV calculation bugs in production. Your specific concerns
are: (1) whether the revenue attribution logic handles multi-product
customers correctly, (2) whether this will behave correctly at
10M+ rows, and (3) whether the cohort boundaries are being calculated
the way the business team actually defines them (calendar month,
not rolling 30 days). Review this function with those priorities.
[function here]
The difference in output isn't just tone — it's what gets caught. A generalist review might flag general Python style issues. The domain-framed review will focus on exactly the bugs that are expensive in production.
A useful domain frame has four components:
You are a [role] with [X years] of experience, specifically in
[narrow domain]. You've worked at companies similar to ours
([describe company type]) and have been burned by [specific failure mode].
When you evaluate [output type], you specifically look for [criteria].
Pro tip: The "prior pain" component is the most underused part of domain framing. Experts don't just know things — they've learned what to be worried about. When you specify what Claude's persona has been burned by, you activate risk-focused reasoning that generic prompts never reach.
Claude can systematically compare options against consistent criteria — but only if you explicitly set up that structure. Left to its own devices, Claude will compare options conversationally, which means the criteria shift between options, the weighting is inconsistent, and the conclusion is often driven more by narrative flow than analytical rigor.
The fix is to establish your evaluation framework before asking Claude to apply it.
Pass 1: Establish the criteria
I need to choose between dbt, Prefect, and Airflow for orchestrating
our data pipelines. Before evaluating any of them, help me build
an evaluation framework. Given that we're a 4-person data team,
have mostly dbt-native transformations, and care a lot about
ease of debugging when things go wrong at 3am, what criteria
should I evaluate these tools on? Give me 5-7 criteria with
a brief explanation of why each matters for my context.
Pass 2: Apply the framework consistently
Now evaluate each of those three tools against exactly those
criteria, in exactly that order, using the same scoring scale
(1-5) for each. Don't change the criteria mid-evaluation.
After the evaluation table, give me a recommendation with
explicit reasoning about which criteria drove the decision.
This two-pass approach solves a real problem: when you ask Claude to both define and apply evaluation criteria in one step, it tends to let the criteria drift to favor whichever option it's evaluating at the moment. Separating the passes forces consistency.
Ask for a structured table explicitly:
Present the evaluation as a markdown table with tools as columns
and criteria as rows, with a score (1-5) and one-sentence
justification in each cell.
| Criteria | dbt | Prefect | Airflow |
|---|---|---|---|
| Ease of debugging | 4 - native DAG lineage | 3 - good UI, less lineage | 2 - requires significant setup |
| ... | ... | ... | ... |
You now have a structured artifact you can share with your team, not just a conversational paragraph.
Most people use Claude for code as a one-shot generator: ask for a function, get a function, copy-paste it, discover it doesn't quite work, go back and ask again. This is the least efficient pattern possible.
Claude can do iterative development — incrementally building code, testing specific behaviors mentally, and refining — if you structure the interaction that way.
Instead of asking for a complete solution, ask for scaffolding first:
I need to build a Python function that reads a CSV of customer
transactions, calculates rolling 30-day revenue by customer_id,
and flags customers who have dropped more than 40% compared to
their previous 30-day window.
Before writing any code: outline the approach you'd take,
identify the edge cases that will be tricky, and tell me
what pandas/polars operations you're planning to use for
the rolling window calculation. Don't write the function yet.
This surfaces problems before they're embedded in code. If Claude's planned approach relies on a pandas operation that doesn't work the way it expects, you want to know that before you're debugging 80 lines of code.
Then build incrementally:
Good. Now write just the data loading and validation piece —
the part that reads the CSV and validates that customer_id,
transaction_date, and revenue_amount columns exist and have
the right types. Include docstring and a few assert statements
I can use to test it.
Then:
That looks right. Now add the rolling window calculation.
Show me what the intermediate dataframe looks like after
this step with a small example (3 customers, 5 transactions each).
The "show me the intermediate state" instruction is particularly powerful. It forces Claude to reason about what the data actually looks like at each step, which catches transformation errors that would otherwise only surface when you run the code.
When you have a bug, don't just paste the error and ask for a fix. Paste the error, your data sample, and ask Claude to reason about the failure before proposing a solution:
This code is failing with the following error:
[error message]
Here's a sample of the data it's processing (5 rows):
[data sample]
Before suggesting a fix: explain what you think is causing
this error, and tell me if there are multiple possible causes
so I can investigate which one applies to my situation.
This gets you an explanation you can verify, rather than a fix that might work for the wrong reason.
Claude can extract structured data from unstructured text with high reliability — but you need to specify the schema explicitly and handle the failure modes.
This is genuinely useful in data work: extracting entities from support tickets, parsing information from email threads, pulling structured fields from analyst notes, converting legacy documentation into structured formats.
Extract the following fields from each support ticket below.
Return results as JSON with exactly this schema:
{
"ticket_id": "string",
"reported_metric": "string or null",
"data_source": "string or null",
"urgency_level": "high|medium|low",
"requires_engineering": true|false,
"summary": "string, max 20 words"
}
Rules:
- If a field is not mentioned in the ticket, use null
- For urgency_level, default to "medium" if not explicit
- requires_engineering is true only if the ticket explicitly
mentions code, pipeline, or infrastructure changes
- Do not infer or guess — only extract what is stated
Tickets:
[ticket text]
The explicit schema, null handling rules, and "do not infer" instruction are all critical. Without them, Claude will make intelligent guesses that seem reasonable but are inconsistent — sometimes inferring, sometimes not, with no way to know which behavior you're getting.
Warning: For production data extraction pipelines, always validate Claude's JSON output against your schema programmatically. Claude will produce valid JSON correctly almost always, but "almost always" isn't good enough for an automated pipeline. Use Pydantic or a JSON schema validator on every response.
Scenario: You're a data analyst at a SaaS company. Your team has been generating weekly churn risk reports manually — someone reads through account health data and writes a narrative summary. You want to systematize this with Claude.
Your task: Build a repeatable prompt workflow (a sequence of 3-4 prompts) that takes raw account health data and produces a formatted churn risk report suitable for your customer success team.
Requirements:
Starter data to work with:
Account: Meridian Logistics
- Last login: 14 days ago (was daily)
- Feature adoption: 23% (down from 67% last quarter)
- Open support tickets: 3 (2 unresolved > 7 days)
- Contract renewal: 47 days
- NPS score: 4 (last survey 60 days ago)
- ARR: $84,000
Account: Brightfield Analytics
- Last login: yesterday
- Feature adoption: 78% (up from 61% last quarter)
- Open support tickets: 1 (resolved same day)
- Contract renewal: 200 days
- NPS score: 9 (last survey 14 days ago)
- ARR: $120,000
Account: Cascade Retail Group
- Last login: 3 days ago
- Feature adoption: 45% (flat for 2 quarters)
- Open support tickets: 0
- Contract renewal: 22 days
- NPS score: 6 (last survey 90 days ago)
- ARR: $210,000
Solution approach: Start with the domain expert frame (customer success manager who has handled churn situations), then use constraint satisfaction to define the report format, then generate and self-critique before producing the final version. Your prompt chain should be reproducible — someone else should be able to run it next week with new data and get a consistently structured output.
What it looks like:
Walk me through your reasoning step by step and tell me whether
we should move to a microservices architecture.
Why it fails: When you bundle the instruction to reason with the actual question, Claude often produces a slightly longer version of its default response with "step 1, step 2" labels tacked on. The reasoning is cosmetic, not structural.
The fix: Separate the reasoning instruction from the question, and ask Claude to complete the reasoning before it answers:
I'm going to ask you a complex architectural question. Before I do,
I want you to commit to reasoning through it step by step and
showing your work before reaching a conclusion. Ready?
Here's the question: [question]
What it looks like:
Act as a senior data engineer and review my code.
Why it fails: "Senior data engineer" is so broad that Claude defaults to a generalist review. The persona has no specific focus.
The fix: Add specificity about what this persona knows, has experienced, and cares about:
Act as a senior data engineer who has specifically been responsible
for data quality in high-volume e-commerce systems, and who has been
burned by silent failures in transformation pipelines (results look
right but are subtly wrong). Review my code with that lens.
What it looks like:
Write a data quality report, then critique it, then improve it.
Why it fails: When you bundle generation, critique, and revision, Claude treats the critique step as a transition paragraph rather than a real evaluation. The revision rarely addresses the specific weaknesses the critique identified.
The fix: Run these as separate messages. Let Claude generate. Then critique. Then revise. The separation creates genuine independence between evaluation and revision.
What it looks like:
Compare Snowflake, BigQuery, and Redshift for our use case.
Why it fails: Without a defined framework, Claude will organize the comparison around whatever dimensions come to mind first — which are usually generic, not specific to your situation. The criteria will drift across options.
The fix: Define your criteria in a separate message before asking for the comparison. Then explicitly instruct Claude to use those criteria and only those criteria for each option.
What it looks like:
Write a Python class that handles incremental loading for our
customer_events table, manages watermarks, handles failures
with retry logic, and logs to our structured logging system.
Why it fails: Complex requirements produce complex code that's hard to validate. When it's wrong (and it will have something wrong), you don't know which piece failed.
The fix: Build incrementally. Ask for the approach first. Then the scaffold. Then one component at a time. Test each piece before building the next.
What we've covered in this lesson is really about a shift in how you relate to Claude as a tool. The built-in skills — chain-of-thought reasoning, self-critique loops, constraint satisfaction, domain framing, comparative analysis, iterative code development, structured extraction — exist in Claude regardless of whether you invoke them. Most people never do, and they get outputs that are fine but not exceptional.
The core insight is this: Claude's default behavior is to be immediately helpful, which means skipping the deliberative steps that produce its best work. Your job as a practitioner is to slow it down in the right places — asking it to reason before concluding, to critique before finalizing, to define criteria before evaluating. That friction is where the quality lives.
The techniques in this lesson compound. Domain framing + chain-of-thought reasoning + self-critique, used together on a complex architectural decision, produces something genuinely different from any individual technique. Once you've internalized these as reflexes — once your instinct when facing a complex question is to reach for the right cognitive tool rather than just typing your question — your output quality will shift permanently.
Where to go next:
System prompts and persistent context — Now that you understand how to invoke specific skills, the next level is building those invocations into system prompts so they apply to every interaction in a given context. A system prompt that establishes domain framing and instructs Claude to always reason before concluding transforms every interaction, not just the ones where you remember to ask.
Multi-turn workflow design — The techniques in this lesson work individually, but the real power is in designing multi-turn workflows: prompt chains where the output of one step becomes structured input to the next. This is the foundation of serious AI-assisted work, and it requires thinking about information architecture across a conversation, not just within a single prompt.
Evaluating LLM outputs programmatically — As you start using Claude in more production-facing contexts (extraction pipelines, automated report generation, code review assistants), you'll need ways to evaluate output quality at scale. Claude can actually help you build those evaluation rubrics — but that's a lesson in itself.