wow-my-zsh

oh-my-zsh for AI coding agents. One canonical source of configuration, transpiled and symlinked into each agent's native path — so Claude Code, opencode, codex, cline, jcode, and mimo-code all share the same house rules and the same MCP server registry, authored once.

Fleet memory (Cognee) — house rules only here

Domain graph memory lives in SIN-Save-Token (binaries, proxy, cost policy). This repo only ships the canonical agent rules in shared/AGENTS.md (CLI cognee-recall / remember, Gemini embed + local fallback, Boundless cognify cost discipline).

# bring-up + CLI (SST)
~/dev/SIN-Save-Token/bin/cognee-fleet-up.sh
cognee-status
cognee-recall "…"

Cognee is optional MCP in shared/mcp/servers.json (always_on=false) — default is CLI, not schema tax. Full stack docs: SST README Cognee fleet memory

SIN-Save-Token/docs/COGNEE-COST-POLICY.md.

Philosophy

        shared/ (canonical)                per-agent native config
  ┌──────────────────────────┐        ┌─────────────────────────────┐
  │ AGENTS.md   (house rules) │──link──▶ ~/.claude/  ~/.config/opencode
  │ mcp/servers.json (MCP)    │──gen───▶ ~/.codex/   cline globalStorage
  └──────────────────────────┘        └─────────────────────────────┘

Author once. Rules live in shared/AGENTS.md; MCP servers live in shared/mcp/servers.json.
Transpile. scripts/gen-mcp.py <agent> renders the registry into each agent's dialect (Claude mcpServers, opencode mcp, codex TOML, cline).
Merge. scripts/merge-mcp.py splices that rendered output into the real config each agent loads — a structural merge for JSON agents, a comment-fenced block for codex TOML — preserving every other key you have.
Symlink. install.sh links the instruction files into place and runs the merge — backing up anything real it finds first.

Directory layout

shared/
  AGENTS.md            canonical cross-agent house rules (the master)
  mcp/servers.json     canonical MCP server registry (single source of truth)
  instructions/ skills/ prompts/ hooks/ loops/   shared building blocks
  skills/visual-diagrams/  /visual-diagrams skill — MANDATORY archify diagram wrapper
  skills/video-creator-openmontage/  OpenMontage video production skill + references
  skills/orca-sin-team/  same-worktree Orca delegation + direct parent callbacks
  skills/orca-sin-goal/  autonomous long-horizon project completion loop
  skills/sin-gpt-web/  ChatGPT Web + Orca OpenSIN + Mac i9 project orchestration
  skills/agentcookie/  signed Mac-to-Mac authenticated-session sync integration
  skills/oci-vm/  dynamic OCI inventory, runtime diagnostics and safe hardening
  skills/skill-productivity-notion/  official-first Notion workflow + safe private fallback
agents/
  claude/CLAUDE.md               thin adapter, imports shared/AGENTS.md
  opencode/AGENTS.md             thin adapter
  codex/AGENTS.md                thin adapter
  cline/clinerules/00-canonical.md  points at shared/AGENTS.md
  jcode/AGENTS.md                thin adapter, imports shared/AGENTS.md
  mimo/AGENTS.md                 thin adapter (OpenCode fork; delegation target)
scripts/gen-mcp.py     registry -> per-agent MCP dialect transpiler
scripts/merge-mcp.py   splices the transpiled output into each agent's real config
scripts/test_gen_mcp.py  regression tests for the transpiler/merge
scripts/export-archify-svg.mjs       Archify Export → SVG reproducer
scripts/verify-archify-diagrams.mjs  JSON → HTML → SVG freshness gate
machines/              per-machine overrides
install.sh doctor.sh uninstall.sh

Quickstart

git clone <repo-url> ~/.wow-my-zsh
cd ~/.wow-my-zsh
bash ./install.sh                       # all agents, minimal MCP profile
bash ./install.sh --agents claude,opencode   # subset
bash ./doctor.sh                        # verify symlinks + required env vars

Authenticated agent Macs with agentcookie

