How do I install the Client Facing Docs skill?

Run npx skillmds@latest add joaoequer/client-facing-docs in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Client Facing Docs safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Client Facing Docs?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Client Facing Docs free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Client Facing Docs?

JoaoEquer (@joaoequer) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Client Facing Docs by joaoequer — Agent Skill

Name: Client Facing Docs
Author: JoaoEquer

Client Facing Docs

Writing client-facing technical documentation — architecture documents, proposals, project presentations — in plain language, jargon-free, with honest numbers and explicit pragmatic engineering principles. Use whenever the material will be read by a client or non-technical stakeholder - architecture doc, kickoff presentation, proposal, delivery report or closing email.

JoaoEquer 39b0704 2.9 KB Updated Sep 17, 2026

File contents

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

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.
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.
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").
Real team, real roles. Only people actually allocated, each with their correct role. Double-check before sending.
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

Closing email (weekly/delivery):

What was done (verifiable facts), what comes next, items pending on the client
Short: if it's longer than one screen, it became a report and nobody reads it

Checklist before sending any material

Numbers match the contract/execution plan
Team and roles verified
Jargon translated or eliminated
Scope limited to what was contracted
Rendering checked on the device the client will open it on (usually a phone)

---name: client-facing-docsdescription: Writing client-facing technical documentation — architecture documents, proposals, project presentations — in plain language, jargon-free, with honest numbers and explicit pragmatic engineering principles. Use whenever the material will be read by a client or non-technical stakeholder - architecture doc, kickoff presentation, proposal, delivery report or closing email.---# Client-facing documentationA document for a client is not a technical document with a nice cover. It is a different kind of writing.## Principles1. **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**Closing email (weekly/delivery):**- What was done (verifiable facts), what comes next, items pending on the client- Short: if it's longer than one screen, it became a report and nobody reads it## Checklist before sending any material- [ ] Numbers match the contract/execution plan- [ ] Team and roles verified- [ ] Jargon translated or eliminated- [ ] Scope limited to what was contracted- [ ] Rendering checked on the device the client will open it on (usually a phone)

Frequently asked questions