# Application Summary Generator

> Generate a 5-6 page business-facing summary of an existing application or codebase — what it does, who it's for, key capabilities, and its business value — written for non-technical stakeholders (executives, sales, new hires, partners), not developers. Use this when someone wants to understand "what does this app/product do" without wading through code, wants a business overview of an existing system, or asks to "summarize this codebase/application for business use," "explain what this app does," or similar. Discovers the app's purpose by checking any user-provided documentation first, then the codebase itself (README, package manifests, routes, models, config) — never invents business claims that aren't evidenced. Distinct from project-overview-doc (which documents a project via interview, for a handover) — this one reverse-engineers an existing, possibly-undocumented app. Part of the enterprise handover documentation suite but fully usable standalone.

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

```javascript
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.