shared/skills/agentcookie/ integrates mvanhorn/agentcookie as a pinned, Apple-signed runtime for one-way authenticated-session sync from a trusted source Mac to a trusted agent Mac over Tailscale. The integration is allowlist-first, verifies the v0.17.1 archive and binary hashes plus the Apple Developer ID signature, and deliberately separates binary installation from machine pairing:

agentcookie-install       # installs the reviewed signed binary only
agentcookie-doctor        # checks binary, signature, Chrome, Tailscale and setup

Current upstream supports macOS on both source and sink. An OCI Ubuntu VM is not an agentcookie sink. Personal browser profiles, cookie databases, cookie exports, pairing data, and secret-bus state are never committed to this repo. Pairing and exact domain allowlists remain explicit user-authorized operations.

Isolated agent Chrome (sin-chrome)

shared/skills/sin-chrome/ turns agentcookie agent-sync into a focused, safe agent-browser workflow. It starts an always visible, persistent bot Chrome with its own ~/Library/Application Support/SIN-Chrome data directory, loopback-only CDP endpoint, verified agentcookie runtime, and explicit hostname scope. It does not control, clone, or lock the user's everyday Chrome profile.

# Install the command and managed MCP runtime for OpenCode.
bash ./install.sh --agents opencode

sin-chrome doctor
sin-chrome start --domain github.com --domain app.example.com

# Enable simple typed browser tools for authenticated bot-Chrome work.
sin-mcp-profile sin-chrome opencode --apply

The bot Chrome is never headless. Agents use the task-scoped sin_chrome_* MCP tools for status, snapshot, navigation, click, text click, form filling, select, keyboard, scroll, hover, drag, checkbox, tab, login, TOTP, CAPTCHA detection, and screenshots. Trusted remote callers, including ChatGPT Web through Mac i9, use the same fixed-policy JSON CLI: sin-chrome-control status.

The same isolated browser can now be mirrored into the authenticated SIN Control Center. The center lists real ChatGPT Web tabs by stable Chrome target ID, streams the selected viewport with CDP Page.startScreencast, and returns mouse, keyboard, paste, and scroll input to that exact tab. It is not a ChatGPT API client or a reconstructed chat UI: the central canvas shows the real live website, including tool calls, dialogs, loading states, and rate-limit banners.

# With configured agentcookie session import:
sin-chrome start --domain chatgpt.com

# Or use a direct persistent bot profile and log in manually once:
sin-chrome start --direct --domain chatgpt.com

# In a second terminal, open the authenticated loopback dashboard.
sin-chrome dashboard --open
# Equivalent direct launcher: sin-chrome-node --open

The lifecycle-recovery and live acceptance record is documented in docs/sin-chrome-acceptance-2026-07-29.md.

The control center also includes an operations strip for all machines: live session/node counts, quick status filters, named saved views, JSON inventory export, peer latency, and a one-click action that parks idle unpinned chats while leaving active and pinned work untouched. Peer health is fetched in parallel, and the Chrome-first status path avoids waiting for Orca unless fallback is actually needed.

A dedicated composer below the mirrored viewport makes normal text chat reliable: it preserves per-session drafts, supports multiline Unicode, sends through the real visible ChatGPT composer, confirms acceptance, reports generation state, and can stop a running response. Enter sends and Shift+Enter inserts a line break. The complete website remains available in the canvas for attachments, model selection, tools, dialogs, and every other ChatGPT Web control. Registered peer machines expose the same chat-state, send, and stop operations through the local control plane.

Inactive chats can be parked by preserving their /c/<conversation-id> URL and closing only the browser tab. The dashboard reports Chrome, session, and machine capabilities for integration with additional Mac plugin tunnels. Raw CDP remains loopback-only; remote machines must reach the authenticated node through a trusted connector or tunnel. When Chrome streaming is unavailable, the node can list and drive Orca browser sessions through stable browserPageId values and a low-frame-rate screenshot fallback.

Additional machines run the same loopback node behind their own authenticated plugin tunnel. Register a peer with a private token file; tokens are stored only in the local 0600 registry and are never returned by list/status commands:

