adr-graph-easy-architect

ASCII architecture diagrams for ADRs via graph-easy. TRIGGERS - ADR diagram, architecture diagram, ASCII diagram.

29 stars

Best use case

adr-graph-easy-architect is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

ASCII architecture diagrams for ADRs via graph-easy. TRIGGERS - ADR diagram, architecture diagram, ASCII diagram.

Teams using adr-graph-easy-architect should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/adr-graph-easy-architect/SKILL.md --create-dirs "https://raw.githubusercontent.com/terrylica/cc-skills/main/plugins/itp/skills/adr-graph-easy-architect/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/adr-graph-easy-architect/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How adr-graph-easy-architect Compares

Feature / Agentadr-graph-easy-architectStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

ASCII architecture diagrams for ADRs via graph-easy. TRIGGERS - ADR diagram, architecture diagram, ASCII diagram.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# ADR Graph-Easy Architect

Create comprehensive ASCII architecture diagrams for Architecture Decision Records (ADRs) using graph-easy. Pure text output with automatic layout - no image rendering required.

> **Self-Evolving Skill**: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.

## When to Use This Skill

- Writing new ADR that involves architectural changes
- ADR describes migration, integration, or system changes
- User asks for visual representation of a decision
- Existing ADR diagram needs review or update

## Preflight Check

Ensure graph-easy is installed and functional before rendering diagrams.

Full setup instructions: [Preflight Setup](./references/preflight-setup.md)

**Quick verify:**

```bash
echo "[Test] -> [OK]" | graph-easy --as=boxart &>/dev/null && echo "✓ graph-easy ready"
```

---

## DSL Quick Reference

Full syntax with examples, node styling, edge styles, and emoji rules: [DSL Syntax Reference](./references/dsl-syntax.md)

### Essential Syntax

```
[Node]                          # Node
[A] -> [B]                      # Edge
[A] -- label --> [B]            # Labeled edge
[A] <-> [B]                     # Bidirectional
( Group: [Node A] [Node B] )    # Group/container
[id] { label: "Display"; }     # Custom label
```

### Flow Direction (MANDATORY)

```
graph { flow: south; }   # Top-to-bottom (architecture, decisions)
graph { flow: east; }    # Left-to-right (pipelines, sequences)
```

### Graph Label (MANDATORY: EVERY diagram MUST have emoji + title)

**WARNING**: This is the most commonly forgotten requirement. Diagrams without labels are invalid.

**Correct:**

```
graph { label: "🔄 Database Migration"; flow: south; }
[Old DB] -> [New DB]
```

**Anti-Pattern (INVALID):**

```
graph { flow: south; }
[Old DB] -> [New DB]
```

Missing `label:` with emoji. The preflight validator will **BLOCK** any ADR containing diagrams without `graph { label: "emoji ..."; }`.

### Emoji Selection (for graph labels ONLY - never inside nodes)

| Diagram Type       | Emoji | Diagram Type     | Emoji |
| ------------------ | ----- | ---------------- | ----- |
| Migration/Change   | 🔄    | Architecture     | 🏗️    |
| Deployment/Release | 🚀    | Network/API      | 🌐    |
| Data Flow          | 📊    | Storage/Database | 💾    |
| Security/Auth      | 🔐    | Monitoring       | 📡    |
| Error/Failure      | ⚠️    | Hook/Event       | 🪝    |
| Decision/Branch    | 🔀    | Before/After     | ⏮️/⏭️ |

### Node & Edge Styling Summary

| Style           | Syntax                | Use For               |
| --------------- | --------------------- | --------------------- |
| Rounded corners | `{ shape: rounded; }` | Start/end nodes       |
| Double border   | `{ border: double; }` | Critical/emphasis     |
| Bold border     | `{ border: bold; }`   | Important nodes       |
| Dotted border   | `{ border: dotted; }` | Optional/skippable    |
| Solid arrow     | `->`                  | Main/happy path       |
| Dotted arrow    | `..>`                 | Conditional/alternate |
| Bold arrow      | `==>`                 | Emphasized/critical   |
| Labeled edge    | `-- label -->`        | Annotated connections |

### Character Safety

- Graphical emojis INSIDE nodes: **NEVER** (breaks box alignment)
- Unicode symbols inside nodes (checkmark, cross, warning): **OK** (single-width)
- ASCII markers inside nodes ([x] [+] [!]): **ALWAYS safe**
- Graphical emojis in `graph { label: }`: **OK**

Full symbol reference: [Monospace-Safe Symbols](./references/monospace-symbols.md)

---

## Common Diagram Patterns

### Migration (Before -> After)

```
graph { flow: south; }
[Before] -- migrate --> [After]
```

### Multi-Component System

