# General Document Generator

> Generate any Word (.docx) or Markdown document that doesn't fit one of the other specific documents in this suite (project overview, architecture document, HLD, ops & deployment guide, runbook, API docs, database design, release & maintenance guide). Use this for memos, proposals, reports, whitepapers, meeting notes, policy documents, one-pagers, letters, or any other ad hoc document request — anything where the person wants "a document," "a report," "a Word doc," "a memo," a write-up of something, or a document type not covered by the more specific skills. Follows the same underlying engine as the rest of the suite (the docx library, and Mermaid + mmdc for any diagrams) but without a fixed section schema — the structure is decided per document rather than hardcoded.

- Skill: `vedkathe/general-document-generator` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add vedkathe/general-document-generator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vedkathe/general-document-generator/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/general-document-generator

---


# General Document Generator

The other skills in this suite each produce one fixed, specific document
type with a predetermined section list. This one is the opposite: it handles
everything else, using the exact same underlying engine and conventions —
`docx_builder.js`, Mermaid + `mmdc` for diagrams, the same missing-information
discipline — but you decide the right structure for what's actually being
asked, because "any kind of document" can't have a fixed schema.

If the request actually matches one of the other seven documents (project
overview, architecture, HLD, ops & deployment, runbook, API docs, database
design, release & maintenance), use that skill instead — it'll do a better,
more thorough job than this general-purpose one for that specific case.

## Decide the document's weight

Pick a front-matter level and pass it to `buildDocument()` as `frontMatter`:

| Value | What you get | Use for |
|---|---|---|
| `"full"` | Cover page + version history + document approval + revision log + auto TOC | Anything that reads like a formal deliverable multiple people will review or sign off on — a policy, a formal proposal |
| `"minimal"` | Just a title page + auto TOC, no version/approval/revision tracking | Reports, whitepapers, longer internal docs that don't need sign-off machinery |
| `"none"` | No cover page or TOC at all — straight into a title heading and content | Memos, one-pagers, meeting notes, letters, anything short |

If it's not obvious which weight fits, a quick judgment call is fine — err
toward the lighter option unless something about the request (explicit
mention of approval, sign-off, formal review, multiple stakeholders) signals
otherwise. This is one of the few times in this suite worth a quick check
with the user if it's genuinely ambiguous, since it changes the whole shape
of the deliverable.

## Decide the structure

There's no section table to follow here — build headings the way a
professional writer would organize this specific document type:

- A **memo** typically needs: To/From/Date/Re, Purpose, Body, Action Items.
- A **proposal** typically needs: Problem, Proposed Solution, Cost/Timeline,
  Next Steps.
- A **report** typically needs: Executive Summary, Findings, Methodology
  (if relevant), Conclusion/Recommendations.
- A **whitepaper** typically needs: Introduction, Background, Analysis,
  Conclusion, References.

These are starting points, not rules — adapt to what's actually being asked.
If the person already gave you an outline, follow it. If the document is
going to be long and they haven't specified structure, propose a short
outline before writing the whole thing, so structural mistakes get caught
before you've drafted ten sections around the wrong shape.

Use `h1` for major sections, `h2`/`h3` for subsections — same rule as every
other skill in this suite: never fake a heading with bold text, it breaks the
Table of Contents and Word's Navigation Pane.

## 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"), and only when a diagram
actually helps this particular document (don't force one in just because the
capability exists). 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 needs no diagrams.

## Missing Information Policy

Never invent specifics you have no basis for — names, figures, dates,
quotes, technical details. Use `B.toBeCompleted("...")` for anything you
don't have real input for, explaining what's needed, and still write
everything else. This matters just as much for a casual memo as for a
formal report — a plausible-sounding fabricated detail is worse than an
honest gap either way.

## Output Format

Ask the user which output format they want, unless already specified in
this request — Word (`.docx`) or Markdown (`.md`):

- **Word document (.docx)** — follow "Using the builder" below.
- **Markdown (.md)** — write the file directly, no script needed:
  - Title as an `#` heading, subtitle (if any) as an italic line beneath it.
    Skip cover-page/version-history machinery entirely for `.md` regardless
    of what `frontMatter` level you'd have used for `.docx` — Markdown
    documents read start-to-finish, they don't need a title page.
  - Headings `#`/`##`/`###` matching the structure you chose above.
  - Tables as standard Markdown tables.
  - Diagrams: write the real Mermaid source in a fenced `mermaid` code block
    (GitHub, GitLab, Obsidian, and most modern viewers render these
    natively) — no rendering step needed. Fall back to a short blockquote
    only if you don't have enough concrete detail yet.
  - "To be completed" callout: `> ⚠️ **TO BE COMPLETED** — explanation`.

## Workflow

1. Figure out what's actually being asked — document type, formality level,
   structure. Ask a clarifying question only if genuinely ambiguous (see
   "Decide the document's weight" above); otherwise make a reasonable call
   and proceed.
2. Ask the output format (docx/md) unless already specified.
3. Draft the content using the builder functions below (or direct Markdown).
4. If diagrams are needed, render them first (see "Diagram Policy"), then
   assemble the final `sections` array with `B.diagramImage()` swapped in.
5. Build with `scripts/docx_builder.js`, or write the `.md` file directly.
6. Skip PDF conversion by default — the library is already tested and
   hardened. Only convert to PDF and view it if the user explicitly asks for
   visual verification, or something about this generation is unusual.
7. Save to `/mnt/user-data/outputs/<Document_Name>.docx` (or `.md`) and
   present it.

## Using the builder

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.

```javascript
const B = require("./scripts/docx_builder.js");

// Example: a short internal memo — no cover page, no TOC, straight to content
const sections = [
  B.h1("Purpose"),
  B.para("This memo proposes moving our weekly sync from Monday to Wednesday."),

  B.h1("Details"),
  ...B.bullets([
    "Monday syncs conflict with the leadership standup for 3 of 6 team members.",
    "Wednesday has no known conflicts for the current team.",
  ]),

  B.h1("Action Items"),
  B.table(["Owner", "Action", "Due"],
    [["Jane Doe", "Update recurring calendar invite", "Friday"]],
    [2400, 4800, 1800]),
];

await B.buildDocument("/mnt/user-data/outputs/Sync_Time_Change_Memo.docx", {
  docLabel: "Internal Memo",
  title: "Proposal: Move Weekly Sync to Wednesday",
  subtitle: "Engineering Team",
  frontMatter: "none",   // "full" and "minimal" also available — see above
  sections,
});
```

For `"full"` mode, also pass `versionHistory`, `approvers`, and
`revisionLog` — see any of the other seven skills' `SKILL.md` for that
pattern; it's identical here. `"minimal"` and `"none"` don't need those
fields at all.

Available functions: `h1`/`h2`/`h3`/`h4`, `para`, `bullets`, `table(headers,
rows, widths)`, `pageBreak`, `toBeCompleted(explanation)`,
`diagramPlaceholder({name, purpose, recommendedContent, notes})`,
`diagramImage(path, {caption})`, and `buildDocument(path, options)`.

## Success Criteria

The finished document should read like something a professional in the
relevant context would actually produce — right level of formality for what
was asked, a structure that makes sense for that document type, and no
fabricated specifics standing in for real information that wasn't provided.