sin-chrome-node peer add \
  --name "MacBook" \
  --url "https://trusted-tunnel.example/sin-chrome" \
  --token-file "$HOME/.config/sin/macbook-node-token"
sin-chrome-node peer list

The local control plane then aggregates peer machine health and sessions and proxies their authenticated WebSocket stream/input channel. The dashboard's machine selector chooses where a new ChatGPT Web session is opened.

Dashboard automations

The SIN Control Center includes its own private scheduler for real ChatGPT Web sessions. A schedule stores the conversation URL, prompt, next run time, and optional daily, weekly, or hourly recurrence in the profile's private runtime directory. At execution time the local node opens or reuses that exact ChatGPT conversation, fills the visible composer through Playwright, and submits the message. This deliberately does not depend on ChatGPT's built-in scheduled-task feature, so connector and Mac tunnel availability is evaluated in the normal web conversation when the scheduled prompt runs. The minimum interval is one hour; failed deliveries remain visible with their last error and can be retried manually from the dashboard. Each automation also keeps a bounded durable run history in bot.automation-runs.json with planned/manual origin, start and completion time, duration, selected conversation, acceptance result, and error. The dashboard exposes this history per job, shows consecutive failures and the last runtime, and changes failed jobs to an explicit Erneut versuchen action. A per-automation execution lock prevents manual and scheduled triggers from delivering the same prompt concurrently.

CDP is unauthenticated, so every process under the same macOS login must be trusted. Hostname allowlists are mandatory, DBSC cookies are always excluded, and neither cookie values nor profile data may be exported. The MCP bridge is bound to the bot profile, so agents cannot name or access another active profile. Password/TOTP login consumes pre-provisioned host-bound Keychain values without returning them. CAPTCHA detection reports a block; the integration does not solve or bypass anti-bot controls. Device-bound/passkey-only flows require a supported service API rather than browser automation.

OCI VM operations

shared/skills/oci-vm/ replaces stale hardcoded OCI inventories with live OCI CLI and SSH discovery. It incorporates the reusable operational knowledge from the local skill-oci-oracle-cloud, Infra-SIN-Dev-Setup, OpenSIN-Chat, and OpenAfD-Chat sources without committing private IPs, OCIDs, tunnel credentials, or key material.

oci-vm-doctor                         # local OCI/SSH/Tailscale prerequisites
oci-vm-inventory                      # read-only dynamic OCI + SSH inventory
oci-vm-runtime-dump --host <alias>    # bounded read-only VM evidence
oci-vm-hardening-install --host <alias> --dry-run
oci-vm-hardening-install --host <alias> --apply

The hardening installer is dry-run by default and installs only conservative journald limits and a disk-pressure timer. It never guesses application service names and does not use destructive docker system prune -a. OCI/Linux agents receive service credentials through OCI workload identity, Infisical, or other revocable providers—not personal Mac cookies.

Notion productivity skill

shared/skills/skill-productivity-notion/ is the canonical Notion instruction and runtime package for every supported agent. It uses a strict two-provider model:

notion task profile → official hosted OAuth MCP at https://mcp.notion.com/mcp (preferred);
notion-private task profile → repository-owned vibe-notion-mcp bridge for personal-session identity and narrow private-API gaps such as upload, export, or guarded publish/unpublish.

The installer copies the skill to all native agent skill directories, links sin-mcp-profile, vibe-notion-mcp, vibe-notion-verify, and vibe-notion-root-fix into ~/.local/bin, creates a managed Python virtual environment, and idempotently restores the local root-page permissions patch when vibe-notion is installed. The bridge rejects root-page creation, confines uploads, separates raw reads from raw writes, and performs read-after-write verification.

bash bin/sin-mcp-profile notion claude --apply          # official provider
bash bin/sin-mcp-profile notion-private opencode --apply # private fallback
bash bin/vibe-notion-verify                              # local fallback health

OAuth and Notion session credentials remain outside the repository.

Gmail skill (sin-gmail)

