Application Summary Generator

Application Summary Generator

Produce a single .docx (or .md) document, roughly 5-6 pages, that lets a non-technical person — an executive, a salesperson, a new hire, a partner — understand what an existing application does and why it matters, without touching any code or technical jargon. This is a business communication artifact, not a technical specification. If you find yourself writing about frameworks, databases, or API endpoints, you've drifted into the wrong audience — that detail belongs in this suite's architecture-document or api-documentation-doc skills instead.

Discovery order — where the content comes from

Follow this order; don't jump straight to codebase archaeology if better sources already exist:

1. User-provided documentation first. If the person has already shared a README, PRD, pitch deck, wiki export, or just described the app in chat, that's the primary source — it reflects intent, which is more reliable than what you can infer from code alone.
2. The codebase itself, if no documentation exists or it's incomplete. Look for, roughly in this order:
   • README.md and any docs/ folder — often has exactly what's needed
   • Package manifests (package.json, pyproject.toml, Cargo.toml, pom.xml) — name/description plus dependencies hint at both purpose and integrations (a Stripe dependency + checkout routes means payment processing; a Twilio dependency means SMS/calling)
   • Entry points and routing (routes/, controllers/, api/, pages/, or the framework's equivalent) — route and page names describe user-facing features better than almost anything else in a repo
   • Data models/schema — entity names describe the business domain (a Shipment, Invoice, and Carrier model strongly implies logistics)
   • Config/environment variable names — often reveal integrations not obvious from the code itself
   • Any architecture diagrams, ADRs, or design docs already in the repo
3. Your own judgment, to interpret what you find. Recognizing that Stripe + Twilio + a Shipment model likely means "e-commerce with SMS delivery notifications" is exactly the inference this skill needs — translate dependencies and structure into capabilities a business reader would recognize, don't just list them.

Note in the appendix which sources you actually consulted (README, specific files/folders, or "the person's description in chat") — this lets the reader judge how much to trust any given claim.

Suggested structure (5-6 pages — adjust to what you actually find)

No fixed section schema, but this is what typically fills 5-6 pages at the right level of detail:

1. Executive Summary — 2-3 sentences: what this is and who it's for.
2. What It Does — the core purpose and problem it solves, in plain language, no jargon.
3. Who It's For — the target users/customers and how they interact with it.
4. Key Capabilities — a bulleted list described in outcome terms ("lets customers track shipments in real time"), never implementation terms ("polls a carrier API every 60 seconds").
5. How It Creates Value — why this matters to the business — time saved, revenue enabled, risk reduced — whatever's actually evidenced.
6. How It Works — one plain-language paragraph, optionally paired with a single simple conceptual diagram (see below). Not an architecture walkthrough.
7. Current Status — version, activity level, or maturity, if discoverable (recent commits, changelog, version number).
8. Appendix: Sources Consulted — what you actually looked at.

Diagrams — optional, and simple only

Most application summaries don't need one. If a single conceptual diagram would genuinely help a business reader picture the product (e.g., a simple "customer → app → outcome" flow), it's fine to include exactly one, kept deliberately simple — no sequence diagrams, ER diagrams, or technical labels. If you do render one, follow this suite's usual Mermaid + mmdc process: see references/diagram-generation.md and assets/mermaid-config.json. Skip this entirely rather than force in a diagram that doesn't add anything.

Missing Information Policy

Business-value and impact claims need real evidence — a discovered feature, an integration, a stated goal in provided docs — not invention. If something a good summary would normally cover isn't discoverable (user counts, revenue impact, market position), say so plainly: "usage and business metrics weren't available in the codebase or provided materials" reads as honest; a fabricated number is actively misleading in a document meant to inform business decisions. Capability claims inferred from code (routes, models, dependencies) are fine to state directly — that evidenced kind of inference is exactly what this skill is for.

Output Format

Ask which format the user wants (Word or Markdown) unless already specified — same convention as the rest of this suite. Default to frontMatter: "minimal" for the .docx path (title page + auto TOC, no version history/approval/sign-off tables) — this is a communication document, not a formal deliverable needing sign-off machinery. For Markdown, skip the title page too and just open with an # heading.

Workflow

1. Establish what's available: ask if the user has documentation to share, or a codebase/repo to inspect, if neither has been provided yet.
2. Work through the Discovery order above — docs first, then codebase, applying judgment to translate findings into business language.
3. Draft the 5-6 page structure above, adapting emphasis to what you actually found (e.g., skip "Current Status" if there's nothing to draw on for it).
4. If a single simple diagram would help, render it (see "Diagrams" above); otherwise skip that step entirely.
5. Build with scripts/docx_builder.js (or write Markdown directly).
6. Skip PDF conversion by default — only verify visually if asked, or if something is unusual.
7. Save to /mnt/user-data/outputs/<Application_Name>_Summary.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 first.

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

const sections = [
  B.h1("Executive Summary"),
  B.para("Acme Order Platform is an internal system that lets warehouse staff manage incoming orders and coordinate fulfillment across three regional warehouses."),

  B.h1("What It Does"),
  B.para("..."),

  B.h1("Key Capabilities"),
  ...B.bullets([
    "Real-time inventory visibility across all warehouses",
    "Automated order routing to the nearest warehouse with stock",
  ]),

  B.h1("Appendix: Sources Consulted"),
  ...B.bullets([
    "README.md",
    "package.json (dependencies: stripe, twilio, pg)",
    "src/routes/ (order, inventory, fulfillment endpoints)",
    "src/models/ (Order, Shipment, Warehouse, Customer)",
  ]),
];

await B.buildDocument("/mnt/user-data/outputs/Acme_Order_Platform_Summary.docx", {
  docLabel: "Application Summary",
  title: "Acme Order Platform — Application Summary",
  subtitle: "Prepared for business stakeholders",
  frontMatter: "minimal",
  sections,
});

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

A non-technical reader — someone who has never seen the code and doesn't want to — should finish this document understanding what the application does, who it serves, and why it matters to the business, in roughly the time it takes to read 5-6 pages, with no fabricated claims they'd be embarrassed to repeat in a meeting.