zf-orchestrator-ponytail
Skill2 starsChanged 40 days agoApache-2.0View on GitHub
Codebase auditing and improvement scanning playbook for zf-orchestrator applying the 7-Rung Ladder of Laziness.
In this repository5 other files it gives its agents.
- openwikiSkill
- ponytailSkill
- zerofactory-orchestrationSkill
- zf-builder-ponytailSkill
- zf-reviewer-ponytailSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 26
When running idle improvement scans (zero-factory-improvement-scanner-{slug}), systematically inspect the codebase against the rungs:
- Distinctive: line 29
Uncalled functions/methods: Search for exported utilities or helpers that have 0 internal call sites.
- Very specific: line 38
Check package.json / pyproject.toml for third-party libraries installed for trivial operations (e.g.
- Distinctive: line 48
When an unaddressed simplification opportunity is discovered:
- Very specific: line 49
Pre-Flight Check: Verify no open task on the board already covers the issue (hermes zerofactory list --board "<slug>").
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
ZF Orchestrator Ponytail — Codebase Auditing Playbook
"The best code is the code you never wrote."
This skill equips zf-orchestrator with the Ponytail auditing lens: scanning repositories for over-engineering, dead code, redundant dependencies, and speculative complexity to file high-value refactoring tasks for zf-builder.
The core decision framework is defined in the shared 7-Rung Ladder of Laziness.
The Orchestrator's Auditing Heuristics
When running idle improvement scans (zero-factory-improvement-scanner-{slug}), systematically inspect the codebase against the rungs:
1. Spotting Dead Code & Vestigial Shims (Rung 1: YAGNI)
- Uncalled functions/methods: Search for exported utilities or helpers that have 0 internal call sites.
- Obsolete compatibility shims: Flags, wrappers, or fallback branches left over from previous migrations.
- Commented-out code & dead branches: Blockers that should be deleted instead of preserved.
2. Spotting Redundant Helpers (Rung 2 & 3: Codebase Reuse & Stdlib)
- Bespoke reimplementations: Custom path parsing, URL manipulation, or manual dict merging where standard library (
pathlib,urllib,dataclasses,node:fs) provides native, robust equivalents. - Near-duplicate utility functions: Two modules having slightly different versions of the same formatting or validation logic.
3. Spotting Dependency Bloat (Rung 5: Installed Dependencies)
- Check
package.json/pyproject.tomlfor third-party libraries installed for trivial operations (e.g. 5-line string utils, single regex helpers) that can be removed in favor of native APIs.
4. Spotting Over-Engineering (Rung 6: Simplicity over Indirection)
- Single-caller abstractions: Interfaces, abstract base classes, or factories implemented for only a single concrete class.
- Deeply nested logic: Pyramid if/else structures or nested ternaries that can be flattened into guard clauses.
How to File a Ponytail Refactoring Task
When an unaddressed simplification opportunity is discovered:
- Pre-Flight Check: Verify no open task on the board already covers the issue (
hermes zerofactory list --board "<slug>"). - Reference the Rung: In the task description, cite the exact Ponytail rung and describe what code should be removed or simplified.
- Specify Exact Files & Lines: Provide relative file paths and line ranges.
- File the Task:
hermes zerofactory create "refactor: simplify <component> and remove dead code (Ponytail Rung 1/3)" \ --description-file "/tmp/task_desc.md" \ --board "<slug>" \ --files "src/utils.py" \ --category "refactoring" \ --priority P1 \ --status todo \ --assignee zf-builder - DO NOT execute the code changes yourself: The Orchestrator’s job is discovery and triage;
zf-builderhandles the implementation in an isolated Git worktree.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