shared/skills/sin-gmail/ gives every supported agent full Gmail access via himalaya — a Rust CLI email client using IMAP/SMTP with App-Password auth. No Google Cloud project, no OAuth consent screen, no service account: just an App-Password per Gmail account (2FA required), stored in the macOS Keychain and referenced from ~/.config/himalaya/config.toml via auth.cmd.

Install only this skill without other runtimes, MCP wiring, or agent plugins:

bash install.sh --skills sin-gmail --agents opencode
# or install Himalaya, the skill, and one Gmail account in one guided flow:
bash shared/skills/sin-gmail/scripts/install-sin-gmail.sh \
  --agent opencode --install-himalaya --setup \
  --email you@gmail.com --slug work --default

The account setup uses a native macOS secure field and stores the App-Password only in Keychain. Follow shared/skills/sin-gmail/references/google-app-password.md; never paste an App-Password into a command, file, or chat.

For ChatGPT Web through the Mac i9 tunnel, use the read-only smoke test and explicit-send authorization flow in shared/skills/sin-gmail/references/chatgpt-web-mac-i9.md.

# Add a new Gmail account using the native secure Keychain prompt
bash shared/skills/sin-gmail/scripts/sin-gmail-setup.sh -e you@gmail.com -s work --default

# Read / search
himalaya envelope list -a work -s 10
himalaya message read <ID>

# Send normal correspondence in the shared current OpenAI style
python3 shared/skills/sin-gmail/scripts/sin-gmail-send-rich.py \
  --account work --from "Name <you@gmail.com>" --to recipient@example.com \
  --subject "Betreff" --body $'Guten Tag,\n\nhier ist die vereinbarte Information.\n\nFreundliche Grüße\nName'

# Schedule a send for a future date/time (himalaya has no native delayed
# send; this wraps sin-scheduler as a one-shot cron job)
bash shared/skills/sin-gmail/scripts/sin-gmail-schedule-send.sh \
  -f /tmp/followup.eml -m 0 -H 8 -d 24 -M 7

Full command reference (read, send, reply, forward, drafts, attachments, folders, flags, multi-account, and the scheduled-send pattern) is in shared/skills/sin-gmail/SKILL.md.

ChatGPT Web orchestration skill (sin-gpt-web)

shared/skills/sin-gpt-web/ lets any supported local agent operate ChatGPT Web through the Orca CLI using the persistent browser profile OpenSIN, while ChatGPT works on the same repository through the secure Mac i9 plugin tunnel. ChatGPT Web remains the sovereign lead, planner, verifier, and normal repository writer. MiMo Code is bounded to low-cost exploration, reading, testing, research, and review; edits are exceptional, mechanical, and explicitly scoped.

The installer copies the skill into every selected agent's native skill directory and exposes four stable commands in ~/.local/bin:

sin-gpt-web-doctor
sin-gpt-web-open --repo /absolute/path/to/project
sin-gpt-web-state --repo /absolute/path/to/project summary
sin-gpt-web-context --repo /absolute/path/to/project "current architecture and constraints"

Both the local agent and ChatGPT Web work from one canonical SQLite plan at .sin-gpt-web/taskplan.sqlite3. It provides WAL-backed concurrent reads, transactional updates, normalized dependencies, atomic task claims, owner and revision tracking, blockers, acceptance criteria, completion evidence, and an append-only event log. .sin-gpt-web/TASKPLAN.md is generated automatically as the readable view and must not be edited manually.

The workflow also includes an event-driven completion channel: delegation opens an expiring one-shot callback bound to the exact originating Orca/OpenCode terminal, ChatGPT Web calls it through Mac i9, and a structured SIN_GPT_WEB_CALLBACK wakes the original OpenCode TUI. OpenCode independently verifies the claim, updates the SQLite plan, and continues the same ChatGPT conversation with the next bounded CEO-loop task until acceptance gates pass. Callback state records the correlated OpenCode session, stable page ID, conversation URL, expiry, and bounded loop round without storing transcripts or secrets.

