In short
Give Claude the context once and reuse it, ask for drafts and options rather than final answers, let it do the first pass on code and reviews, and keep people responsible for decisions and for anything sensitive.
The biggest gains we see from AI at work do not come from one clever prompt. They come from small habits repeated every day. This is how our team uses Claude in a normal week, and the rules we follow so that speed never costs quality.
Set up the context once
Re-explaining your project in every chat is slow and gives uneven answers. We set context up front and reuse it:
- Projects with their own instructions and files. Each client project has a space with the brief, the glossary, the tone of voice and the key documents, so every conversation starts informed.
- A short "how we work" note. Our coding conventions, how we name things and what a good pull request looks like. Claude follows written rules far more reliably than implied ones.
- Connected tools where they help. With connectors (MCP), Claude can read the ticket, the design doc or the repository it is working on instead of us pasting excerpts.
Ask for drafts and options, not final answers
Our most useful prompts ask for a starting point we can judge:
- "Give me three ways to structure this proposal, with the trade-offs of each."
- "Draft the release notes from these merged changes; flag anything you were unsure about."
- "What questions would a sceptical client ask about this plan?"
Asking for options and open questions keeps a person doing the judging, which is the part that matters.
Let it take the first pass on code
For engineering work, Claude Code works inside the repository with our tests and tools:
- Explain before changing. We ask it to read the relevant files and describe the plan first. A wrong plan is cheap to fix; a wrong diff is not.
- Small, reviewable changes. One issue, one branch, one focused change, with the tests that prove it.
- Run the checks. Formatting, types, unit and end-to-end tests run before anything is called done, and failures are reported, not hidden.
- A second look. We use a separate review pass, by a person and often by Claude with fresh context, to catch what the author missed.
Speed up the boring parts of every role
- Writing: first drafts of emails, proposals, documentation and meeting summaries, then a human edit.
- Research: reading long documents, comparing options and pulling out what matters, with sources checked before anything is relied on.
- Data: turning messy exports into clean tables, and writing the query or script instead of doing it by hand.
- Design and prototypes: quick interactive mock-ups to discuss before anyone builds the real thing.
Guardrails we keep
- People own decisions. Claude drafts and suggests; a named person approves anything that goes to a client or into production.
- Sensitive data stays out unless it is allowed. Client secrets, credentials and personal data follow the client's rules and the agreement in place, not convenience.
- Check facts that matter. Numbers, names, legal or medical statements and anything quoted are verified against the source.
- Say when AI helped. Inside the team we are open about it, so reviewers know where to look harder.
Where to start
Pick one task you do every week, such as status updates, code reviews or meeting notes. Write down what a great result looks like, give Claude that and the context once, and use it for a month. Keep what saves time, drop what does not, and only then move on to the next task.
