Skill-Details
process-documentation
Creates structured documentation for business processes only.
Vor Nutzung prüfen
Die automatische Prüfung bewertet Relevanz, nicht Sicherheit oder Empfehlung. Lies vor der Nutzung die Quellanweisungen.
SKILL.md
Dieser Auszug wurde bei der Prüfung gespeichert. Die externe Quelle enthält die vollständige und aktuelle Version.
--- name: process-documentation description: "Document any business process in a clear, structured format. Use when asked to document a process, write a process guide, create a workflow document, or map out how something works. Produces a complete process document with steps, roles, inputs, outputs, and edge cases." --- # Process Documentation Skill Produces clear, structured process documentation that someone new to a role can follow without needing to ask questions. ## Required Inputs - **Process name** - **Process description** (rough notes are fine) - **Who does this process** (roles involved) - **How often it runs** (daily / weekly / monthly / event-triggered) - **Tools involved** - **Known edge cases** ## Output Structure --- # Process: [Process Name] **Owner:** [Role] | **Frequency:** [How often] | **Estimated time:** [Duration] --- ### Purpose [1-2 sentences. Why does this process exist? What breaks if it is not done?] ### Scope **In scope:** [What this covers] **Out of scope:** [What it does not cover] ### Prerequisites - [ ] [Required access or information] - [ ] [Any dependency that must be completed first] --- ### Roles and Responsibilities | Role | Responsibility | |---|---| | [Role 1] | [What they do] | --- ### Process Steps **Step 1: [Step name]** - **Who:** [Role] - **When:** [Trigger or timing] - **How:** [Substeps numbered] - **Output:** [What exists at end of this step] - **Tool:** [System used] [Continue for all steps] --- ### Edge Cases and Exceptions | Situation | What to do | Who to contact | |---|---|---| | [Edge case] | [Action] | [Name/role] | --- ### Common Mistakes [2-4 things people get wrong the first time] ### Escalation Path [Name/role] → [Next level] → [Final escalation] ### Review Next review due: [Date] ## Quality Checks - [ ] Every step has a named role (not "someone" or "the team") - [ ] Edge cases and exceptions table is complete - [ ] Prerequisites are listed so someone new can prepare before starting - [ ] Escalation path is named (specific people or roles, not just "your manager") - [ ] Review date is set ## Anti-Patterns - [ ] Do not write steps without specifying who is responsible for each — ownership must be explicit throughout - [ ] Do not omit the escalation path — every process must say what happens when something goes wrong - [ ] Do not document the ideal process if the real process differs — document reality, then note improvements separately - [ ] Do not skip edge cases and exceptions — they are where most process failures actually occur - [ ] Do not produce documentation without a review date — undated process docs quickly become incorrect ## Example Trigger Phrases - "Document this process: [description]" - "Write a process guide for [workflow]" - "Map out how [process] works"Vollständige Quelle auf GitHub lesen (öffnet externe Seite)