The workflow also includes continuous browser supervision, Deep Research and other ChatGPT tools, local shell/Git/GitHub work through Mac i9, image generation, bounded MiMo parallelism, and deterministic recovery. Repository and memory context route first through sin-context; Graphify is primary for architecture, GitNexus is the serialized fallback, Cognee owns durable domain memory, claude-mem supplies pull-based session observations, and gbrain or global-brain remain curated/on-demand rather than parallel automatic injectors. Runtime state is ignored by Git. Contract and execution tests keep the task state, role boundary, recovery behavior, installer links, documentation, and CI integration from drifting.

Full operational guide: docs/sin-gpt-web.md. Canonical agent instructions: shared/skills/sin-gpt-web/SKILL.md.

Autonomous project completion

Invoke /orca-sin-goal or explicitly ask the lead agent to finish a project completely and autonomously. The lead then owns the whole outcome, creates durable .sin-goal/<goal-id>/ state, maintains a dynamic dependency-aware plan, delegates bounded work to same-worktree Orca terminals, receives direct event callbacks, runs fresh verification and an independent observer, and continues until the completion gates pass or a genuine external irreversible authority blocker remains.

This mode is designed to remove routine human babysitting. The lead decides ordinary reversible technical choices using repository conventions, evidence, and production-safe defaults. Workers report newly discovered necessary work through discovery callbacks; the lead incorporates justified scope expansions and keeps iterating. Exact bounded tasks are continuous-preauthorized by default: checkpoints keep the lead informed but do not require routine replies. Only high-risk or irreversible boundaries use stepwise approval.

The durable state survives agent/session restarts on the same machine and allows deterministic resume. Continuous execution still requires the relevant Orca/agent processes to remain running; this skill is not an operating-system daemon and cannot execute while the host or agent runtime is stopped.

Canonical files:

shared/skills/orca-sin-goal/SKILL.md
shared/loops/orca-sin-goal.md
config/orca-orchestrator.json → goal_runtime
config/orca-goal-state.schema.json
scripts/orca-goal-state.py
.github/workflows/orca-contracts.yml

Re-running install.sh is safe and idempotent: correct symlinks are left alone, and MCP servers are merged into each agent's real unified config (preserving every other key you have) — the pre-merge file is copied to *.bak-<epoch> only when the merge actually changes it. Which servers this repo owns is tracked in a sidecar state file next to each config (<config>.wow-my-zsh-managed.json), so a re-run prunes ones you dropped from the registry and never touches the rest. The state lives in the sidecar — not inside the config — because strict-schema agents (opencode/mimo, an OpenCode fork) reject any unrecognized top-level key and refuse to start. uninstall.sh removes only the symlinks this repo created (verified to point into WOW_HOME) and restores the newest backup.

Per-agent config

The MCP servers are merged in place into the single config each agent actually loads — every other key in that config is preserved. Only the bookkeeping of which servers this repo owns lives in a small sidecar (<config>.wow-my-zsh-managed.json); the agent never reads that file.

Agent	Instructions file (symlinked)	MCP merged into (real config)
Claude Code	`~/.claude/wow-my-zsh-AGENTS.md`	`~/.claude.json` (`mcpServers`)
opencode	`~/.config/opencode/AGENTS.md`	`~/.config/opencode/opencode.json` (`mcp`)
codex	`~/.codex/AGENTS.md`	`~/.codex/config.toml` (`[mcp_servers.<name>]`, comment-fenced)
cline	`~/.clinerules/00-canonical.md`	`…/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json` (`mcpServers`)
jcode	`~/.jcode/AGENTS.md`	`~/.jcode/mcp.json` (`mcpServers`, stdio-only)
mimo-code	`~/.config/mimocode/AGENTS.md`	`~/.config/mimocode/mimocode.json` (`mcp` — OpenCode fork)

Structural SIN enforcers (6 of 6 agents)

Text rules get skipped under load, so for every agent with a runtime hook we wire the SIN token-discipline toolkit (graphify, sin verify|review|debt, Simone-MCP, agent-grep) in by code: a session-start roster and/or a just-in-time nudge on a broad code search. All six — Claude, opencode, mimo, codex, jcode, and cline — are now structurally enforced.

