Config Hygiene Edho Ferdian

Config Hygiene — Edho Ferdian Mode

Scope — read this first

Target: the user's own Claude Code environment — ~/.claude/*, project-level .claude/*, ~/.claude.json, and .mcp.json.

This is the deliberate complement to skill-audit-edho-ferdian, which audits the content quality of this ecosystem's skills/* and explicitly refuses to look at ~/.claude. This skill looks at exactly what that one refuses to: the environment those skills run inside.

| Question | Skill | |---|---| | Is this ecosystem's skill well-written, non-redundant, links intact? | skill-audit-edho-ferdian | | Should a new skill exist at all, and is it actually obeyed? | skill-authoring-edho-ferdian | | Is the environment carrying dead weight, and what does it cost? | this skill |

Never delete autonomously. Every candidate gets its own confirmation.

Design principles

1. Append-only configs leak. Skills, memory files, hooks and permission

entries only ever get added. Without a periodic pass they rot silently.

1. Periodic beats one-time. Scan roughly every 30 days, propose a small

batch each time. Cap a run at ~20 candidates — this is GC, not a purge.

1. Per-channel signals. Each accumulation type has its own staleness

test. Do not apply one rule everywhere.

1. Soft-delete first. Rename to .disabled > move to

~/.claude/_gc_trash// > real deletion. Always keep an undo path.

1. Human-in-the-loop, per item. Show the evidence, then [y/n/skip].

There is no "yes to all".

1. Log every run to ~/.claude/gc_log.md: what was touched, why, and

how to undo it.

Scan channels

| # | Channel | Path | Staleness / redundancy signals | |---|---|---|---| | 1 | Skills | ~/.claude/skills/*/ | Heavily overlapping names; never triggered in recent transcripts; domain mismatch with actual work; broken or empty SKILL.md | | 2 | Memory | ~/.claude/**/memory/*.md + index | Several index entries for one topic; contents contradicted by newer entries; dates already passed; orphans missing from the index; sub-100-word fragments that should merge | | 3 | Hooks | ~/.claude/hooks/ + settings | Scripts on disk referenced by no hook config; old versions superseded by rewrites | | 4 | Permissions | permissions.allow in settings.json / settings.local.json | Duplicates; specific entries already covered by a wildcard; one-off grants from past experiments | | 5 | MCP servers | ~/.claude.json, project .mcp.json | Servers that fail to connect; functional duplicates; long unused | | 6 | Automations | scheduled jobs / reminders, wherever kept | Fired one-shots older than 30 days; jobs whose target script no longer exists | | 7 | Project history | ~/.claude/projects/*/ | Stale handoff snapshots; session records superseded by newer state | | 8 | Runtime caches | cache/, file-history/, logs/, shell-snapshots/ | Sort by size and mtime; propose items >30 days old and large | | 9 | Context cost | every loaded component | See §Context budget below — a component can be healthy and still not worth its tokens |

Config tamper guard (harvested from ECC plankton-code-quality)

A distinct failure mode from all nine channels above: an agent facing a failing lint/format/build gate loosens the config instead of fixing the code — relaxing a .eslintrc rule, widening ruff.toml's ignore list, disabling a .shellcheckrc/.yamllint/.hadolint.yaml check — so the gate goes green without the underlying issue being fixed. This is metric-gaming, not cleanup, and it is the same shape of problem the false-positive/gaming patterns in gan-harness-edho-ferdian/references/loop-design-review.md already name for evaluator loops ("Goodhart-gaming the verifier" — the score climbs while the artifact gets worse). Treat a lint/format config edit found during a scan as a high-confidence flag, not a routine change: check whether it was made because a check was failing at the time, and whether it narrows coverage rather than reflecting a genuinely agreed convention (a narrowing with an inline comment explaining the deliberate exception is a documented convention, not tampering — same test language-code-review- edho-ferdian's Reflection gate already applies to a suppressed lens finding). This is a detection responsibility for this skill's channel 3/4 scans, not a new channel — a tampered config is the same "stale/unreachable correctness" concern as any other hook/permission drift, just with a gaming motive behind it.

Language/tool gate table (harvested from ECC plankton-code-quality)

Useful as a quick cross-check when this skill (or build-fix-edho-ferdian Phase 0) needs to confirm which formatter/linter should be running for a given file extension before treating its absence as a gap:

| Extension / stack | Formatter | Linter | Optional | |---|---|---|---| | .py | ruff format | ruff | ty, vulture, bandit | | .ts/.tsx/.js/.jsx | biome (or prettier) | biome (or eslint) | oxlint, semgrep, knip | | .sh/.bash | shfmt | shellcheck | — | | .yml/.yaml | — | yamllint | — | | .md | — | markdownlint-cli2 | — | | Dockerfile | — | hadolint (≥2.12.0) | — | | .toml | taplo | — | — | | .json | jaq | — | — |

