# Config Hygiene Edho Ferdian > >- - **Type:** Skill - **Install:** `agentstack add skill-edhoferdian-eef-config-hygiene-edho-ferdian` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [edhoferdian](https://agentstack.voostack.com/s/edhoferdian) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [edhoferdian](https://github.com/edhoferdian) - **Source:** https://github.com/edhoferdian/EEF/tree/main/.hermes/skills/config-hygiene-edho-ferdian ## Install ```sh agentstack add skill-edhoferdian-eef-config-hygiene-edho-ferdian ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # 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. 2. **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. 3. **Per-channel signals.** Each accumulation type has its own staleness test. Do not apply one rule everywhere. 4. **Soft-delete first.** Rename to `.disabled` > move to `~/.claude/_gc_trash//` > real deletion. Always keep an undo path. 5. **Human-in-the-loop, per item.** Show the evidence, then `[y/n/skip]`. There is no "yes to all". 6. **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_*`). 2. **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). 3. **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. 4. **Disable before deleting.** Rename to `.disabled`, run normally for at least one working session, and only then move to `_gc_trash/`. 5. **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. 2. **Rank by confidence** — broken/orphaned is high, merely old is low — and present a numbered table. Cap at ~20. 3. **Confirm one by one.** Show the evidence, then `[y/n/skip]`. The user can stop at any point. 4. **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. 5. **Log** the run. 6. **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](https://github.com/edhoferdian) - **Source:** [edhoferdian/EEF](https://github.com/edhoferdian/EEF) - **License:** MIT Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-edhoferdian-eef-config-hygiene-edho-ferdian - Seller: https://agentstack.voostack.com/s/edhoferdian - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.