You get:
- workflows that no one fully understands (black boxes)
- on-call engineers debugging blind (no docs, no diagrams)
- knowledge lost when team members leave
- duplicate workflows (someone rebuilt what already existed)
- hours spent tracing dependencies manually
But documentation can be generated:
- trigger: what starts this workflow?
- actions: what does it do, step by step?
- dependencies: what other workflows does it rely on?
- owners: who is responsible for maintenance?
- failure modes: how does it break?
Without documentation, workflows become unmaintainable.
This prompt generates complete documentation from workflow descriptions.
Assume the role of a technical documentation specialist who documents workflow systems.
Your task is to generate complete documentation for a set of workflows.
Generate:
1. SYSTEM OVERVIEW
- System name
- Purpose (one sentence)
- Business value (what problem it solves)
2. WORKFLOW INVENTORY
| Workflow ID | Name | Trigger | Owner | Criticality |
|-------------|------|---------|-------|-------------|
| WF-001 | [name] | [trigger] | [person/team] | High/Med/Low |
3. PER-WORKFLOW DOCUMENTATION
**Workflow: [WF-001 - Name]**
- **Purpose:** [what this workflow does]
- **Trigger:** [how it starts]
- **Input data:** [what data it needs]
- **Steps:**
1. [Step 1 description]
2. [Step 2 description]
3. [Step 3 description]
- **Output data:** [what data it produces]
- **Dependencies:** [other workflows it relies on]
- **Failure modes:** [how it breaks, what to check]
- **Owner:** [who to contact]
- **Run frequency:** [X times per day/week/month]
- **Average duration:** [X seconds/minutes]
4. DEPENDENCY DIAGRAM (text-based)
WF-001 (Lead Capture) → WF-002 (Lead Scoring) → WF-003 (Lead Routing)
↘ WF-004 (Reporting)
5. RUNBOOK LINKS
- On-call runbook: [link]
- Recovery procedures: [link]
- Escalation contacts: [list]
6. LAST REVIEW DATE & NEXT REVIEW
- Last documented: [date]
- Next review due: [date]
INPUTS:
Workflow descriptions (from your existing automations):
[PASTE DESCRIPTIONS OF EACH WORKFLOW]
Team structure (who owns what):
[PASTE TEAM AND OWNER INFORMATION]
Known failure modes (from experience):
[PASTE COMMON FAILURES]
RULES:
- Document one workflow at a time (prevents information overload)
- Keep descriptions concise (future you will thank you)
- Link to runbooks, don't embed them (maintainability)
- Assign explicit owners (no orphaned workflows)
- Review documentation quarterly (workflows change)
- Include failure modes (document how things break, not just how they work)
- Document one workflow at a time — prevents information overload and missed details.
- Keep descriptions concise — future you and new team members will appreciate clarity.
- Link to runbooks, don’t embed them — maintains single source of truth.
- Assign explicit owners to every workflow — no orphaned automations.
- Review documentation quarterly — workflows change faster than you think.
- Include failure modes — document how things break, not just how they work.
Workflow descriptions:
“WF-001: Lead Capture — when Typeform submission received, create lead in Salesforce. WF-002: Lead Scoring — when lead created, calculate score based on industry and company size. WF-003: Lead Routing — when score calculated, assign to sales rep. WF-004: Reporting — daily at 9am, aggregate lead data and email to sales ops.”
Team structure:
“Sales Ops owns WF-001, WF-002, WF-003, WF-004. Primary owner: Jane (Sales Ops Manager).”
Known failure modes:
“WF-003 fails when no rep available for territory (unassigned leads). Manual fallback: assign to manager.”
This framework improves outcomes by forcing:
- system overview (what does this system do?)
- workflow inventory (what workflows exist?)
- per-workflow details (how does each one work?)
- dependency mapping (what relies on what?)
- owner assignment (who is responsible?)
Failure modes this prevents:
- Lost knowledge — original builder leaves, no documentation remains
- Duplicate workflows — team rebuilds what already exists
- Blind debugging — on-call engineer has no idea where to start
- No ownership — broken workflow, no one responsible
This improves on: Tribal knowledge and memory-dependent operations. Documentation creates institutional memory.
Related to: WS-02 (Dependency Mapper) for cross-workflow relationships; WS-06 (Dashboard) for health monitoring.
Build Better AI Systems
Subscribe for advanced prompt engineering, AI coding tools, debugging frameworks, and practical strategies for developers and engineers.