Three skills that keep agentic work from turning into entropy

This post discusses reusable methods only. I have deliberately removed real tool names, local paths, resource identifiers, customer information, accounts, infrastructure topology, and operational parameters.

AI agents made me faster. They also amplified three old engineering problems.

First, code, files, automation, and intermediate artifacts accumulate. Agents are good at adding things. They do not naturally know when something has lost its last real user.

Second, agents can work in parallel while a database, port, GPU, simulator, or local service still exists only once. Parallelism quickly becomes interference.

Third, explanations drift as systems grow. A design document states intent, a runtime shows current behavior, and a log proves that an event occurred. They are often treated as the same kind of fact.

I wrote one skill for each problem. I call them Sweep, Musical Chairs, and Whiteboard.

An entity or system
→ Sweep: should it still exist?
→ Musical Chairs: who may operate it now?
→ Whiteboard: do we agree on how it actually works?

GitHub repository: zhaidewei/agent-skills — sanitized, reusable versions of all three skills, with installation instructions.

Sweep: remove by responsibility, not by age

Cleanup is not a search for files untouched for six months. Old code may be a stable authority. A file generated yesterday may already be an unmaintained duplicate.

The decision chain is short:

Does it have a real consumer and trigger?
→ Is it a source of truth or a projection?
→ If it is a projection, does it add unique value?
→ If it adds value, what keeps it correct?
→ keep / warn / archive / remove

The central distinction is between a source of truth and a projection. A source of truth owns a decision. A projection turns that decision into a more convenient form: an index, report, manifest, generated configuration, or cache.

Projections are useful. The dangerous version is a projection that adds no unique value, has no synchronization mechanism, and still looks trustworthy.

My rules are:

1. Keep a source of truth that has a real consumer, a trigger, and a necessary decision to own.
2. Keep a projection that adds performance, compatibility, auditability, or a distinct consumption shape, provided generation, validation, or expiry keeps it correct.
3. Warn when a projection has value but no reliable maintenance mechanism.
4. Archive or remove an entity with no consumer, authority role, or maintained unique value.

This skill does not primarily reduce file count. It removes false promises: things that look alive after the system has stopped maintaining them.

Musical Chairs: shared resources need leases, not just locks

Several agents reading documentation is usually harmless. Several agents rebuilding the same database, restarting the same service, or claiming the same port is not.

I call this Musical Chairs. A chair does not belong to whoever noticed it first. A participant obtains a time-bounded lease from a registry that all cooperative participants recognize.

The complete model is larger than locked/unlocked:

Resource definition + health + capacity
→ availability preflight
→ atomic expiring lease
→ operation
→ evidence and health check
→ release

I normally separate three modes:

• read for observation proven to have no side effects;
• write for ordinary mutations, task triggers, and uncertain operations;
• destroy for stop, restart, rebuild, deletion, or anything that disrupts current readers and writers.

Availability is not reservation. Another agent can take the resource between a check and the operation, so the final step must be an atomic lease acquisition. Every lease has a TTL. Long work renews it. Success, failure, cancellation, and handoff all release it. Nobody owns a chair forever.

This is coordination, not security. A lease helps rule-following clients cooperate. It does not grant permissions or replace database authorization, operating-system isolation, or cloud IAM.

The skill turns hidden collisions into visible states that can be waited on and explained, instead of two jobs damaging each other and leaving humans to guess.

Whiteboard: explain causality, not a glossary

I often read documentation in which every term has a definition, yet nobody can answer which fact wins when the system disagrees with itself.

The Whiteboard skill does not summarize chapters. It builds a causal model that another person can repeat:

External facts
→ internal authority / source of truth
→ projection / manifest
→ runtime execution
→ evidence / lineage / outcome
→ consumer interpretation

This is not a form to fill in. Missing layers must not be invented. But the explanation must answer:

1. What does each object own, and what does it explicitly not own?
2. What does it read, and who reads it?
3. Which object decides when facts conflict?
4. Is the relationship one-to-one, one-to-many, or many-to-many?
5. Can the current version explain history, or is an exact historical version required?
6. What does a log or evidence item prove, and what does it not prove?
7. What happens on zero matches, multiple matches, missing evidence, or drift?

“What should happen” and “what happened” stay separate. Configuration expresses intent. Runtime executes. Logs record outcomes. A log does not become a source of truth merely because it is closest to the incident.

A good whiteboard explanation leads with the conclusion, draws one causal chain, gives 6–12 numbered statements that can be repeated, and ends with a few long-lived invariants. The reader should leave able to reason about a new case, not merely recite my vocabulary.

How the three work together

Imagine several agents maintaining a shared local test environment.

Sweep identifies which configurations, caches, and old scripts still have consumers, which one is authoritative, and which are projections. It reduces the number of things the system must explain and maintain.

Musical Chairs decides who may read the environment, who may write, and who may perform a rebuild that interrupts everyone else. It reduces collisions during parallel execution.

Whiteboard puts configuration, generated artifacts, running services, logs, and test results back into their correct causal positions. It reduces drift in how humans and agents understand the system.

All three solve the same higher-level problem: do not let speed create entropy faster than the team can understand and govern it.