```
graph { flow: south; }
[A] -> [B] -> [C]
[B] -> [D]
```

### Pipeline (Left-to-Right)

```
graph { flow: east; }
[Input] -> [Process] -> [Output]
```

### Decision with Options

```
graph { flow: south; }
[Decision] -> [Option A]
[Decision] -> [Option B]
```

### Grouped Components

```
( Group:
  [Component 1]
  [Component 2]
)
[External] -> [Component 1]
```

### Bidirectional Flow

```
[Client] <-> [Server]
[Server] -> [Database]
```

More patterns by ADR type: [Diagram Examples](./references/diagram-examples.md)

---

## Rendering

### Command (MANDATORY: Always use boxart)

```bash
graph-easy --as=boxart << 'EOF'
graph { flow: south; }
[A] -> [B] -> [C]
EOF
```

**Never use** `--as=ascii` - it produces ugly `+--+` boxes instead of clean `┌──┐` lines.

### Validation Workflow

```bash
# 1. Write DSL to heredoc
# 2. Render with boxart
# 3. Review output
# 4. Iterate if needed
# 5. Copy final ASCII to ADR
```

---

## Embedding in ADR

Every rendered diagram MUST include a collapsible `<details>` block with graph-easy source. Full format guide and GFM syntax rules: [ADR Embedding Guide](./references/adr-embedding.md)

**Required format:**

````markdown
```
┌───────┐     ┌──────┐
│ Build │ --> │ Test │
└───────┘     └──────┘
```

<details>
<summary>graph-easy source</summary>

```
graph { label: "🚀 Pipeline"; flow: east; }
[Build] -> [Test]
```

</details>
````

**The `<details>` block is MANDATORY** - never embed a diagram without its source.

---

## Mandatory Checklist (Before Rendering)

### Graph-Level (MUST have)

- [ ] **`graph { label: "🚀 Title"; }`** - semantic emoji + title (MOST FORGOTTEN - check first!)
- [ ] `graph { flow: south; }` or `graph { flow: east; }` - explicit direction
- [ ] Command uses `--as=boxart` - NEVER `--as=ascii`

### Embedding (MUST have - non-negotiable)

