graph-easy
Create ASCII diagrams for markdown using graph-easy. TRIGGERS - ASCII diagram, graph-easy, architecture diagram, markdown diagram.
What this skill does
# Graph-Easy Diagram Skill
Create ASCII architecture diagrams for any GitHub Flavored Markdown file 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
- Adding diagrams to README files
- Design specification documentation
- Any GFM markdown file needing architecture visualization
- Creating flowcharts, pipelines, or system diagrams
- User mentions "diagram", "ASCII diagram", "graph-easy", or "architecture chart"
**NOT for ADRs** - Use `adr-graph-easy-architect` for Architecture Decision Records (includes ADR-specific patterns like 2-diagram requirement and before/after templates).
## Preflight Check
Ensure graph-easy is installed and functional before rendering. See [Preflight Check](./references/preflight-check.md) for the full layered installation guide (mise-first approach, macOS + Linux).
**Quick verify:**
```bash
echo "[Test] -> [OK]" | graph-easy &>/dev/null && echo "✓ graph-easy ready"
```
---
## DSL Quick Reference
Full syntax reference: [DSL Syntax](./references/dsl-syntax.md)
### Essentials
```
[Node] -> [Node] # Basic edge
[A] -- label --> [B] # Labeled edge
[A] <-> [B] # Bidirectional
( Group: [Node A] [Node B] ) # Container
[n] { label: "Display Name"; } # Custom label
```
### Mandatory Graph Attributes
```
graph { label: "Title"; flow: south; } # Top-to-bottom
graph { label: "Title"; flow: east; } # Left-to-right
```
- **Every diagram MUST have** `label:` with semantic emoji + title
- **Every diagram MUST have** explicit `flow:` direction
### Character Safety
| Location | Graphical Emojis | Unicode Symbols | ASCII Markers |
| ------------ | ---------------- | --------------- | ------------- |
| Inside nodes | NEVER | OK | ALWAYS safe |
| Graph label | SAFE | OK | OK |
ASCII markers: `[x]` `[+]` `[!]` `[OK]` `[>]` `[*]` `[~]` `[?]` `[=]`
### Node & Edge Styling
| Style | Syntax | Use For |
| ------------- | --------------------- | --------------------- |
| Rounded | `{ shape: rounded; }` | Start/end nodes |
| Double border | `{ border: double; }` | Critical/emphasis |
| Bold border | `{ border: bold; }` | Important nodes |
| Dotted border | `{ border: dotted; }` | Optional (GH caution) |
| Solid arrow | `->` / `<->` | Normal/happy path |
| Dotted arrow | `..>` | Conditional/alternate |
| Bold arrow | `==>` | Critical path |
---
## Common Patterns
See [Diagram Patterns](./references/diagram-patterns.md) for full examples (pipeline, multi-component, decision, grouped, bidirectional, layered architecture).
**Quick templates:**
```
# Pipeline (left-to-right)
graph { label: "Pipeline"; flow: east; }
[Input] -> [Process] -> [Output]
# Multi-component (top-down)
graph { label: "System"; flow: south; }
[Gateway] -> [Service A]
[Gateway] -> [Service B]
[Service A] -> [Database]
[Service B] -> [Database]
```
---
## Rendering
### Command (Platform-Aware)
```bash
# For GitHub markdown (RECOMMENDED) - renders as solid lines
graph-easy --as=ascii << 'EOF'
graph { flow: south; }
[A] -> [B] -> [C]
EOF
# For terminal/local viewing - prettier Unicode lines
graph-easy --as=boxart << 'EOF'
graph { flow: south; }
[A] -> [B] -> [C]
EOF
```
### Output Modes
| Mode | Command | When to Use |
| -------- | ------------- | --------------------------------------------------------------- |
| `ascii` | `--as=ascii` | **GitHub markdown** - `+--+` renders as solid lines everywhere |
| `boxart` | `--as=boxart` | **Terminal only** - `┌──┐` looks nice locally, dotted on GitHub |
**Why ASCII for GitHub?** GitHub renders Unicode box-drawing characters (`┌─┐│└─┘`) as dotted lines. Pure ASCII (`+---+`, `|`) renders correctly everywhere.
### Post-Generation Alignment Validation (Recommended)
After embedding, validate with: `Skill(doc-tools:ascii-diagram-validator)`
- Catches copy-paste alignment drift and font rendering issues
- Skip if diagram was just generated and not manually edited
---
## Embedding in Markdown
Full guide with GFM collapsible section syntax: [Embedding Guide](./references/embedding-guide.md)
**CRITICAL: Every diagram MUST include a `<details>` source block.** This is non-negotiable.
````markdown
## Architecture
```
+----------+ +----------+ +----------+
| Input | --> | Process | --> | Output |
+----------+ +----------+ +----------+
```
<details>
<summary>graph-easy source</summary>
```
graph { flow: east; }
[Input] -> [Process] -> [Output]
```
</details>
````
---
## Monospace-Safe Symbols
Full reference: [Monospace Symbols](./references/monospace-symbols.md)
Key markers: `[+]` Added | `[x]` Removed | `[*]` Changed | `[!]` Warning | `[>]` Active
---
## Graph Label (MANDATORY: EVERY diagram MUST have emoji + title)
**WARNING**: This is the most commonly forgotten requirement. Diagrams without labels are invalid.
### Correct Example
```
graph { label: "Deployment Pipeline"; flow: east; }
[Build] -> [Test] -> [Deploy]
```
### Anti-Pattern (INVALID - DO NOT DO THIS)
```
graph { flow: east; }
[Build] -> [Test] -> [Deploy]
```
**Why this is wrong**: Missing `label:` with emoji. Every diagram needs context at a glance.
---
## 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=ascii` for GitHub markdown (or `--as=boxart` for terminal only)
### Embedding (MUST have - non-negotiable)
- [ ] **`<details>` block with source** - EVERY diagram MUST have collapsible source code block
- [ ] Never commit a diagram without its reproducible source
### Post-Embedding Validation (Recommended)
- [ ] Run `ascii-diagram-validator` on the file after embedding diagram
- [ ] Especially important if diagram was manually edited after generation
### Node & Edge Styling
- [ ] Start/end: `{ shape: rounded; }` | Critical: `{ border: double; }` | Optional: `{ border: dotted; }`
- [ ] Main path: `->` | Conditional: `..>` | Critical: `==>` | Labels: 1-3 words
- [ ] NO graphical emojis inside nodes; emojis ONLY in `graph { label: "..."; }`
### Structure
- [ ] Groups `( Name: ... )` for 4+ related nodes
- [ ] Node IDs short, labels descriptive: `[db] { label: "PostgreSQL"; }`
- [ ] Max 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 MUST have `<details>` block with graph-easy DSL source
### Aesthetics
1. **Platform-appropriate output** - `--as=ascii` for GitHub, `--as=boxart` for terminal
2. **Readable labels** - multiline with `\n`, no truncation
3. **Clear flow** - direction matches natural reading (top-down or left-right)
4. **Consistent styling** - same border style = same semantic meaning throughout
### Comprehensiveness
1. **Edge semantics** - solid=normal, dotted=conditional, bold=critical
2. **Logical grouping** - related nodes in `( Group: ... )` containers
## Troubleshooting
| Issue | Cause | Solution |
| ------------------- | ------------------------ | ------------------------------------------------------ |
| `command not found` | graph-easy not installed Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.