harness-boundarylisted

A design lens for adding, changing, or reviewing a mechanism (rule / skill / hook / agent / workflow / runtime extension / prompt chain) in an agent environment: it asks which of 6 layers (model capability / skill = procedural memory / values & policy / eval / data & memory / runtime) the mechanism belongs to, why it cannot be left to the model itself, whether the next model generation will make it unnecessary, and whether it is worth keeping when the runtime is swapped (Claude Code → Pi → Codex), and returns Keep / Move / Simplify / Make temporary / Delete / Defer. Use when — "should this go in the harness?", "which layer does this belong in?", "can't the model handle this itself?", "will this survive a runtime change?", "the harness is bloated", "can I add this hook / rule / workflow?", when implementation-chain's Plan judges a task to change the harness itself (rules / skills / hooks / agents / settings in ~/.claude), or /harness-boundary. Delete / Simplify count as success. NOT for — a standalone build-or
shimo4228/claude-harness · ★ 3 · AI & Automation · score 82

Install: claude install-skill shimo4228/claude-harness

# harness-boundary — a design lens that treats as assets only what survives discarding the harness "The harness is the asset" is only half right. Harness logic that compensates for model-specific weaknesses goes stale with each model generation, and the runtime (tool execution, permissions, state, retry, agent loop) is being standardized and replaced. What remains are **other layers mixed into** the harness. This skill raises the questions for separating that mixture when a mechanism is added, changed, or reviewed. This is not an enforced architecture but a lens for judging asset boundaries, portability, and obsolescence. ## Core principles - Put model capability in the model. Do not reimplement it in the harness - Put procedural knowledge in skills - Keep values and responsibility boundaries explicit and inspectable - Put the definition of quality in evals - Put domain knowledge and history in data / memory - Keep the runtime as thin and swappable as practically possible And: **do not optimize to preserve the harness. Optimize to preserve what should survive swapping the harness.** When a new model makes existing logic unnecessary, that is not a design failure but the moment to delete. Delete / Simplify count as success. ## The 6 layers | Layer | Contents | Counterpart in this harness | Existing vocabulary | |---|---|---|---| | Model capability | reasoning / planning / coding / tool-use judgment / self-correction / decomposition / reflection | Claude itself (including