client-facing-docs

A guide to writing technical documents for clients and other non-technical readers. It explains technical terms in everyday language and keeps the document aligned with the agreed project scope.

In plain words
What is it for?
Use it when preparing client-facing architecture documents, project proposals, kickoff material, or presentations.
Why use it?
It makes architecture documents, proposals, and presentations easier to understand without hiding important limits, costs, dates, or team details.

Skill for Claude CodeCodex

Part of the oficina plugin — 6 skills, 5 commands shipped together

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/joaoequer/oficina/client-facing-docs
Any agent
npx skills add JoaoEquer/Oficina --skill client-facing-docs
Clone the repo
git clone --depth 1 https://github.com/JoaoEquer/Oficina

Made for: Claude Code, Codex.

Or install oficina, the plugin that ships this one along with the rest of its 6 skills, 5 commands.

Per session 65 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 603 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00065 $0.00603
Opus 5 $0.00032 $0.00302
Sonnet 5 $0.00013 $0.00121
Haiku 4.5 $0.00006 $0.00060

Measured 2d ago against content hash eb8b7368f985, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

client-facing-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

skills/client-facing-docs/SKILL.md · 42 lines

How it starts

The opening of the file, as written. The whole thing — 42 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Client-facing documentation

A document for a client is not a technical document with a nice cover. It is a different kind of writing.

Principles

  1. Zero untranslated jargon. "Monorepo" becomes "a single repository". "Multi-tenant" becomes "each company with its data isolated". "CI/CD" becomes "every change passes automated checks before going live". If a technical term must appear, a one-sentence explanation comes with it.
  2. Honest numbers. Hours, deadlines and scope reflect the real contract — never a partial version that "presents better". A wrong number in presented material is the kind of thing that erodes trust and is very expensive to fix later.
  3. Document scope = contracted scope. Future phases, product vision and commercial possibilities stay out of the MVP document (at most, a one-line note: "future evolutions depend on a new commercial cycle").
  4. Real team, real roles. Only people actually allocated, each with their correct role. Double-check before sending.
  5. Explicit engineering principles. A short section stating how the team decides: proven technology over trends, complexity only when the problem demands it, reversible decisions, honest deadlines. Clients understand and value it — and the document becomes an anchor when someone suggests the trend of the week.

House formats

Architecture/structure document (responsive HTML):

  • Sections: overview → what the system does → how it is organized (repos, modules) → team and roles → engineering principles → timeline/workstreams
  • Flowing prose, tables only where comparison demands them
  • No decorative Unicode borders and no emoji overload (they break rendering and age badly)

Presentation (fullscreen HTML deck):

  • Keyboard (←/→) and click navigation, progress bar, slide counter
  • One topic per slide, short sentences
  • Export to PDF for distribution via WhatsApp/email (the PDF is what circulates; the HTML is what presents)
  • Mandatory final check: deck numbers × contract numbers, before presenting

Read the full file on GitHub · 42 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 42 lines · 65 tokens per session scan A eb8b7368f985

Subscribe to this mod's changes

client-facing-docs is a skill published in the GitHub repository JoaoEquer/Oficina (2 stars, last pushed 1mo ago), licensed MIT. It adds 65 tokens to every session and 603 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

openrig-user

Use when a specific rig command, subcommand, or flag is already known and you need its exact syntax, JSON shape, defaults, or error meaning. NOT for natural capability discovery, open-ended how-do-I questions, or choosing which OpenRig move applies.

mvschwarz/openrig · 58 tokens

orienting-to-an-inherited-seat

Use when you have just been primed into an EXISTING seat through a planned handover — a different agent retired and handed you the seat plus its earned context — and you need a world model of what just happened to you. Covers how a handover differs from compaction and from a fresh launch, the…

mvschwarz/openrig · 207 tokens

forming-an-openrig-mental-model

Use when the system around you does not make sense yet: you just booted into a seat and do not know how the pieces fit; someone said rig, pod, seat, fleet, topology, or slice and you are not certain what they mean here; you are unsure what kind of rig you are in or what it is for; you do not know how skills reach you…

mvschwarz/openrig · 117 tokens

openrig-upgrade

Use when upgrading the OpenRig CLI/daemon on a host with running rigs, especially when preserving tmux-backed agent sessions through a daemon restart or documenting hot-upgrade SOP evidence.

mvschwarz/openrig · 41 tokens

openrig-skills

Use when you're operating OpenRig and need the right skill or context for fleet recovery, seat handover, new-seat orientation, a watchdog wake, cross-host reach to an agent on another machine, rig packaging, an OpenRig upgrade, systematic debugging, queue triage, or implementation planning; also use when you don't…

mvschwarz/openrig · 79 tokens

claude-compaction-restore

Use when a Claude Code session has just compacted, is about to compact, reached context limit, resumed after /compact, or needs to rebuild its working mental model from Claude JSONL transcripts and touched files.

mvschwarz/openrig · 49 tokens