mcnamee/claude-skills

Three things, all for Claude Code, all working entirely offline:
plugins/ — eight MCP servers that give an agent hands on the
things enterprise work actually lives in: Word documents, Excel workbooks,
Outlook mail, Confluence, Jira, PDFs, plus a local RAG knowledge base to tie
them together. This repo doubles as a plugin marketplace for them.
eva/.claude/skills/ — standalone skills that
need no server and no install beyond the eva/ copy below.
eva/.claude/agents/ — subagents that take a whole
job away and hand back a finished result, built on top of the servers and
skills above.
Plus eva/ — the working folder they all read, write and index,
carried here as a scaffold you copy to H:\Eva. The skills and agents live in
its .claude\ folder, so they install with it and stay scoped to H:\Eva
rather than your whole account. It holds the knowledge base,
the document library, and the templates — the blank .docx/.pptx files
new documents and decks are built from. It also carries
eva/CLAUDE.md, the standing instructions that make the
assistant Eva — an executive virtual assistant who writes in Australian
English, without em dashes or the other AI tells, and never fills a gap in the
source material with something invented.
> Using OpenCode instead of Claude Code? The same servers and skills work
> there too - see OPENCODE.md for the install.
## Why this exists
Built for Windows endpoints in an Enterprise environment. No internet calls, no telemetry,
no registry lookups. Copy the folder across, add it as a local marketplace,
install.
One file per server. Every server is a single .py — nothing to build, no
package tree to transfer. Three of the eight are standard library only, and
the standalone skills are prose (bar org-chart's one standard-library script).
Four settings, once, for the whole suite. EVAPYTHON,
EVADOCUMENTSDIR, EVATEMPLATESDIR and EVAKNOWLEDGEDIR are the
configuration. Each server works in its own sub-folder of those roots, named
after the plugin, so there is nothing per-plugin to fill in, no folder prompts
at install, and no folder flags to keep in step across a .mcp.json, a
claude mcp add line and eight plugin dialogs. /plugin install asks for
nothing: what is genuinely one server's own — a Confluence URL, an
embeddings endpoint — is an environment variable too, set in the same env
block. The matching skill comes with the server.
Confined by default. Every server that touches the filesystem is locked to
its sub-folders, and refuses to start unconfined rather than falling back to
"anywhere". The office plugins - word, powerpoint and excel - can
change a file you already have in their folder; the rest either read, or
write new files (Markdown, a downloaded attachment) into their own folders.
Shared systems are read-only until you say otherwise. confluence and
jira can write - create and edit pages, raise and move tickets - but each
ships with writing off. One variable (CONFLUENCEALLOWWRITE,
JIRAALLOWWRITE) turns it on; until then the write tools are not even
offered.
Secrets never hit the command line. Tokens and API keys are environment
variables only — argv is visible to other local users in process listings.