# Project Overview Doc > Generate a professional Project Overview document as a formatted Word (.docx) file — business context, objectives, scope, stakeholders, and business workflow, written for a non-technical audience (product owners, management, new joiners). Use this whenever someone asks for a "project overview," "project charter," "business context document," or wants a one-stop document explaining what a project is and why it exists, separate from its technical architecture. Part of an enterprise handover documentation suite (see also: architecture-document, high-level-design, operations-deployment-guide, support-runbook, api-documentation, database-design, release-maintenance-guide) but fully usable standalone. - Skill: `vedkathe/project-overview-doc` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add vedkathe/project-overview-doc` - Raw SKILL.md: https://api.skillmd.com/api/skills/vedkathe/project-overview-doc/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: VedKathe (https://skillmd.com/u/vedkathe) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/vedkathe/project-overview-doc --- # Project Overview Document Generator Produce a single, professional `.docx` document that lets a non-technical reader (product owner, manager, new hire) understand what a project is, why it exists, and who's involved — with zero architecture or implementation detail. Technical readers get that from the companion `architecture-document` and `high-level-design` skills. ## Sections (in this order) Cover page, Version History, Document Approval, Revision Log, and the Table of Contents are inserted automatically by the builder — your `sections` array starts at "1. Project Overview". | # | Section | Content | Diagram? | |---|---|---|---| | 1 | Project Overview | 2-3 paragraph plain-language summary: what the system does, who uses it, why it exists | | | 2 | Business Objectives | Bullet list of business goals and how success is measured | | | 3 | Scope | `h2` subsections "In Scope" / "Out of Scope", each a bullet list | | | 4 | Assumptions | Bullet list of assumptions the project relies on | | | 5 | Constraints | Bullet list — technical, budget, timeline, regulatory | | | 6 | Stakeholders | Table: Name/Team, Role, Responsibility, Contact | | | 7 | Business Workflow | Narrative of the end-to-end business process | **Business Process Flow** diagram | | 8 | Appendix | Related documents, reference links (link to the other 7 handover documents if they exist) | | ## Diagram Policy **Applies to the `.docx` path only** — Markdown embeds Mermaid source directly instead of rendering anything (see "Output Format" below). Prefer a real Mermaid diagram — rendered via `mmdc` and embedded with `B.diagramImage()` — over `diagramPlaceholder()`, but only once you have concrete structure to draw (real names, not "TBD"). Read `references/diagram-generation.md` when you're actually about to render one — it has the full build order, the bundled config (`assets/mermaid-config.json`), the exact `mmdc` flags, and token-saving tips. Skip it entirely if this document ends up needing no diagrams. ## Missing Information Policy Never invent business objectives, stakeholders, or workflow details you have no basis for — a fabricated-but-plausible detail is worse than an honest gap. Use `toBeCompleted("...")` for any section you lack real input for, explaining what's needed, and still generate everything else. If the user has a codebase, README, or existing docs available, prefer pulling real content from those over asking them to recall everything from memory. ## Output Format Ask the user which output format they want, unless they've already said so in this request (e.g., "as a docx", "in markdown," "just give me an .md file") — a quick single-choice question is enough, don't block on it otherwise: - **Word document (.docx)** — the default assumption if the person hasn't specified and their context suggests a formal deliverable. Follow "Using the builder" below. - **Markdown (.md)** — no script needed, write the file directly. Use these conventions so it stays structurally equivalent to the docx version: - Front matter: instead of a cover page, open with the title as an `#` heading, the project name as an italic subtitle line, then a metadata table instead of separate Version History / Approval / Revision Log tables: ```markdown # Project Overview *Acme Order Platform* | Field | Value | |---|---| | Version | 0.1 | | Author | Jane Doe | | Date | 2026-07-19 | | Status | Draft | | Approved By | Jane Doe (Tech Lead) | ``` - Headings: `#`/`##`/`###`/`####` matching the same section levels used in the table above — don't flatten everything to one level, that's what keeps the document skimmable and consistent with the docx version. - Tables: standard Markdown tables. - Diagrams — unlike the `.docx` path, don't render or embed an image here. Write the actual Mermaid source directly in a fenced code block; GitHub, GitLab, Obsidian, and most modern Markdown viewers render `mermaid` code blocks natively, so this is a real diagram, not a placeholder: ````markdown ```mermaid flowchart TD A[Client] --> B[API Gateway] B --> C[Order Service] C --> D[(Database)] ``` ```` Only fall back to a text placeholder if you don't yet have concrete enough detail to draw something real (mirrors `toBeCompleted` above): ```markdown > 📊 **DIAGRAM PLACEHOLDER — TO BE COMPLETED** > Not enough detail yet to draw the System Architecture Diagram — need > the actual component names and how they connect. ``` - "To be completed" callout — same blockquote treatment: ```markdown > ⚠️ **TO BE COMPLETED** > Explanation of what input is needed to fill this in. ``` - Save as `Project_Overview.md` instead of `Project_Overview.docx`. ## Workflow Ask the output format first (see "Output Format" above). For Markdown, skip straight to writing the file using those conventions — the numbered steps below describe the `.docx` path. 1. Gather what's available: project name/description, business objectives, scope, stakeholders — ask if not already given, but don't block on it. 2. Draft each section as data using the builder functions below. 3. Build the `.docx` with `scripts/docx_builder.js`. 4. Skip PDF conversion by default — `docx_builder.js` is already tested and hardened (table widths and text alignment are enforced at the library level), so routine generations don't need a re-render just to confirm it worked. Only convert to PDF and view it if the user explicitly asks for visual verification, or if something about this generation is unusual (e.g., a new kind of content the library hasn't handled before, or a reported rendering problem). When you do need it: `soffice --headless --convert-to pdf .docx` (or `libreoffice --headless ...`), then `pdftoppm -jpeg -r 100 .pdf page` and view the images. 5. Save to `/mnt/user-data/outputs/Project_Overview.docx` (or `.md` if that's the chosen format) and present it. ## Using the builder (for the .docx path) This library requires the `docx` npm package. Before running any script, check it's available with `node -e "require('docx')"`; if that fails, install it with `npm install docx` in the working directory first — don't assume it's pre-installed, since that varies by environment. ```javascript const B = require("./scripts/docx_builder.js"); const sections = [ B.h1("1. Project Overview"), B.para("Acme Order Platform is an internal service that ..."), B.h1("2. Business Objectives"), ...B.bullets(["Reduce manual order-processing time by 40%", "..."]), B.h1("3. Scope"), B.h2("3.1 In Scope"), ...B.bullets(["Order intake and validation"]), B.h2("3.2 Out of Scope"), ...B.bullets(["Payment processing (handled by Acme Billing)"]), B.h1("6. Stakeholders"), B.table(["Name / Team", "Role", "Responsibility", "Contact"], [["Jane Doe", "Tech Lead", "Owns architecture decisions", "jane@acme.com"]], [2400, 2000, 3200, 1400]), B.h1("7. Business Workflow"), B.para("Orders flow from intake through validation, allocation, and dispatch."), // Prefer B.diagramImage(path, {caption}) with a real mmdc render when // possible (see "Diagram Policy" above) — diagramPlaceholder() is the fallback: B.diagramPlaceholder({ name: "Business Process Flow", purpose: "Show the end-to-end order lifecycle from placement to fulfillment.", recommendedContent: ["Customer", "Order Service", "Inventory Service", "Fulfillment"], }), ]; await B.buildDocument("/mnt/user-data/outputs/Project_Overview.docx", { docLabel: "Project Overview", title: "Project Overview", subtitle: "Acme Order Platform", versionHistory: [["0.1", "2026-07-19", "Jane Doe", "Initial draft"]], approvers: [["Jane Doe", "Tech Lead", "", ""]], revisionLog: [], sections, }); ``` Available functions: `h1`/`h2`/`h3`/`h4`, `para`, `bullets`, `table(headers, rows, widths)`, `pageBreak`, `toBeCompleted(explanation)`, `diagramPlaceholder({name, purpose, recommendedContent, notes})`, and `buildDocument(path, options)`. Always use the heading functions (not bold paragraphs) for section titles — Word builds the clickable Table of Contents and Navigation Pane from real heading styles. ## Success Criteria A product owner or new hire with zero technical background should finish this document understanding what the project is, why it matters to the business, and who to talk to — without needing any of the companion technical documents.