@saibolla/ada 0.1.2

package/skills/markdown-mermaid-writing/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: markdown-mermaid-writing
+description: Comprehensive markdown and Mermaid diagram writing skill. Use when creating any scientific document, report, analysis, or visualization. Establishes text-based diagrams as the default documentation standard with full style guides (markdown + mermaid), 24 diagram type references, and 9 document templates.
+allowed-tools: Read Write Edit Bash
+license: Apache-2.0
+metadata:
+  skill-author: Clayton Young / Superior Byte Works, LLC (@borealBytes)
+  skill-source: https://github.com/SuperiorByteWorks-LLC/agent-project
+  skill-version: "1.0.0"
+  skill-contributors:
+    - name: Clayton Young
+      org: Superior Byte Works, LLC / @borealBytes
+      role: Author and originator
+    - name: K-Dense Team
+      org: K-Dense Inc.
+      role: Integration target and community feedback
+---
+
+# Markdown and Mermaid Writing
+
+## Overview
+
+This skill teaches you — and enforces a standard for — creating scientific documentation
+using **markdown with embedded Mermaid diagrams as the default and canonical format**.
+
+The core bet: a relationship expressed as a Mermaid diagram inside a `.md` file is more
+valuable than any image. It is text, so it diffs cleanly in git. It requires no build step.
+It renders natively on GitHub, GitLab, Notion, VS Code, and any markdown viewer. It uses
+fewer tokens than a prose description of the same relationship. And it can always be
+converted to a polished image later — but the text version remains the source of truth.
+
+> "The more you get your reports and files in .md in just regular text, which mermaid is
+> as well as being a simple 'script language'. This just helps with any downstream rendering
+> and especially AI generated images (using mermaid instead of just long form text to
+> describe relationships < tokens). Additionally mermaid can render along with markdown for
+> easy use almost anywhere by humans or AI."
+>
+> — Clayton Young (@borealBytes), K-Dense Discord, 2026-02-19
+
+## When to Use This Skill
+
+Use this skill when:
+
+- Creating **any scientific document** — reports, analyses, manuscripts, methods sections
+- Writing **any documentation** — READMEs, how-tos, decision records, project docs
+- Producing **any diagram** — workflows, data pipelines, architectures, timelines, relationships
+- Generating **any output that will be version-controlled** — if it's going into git, it should be markdown
+- Working with **any other skill** — this skill defines the documentation layer that wraps every other output
+- Someone asks you to "add a diagram" or "visualize the relationship" — Mermaid first, always
+
+Do NOT start with Python matplotlib, seaborn, or AI image generation for structural or relational diagrams.
+Those are Phase 2 and Phase 3 — only used when Mermaid cannot express what's needed (e.g., scatter plots with real data, photorealistic images).
+
+## 🎨 The Source Format Philosophy
+
+### Why text-based diagrams win
+
+| What matters | Mermaid in Markdown | Python / AI Image |
+| ----------------------------- | :-----------------: | :---------------: |
+| Git diff readable | ✅ | ❌ binary blob |
+| Editable without regenerating | ✅ | ❌ |
+| Token efficient vs. prose | ✅ smaller | ❌ larger |
+| Renders without a build step | ✅ | ❌ needs hosting |
+| Parseable by AI without vision | ✅ | ❌ |
+| Works in GitHub / GitLab / Notion | ✅ | ⚠️ if hosted |
+| Accessible (screen readers) | ✅ accTitle/accDescr | ⚠️ needs alt text |
+| Convertible to image later | ✅ anytime | — already image |
+
+### The three-phase workflow
+
+```mermaid
+flowchart LR
+    accTitle: Three-Phase Documentation Workflow
+    accDescr: Phase 1 Mermaid in markdown is always required and is the source of truth. Phases 2 and 3 are optional downstream conversions for polished output.
+
+    p1["📄 Phase 1<br/>Mermaid in Markdown<br/>(ALWAYS — source of truth)"]
+    p2["🐍 Phase 2<br/>Python Generated<br/>(optional — data charts)"]
+    p3["🎨 Phase 3<br/>AI Generated Visuals<br/>(optional — polish)"]
+    out["📊 Final Deliverable"]
+
+    p1 --> out
+    p1 -.->|"when needed"| p2
+    p1 -.->|"when needed"| p3
+    p2 --> out
+    p3 --> out
+
+    classDef required fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
+    classDef optional fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
+    classDef output fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d
+
+    class p1 required
+    class p2,p3 optional
+    class out output
+```
+
+**Phase 1 is mandatory.** Even if you proceed to Phase 2 or 3, the Mermaid source stays committed.
+
+### What Mermaid can express
+
+Mermaid covers 24 diagram types. Almost every scientific relationship fits one:
+
+| Use case | Diagram type | File |
+| -------------------------------------------- | ---------------- | ---------------------------------------------------- |
+| Experimental workflow / decision logic | Flowchart | `references/diagrams/flowchart.md` |
+| Service interactions / API calls / messaging | Sequence | `references/diagrams/sequence.md` |
+| Data model / schema | ER diagram | `references/diagrams/er.md` |
+| State machine / lifecycle | State | `references/diagrams/state.md` |
+| Project timeline / roadmap | Gantt | `references/diagrams/gantt.md` |
+| Proportions / composition | Pie | `references/diagrams/pie.md` |
+| System architecture (zoom levels) | C4 | `references/diagrams/c4.md` |
+| Concept hierarchy / brainstorm | Mindmap | `references/diagrams/mindmap.md` |
+| Chronological events / history | Timeline | `references/diagrams/timeline.md` |
+| Class hierarchy / type relationships | Class | `references/diagrams/class.md` |
+| User journey / satisfaction map | User Journey | `references/diagrams/user_journey.md` |
+| Two-axis comparison / prioritization | Quadrant | `references/diagrams/quadrant.md` |
+| Requirements traceability | Requirement | `references/diagrams/requirement.md` |
+| Flow magnitude / resource distribution | Sankey | `references/diagrams/sankey.md` |
+| Numeric trends / bar + line charts | XY Chart | `references/diagrams/xy_chart.md` |
+| Component layout / spatial arrangement | Block | `references/diagrams/block.md` |
+| Work item status / task columns | Kanban | `references/diagrams/kanban.md` |
+| Cloud infrastructure / service topology | Architecture | `references/diagrams/architecture.md` |
+| Multi-dimensional comparison / skills radar | Radar | `references/diagrams/radar.md` |
+| Hierarchical proportions / budget | Treemap | `references/diagrams/treemap.md` |
+| Binary protocol / data format | Packet | `references/diagrams/packet.md` |
+| Git branching / merge strategy | Git Graph | `references/diagrams/git_graph.md` |
+| Code-style sequence (programming syntax) | ZenUML | `references/diagrams/zenuml.md` |
+| Multi-diagram composition patterns | Complex Examples | `references/diagrams/complex_examples.md` |
+
+> 💡 **Pick the right type, not the easy one.** Don't default to flowcharts for everything.
+> A timeline beats a flowchart for chronological events. A sequence beats a flowchart for
+> service interactions. Scan the table and match.
+
+---
+
+## 🔧 Core workflow
+
+### Step 1: Identify the document type
+
+Check if a template exists before writing from scratch:
+
+| Document type | Template |
+| ------------------------------ | ----------------------------------------------- |
+| Pull request record | `templates/pull_request.md` |
+| Issue / bug / feature request | `templates/issue.md` |
+| Sprint / project board | `templates/kanban.md` |
+| Architecture decision (ADR) | `templates/decision_record.md` |
+| Presentation / briefing | `templates/presentation.md` |
+| Research paper / analysis | `templates/research_paper.md` |
+| Project documentation | `templates/project_documentation.md` |
+| How-to / tutorial | `templates/how_to_guide.md` |
+| Status report | `templates/status_report.md` |
+
+### Step 2: Read the style guide
+
+Before writing any `.md` file: read `references/markdown_style_guide.md`.
+
+Key rules to internalize:
+
+- **One H1 per document** — the title. Never more.
+- **Emoji on H2 headings only** — one emoji per H2, none in H3/H4
+- **Cite everything** — every external claim gets a footnote `[^N]` with full URL
+- **Bold sparingly** — max 2-3 bold terms per paragraph, never full sentences
+- **Horizontal rule after every `</details>`** — mandatory
+- **Tables over prose** for comparisons, configurations, structured data
+- **Diagrams over walls of text** — if it describes flow, structure, or relationships, add Mermaid
+
+### Step 3: Pick the diagram type and read its guide
+
+Before creating any Mermaid diagram: read `references/mermaid_style_guide.md`.
+
+Then open the specific type file (e.g., `references/diagrams/flowchart.md`) for the exemplar, tips, and copy-paste template.
+
+Mandatory rules for every diagram:
+
+```
+accTitle: Short Name 3-8 Words
+accDescr: One or two sentences explaining what this diagram shows.
+```
+
+- **No `%%{init}` directives** — breaks GitHub dark mode
+- **No inline `style`** — use `classDef` only
+- **One emoji per node max** — at the start of the label
+- **`snake_case` node IDs** — match the label
+
+### Step 4: Write the document
+
+Start from the template. Apply the markdown style guide. Place diagrams inline with related text — not in a separate "Figures" section.
+
+### Step 5: Commit as text
+
+The `.md` file with embedded Mermaid is what gets committed. If you also generated a PNG or AI image, those are supplementary — the markdown is the source.
+
+---
+
+## ⚠️ Common pitfalls
+
+### Radar chart syntax (`radar-beta`)
+
+**WRONG:**
+```mermaid
+radar
+title Example
+x-axis ["A", "B", "C"]
+"Series" : [1, 2, 3]
+```
+
+**CORRECT:**
+```mermaid
+radar-beta
+title Example
+axis a["A"], b["B"], c["C"]
+curve series["Series"]{1, 2, 3}
+max 3
+```
+
+- **Use `radar-beta`** not `radar` (the bare keyword doesn't exist)
+- **Use `axis`** to define dimensions, **not** `x-axis`
+- **Use `curve`** to define data series, **not** quoted labels with colon
+- **No `accTitle`/`accDescr`** — radar-beta doesn't support accessibility annotations; always add a descriptive italic paragraph above the diagram
+
+### XY Chart vs Radar confusion
+
+| Diagram | Keyword | Axis syntax | Data syntax |
+| ------- | ------- | ----------- | ----------- |
+| **XY Chart** (bars/lines) | `xychart-beta` | `x-axis ["Label1", "Label2"]` | `bar [10, 20]` or `line [10, 20]` |
+| **Radar** (spider/web) | `radar-beta` | `axis id["Label"]` | `curve id["Label"]{10, 20}` |
+
+### Forgetting `accTitle`/`accDescr` on supported types
+
+Only some diagram types support `accTitle`/`accDescr`. For those that don't, always place a descriptive italic paragraph directly above the code block:
+
+> _Radar chart comparing three methods across five performance dimensions. Note: Radar charts do not support accTitle/accDescr._
+
+```mermaid
+radar-beta
+...
+```
+
+---
+
+## 🔗 Integration with other skills
+
+### With `scientific-schematics`
+
+`scientific-schematics` generates AI-powered publication-quality images (PNG). Use the Mermaid diagram as the **brief** for the schematic:
+
+```
+Workflow:
+1. Create the concept as Mermaid in .md (this skill — Phase 1)
+2. Describe the same concept to scientific-schematics for a polished PNG (Phase 3)
+3. Commit both — the .md as source, the PNG as a supplementary figure
+```
+
+### With `scientific-writing`
+
+When `scientific-writing` produces a manuscript, all diagrams and structural figures should use this skill's standards. The writing skill handles prose and citations; this skill handles visual structure.
+
+```
+Workflow:
+1. Use scientific-writing to draft the manuscript
+2. For every figure that shows a workflow, architecture, or relationship:
+   - Replace placeholder with a Mermaid diagram following this skill's guide
+3. Use scientific-schematics only for figures that truly need photorealistic/complex rendering
+```
+
+### With `literature-review`
+
+Literature review produces summaries with lots of relationship data. Use this skill to:
+
+- Create concept maps (Mindmap) of the literature landscape
+- Show publication timelines (Timeline or Gantt)
+- Compare methodologies (Quadrant or Radar)
+- Diagram data flows described in papers (Sequence or Flowchart)
+
+### With any skill that produces output documents
+
+Before finalizing any document from any skill, apply this skill's checklist:
+
+- [ ] Does the document use a template? If so, did I start from the right one?
+- [ ] Are all diagrams in Mermaid with `accTitle` + `accDescr`?
+- [ ] No `%%{init}`, no inline `style`, only `classDef`?
+- [ ] Are all external claims cited with `[^N]`?
+- [ ] One H1, emoji on H2 only?
+- [ ] Horizontal rules after every `</details>`?
+
+---
+
+## 📚 Reference index
+
+### Style guides
+
+| Guide | Path | Lines | What it covers |
+| ----------------------- | ------------------------------------------- | ----- | -------------------------------------------------- |
+| Markdown Style Guide | `references/markdown_style_guide.md` | ~733 | Headings, formatting, citations, tables, Mermaid integration, templates, quality checklist |
+| Mermaid Style Guide | `references/mermaid_style_guide.md` | ~458 | Accessibility, emoji set, color classes, theme neutrality, type selection, complexity tiers |
+
+### Diagram type guides (24 types)
+
+Each file contains: production-quality exemplar, tips specific to that type, and a copy-paste template.
+
+`references/diagrams/` — architecture, block, c4, class, complex\_examples, er, flowchart, gantt, git\_graph, kanban, mindmap, packet, pie, quadrant, radar, requirement, sankey, sequence, state, timeline, treemap, user\_journey, xy\_chart, zenuml
+
+### Document templates (9 types)
+
+`templates/` — decision\_record, how\_to\_guide, issue, kanban, presentation, project\_documentation, pull\_request, research\_paper, status\_report
+
+### Examples
+
+`assets/examples/example-research-report.md` — a complete scientific research report demonstrating proper heading hierarchy, multiple diagram types (flowchart, sequence, gantt), tables, footnote citations, collapsible sections, and all style guide rules applied.
+
+---
+
+## 📝 Attribution
+
+All style guides, diagram type guides, and document templates in this skill are ported from the `SuperiorByteWorks-LLC/agent-project` repository under the Apache-2.0 License.
+
+- **Source**: https://github.com/SuperiorByteWorks-LLC/agent-project
+- **Author**: Clayton Young / Superior Byte Works, LLC (@borealBytes)
+- **License**: Apache-2.0
+
+This skill (as part of claude-scientific-skills) is distributed under the MIT License. The included Apache-2.0 content is compatible for downstream use with attribution retained, as preserved in the file headers throughout this skill.
+
+---
+
+[^1]: GitHub Blog. (2022). "Include diagrams in your Markdown files with Mermaid." https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/
+
+[^2]: Mermaid. "Mermaid Diagramming and Charting Tool." https://mermaid.js.org/

package/skills/markdown-mermaid-writing/assets/examples/example-research-report.md

@@ -0,0 +1,221 @@
+# CRISPR-Based Gene Editing Efficiency Analysis
+
+_Example research report — demonstrates markdown-mermaid-writing skill standards. All diagrams use Mermaid embedded in markdown as the source format._
+
+---
+
+## 📋 Overview
+
+This report analyzes the efficiency of CRISPR-Cas9 gene editing across three cell line models under variable guide RNA (gRNA) conditions. Editing efficiency was quantified by T7E1 assay and next-generation sequencing (NGS) of on-target loci[^1].
+
+**Key findings:**
+
+- HEK293T cells show highest editing efficiency (mean 78%) across all gRNA designs
+- GC content between 40–65% correlates with editing efficiency (r = 0.82)
+- Off-target events occur at <0.1% frequency across all conditions tested
+
+---
+
+## 🔄 Experimental workflow
+
+CRISPR editing experiments followed a standardized five-stage protocol. Each stage has defined go/no-go criteria before proceeding.
+
+```mermaid
+flowchart TD
+    accTitle: CRISPR Editing Experimental Workflow
+    accDescr: Five-stage experimental pipeline from gRNA design through data analysis, with quality checkpoints between each stage.
+
+    design["🧬 Stage 1<br/>gRNA Design<br/>(CRISPRscan + Cas-OFFinder)"]
+    synth["⚙️ Stage 2<br/>Oligo Synthesis<br/>& Annealing"]
+    transfect["🔬 Stage 3<br/>Cell Transfection<br/>(Lipofectamine 3000)"]
+    screen["🧪 Stage 4<br/>Primary Screen<br/>(T7E1 assay)"]
+    ngs["📊 Stage 5<br/>NGS Validation<br/>(150 bp PE reads)"]
+
+    qc1{GC 40-65%?}
+    qc2{Yield ≥ 2 µg?}
+    qc3{Viability ≥ 85%?}
+    qc4{Band visible?}
+
+    design --> qc1
+    qc1 -->|"✅ Pass"| synth
+    qc1 -->|"❌ Redesign"| design
+    synth --> qc2
+    qc2 -->|"✅ Pass"| transfect
+    qc2 -->|"❌ Re-synthesize"| synth
+    transfect --> qc3
+    qc3 -->|"✅ Pass"| screen
+    qc3 -->|"❌ Optimize"| transfect
+    screen --> qc4
+    qc4 -->|"✅ Pass"| ngs
+    qc4 -->|"❌ Repeat"| screen
+
+    classDef stage fill:#dbeafe,stroke:#2563eb,stroke-width:2px,color:#1e3a5f
+    classDef gate fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12
+    classDef fail fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d
+
+    class design,synth,transfect,screen,ngs stage
+    class qc1,qc2,qc3,qc4 gate
+```
+
+---
+
+## 🔬 Methods
+
+### Cell lines and culture
+
+Three cell lines were used: HEK293T (human embryonic kidney), K562 (chronic myelogenous leukemia), and Jurkat (T-lymphocyte). All lines were maintained in RPMI-1640 with 10% FBS at 37°C / 5% CO₂[^2].
+
+### gRNA design and efficiency prediction
+
+gRNAs targeting the _EMX1_ locus were designed using CRISPRscan[^3] with the following criteria:
+
+| Criterion | Threshold | Rationale |
+| -------------------- | --------- | ------------------------------------- |
+| GC content | 40–65% | Optimal Tm and Cas9 binding |
+| CRISPRscan score | ≥ 0.6 | Predicted on-target activity |
+| Off-target sites | ≤ 5 (≤3 mismatches) | Reduce off-target editing risk |
+| Homopolymer runs | None (>4 nt) | Prevents premature transcription stop |
+
+### Transfection protocol
+
+RNP complexes were assembled at 1:1.2 molar ratio (Cas9:gRNA) and delivered by lipofection. Cells were harvested 72 hours post-transfection for genomic DNA extraction.
+
+### Analysis pipeline
+
+```mermaid
+sequenceDiagram
+    accTitle: NGS Data Analysis Pipeline
+    accDescr: Sequence of computational steps from raw FASTQ files through variant calling to final efficiency report.
+
+    participant raw as 📥 Raw FASTQ
+    participant qc as 🔍 FastQC
+    participant trim as ✂️ Trimmomatic
+    participant align as 🗺️ BWA-MEM2
+    participant call as ⚙️ CRISPResso2
+    participant report as 📊 Report
+
+    raw->>qc: Per-base quality scores
+    qc-->>trim: Flag low-Q reads (Q<20)
+    trim->>align: Cleaned reads
+    align->>align: Index reference genome (hg38)
+    align->>call: BAM + target region BED
+    call->>call: Quantify indel frequency
+    call-->>report: Editing efficiency (%)
+    call-->>report: Off-target events
+    report-->>report: Statistical summary
+```
+
+---
+
+## 📊 Results
+
+### Editing efficiency by cell line
+
+| Cell line | n (replicates) | Mean efficiency (%) | SD (%) | Range (%) |
+| ---------- | -------------- | ------------------- | ------ | --------- |
+| **HEK293T** | 6 | **78.4** | 4.2 | 71.2–84.6 |
+| K562 | 6 | 52.1 | 8.7 | 38.4–63.2 |
+| Jurkat | 6 | 31.8 | 11.3 | 14.2–47.5 |
+
+HEK293T cells showed significantly higher editing efficiency than both K562 (p < 0.001) and Jurkat (p < 0.001) lines by one-way ANOVA with Tukey post-hoc correction.
+
+### Effect of GC content on efficiency
+
+GC content between 40–65% was strongly correlated with editing efficiency (Pearson r = 0.82, p < 0.0001, n = 48 gRNAs).
+
+```mermaid
+xychart-beta
+    accTitle: Editing Efficiency vs gRNA GC Content
+    accDescr: Bar chart showing mean editing efficiency grouped by GC content bins, demonstrating optimal performance in the 40 to 65 percent GC range
+
+    title "Mean Editing Efficiency by GC Content Bin (HEK293T)"
+    x-axis ["< 30%", "30–40%", "40–50%", "50–65%", "> 65%"]
+    y-axis "Editing Efficiency (%)" 0 --> 100
+    bar [18, 42, 76, 81, 38]
+```
+
+### Timeline of key experimental milestones
+
+```mermaid
+timeline
+    accTitle: Experiment Timeline — CRISPR Efficiency Study
+    accDescr: Chronological milestones from study design through manuscript submission across six months
+
+    section Month 1
+        Study design and gRNA library design : 48 gRNAs across 3 target loci
+        Cell line authentication : STR profiling confirmed all three lines
+    section Month 2
+        gRNA synthesis and QC : 46/48 gRNAs passed yield threshold
+        Pilot transfections (HEK293T) : Optimized lipofection conditions
+    section Month 3
+        Full transfection series : All 3 cell lines, all 46 gRNAs, 6 replicates
+        T7E1 primary screening : Passed go/no-go for all conditions
+    section Month 4
+        NGS library preparation : 276 samples processed
+        Sequencing run (NovaSeq) : 150 bp PE, mean 50k reads/sample
+    section Month 5
+        Bioinformatic analysis : CRISPResso2 pipeline
+        Statistical analysis : ANOVA, correlation, regression
+    section Month 6
+        Manuscript preparation : This report
+```
+
+---
+
+## 🔍 Discussion
+
+### Why HEK293T outperforms suspension lines
+
+HEK293T's superior editing efficiency relative to K562 and Jurkat likely reflects three factors[^4]:
+
+1. **Adherent morphology** — enables more uniform lipofection contact
+2. **High transfection permissiveness** — HEK293T expresses the SV40 large T antigen, which may facilitate nuclear import
+3. **Cell cycle distribution** — higher proportion in S/G2 phase where HDR is favored
+
+<details>
+<summary><strong>🔧 Technical details — off-target analysis</strong></summary>
+
+Off-target editing was assessed by GUIDE-seq at the 5 highest-activity gRNAs. No off-target sites exceeding 0.1% editing frequency were detected. The three potential sites flagged by Cas-OFFinder (≤2 mismatches) showed 0.00%, 0.02%, and 0.04% indel frequencies — all below the assay noise floor of 0.05%.
+
+Full GUIDE-seq data available in supplementary data package (GEO accession pending).
+
+</details>
+
+---
+
+### Comparison with published benchmarks
+
+_Radar chart comparing three CRISPR delivery methods across five performance dimensions. Note: Radar charts do not support `accTitle`/`accDescr` — description provided above._
+
+```mermaid
+radar-beta
+title Performance vs. Published Methods
+axis eff["Efficiency"], spec["Specificity"], del["Delivery ease"], cost["Cost"], viab["Cell viability"]
+curve this_study["This study (RNP + Lipo)"]{78, 95, 80, 85, 90}
+curve plasmid["Plasmid Cas9 (lit.)"]{55, 70, 90, 95, 75}
+curve electroporation["Electroporation RNP (lit.)"]{88, 96, 50, 60, 65}
+max 100
+graticule polygon
+ticks 5
+showLegend true
+```
+
+---
+
+## 🎯 Conclusions
+
+1. RNP-lipofection in HEK293T achieves >75% CRISPR editing efficiency — competitive with electroporation without the associated viability cost
+2. gRNA GC content is the single strongest predictor of editing efficiency in our dataset (r = 0.82)
+3. This protocol is not directly transferable to suspension lines without further optimization; K562 and Jurkat require electroporation or viral delivery for comparable efficiency
+
+---
+
+## 🔗 References
+
+[^1]: Ran, F.A. et al. (2013). "Genome engineering using the CRISPR-Cas9 system." _Nature Protocols_, 8(11), 2281–2308. https://doi.org/10.1038/nprot.2013.143
+
+[^2]: ATCC. (2024). "Cell Line Authentication and Quality Control." https://www.atcc.org/resources/technical-documents/cell-line-authentication
+
+[^3]: Moreno-Mateos, M.A. et al. (2015). "CRISPRscan: designing highly efficient sgRNAs for CRISPR-Cas9 targeting in vivo." _Nature Methods_, 12(10), 982–988. https://doi.org/10.1038/nmeth.3543
+
+[^4]: Molla, K.A. & Yang, Y. (2019). "CRISPR/Cas-Mediated Base Editing: Technical Considerations and Practical Applications." _Trends in Biotechnology_, 37(10), 1121–1142. https://doi.org/10.1016/j.tibtech.2019.03.008

package/skills/markdown-mermaid-writing/references/diagrams/architecture.md

@@ -0,0 +1,108 @@
+<!-- Source: https://github.com/SuperiorByteWorks-LLC/agent-project | License: Apache-2.0 | Author: Clayton Young / Superior Byte Works, LLC (Boreal Bytes) -->
+
+# Architecture Diagram
+
+> **Back to [Style Guide](../mermaid_style_guide.md)** — Read the style guide first for emoji, color, and accessibility rules.
+
+**Syntax keyword:** `architecture-beta`
+**Best for:** Cloud infrastructure, service topology, deployment architecture, network layout
+**When NOT to use:** Logical system boundaries (use [C4](c4.md)), component layout without cloud semantics (use [Block](block.md))
+
+> ⚠️ **Accessibility:** Architecture diagrams do **not** support `accTitle`/`accDescr`. Always place a descriptive _italic_ Markdown paragraph directly above the code block.
+
+---
+
+## Exemplar Diagram
+
+_Architecture diagram showing a cloud-hosted web application with a load balancer, API server, database, and cache deployed within a VPC:_
+
+```mermaid
+architecture-beta
+    group cloud(cloud)[AWS Cloud]
+    group vpc(cloud)[VPC] in cloud
+
+    service lb(internet)[Load Balancer] in vpc
+    service api(server)[API Server] in vpc
+    service db(database)[PostgreSQL] in vpc
+    service cache(disk)[Redis Cache] in vpc
+
+    lb:R --> L:api
+    api:R --> L:db
+    api:B --> T:cache
+```
+
+---
+
+## Tips
+
+- Use `group` for logical boundaries (VPC, region, cluster, availability zone)
+- Use `service` for individual components
+- Direction annotations on connections: `:L` (left), `:R` (right), `:T` (top), `:B` (bottom)
+- Built-in icon types: `cloud`, `server`, `database`, `internet`, `disk`
+- Nest groups with `in parent_group`
+- **Labels must be plain text** — no emoji and no hyphens in `[]` labels (parser treats `-` as an edge operator)
+- Use `-->` for directional arrows, `--` for undirected edges
+- Keep to **6–8 services** per diagram
+- **Always** pair with a Markdown text description above for screen readers
+
+---
+
+## Template
+
+_Description of the infrastructure topology and key components:_
+
+```mermaid
+architecture-beta
+    group region(cloud)[Cloud Region]
+
+    service frontend(internet)[Web Frontend] in region
+    service backend(server)[API Server] in region
+    service datastore(database)[Database] in region
+
+    frontend:R --> L:backend
+    backend:R --> L:datastore
+```
+
+---
+
+## Complex Example
+
+_Multi-region cloud deployment with 3 nested groups (2 regional clusters + shared services) showing 9 services, cross-region database replication, CDN distribution, and centralized monitoring. Demonstrates how nested `group` + `in` syntax creates clear infrastructure boundaries:_
+
+```mermaid
+architecture-beta
+    group cloud(cloud)[AWS Platform]
+
+    group east(cloud)[US East Region] in cloud
+    service lb_east(internet)[Load Balancer East] in east
+    service app_east(server)[App Server East] in east
+    service db_primary(database)[Primary Database] in east
+
+    group west(cloud)[US West Region] in cloud
+    service lb_west(internet)[Load Balancer West] in west
+    service app_west(server)[App Server West] in west
+    service db_replica(database)[Replica Database] in west
+
+    group shared(cloud)[Shared Services] in cloud
+    service cdn(internet)[CDN Edge] in shared
+    service monitor(server)[Monitoring] in shared
+    service queue(server)[Message Queue] in shared
+
+    cdn:B --> T:lb_east
+    cdn:B --> T:lb_west
+    lb_east:R --> L:app_east
+    lb_west:R --> L:app_west
+    app_east:B --> T:db_primary
+    app_west:B --> T:db_replica
+    db_primary:R --> L:db_replica
+    app_east:R --> L:queue
+    app_west:R --> L:queue
+    monitor:B --> T:app_east
+```
+
+### Why this works
+
+- **Nested groups mirror real infrastructure** — cloud > region > services is exactly how teams think about multi-region deployments. The nesting creates clear blast radius boundaries.
+- **Plain text labels only** — architecture diagrams parse-fail with emoji in `[]` labels. All visual distinction comes from the group nesting and icon types (`internet`, `server`, `database`).
+- **Directional annotations prevent overlap** — `:B --> T:` (bottom-to-top), `:R --> L:` (right-to-left) control where edges connect. Without these, Mermaid stacks edges on top of each other.
+- **Cross-region replication is explicit** — the `db_primary:R --> L:db_replica` edge is the most important infrastructure detail and reads clearly as a horizontal connection between regions.