unison
Ships with gsd-skill-creator: An adaptive learning and coprocessor architecture for Claude Code, built as an extension to GSD (open-gsd)
Claude Code
$ npx @opengsd/get-shit-done-redux@latest
Codex
$ npx @opengsd/get-shit-done-redux@latest
Cursor
$ npx @opengsd/get-shit-done-redux@latest
Gemini CLI
$ npx @opengsd/get-shit-done-redux@latest
GitHub Copilot
$ npx @opengsd/get-shit-done-redux@latest
OpenCode
$ npx @opengsd/get-shit-done-redux@latest
Windsurf
$ npx @opengsd/get-shit-done-redux@latest
From the README
What can you do with unison?
WebGL CRT shader engine -- Scanlines, barrel distortion, phosphor glow, chromatic aberration, and vignette with…
32-color indexed palette -- Five retro-computing presets (Amiga 1.3/2.0/3.1, C64, custom) with OKLCH-based palette…
Native PTY terminal -- Rust-backed pseudo-terminal with xterm.js emulator, watermark-based flow control, and tmux…
Window manager -- Amiga-style depth cycling, drag/resize, custom chrome with frameless Tauri window
Desktop shell -- Taskbar with process indicators, pixel-art icons, system menu, keyboard shortcuts (Alt+Tab, F10,…
Live dashboard -- All 6 planning doc pages render inside GSD-OS windows with file-watcher-driven refresh
First-boot calibration -- Three-screen wizard for color picking, CRT tuning, and theme selection
Boot sequence -- Amiga chipset initialization animation (Agnus, Denise, Paula, Gary), skippable
Security report
Not enough data
Known flaws
Not published
Signed build
Not published
Maintained
Jul 19, 2026
Last push
Licence
Not published
Runs as
Local process
On your machine
Deprecated
Not published
Signals from public registries, not an audit. Checked Nov 12, 2026.
gsd-skill-creator README
GSD Skill Creator
An adaptive learning and coprocessor architecture for Claude Code, built as an extension to GSD (open-gsd)
npx @opengsd/get-shit-done-redux@latest
npx gsd-skill-creator@latest
v1.49.561 — Living Sensoria
Eight composable modules (M1–M8) ship in v1.49.561, extending gsd-skill-creator with a native memory stack, a net-shift receptor substrate, a Markov-blanket boundary layer, and a teaching/co-evolution relationship layer. All modules default off via opt-in flags; v1.49.560 installs load unchanged.
| Module | What it adds | Guide |
|---|---|---|
| M1–M5 Memory Stack | Semantic graph, hybrid memory, trace ledger, branch-context, orchestration | docs/memory-stack.md |
| M6 Sensoria | Lanzara net-shift receptor substrate for skill activation | docs/sensoria.md |
| M7 Umwelt | Markov-blanket boundary with variational free-energy minimiser | docs/umwelt.md |
| M8 Symbiosis | Teaching ledger, co-evolution offerings, Quintessence five-axis report | docs/symbiosis.md |
Theoretical foundations (Lanzara 2023, Friston 2010, Kirchhoff et al. 2018, Foxglove 2026, Traag 2019) are documented with primary-source citations in docs/foundations/theoretical-audit.md.
Refinement wave (added 2026-04-18): six further components land in v1.49.561 — ME-5 output-structure frontmatter, ME-1 tractability classifier, MA-6 canonical reinforcement taxonomy, MA-1 eligibility-trace layer, MA-2 ACE actor-critic wire, ME-4 coin-flip teach warning. Keystone insight from Zhang et al. 2026: prompt-content edits are statistically indistinguishable from a coin flip except when the skill declares exploitable output structure. Overview + through-line: docs/refinement-wave.md. Individual guides: docs/tractability.md, docs/reinforcement-taxonomy.md, docs/actor-critic.md.
Continuation wave (added 2026-04-19): thirteen second-wave components across five bundles complete the Living Sensoria adaptation stack. Bundle 3 — Stability Rails (MB-1 Lyapunov, MB-2 projection, MB-5 dead-zone) applies adaptive-control stability theory (Sastry & Bodson 1989 / Narendra & Annaswamy 1989) to the K_H learning loop — guide: docs/stability-rails.md. Bundle 4 — Exploration Harness (MA-3+MD-2 stochastic selection, MD-3 Langevin noise, MD-4 temperature schedule) adds SGLD-grounded structured exploration (Welling & Teh 2011) — guide: docs/exploration-harness.md. Bundle 5 — Representation Frontier (MD-1 learned embeddings, MD-5 learnable K_H, MD-6 representation audit) introduces skip-gram embeddings (Mikolov et al. 2013) and per-(skill, task-type) K_H specialisation — guide: docs/representation-frontier.md. Bundle 6 — Authoring Tools (ME-2 model affinity, ME-3 A/B harness) provides developer-facing tier routing and significance-gated experimentation — guide: docs/authoring-tools.md. Bundle 7 — College + Rosetta bootstrap closes GAP-2 from the v1.49.132 AAR. All thirteen components default off; the full-stack flag-off invariant (SC-CONT-FLAG-OFF) is enforced by integration test.
Table of Contents
- The Problem: Why AI-Assisted Development Breaks Down
- How GSD and Skill Creator Solve It Together
- The Coprocessor Architecture
- GSD-OS Desktop Application
- Quick Start
- Documentation
- Security
- License
- Contributing
The Problem: Why AI-Assisted Development Breaks Down
AI coding assistants are powerful in short bursts, but they degrade on sustained, complex work. The core issues:
- Context rot -- As a session fills its context window, the AI loses track of earlier decisions, repeats mistakes, and produces lower-quality output. By the time you're deep into implementation, the assistant has forgotten why you made the architectural choices it's now contradicting.
- Amnesia between sessions -- Every new session starts from zero. The AI doesn't know what worked last time, what patterns you prefer, or what it should avoid. You re-explain the same things across every conversation.
- No workflow memory -- Recurring sequences (test, fix, commit, verify) are executed ad-hoc every time. The AI never learns that "after a test failure, you always check the fixture data first" or that "deploy means these seven steps in this order."
- Scaling complexity -- A single AI session can handle a function or a file. It cannot reliably coordinate a multi-phase feature across dozens of files without losing coherence, skipping steps, or drifting from the plan.
These aren't limitations of the models themselves. They're limitations of how work is structured around them.
How GSD and Skill Creator Solve It Together
GSD is the workflow engine. It solves context rot and scaling complexity by structuring work into phases with atomic execution boundaries. Each phase gets a fresh context window, a detailed plan, and persistent state tracking. The AI executes one well-scoped unit of work at a time, commits atomically, and hands off cleanly to the next phase. Context never rots because it never accumulates beyond what's needed for the current task.
Skill Creator is the learning layer that extends GSD. It doesn't replace any GSD functionality -- it observes how you work within the GSD lifecycle and builds reusable knowledge from your patterns:
- Observe -- Watches tool sequences, file patterns, corrections, and phase outcomes across sessions
- Detect -- Identifies recurring workflows using n-gram extraction and DBSCAN clustering when patterns repeat 3+ times
- Suggest -- Proposes skill creation from detected patterns, always requiring explicit user confirmation
- Apply -- Loads relevant skills automatically based on context, respecting a 2-5% token budget
- Learn -- Refines skills from your corrections with bounded guardrails (minimum 3 corrections, 7-day cooldown, maximum 20% change per refinement)
- Compose -- When skills consistently co-activate (5+ times over 7+ days), composes them into purpose-built agents and multi-agent teams
The two systems working together solve a fundamentally different problem than either one alone. GSD prevents the AI from degrading during work. Skill Creator prevents the AI from forgetting between work. The result is an AI development environment that maintains quality over long projects and gets meaningfully better the more you use it.
What They Solve Together
| Problem | GSD's Role | Skill Creator's Role |
|---|---|---|
| Context rot | Fresh context per phase, atomic execution | Pre-compiled skill activation eliminates re-explanation |
| Lost decisions | Persistent .planning/ state artifacts | Session observations capture decision patterns |
| Repeated mistakes | Plan verification against requirements | Bounded learning from corrections refines behavior |
| Scaling complexity | Phase decomposition with dependency graphs | Agent teams coordinate specialized roles |
| Workflow amnesia | Structured lifecycle (plan/execute/verify) | Pattern discovery codifies recurring sequences |
| Cross-session continuity | STATE.md tracks position and blockers | Warm-start briefings restore learned context |
The Coprocessor Architecture
Complex agent systems face the same coordination challenges that early computer designers solved decades ago: multiple specialized processors need to share resources, communicate efficiently, and synchronize their work without a single bottleneck controlling everything.
Skill Creator uses two complementary chipset models: the Amiga chipset for resource coordination within a single agent context, and the Gastown chipset for orchestrating multiple agents across parallel workstreams.
Amiga Chipset: Resource Coordination
The original architecture is modeled after the Amiga's custom chipset -- a system where dedicated coprocessors handled graphics, sound, and I/O in parallel while a lightweight kernel coordinated scheduling and resource allocation. This isn't an analogy for presentation purposes; it's the actual architectural pattern used to coordinate multi-agent teams.
Just as the Amiga distributed work across specialized chips rather than routing everything through the CPU, Skill Creator distributes agent responsibilities across four domain-specific chips:
| Chip | Domain | Real Computer Analog |
|---|---|---|
| Agnus | Context management -- memory allocation, context window budgets, state tracking | Memory controller |
| Denise | Output generation -- code production, documentation, rendering | Graphics processor |
| Paula | I/O operations -- file access, API calls, external tool integration | I/O controller |
| Gary | Glue logic -- routing, lifecycle coordination, inter-chip communication | Bus controller |
Each chip has dedicated budget channels (token budgets with guaranteed minimums), message ports (FIFO queues with reply-based ownership), and a 32-bit signal system for lightweight wake/sleep coordination -- the same primitives that real hardware uses for inter-processor communication.
Pipeline Lists: Declarative Workflow Programs
Pipeline Lists are declarative workflow programs -- sequences of WAIT, MOVE, and SKIP instructions synchronized to GSD lifecycle events. Inspired by the Amiga's Copper coprocessor (which executed display lists synced to the video beam), Pipeline Lists bring the same concept to workflow automation:
# A Pipeline List synchronized to GSD lifecycle events
- wait: phase-planned # Block until planning completes
- move:
target: skill
name: test-generator
mode: sprite # Lightweight activation (~200 tokens)
- wait: tests-passing # Block until tests pass
- skip:
condition: "!exists:.planning/phases/*/SUMMARY.md"
- move:
target: script
name: generate-docs
mode: offload # Execute outside context window
Pipeline Lists pre-compile during planning and execute automatically during phase transitions. The AI doesn't decide what skills to load at runtime -- the workflow program has already determined the optimal activation sequence based on observed patterns. This eliminates the overhead of skill selection from the critical path.
The Offload Engine: Bulk Operations Outside the Context Window
The Offload engine handles deterministic operations that don't need AI reasoning -- running test suites, generating boilerplate, formatting code, computing metrics. These operations are "promoted" from skill metadata to standalone scripts and executed as child processes, freeing the context window for work that actually requires intelligence.
The Exec Kernel
A prioritized round-robin scheduler coordinates the chips, managing 18 typed message protocols for inter-team communication and per-team token budgets with burst mode for temporary overallocation. Teams at different priority levels (phase-critical at 60%, workflow at 15%, background at 10%, pattern detection at 10%) share resources without starvation.
Why This Matters
More MCP servers from other plugins.
Questions about unison.
- Which coding agents can use unison?
- unison works in any agent that reads an MCP config file: Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf. Each agent reads it from its own file; this page names the file for each one.

