Seven-Rung Ladder Decision Framework in Ponytail: How It Works

The seven-rung ladder is Ponytail's hierarchical decision-making protocol that forces the agent to exhaust the simplest solutions—from rejecting unnecessary work (YAGNI) to writing minimal code—before implementing any feature.

The seven-rung ladder decision framework is the core philosophy behind Ponytail, an AI coding agent designed to mimic a "lazy senior developer." Defined in the DietrichGebert/ponytail repository, this ordered checklist prevents over-engineering by requiring the agent to validate seven increasingly specific constraints before writing new code.

What Is the Seven-Rung Ladder?

The seven-rung ladder is a prioritization framework that dictates how Ponytail solves coding tasks. Rather than immediately generating implementations, the agent climbs a metaphorical ladder, stopping at the first rung that yields a valid solution. This ensures the smallest, most maintainable implementation possible.

The framework is formally documented in lines 34-43 of skills/ponytail/SKILL.md and embedded in the agent's prompt templates via commands/ponytail.toml.

The Seven Rungs in Priority Order

Here are the seven decision steps, evaluated in strict sequence:

1. YAGNI (You Aren't Gonna Need It) — Does this need to exist at all? If the feature isn't required, Ponytail skips it entirely and states why in one line.

2. Reuse Existing Code — Is there an existing helper, utility, type, or pattern already in the repository? Reuse it instead of re-implementing.

3. Standard Library — Does the language's standard library provide this functionality? Prefer built-in functions and classes.

4. Native Platform Features — Can a browser element, OS capability, or database constraint solve this without adding dependencies?

5. Already-Installed Dependencies — Is a suitable dependency already present in package.json, requirements.txt, or similar? Use it rather than adding a new package.

6. One-Line Solution — Can the implementation collapse to a single expression or statement?

7. Minimum Code That Works — Only as a last resort, write the smallest implementation that satisfies the requirement, adding no extra scaffolding.

The Ladder as a Reflex: Read First, Then Climb

According to AGENTS.md and the prompt logic in hooks/ponytail-instructions.js, the ladder is a reflex, not an afterthought. Ponytail does not start coding until the problem is fully read and the affected code traced. The agent climbs only after understanding the full context, ensuring the "laziest" (most efficient) correct change.

Practical Examples Across Execution Modes

The same request produces different outputs depending on Ponytail's intensity mode (lite, full, ultra), but the decision flow always respects the seven rungs.

Full Mode: Standard Library First

When asked to add caching in full mode, Ponytail stops at rung 3 (stdlib) then rung 6 (one-liner):

from functools import lru_cache

@lru_cache(maxsize=1000)          # Rung 3 satisfied, collapsed to one line (Rung 6)

def fetch_data(url: str) -> str:
    # original implementation omitted for brevity

    ...

This skips custom cache classes (rung 2) because the standard library solution is available.

CLI Invocation

ponytail full "Add a cache for these API responses."

The agent automatically follows the ladder, citing that functools.lru_cache satisfies the need (rungs 3 and 6) and that no custom class is required.

Ultra Mode: YAGNI Extremist

In ultra mode, Ponytail stops at rung 1:

No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm.

This demonstrates rung 1 adherence—refusing to implement until proven necessary.

Key Source Files

The seven-rung ladder is implemented across several files in the DietrichGebert/ponytail repository:

• skills/ponytail/SKILL.md (lines 34-43): Defines the ladder and full Ponytail behavior.
• commands/ponytail.toml: Stores the prompt template embedding the ladder logic.
• hooks/ponytail-instructions.js: Emits the ladder description to the user session.
• AGENTS.md: Documents the "read-first, then climb" philosophy.
• README.md: Provides the public overview of the framework.

Summary

• The seven-rung ladder decision framework is Ponytail's core methodology for preventing over-engineering.
• Rungs are evaluated in strict order: YAGNI → Reuse → Stdlib → Platform → Installed Deps → One Line → Minimum Code.
• The framework is hardcoded in skills/ponytail/SKILL.md and enforced through prompt templates in commands/ponytail.toml.
• Ponytail treats the ladder as a reflex, requiring full problem comprehension before climbing.
• Execution varies by mode (lite, full, ultra), but always respects the hierarchical constraints.

Frequently Asked Questions

What are the seven rungs of the Ponytail ladder in order?

The seven rungs are: (1) YAGNI—reject unnecessary features, (2) Reuse existing codebase helpers, (3) Use standard library functions, (4) Leverage native platform features, (5) Utilize already-installed dependencies, (6) Collapse to a one-line solution, and (7) Write the minimum code that works.

Where is the seven-rung ladder defined in the Ponytail repository?

The ladder is formally defined in lines 34-43 of skills/ponytail/SKILL.md. It is also embedded in the agent's prompt system via commands/ponytail.toml and surfaced to users through hooks/ponytail-instructions.js.

How does Ponytail's ultra mode differ from full mode when using the ladder?

In ultra mode, Ponytail aggressively prioritizes rung 1 (YAGNI), often refusing to implement features until proven necessary by profiling data. In full mode, the agent climbs to rung 3 or 6 to produce working standard-library solutions, while lite mode may climb higher to satisfy requests quickly.

Why does Ponytail wait before climbing the ladder?

According to AGENTS.md, the ladder operates as a reflex that triggers only after the problem is fully understood and the affected code traced. This prevents premature optimization and ensures the agent selects the correct rung based on complete context rather than partial information.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}