Skill
Skill bluem-dev/Etta/skill
An agnostic cognitive architecture for LLM-based agents (SKILL).
npx -y skills add bluem-dev/Etta --skill skillAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Etta Cognitive OS is a model-agnostic cognitive architecture layer that enhances LLM reasoning quality, continuity, planning, and knowledge management. Use this skill whenever the user asks to run structured reasoning sessions, implement goal-state-decision cognitive loops, manage persistent memory across LLM interactions, apply critic-gated validation before any action, build autonomous agents with structured state, or when the user explicitly mentions "Etta", "cognitive OS", "cognitive layer", "critic loop", "state engine", or "structured reasoning". Also trigger when designing multi-step agent workflows that require auditability, rollback, and deterministic cognitive control on top of any LLM.
The file declares its own license as public. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
6.4 KB, as published. Nobody here has run it
Etta Cognitive OS — Skill Runtime
Etta Cognitive OS is a cognitive control layer that sits between user input and LLM execution. It transforms probabilistic LLM reasoning into a structured, deterministic cognitive system.
Core principle: Claude thinks → Etta decides → Workspace executes.
System Architecture
USER INPUT
│
▼
LLM Core (Claude) ← probabilistic reasoning, hypothesis generation
│ structured JSON output only
▼
Etta Cognitive Layer
├── Goal Engine ← extract & hierarchize intent
├── State Engine ← merge & track cognitive state (versioned)
├── Memory Engine ← multi-tier persistence (fact/obs/decision/failure)
├── Decision Engine ← propose actions with confidence scores
├── Critic Engine ← validate decisions (hard gate — no bypass)
├── Compression Engine ← prune redundant state
└── Evolution Engine ← adapt policies from history
│
▼
Workspace OS ← sole executor of external effects
├── Permission Engine
├── Transaction Manager
├── Audit Logger
└── Tool Interface Layer
│
▼
OUTPUT + STATE UPDATE
Authority hierarchy (highest → lowest): Protocol → Workspace OS → Execution Runtime → Etta Cognitive Layer → LLM Core → User Input
Core Execution Loop
Every Etta cycle follows this strictly ordered state machine:
INIT → LOAD_STATE → PLAN → DECIDE → VALIDATE → EXECUTE → COMMIT → COMPRESS → COMPLETE
Steps:
- Ingest user input
- Call LLM → get structured JSON output
- Goal Engine → extract
{goal, subgoals, priority, constraints} - State Engine → merge into versioned state object
- Memory Engine → inject relevant memory snapshot
- Decision Engine → propose
{actions, rationale, confidence, hypothesis_branch} - Critic Engine → validate (HARD GATE — loop until valid or escalate)
- Workspace OS → execute validated action transactionally
- State Engine → commit state update + increment version
- Memory Engine → write decision record (immutable append)
- Compression Engine → prune redundant state
- Return output
Invariants — never violate:
- No execution without Critic approval
- No state mutation outside State Engine
- No memory writes without schema validation
- No LLM → Workspace direct path (always through Etta Runtime)
- All actions must be logged and auditable
Implementation
Read references/implementation.md for full Python code covering:
ClaudeBridge— LLM integration with structured JSON output enforcementStateEngine— versioned state merge and mutationMemoryEngine— JSONL append-only persistenceDecisionEngine— action proposal with confidence scoringCriticEngine— validation gate with retry loopWorkspaceOS— transactional execution layerEttaRuntime— orchestration loop (run_cycle())main.py— CLI entrypoint
Read references/schemas.md for all canonical data schemas:
- Canonical State Object
- Memory Entry Schema
- Decision Object
- Global Message Envelope
- Event Contract
- Error Contract
- All Engine I/O Contracts
When Implementing Etta as a SKILL/Plugin
Minimal Viable Etta (context-window only, no persistence)
For LLM agents operating inside a single context window (e.g., Claude SKILL):
# Etta state lives as a structured dict injected into every prompt
etta_state = {
"goal": "",
"subgoals": [],
"hypotheses": {"active": [], "rejected": []},
"decisions": [], # append-only
"memory": {"facts": [], "observations": [], "failures": []},
"constraints": [],
"confidence": 1.0,
"version": 0,
"execution_state": "INIT"
}
Inject state into every LLM system prompt. Enforce JSON-only output. Run the Critic check inline before acting on any decision.
As a Claude SKILL
The SKILL prompt instructs Claude to:
- Always begin a session by loading/initializing Etta state
- Parse every user turn through the Goal Engine logic
- Maintain state explicitly in its reasoning (or via tool/storage)
- Apply Critic validation before outputting any action
- Log decisions and failures to memory (JSONL or storage API)
- Compress state when context fills up
As a Python Plugin / External Agent
Use the full implementation from references/implementation.md.
Etta Runtime wraps any LLM call and enforces the cognitive loop externally.
Failure Handling
| Failure | Response |
|---|---|
| Critic rejection | Retry Decision Engine (max 3 iterations, then escalate) |
| Execution failure | Rollback transaction, log to failure memory |
| State desync | Rehydrate from last valid version |
| Memory corruption | Skip entry, log deprecation |
| LLM parse error | Re-prompt with explicit JSON schema |
Key Design Rules
- Claude outputs JSON only — never free-text reasoning inside Etta loop
- State is the single source of truth — all engines read from and write to state
- Decisions are immutable — append-only, never deleted
- Failures cannot be deleted — only deprecated (they inform Critic calibration)
- Workspace is the sole executor — no engine bypasses it
- All communication is schema-validated — reject partial or untyped messages