Architecture diagram

<!-- RUBRIC-COMPLIANCE:START (self-improve) -->

Output Quality Requirements (rubric compliance, MANDATORY, overrides all guidance below)

This block OVERRIDES any conflicting instruction, template, or example later in this skill. It applies to EVERY claim, label, annotation, capability tag, wiki-sync entry, and pending-sync record in the output. If guidance below this block conflicts, this block wins.

• Pattern selection is binding: Before any diagram work, confirm the vendor context (Nimbus vs Aegis Core vs a named incumbent platform) from the RFP. If the anti-pattern self-check flags a vendor mismatch (e.g., "aegis-branded" chosen for a Nimbus-flavored RFP), STOP and re-select the pattern. Do not ship with a known-wrong pattern.
• No internal contradictions: A capability cannot be [doc-verified]/HIGH in one section and NEEDS VERIFICATION in another. Resolve to a single status before output. SOC 2 Type II conformance, BYOK regional GA, and SLA tier are central RFP claims and MUST be internally consistent across diagram tiles, capability map, and open items.
• Every [doc-verified] tag must cite the document: Format [doc-verified: <vendor> <doc-name>, v<version>, <YYYY-MM-DD>, <URL>]. No bare [doc-verified]. If you cannot cite doc+version+date+URL, downgrade to [UNVERIFIED] or [INFERRED].
• Vendor capability + quantitative claims require sources: SLA percentages, p95 latency targets, MAU references, regional GA status, SOC 2 conformance, Workspaces behavior, each needs a source URL + date or [UNVERIFIED]. Distinguish Globex's requirement (from RFP) from Nimbus's published commitment (from vendor doc); never conflate.
• Document-claim framing is mandatory for ALL _inbox/RFP/research content: Write "the RFP document states Globex requires X" or "2026-05-18 research notes indicate X", NEVER "Globex requires X" or "the customer needs X". This applies in the diagram, capability map, wiki-sync entries, and pending-syncs.
• Corroboration tags on EVERY carried-forward fact: Tag with [CORROBORATED: N sources: <who1>, <who2>] or [UNCORROBORATED: single source: <who or "RFP document">]. Single-source facts MUST NOT be written to pending-syncs with independent: true. Entries with who: null are open questions, not facts, and MUST NOT be queued for wiki promotion.
• Authority-gap flags are mandatory on any decision/commitment claim (budget, vendor selection, architecture commitment, timeline, sign-off) sourced from a non-economic/non-technical buyer. Apply MEDDPICC title rules:
  • Procurement (e.g., Diego Alvarez) → NOT a technical architecture decision-maker → tag [AUTHORITY GAP: procurement, not technical buyer] on every requirement sourced from them.
  • Engineer / Senior Engineer (e.g., Marcus Reyes, Senior Platform Engineer) → observational only → DO NOT label "technical buyer". Use "technical contact (engineer-tier, observational)".
  • Director-level secondhand claims about C-level approvals (e.g., "Priya says CFO signed off on the workflow-automation budget") → tag [AUTHORITY GAP: secondhand C-level commitment, not independently corroborated]. Never record as established budget fact.
  • Public statements with no established title (e.g., Lila Tanaka 2M MAU) → [UNCORROBORATED: single source, authority unverified].
• Numbered phase sequence must be complete: Steps 1→N with no gaps. If Steps 4 and 5 exist in the skill, they MUST appear in output; jumping 3→6 is a hard fail.
• Pre-flight reads must actually execute: No placeholder text like "(In a live run, MCP reads happen here)". Either perform the reads and quote them, or explicitly state "PRE-FLIGHT SKIPPED, reason: <X>" and degrade confidence on dependent claims.
• Element-count self-check must be accurate: Recount shapes per page by enumeration before asserting compliance. If count exceeds the tier cap (architect tier: 20), either reduce shapes or escalate tier, do not assert false compliance.
• Epistemic honesty markers: [doc-verified: ...] = cited vendor doc; [CORROBORATED: N] = ≥2 independent sources; [UNCORROBORATED: single source: X] = 1 source; [INFERRED] = analyst inference; [UNVERIFIED] = claim with no source; [AUTHORITY GAP: reason] = source lacks authority for this claim type. These are orthogonal and may stack.
• Vendor objectivity: Acknowledge limits (regional GA gaps, conformance pending, tier-dependent SLA). Strip "best-in-class", "industry-leading", and unhedged superlatives.
• Tone: Use ZERO em-dashes. Use commas, periods, colons, or parentheses instead.

<!-- RUBRIC-COMPLIANCE:END --> <!-- quality-gates: see rules/skill-quality-gates.md (do not copy-paste; council scores against rules/council-gate.md) -->

Architecture Diagram Generator

Note: Uses state-tree placeholder paths and plugin frontmatter conventions; Obsidian vault references deferred to per-company _inbox/.

Generate polished, customer-specific technical architecture diagrams for B2B sales presentations.

Primary path: Lucid MCP (lucid_create_diagram_from_specification), produces editable, shareable Lucidchart documents with native text, real AWS/Azure/GCP service icons, and customer collaboration links.

Fallback path: AI image generation (nano-banana-art), use for rapid whiteboard sketches or when photorealistic/illustrated style is needed.

This skill produces post-discovery deliverables, follow-up emails, proposal slides, workshop leave-behinds. It is not a whiteboard tool for live discovery sessions.

State-tree placeholder: <state-tree>/ resolves to wherever the adopter has chosen for their per-company state. Plugin convention: output/<company>/. Throughout this skill, <state-tree>/ may be read as output/ for default deployments.

Inputs and resolution contract

Required input: $ARGUMENTS MUST contain a company identifier as the first positional value. If missing or empty, this skill rejects with exit code 2 and emits exactly:

ERROR: company required

per rules/source-trust-hierarchy.md Tier 1 input-validation guard. This matches the input-validation contract used by discovery, competitive, and the other Tier 1 skills.

