How I Collaborate with AI at Work: 5 Practical Principles
The article outlines a systematic approach to working with AI by treating context as infrastructure, encoding preferences in configuration files, front‑loading validation, progressively delegating larger tasks, and closing the feedback loop, with concrete examples of directory organization, CLAUDE.md onboarding, skill files, hooks, and session monitoring.
1. Context is infrastructure
2. Taste is configuration
3. Use validation to gain autonomy
4. Scale work by delegating
5. Close the loop
1. Context is infrastructure
Store all code in ~/src and knowledge work in ~/vault, with sub‑directories projects/, notes/, and kb/. A clean directory tree lets the model retrieve files via grep or glob.
Connect the model to organizational sources (Slack, Drive, Mail) through MCP (Claude Code, Cowork, Claude.ai).
Maintain an INDEX.md per project that lists URLs, owners, and short descriptions so the model can filter relevant links without opening every URL.
Treat each new session as onboarding: place a CLAUDE.md in the project root containing an acronym glossary, project codes, disambiguation for same‑named teammates, and a recommended reading order (e.g., INDEX.md → TODOS.md → topic‑specific notes).
Persist memory on disk in two layers: ~/vault for project state, results, and domain knowledge (context); ~/.claude (including CLAUDE.md, skills/, guides/) for preferences and workflow (configuration).
2. Taste is configuration
Write a global ~/.claude/CLAUDE.md that the model reads at the start of every session. It defines behavior (direct opinions, uncertainty signaling, root‑cause investigation before retry, limited scope edits) and teaching style (explain new terminology with a 💡 prefix).
Scope configuration by directory:
Global preferences in ~/.claude/CLAUDE.md Repository‑specific conventions (linting, naming, PR guidelines) in the repository root CLAUDE.md Project‑specific context in the project’s CLAUDE.md When the model changes directories, it walks up the tree and loads each level’s CLAUDE.md (see documentation[2]).
If CLAUDE.md becomes large, split it into guides and reference them with a <guides> block:
<guides>
- Documentation, single‑page explanations: ~/.claude/guides/writing.md
- Build evaluations and reports: ~/.claude/guides/evals.md
- Dashboards: ~/.claude/guides/dashboards.md
</guides>Define recurring tasks as skills —Markdown files that specify a name, trigger conditions, and execution flow. Example skills: /polish: check diff, run metrics‑based evaluation, or render in Chrome; iterate until no serious issues; draft a Pull Request. /write: interview to create outline, launch a research sub‑agent, draft, receive adversarial reviewer feedback, iterate. /daily: read calendar, Slack, PRs, and yesterday’s log; produce today’s priority list.
Keep SKILL.md short (workflow and routing only); templates, scripts, and heavy knowledge live in separate files loaded lazily.
Build a skill by first performing the task manually, then asking the model to distill the process into a skill. Run the skill on similar inputs, correct any errors within the same session, and let the model update the skill using the session’s before/after feedback.
For lightweight brainstorming, enable a simple mode: CLAUDE_CODE_SIMPLE=1 claude which loads CLAUDE.md but disables hooks, skills, and heavy tool‑call loops.
3. Use validation to gain autonomy
Move validation forward: the lowest rung is a deterministic edit‑hook that runs ruff format and ruff check --fix after each model edit. Higher rungs include tests, evaluations, and LLM‑based reviews.
Make validation easy for the model:
If the system produces metrics, let the model run evaluations and optimise.
If output renders in a browser, let the model check via Claude in Chrome.
Otherwise, let the model execute the program, read errors, and fix them (e.g., rebuild a Docker image after reading build errors, modify the Dockerfile, and retry).
For long‑running tasks, spawn a fresh supervision session with a clean context. Feed it the original task description and recent excerpts from the main session (using two tmux panels). The supervision session periodically reads the main session’s logs, compares them to the original requirements, and provides corrective feedback. It detects:
Execution drift – missed steps or ignored errors.
Direction drift – building the wrong thing due to misunderstood intent.
4. Scale work by delegating
Gradually increase delegation size. Start with clear intent, constraints, and success criteria, then let the model execute end‑to‑end. Tasks that cannot be verified are not delegated.
“Based on these test suites, build an isolated container for each suite, smoke‑test that it builds successfully, then run the full evaluation, record metrics and session logs, have a sub‑agent read the logs to confirm correct execution, repeat each test n times to compute confidence intervals, generate a report, verify it against the report guide, and post the result and report URL to Slack.”
Run multiple sessions in parallel (typically three to six). Use git worktree so each session has its own checkout directory, preventing overwrites.
Make session state observable. On macOS, configure a Stop Hook that plays a sound when a session finishes:
# Stop Hook sound example
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "if command -v afplay >/dev/null 2>&1; then afplay -v 1.0 /System/Library/Sounds/Glass.aiff; else tput bel; fi"
}
]
}
]Use tmux window titles with emojis (⏳ for running, 🟢 for completed) plus a short label generated by Claude Haiku. Claude Code’s status bar shows context usage and current mode.
When away from the computer, use Claude Code’s /remote-control to view running or blocked tasks and inject additional context or instructions.
5. Close the loop
Public collaboration enriches context. Shared documents, repositories, and channels make it easier for both teammates and the model to retrieve relevant information. A simple test: can a new teammate reproduce last week’s work using only the shared context?
Automate updates to a work‑log channel from CLAUDE.md whenever a large task finishes.
Mine session logs for configuration improvements. Scanning ~2,500 user messages revealed frequent phrases like “could you also…”, “did you check…?”, or “that’s still wrong”, indicating missing autonomous actions. Update CLAUDE.md or skills accordingly; the frequency of such corrections quantifies the prevalence of each issue.
Periodically refactor configurations to eliminate overlapping or conflicting rules. Consolidate scattered settings.json files under ~/.claude and keep a single source of truth for each rule in CLAUDE.md.
Core principles remain constant: provide sufficient context, encode taste in configuration, lower validation cost, gradually delegate larger work, and feed feedback back into the system.
Reference links:
[1] https://modelcontextprotocol.io/docs/getting-started/intro
[2] https://code.claude.com/docs/en/memory#how-claude-md-files-load
[3] https://eugeneyan.com/assets/SETUP.txt
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
AI Tech Publishing
In the fast-evolving AI era, we thoroughly explain stable technical foundations.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
