Engineering
Commit message from a diff
Write a commit message from a diff: a subject line that states what was found, then prose explaining why the change was made.
Add in the app
Engineering · For your bots
Architecture diagram
Draw how a system fits together -- components, data flow, a request's path, a data model -- as a Mermaid diagram with a short note on what it shows.
In Lobstack: Skills › Library › Add
Download LobstackWhen to use it
Someone asks how a system works, wants a diagram for docs or a design review, or is about to change how parts connect.
What your bot will do
- 01
Read the code and config before drawing: entry points, services, queues, stores, external APIs, and how they call each other. Draw what is there.
- 02
Pick one question per diagram: what the parts are (flowchart LR with subgraphs per boundary), how one request flows (sequenceDiagram), or how data is shaped (erDiagram).
- 03
Keep it to five to fifteen nodes with two or three word labels. Put protocols or payloads on the arrows, not in the boxes.
- 04
Post it with post_diagram, then a short post_document: what each part owns, where the risks and single points of failure are, and the file each claim came from.
- 05
For a proposed change, draw the before and the after as two diagrams.
Never commit a diagram to a repository or wiki without asking.
The file
---name: architecture-diagramdescription: "Draw how a system fits together -- components, data flow, a request's path, a data model -- as a Mermaid diagram with a short note on what it shows."metadata: title: "Architecture diagram" category: engineering tags: [architecture, diagrams, docs]--- ## When to use this Someone asks how a system works, wants a diagram for docs or a design review, oris about to change how parts connect. ## How 1. Read the code and config before drawing: entry points, services, queues, stores, external APIs, and how they call each other. Draw what is there.2. Pick one question per diagram: what the parts are (flowchart LR with subgraphs per boundary), how one request flows (sequenceDiagram), or how data is shaped (erDiagram).3. Keep it to five to fifteen nodes with two or three word labels. Put protocols or payloads on the arrows, not in the boxes.4. Post it with post_diagram, then a short post_document: what each part owns, where the risks and single points of failure are, and the file each claim came from.5. For a proposed change, draw the before and the after as two diagrams. Never commit a diagram to a repository or wiki without asking.