You’re Using Claude. Here’s How to Make It More Useful in Your Daily Work.

You ask Claude to fix a bug. It makes a reasonable change.

Then comes the follow-up:

“Use pnpm.”

“Don’t include those unrelated files.”

“Check how we handle this elsewhere.”

“Run the formatter.”

Each instruction is small. Together, they leave you supervising details you’ve already explained.

Claude has features that help with this, but the names can be confusing. Skills. Hooks. Subagents. MCP. Cowork. It takes a little work to understand where each one fits.

The useful question is: what problem would I actually use this for?

Let’s work through that using situations developers recognize: investigating a bug, committing changes, preparing release notes, and checking a spreadsheet against a CRM.

The configurations are examples you can adapt. The sample findings and results are illustrative, so you know what to look for when trying them yourself.

Start by giving Claude a task it can investigate#

Imagine a customer enquiry appears in a spreadsheet but never reaches your CRM.

You could ask:

Fix the missing leads.

But “missing” leaves a lot open. Did the webhook arrive? Did the queue job run? Was a contact created without a lead? Did the lead enter another pipeline?

A more useful request would be:

Investigate why submission TEST-002 did not appear in the CRM.

Trace the webhook handler, queue job, and CRM creation request.
Check whether it failed, was skipped, or created a lead elsewhere.

Show the relevant files and evidence before proposing changes.
An existing contact does not necessarily mean a lead exists.

You’ve given Claude an identifier, an investigation path, and a business rule that affects the answer.

For a substantial change, Claude Code’s Plan mode lets it investigate and propose an approach before implementation. Ask for the smallest proposed fix and how it would be verified.

This also makes the response easier to assess. “The retry logic is broken” is a hypothesis. A specific condition in a specific handler gives you something to examine.

The project facts you keep repeating belong in CLAUDE.md#

You explain that the repository uses pnpm. Later, Claude suggests npm.

You explain that controllers should stay thin. Another session puts business logic in a controller.

Claude Code loads project guidance from CLAUDE.md. You can run /init to generate a starting version, then edit it to reflect how your team actually works.

For a NestJS project, it might contain:

# Working in this repository

- Use pnpm.
- Keep controllers thin; business logic belongs in services.
- Validate webhook payloads before enqueueing jobs.
- Use source submission IDs for duplicate detection.
- Database changes require migrations.
- Run relevant checks and report their actual results.

Now consider the next request:

Add duplicate protection to the lead-import handler.

Claude has a starting point for deciding where the logic belongs and which identifier matters.

That doesn’t guarantee a correct implementation. It makes your expectations explicit and available across sessions.

Keep this file focused on facts that change decisions. “Write clean code” gives little direction. “Use the source submission ID for duplicate detection” can prevent a particular mistake.

Also, maintain it. An instruction describing an old queue system can send Claude in the wrong direction long after your code has changed.

A skill saves a procedure you want to reuse#

Project conventions don’t fully describe how you want a particular task completed.

Committing changes is a good example. You may want Claude to inspect the diff, exclude unrelated work, stage carefully, and write a message in your preferred format.

Create:

.claude/skills/commit/SKILL.md

Add:

---
name: commit
description: Review and commit changes belonging to the current task.
disable-model-invocation: true
---

Inspect git status, unstaged changes, and staged changes.

Identify changes belonging to the current task.
Ask if unrelated changes cannot be separated confidently.

Stage only the intended files or hunks.
Review the staged diff before committing.

Write a concise Conventional Commit message explaining
the behavior changed.

Create the commit and report its hash and message.
Report which checks ran and which did not.
Do not push or amend unless requested.

Then type:

/commit

Suppose the working tree contains:

M src/leads/lead-import.service.ts
M src/leads/lead-import.service.spec.ts
M docs/pricing-notes.md

The current task concerns importing leads. The pricing notes belong to something else.

A useful result would identify that distinction, commit the relevant changes, and tell you what remains uncommitted. The message might be:

fix(leads): prevent duplicate imports for the same submission

The frontmatter controls how the skill is discovered and invoked. The body describes the procedure.

Here, disable-model-invocation: true means you explicitly trigger the skill. Without that restriction, Claude can select relevant skills based on their descriptions. Invoking a skill does not bypass tool permissions.

The benefit is consistency. You can review and improve the procedure once, then reuse it.

