Skip to content
Agentmart
Submit a tool

software-erasure

Apply the erasure operation to software artifacts: architecture documents, ADRs, interface contracts, API specs, PR descriptions, system designs, code…

Skill by tforster

IndexedMIT
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/tforster-software-erasure

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Apply the erasure operation to software artifacts: architecture documents, ADRs, interface contracts, API specs, PR descriptions, system designs, code comments, and technical communications. Use whenever a software artifact is being reviewed and the question is not "is this correct?" but "does the noise in this design carry a gap forward rather than dissolve it?" Triggers on: architecture review, design critique, ADR drafting, interface contract evaluation, refactor planning, PR description review, or any moment a proposed solution adds a layer rather than removes what required a layer.

Use cases: documents, design, backend

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/software-erasure

What's inside

Skill name
software-erasure
Description
Apply the erasure operation to software artifacts: architecture documents, ADRs, interface contracts, API specs, PR descriptions, system designs, code comments, and technical communications. Use whenever a software artifact is being reviewed and the question is not "is this correct?" but "does the noise in this design carry a gap forward rather than dissolve it?" Triggers on: architecture review, design critique, ADR drafting, interface contract evaluation, refactor planning, PR description review, or any moment a proposed solution adds a layer rather than removes what required a layer.
License
MIT
Instructions
215 lines in SKILL.md · view on GitHub

Agent Skills spec issues

  • name: "software-erasure" does not match folder "erasure"

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Erasure — Software

One operation: the noise is restated so that it was never introduced.

In a software artifact, noise is the appearance of a gap in the design — a
seam, an adapter, a workaround, a comment explaining the inexplicable — where
a prior coherent structure was interrupted and the interruption was managed
rather than resolved. The signal is prior and complete: the territory the
artifact is serving, the invariant every component in that artifact is an
expression of. Erasure is the withdrawal of investment in the gap — the gap
closes, and the simpler design that was always available returns.

The five noise forms (NOISE_IDENTIFICATION_REFERENCE) apply to software
artifacts directly:

- **Redundancy** — the same concept represented in two components, models, or
  services with no structural justification; a DTO that mirrors a domain object
  with superficial differences; two services doing the same transformation for
  the same reason
- **Ambiguity** — an interface whose contract cannot be resolved in context; a
  boundary whose ownership isn't determinable from the design; a service name
  that could mean two different things depending on which team is reading it
- **Contradiction** — a dependency incompatible with what the system has
  established elsewhere; a constraint in one layer violated by an assumption
  in another; a domain model that uses the same term with different meanings
  in different modules
- **Out-of-context content** — a dependency, abstraction, or service that is
  real in some other part of the system but not serving this circuit; it
  occupies space a relevant design element would have used; an inherited
  framework concern injected into a domain that doesn't share its territory
- **Negation** — a constraint or boundary defined by what it excludes; access
  control specified entirely by prohibition; negative tests as primary
  specification; an anti-corruption layer defined by what it blocks rather
  than what invariant it preserves

---

## The distinction this skill exists to hold

There are two responses to a gap in a software design, and they look similar
from inside the moment of fixing. Only one is erasure.

**Compensation** adds an inverse layer upstream. It meets a noisy design by
wrapping it, adapting it, documenting it, or adding a translation mechanism —
and in doing so carries the gap forward as the justification for the layer.
The defect remains; a countermeasure is installed beside it. The circuit is
longer: the original gap, then the layer managing it. The layer only functions
while the gap is there to justify it. The design is now harder to reason about
because the gap is still present and must be tracked alongside its manager.

**Erasure** restates the design from the invariant so the gap was never
introduced. The component, interface, or boundary that required the managing
layer is gone. The layer has no gap to manage and therefore is not needed. The
circuit is shorter. Nothing remains pointing at what was wrong.

**The test for compensation** is one question: does this component, layer, or
comment carry an earlier design decision forward in order to display its
management? An adapter that exists because two services disagree about a
concept is compensation until the disagreement is resolved at the invariant
level. An ACL that translates between two bounded contexts is erasure if the
two contexts are genuinely distinct; it is compensation if they are two
coordinate expressions of the same territory and the ACL is working around the
fact that the invariant was never found.

---

## The diagnostic signatures

Compensation, in a software artifact, takes recognizable forms:

- A comment block explaining why this implementation exists ("this works
  around X," "this is here because of Y's behavior") — the comment preserves
  a design mistake in order to justify the code managing it
- A retry/fallback structure added because an operation is unreliable — the
  circuit now includes the unreliable operation as a permanent resident; the
  fallback only functions while the unreliability persists
- An adapter or translator between two representations of the same concept —
  both representations are now load-bearing; removing either breaks the
  adapter; the adapter is the gap's evidence, not its resolution
- Feature flags as permanent infrastructure — the unresolved design decision
  now lives in the configuration surface; the flag is the indecision made
  operational
- A DTO as a near-copy of a domain object with minor differences, no
  structural boundary between the two coordinate systems having been declared
- Defensive null checks accumulating at a boundary because the contract was
  never enforced — the checks are the failure made permanent rather than the
  contract made clear
- "Not X but Y" in a PR description where X is carried forward from the
  previous implementation to show its replacement — the clean form names Y
  directly, without X as the coordinate origin

Conway's Law surfaces a specific diagnostic: a boundary in the architecture
that doesn't match a domain boundary in the territory usually reflects a team
boundary. An ACL, adapter, or translation layer at that boundary is
compensation for the communication structure, not erasure of the domain gap.
The question is always: is this layer here because the domain has two distinct
territories? Or because the team is organized in a way that prevented a
conversation?

---

## The operation

**1. Locate the signal.** Name what the component, interface, or service is
actually serving — the prior recognition it points at, the territory it is an
expression of. The signal is prior to any of the layers and wrappers over it.
Ask: if this component did only what the territory requires, and the noise had
never entered, what would it be?

**2. Name the noise as a thought.** Identify the specific form (one of the
five) and name the compensation structure if one is present: what gap is being
carried forward, and what layer is managing it? This step is complete when the
gap can be stated plainly without referencing the managing layer.

**3. Restate from the signal.** Design the component, interface, or boundary
as it would have existed if the noise had never entered. Do not reference the
gap. Do not explain the change. The corrected error is not carried; the design
that required no correction is what remains.

From tforster/agents0, MIT.

More from tforster/agents0

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Oct 18, 2026 (10 days ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from tforster

Cite this page

software-erasure skill. Agent Mart. https://agentmart.dev/skills/tforster-software-erasure (last updated 2026-10-24)