Slide Arch Diagram

---
name: slide-arch-diagram
description: "Turn an ideated business workflow into a slide-ready FE/BE/DB architecture diagram: three horizontal lanes (前端 Front End · 後端 Back End · 資料庫 Database) with the workflow's IPO units stitched LEFT→RIGHT across them — human inputs drop ↓ from the FE lane into dark octagon process nodes chained → across the BE lane, stored knowledge feeds ↑ from the DB lane, and the output document rises ↑ back to FE at the far right, closed by exactly ONE orange 'law line' verdict bottom-right. Trigger when the user hands over a workflow (free text, an IPO breakdown, or a SLIDE_PACKET ▸ Pages entry) and says 'draw this as an architecture diagram', 'draw the FE/BE/DB view', 'architecture slide for this workflow', '畫成架構圖', '畫 FE/BE/DB', '前後端架構圖', '工作流架構圖', '把這個流程畫上簡報', or when slide-visual-selector routes an architecture-flavoured process-diagram page here. Boundaries: renders HTML/CSS slide pages (artifact decks) — for the same FE/BE/DB convention drawn into Lucid charts use product-flow-design; for generic per-page layout selection use slide-visual-selector; this skill does not write storylines, paginate, or render .pptx."
category: brand-marketing
project: slide-arch-diagram
platform: claude
status: Done
author: Peter Tu
sheetId: "1.39"
input: "One ideated workflow: free text, a structured Input/Process/Output breakdown, or a SLIDE_PACKET ▸ Pages entry flagged as an architecture-style process page"
process: "Decompose into IPO elements → place each in FE/BE/DB via the canonical decision questions and golden rules → stitch left→right (FE inputs ↓, BE chain →, DB feeds ↑, output ↑) → render the .arch component with runtime brand tokens → run the QA checklist"
output: "A slide-ready .arch diagram block (plus per-deck CSS) with a conclusion-bearing title and one orange law-line verdict, dropped into the target artifact deck page"
synergy: ["slide-visual-selector", "zynkr-slide", "product-flow-design"]
handoff: []
house-style: bound

---

# Slide Arch Diagram

```bash
npx skills add https://github.com/peter-tu-zynkr/zynkr-skill-builder --skill slide-arch-diagram
```

Turns one ideated business workflow into a slide-ready architecture diagram: three horizontal lanes (前端 Front End · 後端 Back End · 資料庫 Database) with the workflow's IPO stitched left→right across them, closed by a single orange law-line verdict. Trigger it whenever a workflow needs to be drawn as an architecture view on an artifact deck — 「畫成架構圖」「畫 FE/BE/DB」"draw this workflow as an architecture diagram" — or when slide-visual-selector routes an architecture-flavoured process page here.

## What this is

A business workflow drawn as **architecture, not as a flowchart**. The three lanes answer "who owns this?" — the human surface (FE), the execution and its rules (BE), the stored state and knowledge (DB) — and the workflow's IPO pushes **left→right** across them. One diagram = one workflow = one page.

The point of the drawing is the placement discipline behind it: if you can place every element of a workflow into the right lane, you have already answered what can be automated, what knowledge must be written down first, and where the human stays in the loop. The diagram is that argument made visible.

**Core mental model (canonical, load the full version from `./references/canonical-model.md`):**

- **FE — Interaction & Intent**: where humans interact; captures inputs and commands, presents outcomes. FE shows intent, it never owns rules.
- **BE — Execution & Meaning**: where work is orchestrated and rules are enforced; the canonical source of meaning. Every process node lives here.
- **DB — State & Knowledge**: durable state and codified knowledge that feed execution. An index or a context window is never the system of record.

## Resources you'll use

- **`./references/canonical-model.md`** — the FE/BE/DB placement method: per-lane decision questions, the cross-layer golden rules, and the anti-patterns to refuse. Read it before placing anything.
- **`./references/visual-grammar.md`** — the render contract: the `.arch` CSS component (proven in production), the markup skeleton, per-element semantics (doc icon / octagon node / folder icon / arrows / law line), and the QA gotcha list. Read it before rendering.
- **`./references/brand-source.md`** — where brand tokens come from at runtime (never hard-coded here; this is a public repo). Sage frames and arrows, ink octagons, paper ground, orange for the single law line.

## Step 1 — Intake: decompose the workflow into IPO elements

Accept any of: a free-text workflow description, a structured IPO breakdown, or a `SLIDE_PACKET ▸ Pages` entry. Extract four element sets:

1. **Human-provided inputs** — what does a person hand in or ask? (a name, a file, a one-line command like 「今天該追誰？」)
2. **Process steps** — the actions and judgments, in order. Target **exactly 3 nodes** per diagram; merge or split steps to get there (2 is acceptable for genuinely simple flows, 4 is the hard max — beyond that, split into two diagrams or two pages).
3. **Stored knowledge / state consumed** — what already-written things feed the steps? (CRM records, a spec, past examples, quotas)
4. **The output** — the one artifact that goes back to a human, and where it lands.

If the workflow has no identifiable output, stop and ask — a diagram without an output document at far right is not this grammar.

## Step 2 — Placement: put every element in its lane

