Update — August 9, 2026: We are now working on a first-class skill observability system to identify exact skill activations, correlate them with agent sessions and outcomes, and make failures like these easier to diagnose.

Two instructions looked useful:

• JFDI: “Continue until acceptance is met or a permanent external blocker is proven.”
• Codebase Maintainability Guardrails: “Use for most substantial coding work.”

The first skill tried to remove permission latency. The second tried to stop coding agents from producing giant files, vague utility folders, and fragile refactors. Both expressed goals we still want: decisive execution and maintainable code.

Both hurt us. JFDI made the task's authority and endpoint elastic. The maintainability skill made its method and scope elastic. One encouraged the agent to keep absorbing production failures. The other attached a general hardening program to almost any meaningful change. We deleted both skills instead of writing more policy to reconcile them.

The evidence is not symmetrical. We can connect JFDI's literal permissions to specific decisions across a long release incident. For the maintainability skill, we can prove its broad trigger, the extra obligations it loaded, its appearance in a second failed simplification attempt, and the decision to remove it. We cannot assign every slow refactor to one instruction file. That distinction is part of the result.

Skill one made approval elastic

Three hours into a difficult Forge release, the operator tried to remove permission latency with a direct prompt: “approving everything to get u to $jfdi — fucking ship.” The intent was obvious. Stop asking. Take the shortest safe path to production.

JFDI interpreted that approval more broadly. Its 86-line instruction file granted standing approval to push main, run release orchestration, change provider policy, apply migrations, retry interrupted releases, and bootstrap Forge when Forge could not release itself.

The decisive lines described an embedded release operator:

- Continue until acceptance is met or a permanent external blocker is proven.
- Fix dependent backend, frontend, docs, CLI, telemetry, and release-contract gaps.
- Push or merge to canonical main when the request says ship or do it all.
- Apply a narrow provider-policy or binding allowlist expansion.
- Apply checked-in numbered migrations through the project migration gate.
- Perform one explicit exact-SHA retry after an interrupted run.
- Build locally and upload a runner/API bootstrap when Forge cannot release itself.
- Stop only when acceptance is met or the remaining blocker is outside the skill.

Each line was defensible alone. Together they collapsed three decisions:

• Permission: routine execution became standing approval for adjacent mutations.
• Scope: shipping one candidate became fixing dependent platform gaps.
• Persistence: making progress became continuing until a moving acceptance condition passed.

The release exposed real defects:

• Release evidence lacked changed files.
• Workflow discovery needed egress.
• The coordinator lost synchronization.
• Provider lookup needed another permission.
• Rollback fencing needed correction.

Each failure then authorized implementation for the next candidate.

candidate
  → platform or provider failure
  → policy, binding, controller, or component patch
  → new candidate
  → different failure
  → another patch

The agent remained locally rational while the release became globally absurd. JFDI did not cause the Cloudflare, Git, runner, or controller defects. It changed the agent's response: a release-platform defect discovered by a feature release silently joined the feature release.

Skill two made “substantial” mean “everything”

Codebase Maintainability Guardrails did not grant production authority. Its failure started earlier, in its trigger:

- Use for most substantial coding work, especially frontend/fullstack apps,
- greenfield apps, production refactors, UI migrations, and feature work.

Once triggered, it added a broad program of work:

• Structure: keep files under rough size limits and split code by product feature.
• Contracts: centralize shared interfaces and separate pure logic.
• Reliability: preserve persisted state, add structured logging and error boundaries, and harden tests.
• Presentation: inspect several real viewport sizes.

Most of those are good recommendations. The problem was packaging them as an automatic default for “most substantial coding work.” A narrow controller reduction could now inherit architecture, testing, observability, CSS, state-compatibility, and visual-QA concerns before its own acceptance condition was complete.

That is how a skill can slow work without containing a single unsafe command: it changes what completion appears to require. Instead of asking, “What is the smallest correct patch for this incident?”, the agent starts asking whether the surrounding code has the right modules, contracts, tests, file sizes, telemetry, and long-term shape.

• What we observed: In the replacement “restore and simplify” thread, the agent explicitly announced “maintainability guidance for the controller reduction” alongside test-strategy and autoreview guidance. That thread then spent another hour without restoring a simple release path.
• What we cannot claim: The skill was not the only cause. The release system was genuinely inconsistent, other skills were active, and ordinary agent judgment still mattered.