codex — [[hooks.*]] in config.toml (roster inject + allow-nudge), fired via a codex() wrapper that adds --dangerously-bypass-hook-trust.
jcode — a pre_tool gate in [hooks] (block-once nudge on a broad search; no roster channel, no trust flag needed).
cline — a PreToolUse.sh file hook in ~/.cline/hooks/ (non-blocking context nudge; discovered by filename, no config edit or trust flag). Long assumed "text-only" — but cline shipped a file-hook runtime in v3.56→v4.0 that works in the VS Code extension, closing the last gap.

All are installed by install.sh, checked by doctor.sh, and touch only sentinel-fenced blocks or our own symlinked files (never auth/provider keys). Full mechanism, the binary/repo-level contract, and how each was reverse-engineered: docs/structural-enforcers.md.

L2 MCP budget (token discipline)

Always-on MCP schemas tax every agent turn. This registry tags each server:

Field	Meaning
`tier`	`core` · `optional` · `experimental`
`always_on`	`true` only for the explicit core profile; minimal remains empty

Install profiles:

bash ./install.sh                         # profile=minimal (default) — zero managed MCP
bash ./install.sh --profile core          # always_on only; currently zero
bash bin/sin-mcp-profile coding opencode  # task-scoped preview, hard cap 1–2 servers
SIN_ADMIN_CONFIRM=1 bash ./install.sh --profile full

merge-mcp prunes previously managed servers that are not allowed by the selected profile, so the live config converges to the declared surface. User-owned servers outside the managed sidecar are left alone.

SST verify-tokens and doctor.sh fail if a registry-managed server remains outside the selected budget. SST_ALLOW_OPTIONAL_MCP=1 is a diagnostic override, not the production default.

Adding an MCP server

Author the server once in shared/mcp/servers.json, then re-run ./install.sh to merge it into each agent's real config (or preview a single dialect with python3 scripts/gen-mcp.py <agent>). The agents array controls which agents receive it. Registry changes are covered by python3 scripts/test_gen_mcp.py.

stdio (command-based) server — works for all five agents:

"serena": {
  "transport": "local",
  "command": ["uvx", "--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"],
  "env": {},
  "agents": ["claude", "opencode", "jcode"]
}

remote (HTTP/SSE) server — set transport:"remote", a url, an optional type ("http" default, or "sse"), and optional headers for auth:

"myserver": {
  "transport": "remote",
  "url": "https://mcp.example.com/mcp",
  "type": "http",
  "headers": { "Authorization": "Bearer ${MYSERVER_TOKEN}" },
  "agents": ["claude", "opencode", "codex", "cline"]
}

Each agent renders remote servers in its own dialect (claude type:http, opencode type:remote, codex url+http_headers, cline type:streamableHttp). jcode is stdio-only — it silently drops remote servers, so don't rely on it for HTTP/SSE. Secrets stay as ${VAR} placeholders; never write resolved values.

Secrets policy

This repo is public. It contains no secrets — only ${VAR} placeholders resolved from the environment at runtime. Provide values via Infisical, 1Password, or your shell environment. Never commit resolved values. doctor.sh reports any ${VAR} referenced by the registry that is unset.

ChatGPT Web ↔ Mac tunnel (Secure MCP Tunnel)

Gives ChatGPT Web read/write access to local Mac directories via OpenAI's official Secure MCP Tunnel — no inbound port, no Cloudflare. The tunnel always runs under a launchd Watchdog (KeepAlive=true), so the connection is live whenever the Mac is on.

