Practical approaches and cases — short notes on how Claude can be used in a manager's daily work: where it helps most often, and where it lets you down.
Three unread client messages, a follow-up to send after the morning call — and the reflex to paste the company name, the amount and what was discussed into your favourite AI tool. Stop for a second and ask yourself two questions.
Client names, amounts, contacts, NDA notes and anything Restricted do not go into an unapproved tool. Redaction is not a workaround.
One skill for follow-ups, roadmaps, risk analysis, client replies… It almost never triggers correctly. Five small skills for specific, repeatable tasks beat one big skill “for every occasion”.
The most common reason a “skill didn't fire”. If the trigger is written in general terms, the model doesn't understand when to call it.
If the task isn't repeatable, start with a prompt. If it sticks and keeps repeating, then turn it into a skill — otherwise you get a folder nobody uses.
The process changed, the instruction didn't, and the model keeps doing things the old way. Check once a quarter, or as soon as the process changes.
“Prepare a report” — and the library has status-report, weekly-report and client-report. The model picks the wrong one. Every description must say clearly when this skill, not a neighbouring one, is invoked.
The project says “write in Ukrainian, use this tone”, the skill says something else. The result becomes unpredictable.
A skill is about “how to do it”, not “what to know”. Don't pile in every detail of projects, clients and access.
No client names, internal links, tokens or other confidential info. If the skill goes into the team workspace, that data travels with it.
Nobody ships a feature after one lucky click. Take a few real requests — the kind you actually write at work — and check the skill responds consistently. It's QA, just not for code. For a manager it matters even more: a skill in the team workspace immediately works for everyone, so a bad result is the whole team's problem.
Not every skill needs formal evaluation. Do it when you can no longer confidently say “good / bad” by eye, or when the cost of a mistake is high. Otherwise a few live checks are enough.
For a complex decision, gather different perspectives: several “experts” examine the same decision from their own side, then converge into a comparison matrix and a recommendation.
decision-review: each subagent analyses → a matrix is compiled → a recommendation.SKILL.md — otherwise the system won't see the skill at all.Subagents give several perspectives on a decision. The skill makes sure this bundle switches on by itself whenever you're actually facing a choice.
One searches, another writes, a third checks. A subagent is a separate session the main model spins up: it gets a task, does its part and returns the result. A subagent is a freelancer — came, did the job, left. A skill is closer to a full-time employee.
A verifier agent looks at the result with fresh eyes, like a colleague's draft. A model checking itself defends its own logic; the verifier didn't see how the answer was born. Run it before sending, after research with numbers, after several agents — wherever a mistake is costly. Don't tell it the text was written by AI: have it look for questionable facts, gaps in logic and missed risks. Hallucinations hide in dates, prices and names.
The verifier doesn't replace managers, it only narrows the area to check. The final decision stays with us.
Same font across eight files, identical headings, tidy metadata — work you can hand to AI. For it to look right in Google Docs, a regular chat isn't enough: you need the Google Docs API.
Authorise Google Drive, then grant Claude the access it asks for.
A Templates folder: Communication Plan, Meeting Notes, Project Brief, Retro, Risk Register, Weekly Status…
“Go through all of them”: Open Sans everywhere, large green title, accented headings, date & participants lighter and italic.
Add: “process the files one at a time and write down what's already done” — otherwise the AI may get confused.
Dropdowns for status or priority and date pickers — the model won't place those properly. Structure and style come fast; small interactive bits still get finished by hand.
Instead of a long chat message or half an hour aligning blocks in Miro — a hand-drawn-style whiteboard: blocks, arrows, text. No learning curve; the diagram is in the chat in two or three minutes.
Connect Figma in the connector settings, log in, restart the session. Afterwards three things should be clear: does the mockup solve the task, is everything development needs drawn, and has anything extra appeared without an agreement or budget?
First priority: does the mockup solve the user's problem at all?
All screens and scenarios in place — and nothing extra drawn?
Empty, loading, error, long text, zero items and ten thousand items.
Tokens instead of “freehand” colours, library components, identical spacing.
It can't fully close tasks 1–2 — it doesn't know the requirements until you give them. States and systematic issues it often catches faster than a human: 16 vs 18 px is easy to miss by eye, not for the model.
An AI review is a draft that the manager checks and signs off — never forwarded to the designer without a look.
Practice, not policy — the AI policy still applies to everything here.