Skills also help with the work after coding#

Think about release notes.

A developer-facing change might say:

Add a unique constraint on source_submission_id and handle conflicts.

A customer-facing note could say:

Fixed an issue where repeated form submissions could create
duplicate leads.

That translation is another good skill:

---
name: release-notes
description: Draft customer-facing release notes from a supplied diff or commit range.
---

Identify changes users will notice.

Group them under Added, Improved, and Fixed.
Explain observable behavior in plain language.
Exclude internal refactoring unless it affects users.
Do not invent benefits or claim unreleased changes are live.

Return a draft for review.

Save it as .claude/skills/release-notes/SKILL.md, then ask:

/release-notes Use the changes between v1.8.0 and v1.9.0.

The review still matters. If the draft claims “faster imports,” there should be evidence for that claim. A refactoring commit alone doesn’t establish a performance improvement.

Build skills around procedures you genuinely repeat: API reviews, migration planning, incident summaries, or onboarding notes. A small collection of specific skills is easier to maintain than dozens you rarely use.

A hook handles a step you want to happen automatically#

Some tasks are mechanical enough to attach directly to an event.

Formatting is one. You probably don’t want to remind Claude to run Prettier after every edit.

Claude Code hooks can run commands at defined points in its workflow. PreToolUse happens before a tool executes; PostToolUse happens after a tool succeeds.

For a project with Bash, jq, and locally installed Prettier, create .claude/hooks/format.sh:

#!/usr/bin/env bash
set -euo pipefail

edited_file=$(jq -er '.tool_input.file_path')
cd "$CLAUDE_PROJECT_DIR"

./node_modules/.bin/prettier \
  --write \
  --ignore-unknown \
  "$edited_file"

Register it in .claude/settings.json:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "bash \"$CLAUDE_PROJECT_DIR/.claude/hooks/format.sh\""
          }
        ]
      }
    ]
  }
}

Merge this with your existing settings.

When Claude successfully uses Edit or Write, the hook receives the event data, extracts the file path, and runs Prettier on that file.

Run /hooks to inspect the configuration. Then ask Claude to make a small edit in a disposable file and check whether the formatting follows your project configuration.

This example has clear boundaries. It doesn’t catch files rewritten through Bash. It requires its dependencies to be installed. And because it runs afterward, it cannot prevent the original edit.

For checks that should apply to every developer and every commit, keep Git hooks or CI involved too.

A smaller hook can save you from watching the terminal#

You start an investigation, switch windows, and discover later that Claude has been waiting for input.

On macOS, a Notification hook can display a desktop notification. Add this event inside your existing "hooks" object:

"Notification": [
  {
    "matcher": "",
    "hooks": [
      {
        "type": "command",
        "command": "osascript -e 'display notification \"Claude needs your attention\" with title \"Claude Code\"'"
      }
    ]
  }
]

This runs when Claude Code emits a matching notification event. macOS notification permissions must allow the notification to appear.

It’s a modest improvement, but it makes longer tasks easier to leave running while you work elsewhere.

A subagent can investigate one question without overwhelming the main conversation#

Back to duplicate leads.

The investigation might involve a webhook handler, a queue worker, a CRM client, and database constraints. You need the findings, but you don’t necessarily need every intermediate file read in the main conversation.

Create .claude/agents/lead-investigator.md:

---
name: lead-investigator
description: Investigates missing or duplicate leads across webhook, queue, database, and CRM code.
tools: Read, Grep, Glob
model: inherit
---

Investigate the supplied issue without changing files.

Trace the relevant processing flow.
Separate confirmed evidence from hypotheses.
Cite files and functions supporting each finding.

Return:
- Likely cause
- Evidence
- Unresolved questions
- A suggested way to verify the finding

Then ask:

Use lead-investigator to check whether two workers could
create leads for the same submission.

A hypothetical report might say:

Finding:
Both workers can pass the duplicate lookup before either
records the submission as processed.

Evidence:
The lookup and insert are separate operations, and the schema
has no unique constraint on the submission identifier.

Verification:
Process two jobs concurrently with the same submission ID.

The main Claude session now has a specific hypothesis to examine.

You can ask it to check the evidence and propose a fix. A local database constraint might protect local records, while preventing duplicate remote CRM requests also requires attention to retries and when external IDs are stored.

