Generate a process description document as a downloadable PDF from a detected pattern
Pattern to PDF
Generate a shareable process briefing from a detected pattern or user-described workflow — a visual process map, step-by-step walkthrough, occurrence stats, and improvement opportunities. Output is a downloadable PDF.
The Goal
A PDD is a process briefing document — not a corporate BPM artifact with swim lanes and BPMN notation. It's the document you wish existed when you joined a team: "here's how we actually do X, step by step, with the apps involved, how long it takes, and what varies each time."
The pattern-detector finds that a process exists. The PDD describes how it works — with enough detail that someone unfamiliar could follow it, and enough structure to spot what's automatable.
Pattern Detector output:
"Client Onboarding" — Email → CRM → billing → welcome email,
3-4x/week, ~20 min each
↓ PDD Generator
Process Description Document:
Executive summary — what, why, how often, how long
At a Glance — stats bar with key metrics
Process Map — visual flowchart showing each step
Steps — numbered walkthrough with apps, actions, variations
Opportunity — biggest time sink + concrete automation suggestion
Instructions
Step 1 — Identify the Process
Determine which process to document:
If the user names a specific pattern (e.g., from a previous /discover-patterns run), use that as the starting point.
If the user describes a process vaguely ("the thing I do with invoices"), ask a clarifying question to get the key apps and actions involved.
If nothing is specified, ask: "Which process would you like me to document? Name it or describe the key apps/steps and I'll find it in your activity."
Step 2 — Search for Instances
Cast a wide net across 30 days:
search_context(query="<process description + key apps>", startTime="30 days ago", endTime="now", limit=30)
Use the pattern name, key apps, and distinguishing actions as search terms. Try 2–3 query variations if the first returns sparse results (e.g., search by app name, then by action description, then by output artifact).
Step 3 — Cluster into Occurrences
Group returned activities by date proximity — activities within 60 minutes of each other likely belong to the same occurrence. Count distinct occurrences and note their date ranges.
If 5+ occurrences: excellent — pick the 3–5 clearest for deep dive.
If 3–4 occurrences: sufficient — deep dive all of them.
Reconstruct the process sequence from surrounding context.
If still fewer than 2 clear instances after fallback, tell the user there isn't enough data to produce a reliable document. Suggest they try again after performing the process a few more times with MemoryLane running.
Step 6 — Synthesize
Cross-reference all deep-dived instances to build:
Canonical step sequence — steps that appear consistently across instances
Variations — what changes between instances
Decision points — where the process branches
Timing — average duration overall and per step (from timestamps)
Opportunity — biggest time sink and what's automatable
Step 7 — Render as PDF
Use the HTML Template below to produce the final document. Include:
Header with process name and scan metadata
Executive summary — 3–4 sentences
At a Glance stats — frequency, duration, apps, last seen, instances
Process map — vertical flowchart using the node types below (solid for constant steps, dashed for variable, distinct color for decisions)
Steps table — numbered walkthrough with app, action, and what varies
Opportunity section — time sink, automatable parts, concrete suggestion
Footer with methodology note
Convert to PDF:
Wrap the filled-in HTML template in a full HTML document:
<!DOCTYPE html><html><head><metacharset="utf-8" /><style>@page {
margin: 24px;
}
body {
margin: 0;
padding: 24px;
}
@media print {
body {
-webkit-print-color-adjust: exact;
print-color-adjust: exact;
}
}
</style></head><body><!-- filled-in template HTML here --></body></html>
Write to /tmp/pdd-temp.html using the Write tool.
Convert to PDF using Bash — use a slugified version of the process name (e.g., "Client Onboarding" → client-onboarding-pdd.pdf):
Replace all {placeholders} with actual data. Step 7 handles wrapping this in a full HTML document and converting to PDF — this template is just the body content.
Executive summary: "Client onboarding is a 5-step process that sets up new clients in the company's systems. It runs 3–4 times per week, triggered by a signed contract arriving via email. Average duration is 20 minutes. The process touches Gmail, HubSpot CRM, Stripe billing, and Gmail again for the welcome email."
Process map: 5 nodes — (1) Gmail: Open signed contract email → (2) HubSpot: Create contact with company details [variable: client name, company, address] → (3) HubSpot: Add deal and set stage to "Won" → (4) Stripe: Create customer and subscription [variable: plan type, billing amount] → (5) Gmail: Send welcome email template [variable: recipient, personalized greeting]
Decision branch: None observed — process is linear across all instances.
Opportunity: Steps 2–4 are data entry of the same information into three systems. An intake form → API integration could eliminate 15 of the 20 minutes.
Example 2: Weekly Revenue Report
Input pattern: "Revenue reporting — Stripe → Google Sheets → formulas → Slack, every Monday, ~35 min"
Expected PDD structure:
Executive summary: "The weekly revenue report aggregates Stripe payment data into a formatted summary shared with the finance team via Slack. It runs every Monday morning, takes approximately 35 minutes, and involves Stripe dashboard, Google Sheets, and Slack."
Process map: 6 nodes — (1) Stripe: Export last 7 days of payments as CSV → (2) Sheets: Import CSV into "Weekly Revenue" tab [constant: same spreadsheet] → (3) Sheets: Update date range in summary formulas → (4) Sheets: Review computed totals, check for anomalies [variable: time spent varies 2–15 min depending on discrepancies] → (5) Sheets: Screenshot summary table → (6) Slack: Post screenshot + commentary to #finance [variable: commentary text]
Decision branch: After step 4 — "Discrepancy found?" → Yes: investigate in Stripe (adds 10–20 min) → No: continue to step 5.
Opportunity: Steps 1–3 are fully automatable via Stripe API → Sheets API. A scheduled script could have the spreadsheet pre-populated by Monday morning, reducing the process to review + post (~10 min).
Example 3: Expense Approval Batch
Input pattern: "Expense review — PDF open → policy check in browser → approve/reject in expense tool, 10-15 per batch, twice a week"
Expected PDD structure:
Executive summary: "Expense approval processes 10–15 expense reports in a single sitting. It runs twice per week (typically Tuesday and Thursday), taking 30–45 minutes per batch. Each report involves reviewing the PDF, checking line items against company policy, and recording the decision."
Process map: 4 nodes per report, wrapped in a "Repeat for each report" annotation — (1) Expense tool: Open next pending report → (2) Preview: Review PDF receipt/invoice [variable: vendor, amount, category] → (3) Browser: Check expense policy for category limits [variable: policy section checked] → (4) Expense tool: Approve or reject with notes [decision: "Within policy?" → Yes: approve → No: reject with reason]
Decision branch: After step 3 — "Within policy limits?" → Yes: approve → No: reject with policy citation.
Opportunity: Step 3 (policy lookup) is the bottleneck — different policy sections for different expense categories. A pre-check script that flags policy violations before human review would eliminate the manual lookup for ~80% of reports.
Notes
Minimum data threshold — need at least 2 clear instances to produce a document. Below that, tell the user.
Privacy — summaries are the primary data source. Only use get_activity_details for the deep-dive step. Never reproduce raw OCR in the output.
Scope — one document per process. If the user wants multiple processes documented, run this skill once per process.