The release history gives us a bounded observation, not a controlled causal result. But the trigger was clearly wrong for the desired operating model. Engineering discipline should constrain a chosen change. It should not silently enlarge every change into a hardening pass.

Two useful intentions expanded the task differently

The distinction matters because the fixes differ:

• JFDI needed deletion. Its value proposition combined urgency, standing approval, cloud mutation, and an open-ended terminal condition.
• Maintainability guidance needed an explicit request. Its ideas were useful, but the automatic trigger turned them into ambient obligations. We deleted the bundle and left deliberate structural cleanup to explicitly requested skills.

We also narrowed two adjacent skills:

• Test Strategy Hardening now triggers only when the user asks to work on tests as a system, not whenever an implementation needs a regression test.
• Autoreview now runs only when requested or required by repository policy, and no longer depends on a specific helper, model, panel, or OpenClaw workflow.

The machine was not slow enough to explain the experience

Three user prompts became unusually long work containers:

• 7 hours 23 minutes: the coding turn that eventually included JFDI.
• Almost 7 hours: “keep going until you finish all 5 batches.”
• 2 hours 54 minutes: “ok do 1/2:3” expanded into D1 ownership work, physical API decomposition, and repository Worker extraction.

No single provider operation explains those durations:

• One exact bootstrap completed in 6 minutes 3 seconds.
• In another release, exact branch CI took 5 minutes 15 seconds.
• Duplicate queue CI then took 3 minutes 56 seconds.
• One runner did remain open for 30 minutes after useful build evidence existed.

That last stall should have produced one terminal incident receipt, not a generalized recovery and architecture cycle.

We reconstructed the long turns beside every terminal production-controller attempt through fence 56. The 7-hour-23-minute turn contained 13 controller attempts with 3 hours 26 minutes of aggregate release time. The 6-hour-57-minute turn contained 18 attempts with 4 hours 25 minutes of aggregate release time. Those totals are not cleanly subtractable because attempts overlapped and some intervals lack telemetry. They prove a narrower point: the agent kept one work container open between distinct releases for diagnosis, implementation, coordination, and the next candidate.

We stopped answering policy problems with more policy

An independent review thread eventually gave the useful diagnosis: “You are optimizing the release system instead of releasing.” It recommended quarantine, not one more controller feature: preserve the verified baseline, stop the architectural migrations, record the platform incident, and end the attempt.

Our first response reproduced the problem. We drafted a release-stop-loss skill and began adding precedence rules to JFDI and other guidance. The operator stopped that work:

“no i want to delete things, not add new skills”

Commit 519dff9 removed JFDI's 86-line instruction file and four-line UI manifest. Commit 243a0c6 removed the 63-line maintainability skill and pruned the test and review skills. The second diff removed 403 lines and added 72. Neither commit introduced a replacement policy layer.

Deletion reduced the number of instructions that future agents must reconcile. Existing agent rules already allow routine implementation, require scope preservation, and distinguish diagnosis from unauthorized expansion. A release attempt can ship its fixed candidate or end with a truthful incident. A separate task can then repair the platform.

Review both authority and trigger breadth

Agent skills are executable policy even when they contain no executable code. Review them on two independent axes:

1. Authority: What source-control, provider, database, credential, traffic, and production mutations does the skill permit?
2. Trigger breadth: How often does the skill load, and does the trigger match a user-requested specialty or an ambient category such as “substantial work”?
3. Scope: Does the skill constrain the requested task, or can its checklist redefine completion?
4. Terminal state: What ends an attempt? “Until success” is not a retry policy.
5. Composition: What happens when autonomy, quality, testing, review, security, and release skills all activate together?
6. Evidence: What observed outcome would justify keeping the skill rather than moving its useful ideas into explicit repository guidance?

The demonstrated result remains narrow. We inspected two operating contracts, connected one directly and one cautiously to observed behavior, and removed them from the canonical skills repository. We have not run controlled, otherwise-identical releases with and without either skill. Faster releases remain a hypothesis.

The durable lesson is more useful than “autonomy is dangerous” or “guardrails cause bureaucracy.” A skill hurts when its trigger or authority lets reusable advice redefine the task. Sometimes the safest improvement is not a smarter instruction. It is deleting the instruction that tried too hard to help.