# Ascii Flow

> Creates terminal-friendly ASCII tree diagrams from real code flow for functions, methods, handlers, and endpoints. Use when the user asks to explain, visualize, map, or document code flow, or mentions "tree diagram", "flow tree", "ascii flow", or wants a simpler alternative to sequence diagrams.

- Skill: `muhammadrivaldy/ascii-flow` (Agent Skill)
- Install (CLI): `npx skillmds@latest add muhammadrivaldy/ascii-flow`
- Raw SKILL.md: https://api.skillmd.com/api/skills/muhammadrivaldy/ascii-flow/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: muhammadrivaldy (https://skillmd.com/u/muhammadrivaldy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/muhammadrivaldy/ascii-flow

---


# ASCII Flow

Create readable ASCII tree diagrams from real code flow — terminal-friendly, plain-text, scannable top to bottom.

## Goal

Help the reader understand the full flow of a function, method, handler, or endpoint:

- what starts the flow
- what validation or checks happen
- what important data lookups happen
- what meaningful decisions happen
- what external or persistent interactions happen
- what side effects happen
- what success or failure outcomes matter

## When to Use

Use this skill when the user asks to:

- explain a function or method as a tree diagram
- document an endpoint or handler flow
- map controller, service, repository, or workflow logic
- get a terminal-friendly code flow overview
- understand the end-to-end flow of a request or process

This skill is language-agnostic.

## Core Rules

- Read the real code first.
- Read important helpers that materially affect the flow.
- Show the full meaningful flow — simplified but faithful.
- Prefer readability over literal code structure.
- Prefer plain-English action labels over implementation names.
- Keep the diagram useful to technical and non-technical readers alike.
- Avoid low-level implementation noise unless it changes the story.

## Tree Format Rules

Each line has: `indicator + step + description`.

```
UploadFunctionName
│
├── 1. Step name                         Description of what happens
│     └── error → return 4xx
│
├── 2. Group step                        Parent grouping
│     ├── 2a. Sub-step                   → External service
│     ├── 2b. Sub-step
│     └── 2c. Sub-step
│           └── error → return 5xx
│
└── 3. Final step                        Side effect or return
```

- `├──` for non-final siblings, `└──` for last item
- `│` for continuation lines inside groups
- Sequential numbering (1., 2., 3.) — easy to reference
- Number sub-steps as 2a, 2b, 2c when grouping
- Comments inline: function name on left, plain intent on right
- Error paths: `└── error → return <status>` indented under the step that can fail
- Inline `→` to show targets: `Validate HS codes → MDM`
- Use blank lines between major phases for readability

## Flow Extraction Rules

Keep these:

- validation and authentication checks
- important data loads and lookups
- meaningful grouping or decision points
- external service calls (MDM, API, etc.)
- persistence (DB transactions, bulk inserts)
- side effects that matter (Redis updates, events)
- final success and failure outcomes

Omit these:

- local variable setup
- formatting and tiny conversions
- cache writes not important to the reader
- repeated loops unless they change understanding
- helper nesting that does not change the story

## Workflow

1. Identify the function, method, handler, or endpoint.
2. Read the full main function body.
3. Read helpers that materially affect: validation, branching, lookup, persistence, external calls, side effects.
4. Extract the real flow — responsibilities, not line numbers.
5. Reduce technical noise — keep only what changes the story.
6. Write the tree top to bottom — linear, scannable, with grouped sub-steps.
7. Return a short preface, then the fenced ASCII tree.

## Output Format

Before the diagram, briefly state:

- function or method found (file:line)
- important helpers read
- participants or external services in the flow

Then return one fenced `text` code block containing the final ASCII tree.

## Preferred Writing Style

Good lines:

- `Bind and parse JSON payload`
- `Load account configuration`
- `Check shipment count against limit`
- `Run struct-level validation`
- `Insert shipment records → returns IDs`
- `Bulk insert senders`
- `Update Redis shipment summary`
- `Return 200 with shipment IDs and count`

Avoid:

- code-shaped lines with raw variable names
- stack-trace style listing
- internal framework context manipulation

## Final Check

Before returning, confirm:

- the target function was read
- important helpers were inspected
- the full meaningful flow is present
- readable for technical and non-technical readers
- tree format follows the conventions above
- simplified but still faithful to the real code
- wording is plain and clear