SidCorp-co

Epodsystem CLI — Design skill for Claude Code

Design community

One global, project-scoped CLI for the epod documentation-site CMS: page build/publish, .md <-> epod sync, store bootstrap, and a design-contract linter.

How to install Epodsystem CLI

This entry records only its repository, not the path inside it, so there is no exact command to give. Open SidCorp-co/epodsystem_cli and copy the folder into ~/.claude/skills/, or the file into ~/.claude/agents/.

What Epodsystem CLI does

One global, project-scoped CLI for the epod documentation-site CMS: page build/publish, .md <-> epod sync, store bootstrap, and a design-contract linter. Packaged as a Claude Code plugin.

Alternatives in Design

Opencode Vibe — 🏄‍♂️ Next.js 16 web UI for OpenCode - real-time chat with streaming, SSE sync, and React Server Components 178 ★
Spawn UX Worker — Spawn a repo-scoped UX-fixes worker session that drains only one repo's UX-fixes queue, via the CCC API 130 ★
Looplia — Looplia Skills provides curated skills—packaged as a Claude Code-compatible plugin—to accelerate workflow desi 99 ★

README

epod — a CLI for the epod platform, packaged as a Claude Code plugin

`epod` drives an epod store from the terminal: a Shopify-like platform of CMS pages, a Liquid theme, catalog and commerce, exposed over an MCP endpoint. Documentation sites are the first **pack** built on it, not the whole of it.

epod context                            # which store am I on?
epod page list                          # pages (id/slug/status)
epod theme get sections/doc-layout.liquid
epod schema liquid                      # what a theme can read at runtime
epod docs build file.md --slug srs      # the docs pack: markdown → page, published
epod docs nav                           # rebuild the sidebar from published pages
epod vi lint docs/02-SRS.vi.md          # the vi pack: does the Vietnamese read translated?
epod vi doc docs/02-SRS.md              # write it in natural Vietnamese instead

`epod --help` lists the groups; `epod --help` the verbs.

Two axes

A **resource** is a verb on an epod noun and carries no use case — `page`, `theme`, `menu`, `schema`. A **pack** is a workflow that owns its own policy and bundled assets — `docs` builds documentation sites, `vi` writes and audits the Vietnamese that goes into them. The split is what makes a second use case cheap: it is a directory under `epod_cli/packs/` and one entry in `PACKS`, with no change to the layers below it.

epod_cli/
  core/         transport, auth, store context, project config, text helpers
  resources/    pages · themes (+ the design-contract linter) · menus · schema
  packs/docs/   md2doc, doc blocks, build/sync, nav, bootstrap, sections/*.liquid
  packs/vi/     the Vietnamese style contract, its gateway client, lint and CTA audits
  cli.py        dispatch

A pack may import `core/` and `resources/`. Nothing in `core/` or `resources/` may import a pack, and pack code does not call `e.tool()` directly — a missing verb is added to `resources/` instead. `vi` is the one pack that im