Mode + accounts-root resolution: before running, source helpers/getMode.sh and resolve the accounts root via getAccountsRoot(), this honors $PRESALES_ACCOUNTS_ROOT (adopter's custom account root), $CLAUDE_PROJECT_DIR/output, and $PWD/output in priority order. Then call getMode <company> for the dual-mode classifier.

source "${CLAUDE_PLUGIN_ROOT:-.}/helpers/getMode.sh"
accounts_root="$(getAccountsRoot)"
mode="$(getMode "$company")"
state_tree="${accounts_root}/${company}"

In stateless mode, output is the only side effect. In stateful mode, the skill reads $state_tree/_state.md, $state_tree/_inbox/, and $state_tree/_wiki/ per the conversation contract. See rules/conversation-contract.md for the full Phase 0 / Phase 1 / Phase 2 / Phase 3 read+write loop.

Core Principle: Audience First

The audience tier, not the technical accuracy, is the primary quality variable. A Level 2 C4 diagram shown to a VP is a failure regardless of correctness. Always resolve the audience before generating anything.

---

Step 1: Gather Required Inputs

Before generating, collect four things. Infer from conversation context when possible; ask when ambiguous.

Design Pattern

The pattern determines the shape vocabulary and logo treatment. Defaults to vendor-neutral for internal work; infer aegis-branded automatically for customer-facing proposal artifacts (before-after, future-state, migration-phases) unless the user says otherwise.

Pattern	Tile treatment	When to use
vendor-neutral (default)	Generic rectangles with semantic colors	Internal SE work, competitive bake-offs, discovery whiteboards
aegis-branded	Aegis product logos on platform tiles	Customer proposals, exec leave-behinds, co-branded workshops
aws-native	AWS namedShape entries dominate	AWS-heavy architectures, re:Invent-style diagrams
azure-native	Azure namedShape entries dominate	Microsoft-shop architectures

For aegis-branded, read patterns/aegis-branded/PATTERN.md before generating. It defines the Aegis semantic shape vocabulary, two implementation paths (image tiles vs. custom Lucid shape library), and five additional anti-patterns specific to Aegis brand usage.

Ask before generating if the pattern is genuinely ambiguous, one question, three options: aegis-branded, vendor-neutral, co-branded (customer logo too).

Audience Tier

Tier	Who	Max Elements	Label Style	Protocol Labels
exec	VP, CIO, CFO	8	Business language only	None
ciso	CISO, VP Security	12	Business + security mix	Security-relevant only
architect	Platform architect, IT director	20	Full technical	All (REST, webhook, event-stream)

Diagram Type

Type	Layout	Best For	Lucid Tool
platform-overview	Hub-and-spoke	Exec intro to a unified platform	lucid_create_diagram_from_specification
before-after	2-page document	Proposals, workshops, default if unspecified	lucid_create_diagram_from_specification
current-state	Dense, annotated	Discovery follow-up	lucid_create_diagram_from_specification
future-state	Clean, simplified	Standalone proposal slide	lucid_create_diagram_from_specification
api-flow	Left-to-right sequence	API / integration deep-dive	lucid_create_sequence_diagram
sync-flow	Swimlane (top-to-bottom)	Workflow-automation lifecycle demo	lucid_create_diagram_from_specification
review-flow	Workflow-centric with review cycles	Approval / audit discussions	lucid_create_diagram_from_specification
control-plane	Control plane / data plane separation	Scale + reliability briefings	lucid_create_diagram_from_specification
migration-phases	Three sequential panels	Crawl-Walk-Run roadmaps	lucid_create_diagram_from_specification

Customer-Specific Components

Every customer-facing diagram must use the prospect's actual system names. Generic labels ("App 1", "Vendor Platform") are an anti-pattern that signals the seller hasn't done account research.

Collect:

• Customer name (used in diagram title)
• Platform(s) in scope, proposed or in-use (Aegis, and any incumbent workflow/ops suite)
• User populations, employees, contractors, partners, customers
• Key applications (3-5), their actual names (Salesforce, ServiceNow, SAP, etc.)
• On-prem systems, legacy ERP, mainframe apps, homegrown tooling
• Compliance frameworks, FedRAMP, SOX, HIPAA, etc.

If specifics are unknown, substitute plausible platform defaults and flag them for confirmation. When operating against a per-company state tree, raw customer-specific inputs (architecture diagrams, RFPs, screenshots) live under <state-tree>/<company>/_inbox/, read them before falling back to defaults.

---

Step 2: Plan the Diagram Structure

Map the customer context to shapes and colors before writing any JSON.

Color System (Hex Codes, Required for Lucid)

Lucid requires hex codes in all JSON. Never use color names. For AI image generation prompts (fallback path), use the color names from references/color-system.md.

Role	Hex	textColor	AI Image Name
Platform Core (Aegis hub)	#0D9488	#FFFFFF	teal
Cloud / SaaS apps	#0091DA	#FFFFFF	sky blue
On-prem / Legacy	#6B7280	#FFFFFF	slate gray
Governance / Workflow	#6B21A8	#FFFFFF	deep purple
Risk / Current-state pain	#D97706	#FFFFFF	amber orange
Compliant / Future-state	#166534	#FFFFFF	forest green
Admin Console	#4C1D95	#FFFFFF	deep indigo
Zone background fill	#F8FAFC	,	off-white
Transparent zone boundary	#00000000	,	,
Borders / arrows (default)	#1E293B	,	dark navy
API / integration arrows	#2563EB	,	blue
Sync / automation arrows	#0D9488	,	teal
Governance arrows	#7C3AED	,	purple
Risk / violation arrows	#DC2626	,	red

Component Shapes (for Lucid JSON)

Platform Component	Lucid type	Notes
Aegis / Generic Platform Core	rectangleContainer	Use containerTitle: {text: "Aegis Core"}, containers have no text property
SaaS App	roundedRectangleContainer	containerTitle for name
On-prem / Legacy App	rectangle	Sharp corners = on-prem convention
System of Record / Database	database	Flowchart library
Rules Engine	decision	Flowchart library diamond
Security Gateway / Integration Endpoint	hexagon	Standard library
Approval Workflow step	process	Flowchart library
Integration Flow Start/End	terminator	Flowchart library
Risk Annotation	note	Flowchart library; amber fill
AWS Data Sync Target	namedShape	className: "ArchAmazonSimpleStorageServiceAWS2024"
AWS Event Bus	namedShape	className: "ArchAmazonEventBridgeAWS2024"
AWS Orchestration	namedShape	className: "ArchAWSStepFunctionsAWS2024"
Azure Orchestration	namedShape	className: "LogicAppsAzure2021"
Azure Integration Bus	namedShape	className: "ServiceBusAzure2021"
Azure Event Trigger	namedShape	className: "EventGridTopicsAzure2021"
AWS Cloud boundary	namedContainer	className: "AWSCloudAWS2024"
AWS VPC boundary	namedContainer	className: "VirtualPrivateCloudVPCAWS2024"

See references/lucid-shape-registry.md for the full AWS/Azure/GCP shape library, zone fill patterns, and swimlane templates.

---

Step 3: Generate with Lucid MCP (Primary Path)

Pre-flight: Always Read the Spec First

Before calling lucid_create_diagram_from_specification: read lucid://diagram-specification. The MCP validates strictly, wrong shape type names, missing required properties, and incorrect endpoint formats produce "invalid_file" 400 errors with no indication of which field failed.

Before calling lucid_create_sequence_diagram: read lucid://sequence-diagram-specification.

For AWS/Azure/GCP named shapes: read the relevant library resource first:

• lucid://shape-libraries/aws-2024/application-integration (Aegis-adjacent)
• lucid://shape-libraries/aws-2024/common (top 36 shapes)
• lucid://shape-libraries/azure-2021/integration
• lucid://shape-libraries/gcp-2021/application-integration

Tool Selection

Diagram Type	Tool	use_assisted_layout
platform-overview, future-state, current-state	lucid_create_diagram_from_specification	false (containers present)
before-after	lucid_create_diagram_from_specification	false (2 pages or split zones)
sync-flow, review-flow, control-plane	lucid_create_diagram_from_specification	false (swimLanes present)
migration-phases	lucid_create_diagram_from_specification	false (spatial layout)
api-flow (API calls, webhook, integration sequence)	lucid_create_sequence_diagram	N/A

Set use_assisted_layout: false whenever the diagram uses containers, swimlanes, or zone-based spatial positioning. Use true only for simple linear flowcharts with no containers.

JSON Construction Rules (Prevents 400 Errors)

1. Hex codes only, "#0D9488" not "teal". Color names are silently ignored or cause errors.
2. No emoji in text, render as solid black boxes.
3. Shape type names are exact strings, copy from lucid://diagram-specification. "rectangleContainer" not "rectangle-container".
4. Containers have no text property, use containerTitle: {text: "Zone Name"} on types that support it: rectangleContainer, roundedRectangleContainer, circleContainer, pillContainer. swimLanes, braceContainer, bracketContainer do NOT support containerTitle.
5. text shapes have no style property, adding style to type: "text" causes an error.
6. Endpoint position: both or neither, smart auto-routing omits position from both shapeEndpoint objects. Specifying position on only one endpoint causes failure.
7. Shapes fully inside containers, entire bounding box must fit strictly inside the container with padding on all sides. Edge-touching is not contained.
8. swimLane lane width math, vertical: true (side-by-side columns): sum of lane width values = boundingBox.w. vertical: false (stacked rows): sum of lane width values = boundingBox.h.
9. assistedLayout on the container shape, for swimLanes and bpmnPool, set assistedLayout: true on the container, NOT on individual lane objects.
10. Shape IDs are unique strings, never reuse IDs across the document; never use integer IDs.
11. Z-index = array order, shapes defined later appear in front. Put background containers and zone boundaries first in the shapes array.
12. 2MB limit, use compact JSON (no whitespace indentation) for large diagrams.
13. ERD, DFD, ArchiMate shapes are unsupported by the MCP as of May 2026. Use standard shapes.
14. No vendor platform-core shape libraries, Aegis, Nimbus, and comparable incumbent platforms have no Lucid library. Represent as labeled rectangleContainer with semantic stroke color.

Container Layout Patterns

Hub-and-spoke (platform-overview, future-state):

• One rectangleContainer per zone, User/Device, On-Premises, Platform Core, SaaS Apps, Governance
• Set assistedLayout: true on each container (for its contents)
• Pass use_assisted_layout: false to the tool call
• Zone fills from references/lucid-shape-registry.md

Swimlane (sync-flow):

• swimLanes with vertical: false (stacked rows)
• Set assistedLayout: true on the swimLanes shape
• Standard actor sequence: Source System → Platform Core / Sync Engine → Target Apps → Governance

Before/After:

• Two-page document: page 1 = current state, page 2 = future state
• Or single wide canvas: current-state shapes at x=0–600, future-state at x=750–1350
• Current: amber zone fills, dense connections, note shapes for pain callouts
• Future: clean containers, minimal connections, green metric note shapes

Control-plane architecture (scale + reliability):

• swimLanes with vertical: false, two rows: Control Plane (policy/config) / Data Plane (enforcement + resources)

Migration phases:

• Three rectangleContainer shapes side-by-side with containerTitle Phase 1 / Phase 2 / Phase 3

Integration Flow PlantUML Rules (Sequence Diagrams)

Supported participants: participant, actor, database, boundary, control, entity

Supported arrows: -> --> ->> -->> <-> <--> <<->> <<-->>

Supported groupings: alt/else (else only inside alt), loop, opt, par, critical, group

Do NOT use (causes parse errors):

• skinparam directives of any kind
• activate A #color (color modifier on activate)
• destroy, newpage, return, ref over
• == Section == dividers, ... delays
• Lines starting with ! (preprocessor directives)
• Lost message arrows (->x, [->, ->])
• else outside an alt block
• collections, queue participant types

Post-Generation Workflow

After lucid_create_diagram_from_specification or lucid_create_sequence_diagram returns:

1. Share the edit URL with the account team for internal review.
2. Export PNG: call lucid_export_document_as_PNG, use in slide decks and email attachments.
3. Customer share link: call lucid_create_document_share_link
   • role: "comment" for customer review/feedback
   • role: "edit" for collaborative refinement
   • restrict_to_account: false when sharing with external customers
4. Optional direct access: call lucid_share_document_with_collaborators with customer email.

---

Step 4: Generate with AI Image (Fallback Path)

Use nano-banana-art when Lucid MCP is unavailable, when photorealistic/illustrated style elements are needed, or for quick internal whiteboard sketches.

Mandatory Prompt Rules

1. Use color names, never hex codes, hex codes render as visible text in the image
2. Specify "no text labels" or use only 1-3 word labels, AI text rendering fails on dense labels
3. List every connection explicitly, state "There are exactly N connections." Unlisted connections invite phantom arrows
4. Describe layout spatially, "on the far left", "directly below", not grid counts
5. Max 8 components per generation pass, above this threshold, quality degrades. Use multi-pass for complex diagrams
6. Specify aspect ratio, 16:9 for slides, 4:3 for documents, 1:1 for social

Prompt templates are in references/prompt-templates.md. Color names map to hex via references/color-system.md.

Multi-Pass Strategy (for diagrams with >8 components)

1. Pass 1, User/application tier (users, browsers, apps)
2. Pass 2, Platform tier (core services, admin console, sync engine)
3. Pass 3, Target systems tier (AD, cloud apps, governance)

Then composite layers or generate a simplified version that fits within 8 components for the target audience tier.

npx tsx ~/.claude/skills/nano-banana-art/tools/generate-image.ts \
  --model nano-banana-pro \
  --prompt "[CONSTRUCTED PROMPT]" \
  --size 2K \
  --aspect-ratio 16:9 \
  --output /path/to/output.png

Before/After (AI Image)

Generate as a single image with split-panel layout:

• Left panel: "Current State", dense, tangled, amber risk annotations
• Right panel: "With [Vendor]", clean, hub-and-spoke, green compliance badges
• The visual simplicity of the future state IS the sales argument

---

Step 5: Review

After generation, verify:

For Lucid diagrams:

1. All shapes are correctly contained within zone boundaries (no shapes crossing container edges)
2. Connection arrows have correct labels (REST, webhook, GraphQL, etc.)
3. containerTitle text is readable at target screen size
4. Export PNG at 2K for slides, confirm labels are legible
5. Share link permissions match intent (comment vs. edit, internal vs. external)

For AI-generated images:

1. Label accuracy, AI text may have spelling errors. Flag any labels that need correction.
2. Connection accuracy, verify arrows match the intended connections
3. Layout quality, whitespace meets audience tier requirements (40% for exec, 30% for CISO, 20% for architect)

For customer-facing AI images, recommend importing into Canva or Figma as a background layer, adding native text elements, and exporting at 2K–4K resolution.

---

Step 6: Add Sales Annotations

Transform the technical artifact into a sales artifact:

On current-state diagrams:

• Amber callout cards quantifying pain: "~200 orphaned accounts", "14 manual steps per onboarding"
• Risk zone highlights with compliance framework references

On future-state diagrams:

• Green metric cards showing transformation: "Workflow run time: 4.5 hrs → 12 min"
• Compliance badges: SOC 2 Type II, FedRAMP, HIPAA

In Lucid: Use note shapes for callouts, amber fill for pain, green fill for metrics. Use text shapes for compliance badges (no style property on text types).

On all diagrams:

• Title with customer name and scenario
• Date and version number
• Legend/key for all colors and shapes

---

Anti-Patterns Checklist

Before delivering any diagram, verify none of these apply:

1. Generic labels, "App 1", "Vendor Platform" instead of customer's actual system names
2. Unlabeled arrows, every connection needs a direction and label
3. Wrong abstraction for audience, protocol details shown to a VP, or outcomes-only shown to an architect
4. No current state, jumping to future state without validating current state understanding
5. Too many elements, exceeding the audience tier's max component count
6. Color without text/shape backup, relying on color alone to encode meaning (fails for colorblind and grayscale print)
7. Feature-centric layout, vendor product as the center of the universe instead of the customer's use case
8. No legend, never assume the audience knows your notation
9. Undated/untitled, every diagram needs: title, customer name, date, version
10. Over-complexity as credibility, if a viewer can't extract the central message in 10 seconds, the diagram has failed
11. [Lucid] Color names in JSON, hex codes only; color names cause silent failure or errors
12. [Lucid] Skipping the spec, always read lucid://diagram-specification before generating JSON
13. [Lucid] Vendor logos that don't exist, Aegis and most named incumbent platforms have no Lucid shape library. Use labeled rectangleContainer with semantic stroke color.
14. [Lucid] use_assisted_layout: true with containers, always false for zone-based platform diagrams

---

Reference Files

File	Contents
references/lucid-shape-registry.md	Platform component → Lucid shape type mapping; AWS/Azure/GCP named shape classNames; hex color table; zone container patterns; complete gotchas list
references/prompt-templates.md	Ready-to-use prompt templates for AI image generation (fallback path)
references/color-system.md	Full color palette with hex values, color names, zone fills, arrow colors
references/platform-taxonomy.md	Complete platform-architecture component taxonomy with shapes, colors, and groupings
patterns/aegis-branded/PATTERN.md	Aegis-branded pattern, when to use, Aegis semantic shape vocabulary, five Aegis-specific anti-patterns
patterns/aegis-branded/path-a-image-tiles.md	Path A implementation, image shapes layered on rectangleContainer tiles, asset URL registry, ready to use today
patterns/aegis-branded/path-b-shape-library.md	Path B implementation, custom Lucid shape library spec (AegisCore2026 etc.), one-time admin upload process, JSON recipes
patterns/aegis-branded/examples/hub-spoke-aegis-branded.json	Reference template, Path A hub-and-spoke with Aegis Core + Workflow + Monitor

The original research synthesis lived in the author's Obsidian vault at ~/Documents/ObsidianNotes/Claude-Research/architecture-diagram-research-synthesis-2026-03.md. In a state-tree deployment, equivalent research notes belong under <state-tree>/<company>/_inbox/ (or a shared <state-tree>/_research/ directory) rather than in a private vault.

---

Wiki Update Loop (Phase 3)

Per rules/wiki.md "Output-to-Wiki Loop" section, after this skill saves its output and before Phase 3 completes, scan the output for new facts and propose wiki updates.

Account-status guard: Only run if the cached effective_status from conversation-contract.md step 0.75 is active. For test/archived accounts or --test flag, skip the loop entirely; write a zero-metrics line to <state-tree>/.wiki-state/loop-metrics.jsonl and return.

Dual-mode guard: Only run if <state-tree>/<company>/_state.md exists (stateful mode). In stateless mode, skip the loop entirely, no account context to bind facts to.

Source provenance: This skill's source type is mixed: human-verbal for customer-stated architecture context (current-state tooling, app counts, scale claims gathered during the engagement) and doc-verified for Aegis/Nimbus product capability claims verified via Context7 MCP. Per-fact attribution: customer-stated facts use the named contributor (e.g., "Jane Doe, IT Director") with independent: true per unique external speaker; product capability facts use who: null with independent: true (machine-verified docs are independent by nature). Inline ^[source: ...] annotations override the default mapping when present.

Fact extraction: Scan the saved diagram spec and accompanying narrative for new quantitative claims, named entities, relationships, and corrections. Skip the diagram artifact itself (the JSON spec or image is the deliverable, not the fact source); extract facts from the customer-architecture context that drove the diagram. Skip recommendations, hypotheticals, and pure Aegis/Nimbus product facts (those belong in references, not account wiki). For each extracted fact, populate source: {type, who, who_key, independent} and materiality: HIGH | LOW per the Materiality Decision Rule.

Queue (silent): Append the proposed updates to <state-tree>/.wiki-state/pending-syncs.jsonl. The Wiki Sync Scanner cron (per rules/cron-freshness.md, optional manual setup) drains the queue, OR the user runs /wiki-sync <company> manually. No user prompt; no Phase 2.5 exchange.

Exemption flags: --no-wiki skips this loop entirely. --wiki-review restores interactive A/B/C review of proposed updates.

Loop metrics: Write one line to <state-tree>/.wiki-state/loop-metrics.jsonl on every run (active OR non-active) so /self-improve can see the skill ran.