For each element, run the decision questions from `./references/canonical-model.md` and place it:

| Element looks like | Lane | Rendered as |
|---|---|---|
| A human typing, uploading, asking, receiving | **FE** | doc icon (top lane) |
| An action, judgment, transformation, rule being enforced | **BE** | dark octagon node (middle lane) |
| Stored records, written rules, past examples, canonical numbers | **DB** | folder icon (bottom lane) |

Check placements against the golden rules — the two that catch most mistakes:

- **FE shows intent; BE owns meaning.** A validation or eligibility rule is a BE node even if a form hints at it.
- **The lanes are FE/BE/DB — never Input/Process/Output.** IPO is the *unit stitched across* the lanes, not the lanes themselves. (This exact mistake was made and rejected once; it is the reason this skill exists.)

Then write the **law line**: one sentence, the diagram's verdict — how automatable this workflow is and what gates it (e.g. "全自動——但品質完全由 Input 決定", "卡最兇——Input 散得最開的一格"). Plain text, no emoji, no ✅/❌.

## Step 3 — Stitch the IPO left→right

Assign columns (one per BE node, left→right in execution order), then wire:

- Each **FE input** sits in the top lane above the column of the node it feeds, with a stem + ▼ arrow dropping into the BE lane. Most workflows have one FE input at column 1.
- Each **DB feed** sits in the bottom lane below the column of the node it informs, with a stem + ▲ arrow rising into the BE lane.
- **BE nodes** chain with solid horizontal arrows between columns.
- The **output doc** sits in the FE lane at the far-right column, with a stem + ▲ arrow rising from the BE lane — the flow returns to the human.

Chain-stitching across diagrams is deliberate and powerful: when one workflow's output is another's input, label the DB feed accordingly (e.g. 「②的背景摘要｜上一格的 Output」). A sequence of these pages then *shows* the compounding argument — upstream not written down ⇒ downstream can't automate.

## Step 4 — Render

Follow `./references/visual-grammar.md` exactly. In short:

1. On first use in a deck, add the `.arch` CSS block (it assumes the deck's brand tokens and container-query units; both conventions are in the reference).
2. Emit the markup skeleton: 4-column grid (label gutter + 3 node columns) × 3 lane rows + the law-line row.
3. Page furniture around it: eyebrow (section · index), **conclusion-bearing title** (a claim, not a label — "只要公司名和網址，其餘都自動生得出來", never "背景調查流程"), italic use-case subline (the situation in the user's words), footer.
4. Brand restraint: sage for structure (frame, lane borders, arrows, icon accents), ink octagons on paper, and **orange exactly once — the law line**. Nothing else on the page may be orange.

## Step 5 — QA before handing back

Run the checklist (full version with the why in `./references/visual-grammar.md`):

- [ ] Lane borders form **one continuous line** across all four columns (labels must stretch to row height — `align-self:center` on a bordered cell floats the border mid-row; this shipped as a bug once)
- [ ] Exactly one orange element (the law line); highlight color ≤ 1 per title
- [ ] No emoji anywhere (✅/❌ render as colored boxes that fight the accent)
- [ ] Arrow spans contain **no text glyphs** (drawn arrows only — a leftover 「→」 ghosts under the CSS arrow)
- [ ] 2–4 BE nodes, no node text clipped, diagram clears the footer
- [ ] **Screenshot-verify, don't just DOM-verify** — both alignment bugs above passed geometric checks and were caught only by eyes on pixels

## Outputs

One `.arch` diagram block per workflow, dropped into the target artifact deck page (plus the CSS once per deck), styled by runtime-loaded brand tokens, closed by a single orange law line — and a placement table you can defend, because every element sits in its lane for a reason.

## Limitations

- **HTML/CSS artifacts only (v1).** No pptxgenjs rendering — the octagon clip-path and lane grid need a native-shape recipe that is deferred to v2. To get the diagram into Slides today: screenshot → full-bleed image slide.
- **Not the Lucid skill.** The same FE/BE/DB convention drawn into Lucid charts is `product-flow-design`; this skill renders slide pages.
- **Not a storyline or pagination skill.** It draws one workflow it is given; which workflows deserve pages is the slide relay's call (`slide-storyline-designer` → `slide-page-splitter` → `slide-visual-selector`).
- **Placement canon is loaded, not invented.** When the canonical-model reference and a user instruction conflict, surface the conflict — don't silently deviate from the canon.

## House style

Writing style is **not owned by this file**. The house voice lives in two Google Docs under
`[@] 寫作指南` (`12DBdFz3SK22ie9im_ThFMI7IBRXsTZsV`), read at runtime:

- 《[2.0] Zynkr 通用風格指南 House Voice》 `10bOIQwRm9Pxwgct4hlwCwK_B4Pipai1HqBPZKzyRHSE` —
  the universal core, plus the addendum for this surface
- 《[3.2] 禁用詞清單 Forbidden Words》 `1N5sHLP4qzmmhpCGsi6KElxi1z0MFe4QZ0Q_35T10Uyg`

Read both before producing client- or reader-facing text, and scan the draft against 《[3.2]》
before handing it over. If Drive is unreachable, say so in the output rather than proceeding
unchecked. Never re-implement either list inside this file.