mixocreative

Cia — Testing skill for Claude Code

Testing community

Claude Code / Codex skill: audits a codebase as a Viable System (Stafford Beer VSM).

How to install Cia

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

What Cia does

Claude Code / Codex skill: audits a codebase as a Viable System (Stafford Beer VSM). Maps modules onto Systems 1-5, walks the channels, finds cross-boundary invariant violations a green test suite cannot see.

Alternatives in Testing

  • Gsd To Autoforge Spec — Convert GSD codebase mapping to AutoForge app_spec.txt 1.8k ★
  • Claude Codepro — by Max Ritter - Professional development environment for Claude Code with spec-driven workflow, TDD enforcemen 1.6k ★
  • Test Driven Development.SKILL — Enforces TDD discipline with RED-GREEN-REFACTOR cycle 262 ★

README

cia — Code Integrity Auditor

A skill for Claude Code and OpenAI Codex that audits a codebase as a **viable system** in Stafford Beer's sense, and hunts the defect class that only such a view can see: **cross-boundary invariant violations**, also called **integration-level** or **emergent defects**.

The theory

Beer's Viable System Model (*Brain of the Firm*, 1972; *The Heart of Enterprise*, 1979) states that anything which stays alive in a changing environment has the same five-part structure, repeated at every level of recursion:

System Role In a codebase
1 does the work request handlers, domain services, workers
2 damps oscillation between the parts of System 1 locks, queues, deadlines, idempotency keys, ordering
3 commands and allocates resources to System 1 settings, feature flags, admin pages, config files
3* audits System 1 directly, bypassing its own reports test suites, probes, reconciliation scripts
4 faces the environment and the future vendor specs, external APIs, webhooks, callbacks
5 identity and policy; receives the algedonic (pain) signal defaults, catch-block posture, kill switches, fail-closed rules

The systems are joined by **channels**. Ashby's Law of Requisite Variety says a channel must carry as much variety as the thing it regulates, otherwise the control it claims to exercise is fictional. Beer's diagnosis of a failing organisation is almost never "a department is incompetent"; it is "a channel is missing, saturated, or bypassed".

Software fails the same way. Every function can be correct and the system still not viable, because a channel between two correct pieces is broken: a System 3 setting no System 1 code reads, a System 3\* suite that reports green because the tests touching the store never ran, a System 4 field interpreted against the code's belief rather than the vendor's definition, a System 1 step that re-reads System 3 live afte