A custom subagent has its own context and configurable tools. The main session must pass the details needed for the task. In this example, the tool list limits the worker to reading and searching.

Subagents consume usage and add overhead. They’re useful for substantial, focused investigations. A one-line change rarely needs several workers.

Separate context also doesn’t automatically mean separate files. Agents with editing tools may affect the same checkout unless you arrange filesystem isolation.

MCP gives Claude a way to reach your actual tools#

Reading the repository shows what the application intends to do. Sometimes you need to inspect what actually happened in the CRM.

MCP stands for Model Context Protocol. It provides a standard interface for exposing tools and data to AI applications. A connector can make operations backed by your own services available to Claude.

For example, you could implement:

findLeadBySubmissionId(submissionId)
getLeadNotes(leadId)
createLead(input)

These are illustrative custom tools, not built-in Kommo commands.

A tool request could look like:

{
  "tool": "findLeadBySubmissionId",
  "arguments": {
    "submissionId": "TEST-002"
  }
}

Your server responds:

{
  "matches": [],
  "searchComplete": true
}

Claude can use that result to propose creating the missing lead.

But consider a different response:

{
  "error": "CRM request timed out",
  "searchComplete": false
}

That is not evidence that the lead is missing.

This is why tool design matters. An empty result and a failed search need different representations. Otherwise, a temporary API failure could become a duplicate record.

For an API integration, your server stores the credentials. Claude requests an operation; your backend validates the request, checks authorization, calls the provider, and returns the result.

Cowork can handle the operational side of the same problem#

Claude Code helps you investigate and change the integration.

Cowork brings agent capabilities to work involving documents, spreadsheets, connected applications, and browser tasks. What it can do depends on the tools and access available in your setup.

Our project has an operational problem as well as an engineering problem.

The engineer needs to fix duplicate handling. The operations team needs to identify which enquiries were missed.

Try a small experiment with fictional data:

Give Claude this assignment:

Compare these three submissions with the CRM.

Match by submission ID and include matching lead links.
An existing contact alone does not prove a lead exists.

Report Existing, Missing, or Uncertain.
Prepare the proposed additions for review.

The expected result is one existing lead and two missing leads.

After checking the comparison, authorize the two creations and ask Claude to record their URLs in the sheet. Then repeat the comparison.

The second run should find three existing leads and create nothing.

That repeat run tells you something valuable. A workflow that succeeds once but duplicates records on retry needs more work.

For browser-based experiments, start small enough that you can inspect every action and result.

Having access and having approval are different things#

A CRM token may allow your application to create thousands of records. Your task may authorize creating two.

Your application should enforce that smaller scope.

For custom tools, check the authenticated customer, permitted account, allowed pipeline, and approved actions in backend code.

A tool call containing approved: true is not proof that a human approved anything. That decision needs to come from trusted application state.

Similarly, “never delete records” in a prompt is useful guidance, but removing deletion capability provides a stronger restriction.

Claude Code’s Auto mode concerns permission handling for tool actions. It doesn’t establish that Claude understood the requirements or that a code change is correct.

Review the result with the same questions you would ask another developer: what changed, why, and what evidence supports it?

Sometimes a scheduled job is still the right answer#

While learning about agents, I kept coming back to this question:

“I can already build this with NestJS. Why would I need an agent?”

Suppose the rule is to read new rows every morning and create missing CRM records. A scheduled backend job may be the simplest implementation.

The sequence is known. Retries, duplicate protection, and failure handling can be explicit.

An agent becomes useful when the next step depends on interpreting what it discovers.

One customer asks about delivery, so it retrieves the delivery policy. Another asks to be contacted next month, so it proposes a reminder. A third already received an answer, so it skips another follow-up.

The sequence changes because the information changes.

You can also combine ordinary software with a bounded AI step. Let code control eligibility, scheduling, and sending while a model drafts the message. That can be useful without handing the entire process to an agent.

Start with one instruction you’re tired of repeating#

You don’t need to configure every feature before your next task.

Maybe you keep explaining how commits should be written. Maybe you keep asking Claude to run the formatter. Maybe a long investigation leaves the main conversation full of details you no longer need.

Give that problem a home: project instructions, a skill, a hook, or a focused subagent. Then see whether you need to intervene less often without losing confidence in the result.

The next time you catch yourself typing “I already told you this,” you have somewhere useful to put that instruction.