Not exhaustive for every stack in this ecosystem (e.g. Go/Rust/Java tooling lives in those stacks' own build-fix/review references) — this table covers what ECC's plankton-code-quality ships and is meant as a fast reference, not a replacement for the per-stack detection tables already in build-fix-edho-ferdian and language-code-review-edho-ferdian. It is also not the setup guide — installing and wiring any of these tools (including the Husky/lint-staged git-hook layer around them) is code-quality-tooling-edho-ferdian's job; this table exists only so this skill's own tamper-detection scan (above) has a fast fact-check for "what should be running here" before flagging its absence or a suspicious edit as drift.

Context budget (channel 9)

Channels 1-8 ask "is this dead?". Channel 9 asks a different and often more useful question: "is this alive but not worth what it costs to keep loaded?" A perfectly maintained skill that is loaded every session and fires twice a year is a context-budget problem, not a staleness problem.

Estimate per component — skills (frontmatter always loaded, body on trigger), MCP server tool definitions (always loaded, frequently the single largest line item), rules and always-on memory files, hook definitions. Rank by tokens-per-session against observed usefulness, and report the top offenders with a concrete recommendation: disable, narrow the description so it stops loading speculatively, or move to LIBRARY (below).

DAILY vs LIBRARY. Borrowed from ECC agent-sort (fetched 2026-09-04) — the classification idea only, never its ECC install-planning machinery. Split components in two buckets, and require repo evidence for every DAILY call rather than a feeling:

• DAILY — should be available every session for the work actually being

done. Justified by concrete evidence: file extensions, lockfiles, framework configs, CI config, imports.

• LIBRARY — worth keeping reachable, not worth loading by default.

LIBRARY does not mean delete.

Strategic compaction

Not everything here is deletion. Context also gets reclaimed by compacting at the right moment. Auto-compaction fires at an arbitrary token threshold, which usually lands mid-task and discards exactly the working state that was still needed.

Compact deliberately at a phase boundary instead — for work running under dev-kickoff-edho-ferdian, that means after Stage 6 REMEMBER of a task, once the memory files have been written and the state that matters is on disk rather than in the window. A session that has just snapshotted can afford to lose its context; one mid-IMPLEMENT cannot.

Reference: harness operation

Hook wiring per-type and per-language, model routing tiers, context-budget mechanics, permission-widening posture, and todo-list-as-steering-surface — all detail that channels 3 (hooks), 6 (automations), and 9 (context cost) draw on but that doesn't need to sit inline in this file — lives in references/harness-operation.md.

ECC decommissioning track

This ecosystem's stated end state (D-005) is to stop depending on the ECC install entirely. That removal is a config-hygiene operation, and it is the one place where this skill is allowed to look at ECC-managed paths — to remove them, never to maintain them.

Run this track only on explicit request. It is ordered so that nothing breaks before its replacement exists:

1. Inventory what is actually ECC-managed — ~/.claude/agents/*,

~/.claude/rules/ecc/*, ECC-installed skills, ECC hook entries in settings.json, ECC-specific env vars (ECC_*).

1. Map each one to its native replacement in this ecosystem's own

skills/ (the porting record in project-memory/02-gap-analysis.md and the decision register are the source of truth for this map).

1. Report the unreplaced remainder. Anything ECC-managed with no native

equivalent is a porting gap, not a deletion candidate — surface it and stop. Do not remove a capability that has no replacement.

1. Disable before deleting. Rename to .disabled, run normally for at

least one working session, and only then move to _gc_trash/.

1. Check for dangling references after each removal: grep this

ecosystem's own skills/ for pointers into ECC paths. A native skill pointing at an ECC file is a D-005 violation and was already found once during the kelompok 3 port (e2e-testing-edho-ferdian, 4 locations).

Workflow

1. Scan the channels the user named, or all of them. Collect: path,

channel, the signal that flagged it, size, last-modified.

1. Rank by confidence — broken/orphaned is high, merely old is low —

and present a numbered table. Cap at ~20.

1. Confirm one by one. Show the evidence, then [y/n/skip]. The user

can stop at any point.

1. Soft-delete what was confirmed. Permission entries live in JSON with

no comments: back up the settings file, record each removed entry verbatim in gc_log.md, then remove it from the allow array.

1. Log the run.
2. Report: what was reclaimed, which channels are healthy, suggested

next review date.

Rules

• Never delete autonomously, and never offer a "yes to all".
• An item that is merely old is a low-confidence candidate. Broken,

orphaned, or unreachable is high-confidence. Do not present them at the same severity.

• Do not touch project source code. That is refactoring — see

dead-code-cleanup-edho-ferdian.

• Do not touch this ecosystem's skills/ content quality; that is

skill-audit-edho-ferdian's job. Channel 1 here only asks whether a skill is installed and loaded, never whether it is well written.

• ECC-managed paths are in scope only inside the decommissioning track,

and only ever to remove them.

Provenance

Adapted from ECC config-gc, context-budget, workspace-surface-audit, automation-audit-ops, strategic-compact, and the DAILY/LIBRARY concept of agent-sort — all fetched 2026-09-04. Consolidated into one skill with per-channel lenses per D-009 rather than six near-overlapping skills. The ECC decommissioning track has no upstream equivalent; it exists because of D-005 and inverts agent-sort's purpose (which was to plan an ECC install, not to retire one). The config tamper guard and language/tool gate table are a small harvest from ECC plankton-code-quality, fetched 2026-09-06 — only those two concepts were pulled in, not its PreToolUse/ Stop-hook enforcement machinery, since this skill works by human-confirmed scan-and-flag, not automatic blocking. references/harness-operation.md is a further D-005 harvest, fetched 2026-09-06, from ECC rules/common/hooks.md, rules/common/performance.md, and the 21 rules//hooks.md files — these were still active global instructions loading from the ECC rule tree, and this skill already owns the ~/.claude surface those files govern.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: edhoferdian
• Source: edhoferdian/EEF
• License: MIT

Install and usage instructions live in the source repository linked above.