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:

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.

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.