I treat a single Git repository as my operational control centre. Every project lives there as a folder of living documentation; every repeatable task becomes a reusable skill; every platform — Jira, Power BI, Confluence, Power Automate, Microsoft 365, Glean — is reachable from inside the same workspace. Claude Code is the layer that ties it together: it reads the documentation, runs the skills, calls the platform APIs, and keeps everything synchronised with Git.
Everything radiates out from one repository. Claude Code sits in the middle — reading my project documentation and acting on the platforms through skills, the CLI, and MCP connectors — then commits the entire working state back to Git.
When new work arrives I create a project folder rather than keeping the context in
my head or scattered across emails and chats. Projects are sorted into priority buckets and follow a
strict naming convention (tr-yyyy-mm-<name>) so my work is instantly filterable.
# projects/ — sorted by priority projects/ ├── 0-urgent/ ← drop-everything work ├── 1-priority/ ← current sprint focus ├── 2-normal/ ← standard priority ├── 3-low/ ← backlog └── done/ ← archived / completed
Every project folder contains the same core files, so anyone — or any future session — can resume the work cold:
| File | Purpose |
|---|---|
README.md | The living record — objective, background, plan with checkboxes, contacts, constraints, current status & next action. |
plan.md | The phased task breakdown. |
memory.md | Shared context for Claude — glossary, decisions, gotchas, where credentials live. |
log.md | Optional — running journal of what happened, when. |
inputs/ working/ output/ scripts/ | Optional — source material, scratch work, deliverables, and any code the project produces. |
The discipline that makes this work: the README always reflects current reality. At the end of a session I update Status and Next action, so the next session starts with full context instead of archaeology.
I manage a project's whole life with a set of /project-* skills —
slash-commands that encode each procedure so I never reinvent it. State is always written down; the
transitions are automated.
Scaffolds the folder and first searches Glean for prior work, so I never start from a blank page.
Researches the relevant APIs, internal Confluence docs and existing CLI commands, then writes a phased plan.md.
Pulls a project's README into the session and renames it, so everything I do next is grounded in that project.
Picks up the next task in the plan and either does it or tells me exactly what I need to provide.
Produces a dated progress note and RYG status — mining Glean activity, or capturing the current session.
Wraps up the documentation and moves the folder to done/.
When I find myself doing the same multi-step task more than once, I turn it into a skill
— a folder under .claude/skills/ with a SKILL.md that becomes a
/slash-command. Several of my projects were literally "build a skill" projects:
jira-filter-cleanup, confluence-broken-links,
confluence-permissions-audit, powerbi-dataflow-inspect. I build the
capability once, then reuse it forever — and publish the useful ones to the rest of the company.
Skills fall into a few buckets:
/git-commit, /git-commit-push, /git-pull — these screen for sensitive files before staging./project-* family above./entsol, /power-automate-docs, /confluence-space-creator, /jsm-ticket-responder, and the audit/cleanup skills./presentation, /investcloud-deck.Alongside skills there's the entsol CLI — a Python tool that wraps the same platform APIs. The rule of thumb: use a skill when the task benefits from reasoning (drafting, synthesis, multi-step decisions); use the CLI when it must work without Claude — scripting, scheduled jobs, or resilience during an outage.
For live, read-oriented work I don't even leave the conversation — MCP connectors let Claude query the platforms directly: Atlassian (Jira & Confluence), Glean (enterprise search across 100+ apps — my go-to for "what work do I have" and "has anyone done this before"), Microsoft 365 (Outlook, SharePoint, Teams), Figma, and Power BI.
This is an operational workspace, so the workflow is deliberately lightweight: commit directly
to main. No branch/MR/review ceremony — it doesn't serve an ops repo. One command
stages, commits with a generated message, and pushes. The git skills still screen for secrets
(.env, keys, tokens) before staging, so credentials never get committed.
Because everything — project docs, skills, CLI, generated scripts — lives in the repo, pushing to
main means my entire working state is backed up, versioned, and available to the team.
/project-focus the project I'm working on to load its context./project-execute, or work directly: write a script, inspect a Power BI dataflow, draft a Confluence page, respond to a JSM ticket.README.md status, or /project-update for a dated progress note./git-commit-push to back everything up to main./plugins-publish it.