Connector: connectors/gpt-web-mac/README.md — complete implementation, setup, tests, operations and scheduled-task notes
Guide: connectors/gpt-web-mac/docs/SETUP.md — full setup, security, troubleshooting and Watchdog instructions
Orchestration skill: docs/sin-gpt-web.md — Orca OpenSIN browser control, ChatGPT lead loop, MiMo delegation and recovery
Installers:
- connectors/gpt-web-mac/scripts/install-tunnel.sh — standalone (tunnel, Combiner, dependencies and Watchdog). curl|bash-ready.
- scripts/install-gpt-web-mac-tunnel.sh — backward-compatible wrapper for the canonical connector installer Sets up tunnel profile + LaunchAgent Watchdog in one pass.
- scripts/install-gpt-web-mac.sh — wow-my-zsh-integrated variant.
Scope options: safe 4-folder subset, custom paths, full ~/jeremy/ (Vollzugriff, profile mac-jeremy-full-access), or full disk (/)
Watchdog: RunAtLoad + KeepAlive=true → starts at login, auto-restarts on crash and clean SIGTERM exit. Four gotchas documented (file: key ref, absolute Combiner/backend paths, PATH in plist for #!/usr/bin/env node, KeepAlive=true bare not SuccessfulExit:false — the latter silently drops the tunnel on SIGTERM).

One-time manual step the installer cannot do: grant Full Disk Access to tunnel-client (or the launching Terminal app) under System Settings → Privacy & Security → Full Disk Access. Without it, the filesystem server may be blocked from parts of ~/jeremy/. See the guide's "Full Disk Access" section for details.

Ecosystem

Ownership split with SIN-Save-Token (token discipline vs config router): see docs/ECOSYSTEM.md.

Diagrams: Archify is MANDATORY (no Mermaid)

Every agent in the fleet draws architecture / workflow / sequence / data-flow / lifecycle diagrams exclusively via the archify skill (tt-a1i/archify) — never Mermaid, PlantUML, ASCII art, or hand-rolled SVG. This is enforced in the canonical house rules (shared/AGENTS.md → Diagrams are MANDATORY via Archify) and ships as the /visual-diagrams skill in shared/skills/.

Install once (fleet-wide): npx skills add tt-a1i/archify -g
Use: Use archify to map this repository's runtime architecture.
Deliverable: a self-contained HTML file (dark/light toggle, PNG/JPEG/WebP/SVG export). Mermaid source blocks in chat/docs are forbidden — for inline vector in READMEs, export Archify's SVG, not a Mermaid diagram.
Five diagram modes: use architecture for topology, workflow for ordered processes, sequence for calls/timing, dataflow for data movement, and lifecycle for states/retries/terminal outcomes. Do not force every view into one overloaded graph.
Canonical artifacts: keep *.json (source IR), *.html (interactive render), and *.svg (original Archify vector export) synchronized. Verify with node scripts/verify-archify-diagrams.mjs.
Blocker behavior: if archify is unavailable in the runtime, report it and fall back gracefully — never silently substitute Mermaid.

Full standard + rationale: SIN-Save-Token README Diagramm-Standard: Archify ist PFLICHT.

Preview-Galerie mit echten Archify-Beispielen für alle fünf Modi: shared/skills/visual-diagrams/references/examples.md.

Example — wow-my-zsh architecture (generated with Archify)

Source IR: docs/wow-my-zsh-architecture.json · rendered HTML (dark/light toggle, PNG/JPEG/WebP/SVG export): docs/wow-my-zsh-architecture.html — this is the original Archify SVG export, with no browser chrome or screenshot padding. Open the HTML and press T to switch themes, E to export again.

How we got from "unusable first attempt" to this: docs/issue.md (root-cause) + docs/best-practices-archify.md (fleet-wide rules: grid placement, validation-as-gate, ≤12 nodes, one main path).

Reproducible diagram artifacts

Repository-owned diagrams are listed in docs/archify-manifest.json. The check is reproducible and runs in CI:

node scripts/verify-archify-diagrams.mjs

It validates the JSON IR, renders a temporary HTML artifact, runs Archify's final SVG checker, exports the original SVG through Archify's own Export menu, and rejects stale committed HTML/SVG files. Browser screenshots are never canonical artifacts.

Local prerequisite for the exporter: Node.js 18+, the Archify skill, Playwright, and Chromium or Google Chrome. The CI workflow pins Archify v2.11.0 and installs its browser explicitly; local users can run npm install --no-save playwright@1.58.2 and npx playwright install chromium once.

Credit

Supersedes the opencode-only Infra-SIN-OpenCode-Stack by generalizing its single-agent approach into a canonical, multi-agent, transpile-and-symlink model.

Original ChatGPT Web conversation controls

The dashboard can continue any mirrored saved chat through the semantic composer, branch the conversation from the latest visible response, and delete the saved conversation through ChatGPT Web's own visible menus and confirmation dialog. After a branch is created, a separate Yes / No decision asks whether the original conversation should be deleted; the default and Escape path keep it. Deletion is addressed by the original conversation URL so the new branch cannot be mistaken for its source.

The native chat toolbar also mirrors ChatGPT Web's own attachment input, temporary-chat toggle, model selector, and reasoning selector. Saved conversations can be renamed or archived through the original visible ChatGPT controls, while Dashboard-Name remains a separate local alias. These actions route to the machine that owns the conversation, including authenticated peer nodes; attachments are limited to 64 MB each and 128 MB total per request.

The automation editor loads a searchable inventory of open, parked, and visible ChatGPT-history conversations across registered machines. Each choice carries its title, conversation ID, canonical /c/<id> URL, and machine binding. A scheduled run reopens or reuses that exact URL and posts the prompt into the existing visible conversation, so the automation continues the selected chat rather than creating a new one. The composer also exposes the original Image create and Deep Research modes by selecting the corresponding entries in ChatGPT Web's own tools menu; selecting Chat removes those active mode chips. These actions remain tied to the real mirrored tab and work through registered peer nodes as well.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Repository files navigation

wow-my-zsh

Fleet memory (Cognee) — house rules only here

Philosophy

Directory layout

Quickstart

Authenticated agent Macs with agentcookie

Isolated agent Chrome (sin-chrome)

Dashboard automations

OCI VM operations

Notion productivity skill

Gmail skill (sin-gmail)

ChatGPT Web orchestration skill (sin-gpt-web)

Autonomous project completion

Per-agent config

Structural SIN enforcers (6 of 6 agents)

L2 MCP budget (token discipline)

Adding an MCP server

Secrets policy

ChatGPT Web ↔ Mac tunnel (Secure MCP Tunnel)

Ecosystem

Diagrams: Archify is MANDATORY (no Mermaid)

Example — wow-my-zsh architecture (generated with Archify)

Reproducible diagram artifacts

Credit

Original ChatGPT Web conversation controls

About

Releases

Packages

Contributors

Languages

Name		Name	Last commit message	Last commit date
Latest commit History 125 Commits
.github		.github
.pcpm		.pcpm
.planning		.planning
.rtk		.rtk
agents		agents
bin		bin
config		config
connectors/gpt-web-mac		connectors/gpt-web-mac
docs		docs
machines		machines
scripts		scripts
shared		shared
tests		tests
.gitignore		.gitignore
.gitleaks.toml		.gitleaks.toml
CLAUDE.md		CLAUDE.md
README.md		README.md
doctor.sh		doctor.sh
install.sh		install.sh
uninstall.sh		uninstall.sh

Uh oh!

Folders and files

Latest commit

History

Repository files navigation

wow-my-zsh

Fleet memory (Cognee) — house rules only here

Philosophy

Directory layout

Quickstart

Authenticated agent Macs with agentcookie

Isolated agent Chrome (sin-chrome)

Dashboard automations

OCI VM operations

Notion productivity skill

Gmail skill (sin-gmail)

ChatGPT Web orchestration skill (sin-gpt-web)

Autonomous project completion

Per-agent config

Structural SIN enforcers (6 of 6 agents)

L2 MCP budget (token discipline)

Adding an MCP server

Secrets policy

ChatGPT Web ↔ Mac tunnel (Secure MCP Tunnel)

Ecosystem

Diagrams: Archify is MANDATORY (no Mermaid)

Example — wow-my-zsh architecture (generated with Archify)

Reproducible diagram artifacts

Credit

Original ChatGPT Web conversation controls

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages