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