- [ ] **`<details>` block with source** - EVERY diagram MUST have collapsible source code block
- [ ] Format: rendered diagram in ` ``` ` block, followed by `<details><summary>graph-easy source</summary>` with source
- [ ] Never commit a diagram without its reproducible source

### Node Styling (Visual hierarchy)

- [ ] Start/end nodes: `{ shape: rounded; }` - entry/exit points
- [ ] Critical/important nodes: `{ border: double; }` or `{ border: bold; }`
- [ ] Optional/skippable nodes: `{ border: dotted; }`
- [ ] Long labels use `\n` for multiline - max ~15 chars per line

### Edge Styling (Semantic meaning)

- [ ] Main/happy path: `->` solid arrow
- [ ] Conditional/alternate: `..>` dotted arrow
- [ ] Emphasized/critical: `==>` bold arrow
- [ ] Edge labels are SHORT (1-3 words): `-- YES -->`, `-- error -->`

### Character Safety (Alignment)

- [ ] NO graphical emojis inside nodes (break alignment)
- [ ] Unicode symbols OK inside nodes (single-width)
- [ ] ASCII markers ALWAYS safe ([x] [+] [!] [OK])
- [ ] Graphical emojis ONLY in `graph { label: "..."; }` title

### Structure (Organization)

- [ ] Groups `( Name: ... )` used for logical clustering when 4+ related nodes
- [ ] Node IDs short, labels descriptive: `[db] { label: "PostgreSQL"; }`
- [ ] No more than 7-10 nodes per diagram (split if larger)

## Success Criteria

### Correctness

1. **Parses without error** - graph-easy accepts the DSL
2. **Renders cleanly** - no misaligned boxes or broken lines
3. **Matches content** - all key elements from description represented
4. **Source preserved (MANDATORY)** - EVERY diagram has `<details>` block with source

### Aesthetics

1. **Uses boxart** - clean Unicode lines, not ASCII `+--+`
2. **Visual hierarchy** - start/end rounded, important bold/double, optional dotted
3. **Consistent styling** - same border style = same semantic meaning throughout
4. **Readable labels** - multiline with `\n`, no truncation
5. **Clear flow** - direction matches natural reading (top-down or left-right)

### Comprehensiveness

1. **Semantic emoji in title** - emoji chosen to match diagram purpose
2. **Legend if needed** - multiline title with `\n` for complex diagrams
3. **Edge semantics** - solid=normal, dotted=conditional, bold=critical
4. **Logical grouping** - related nodes in `( Group: ... )` containers

## Troubleshooting

| Issue               | Cause                    | Solution                                                                         |
| ------------------- | ------------------------ | -------------------------------------------------------------------------------- |
| `command not found` | graph-easy not installed | Run [preflight check](./references/preflight-setup.md)                           |
| Misaligned boxes    | Used `--as=ascii`        | Always use `--as=boxart`                                                         |
| Box border broken   | Graphical emoji in node  | Remove emojis from nodes, use [ASCII markers](./references/monospace-symbols.md) |
| Nodes overlap       | Too complex              | Split into multiple diagrams (max 7-10 nodes)                                    |
| Edge labels cut off | Label too long           | Shorten to 1-3 words                                                             |
| No title showing    | Wrong syntax             | Use `graph { label: "Title"; flow: south; }`                                     |
| Weird layout        | No flow direction        | Add `graph { flow: south; }` or `flow: east`                                     |
| Parse error         | Special chars in node    | Escape or simplify node names                                                    |

## Resources

- [Graph::Easy on CPAN](https://metacpan.org/dist/Graph-Easy)
- [Graph::Easy Manual](http://bloodgate.com/perl/graph/manual/)
- [Graph::Easy GitHub](https://github.com/ironcamel/Graph-Easy)


## Post-Execution Reflection

After this skill completes, check before closing:

1. **Did the command succeed?** — If not, fix the instruction or error table that caused the failure.
2. **Did parameters or output change?** — If the underlying tool's interface drifted, update Usage examples and Parameters table to match.
3. **Was a workaround needed?** — If you had to improvise (different flags, extra steps), update this SKILL.md so the next invocation doesn't need the same workaround.

Only update if the issue is real and reproducible — not speculative.

Related Skills

clickhouse-architect

29
from terrylica/cc-skills

ClickHouse schema design and optimization. TRIGGERS - ClickHouse schema, compression codecs, MergeTree, ORDER BY tuning, partition key.

skill-architecture

29
from terrylica/cc-skills

Create new skills, modify existing skills, and understand skill architecture. Use when users want to create a skill from scratch, learn YAML frontmatter standards, validate skill structure, understand progressive disclosure patterns, or choose between structural patterns (workflow, task, reference, capabilities, suite). Also use for troubleshooting skills that don't trigger correctly, optimizing skill descriptions, or learning best practices for writing effective skill instructions.

realtime-audio-architecture

29
from terrylica/cc-skills

Real-time audio playback patterns for macOS Apple Silicon. TRIGGERS - audio jitter, tts choppy, sounddevice, afplay jitter, audio architecture, playback glitch, GIL contention audio, launchd audio priority, wrong audio device, airpods, bluetooth audio, device switching.

graph-easy

29
from terrylica/cc-skills

Create ASCII diagrams for markdown using graph-easy. TRIGGERS - ASCII diagram, graph-easy, architecture diagram, markdown diagram.

ml-data-pipeline-architecture

29
from terrylica/cc-skills

Patterns for efficient ML data pipelines using Polars, Arrow, and ClickHouse. TRIGGERS - data pipeline, polars vs pandas, arrow format, clickhouse ml, efficient loading, zero-copy, memory optimization.

voice-quality-audition

29
from terrylica/cc-skills

Audition Kokoro TTS voices to compare quality and grade. TRIGGERS - audition voices, kokoro voices, voice comparison, tts voice, voice quality, compare voices.

settings-and-tuning

29
from terrylica/cc-skills

Configure TTS voices, speed, timeouts, queue depth, and bot settings. TRIGGERS - configure tts, change voice, tts speed, queue depth, tts timeout, bot config, tune settings, adjust parameters.

full-stack-bootstrap

29
from terrylica/cc-skills

One-time bootstrap for Kokoro TTS engine, Telegram bot, and BotFather setup. TRIGGERS - setup tts, install kokoro, botfather, bootstrap tts-tg-sync, configure telegram bot, full stack setup.

diagnostic-issue-resolver

29
from terrylica/cc-skills

Diagnose and resolve TTS and Telegram bot issues. TRIGGERS - tts not working, bot not responding, kokoro error, audio not playing, lock stuck, telegram bot troubleshoot, diagnose issue.

component-version-upgrade

29
from terrylica/cc-skills

Upgrade Kokoro model, bot dependencies, or TTS components. TRIGGERS - upgrade kokoro, update model, upgrade bot, update dependencies, version bump, component update.

clean-component-removal

29
from terrylica/cc-skills

Remove TTS and Telegram sync components cleanly. TRIGGERS - uninstall tts, remove telegram bot, uninstall kokoro, clean tts, teardown, component removal.

send-message

29
from terrylica/cc-skills

Use when user wants to send a text message on Telegram as their personal account via MTProto, text someone, or message a contact by username, phone, or chat ID.