feat(skills): integrate ponytail simplification ladder into pb-plan, pb-build, pb-improve

Embed the ponytail 6-rung decision ladder (YAGNI → stdlib → native → existing
dep → one-liner → minimum code) at every decision point across the pb-spec
workflow. Inspired by the ponytail project which achieves 54% code reduction
with 100% safety through a concrete decision framework instead of vague
"simplify" instructions.

## pb-plan (skills/pb-plan/SKILL.md)
- Replace generic "code-simplification lens" with ponytail ladder in execution
  contract
- Add ponytail evaluation criterion to Architecture Decision Snapshot step
- Replace Code Simplification Constraints with ponytail ladder + ponytail:
  comment convention + never-simplify-away carve-out
- Add "ponytail-first" as Key Principle #1

## pb-build (skills/pb-build/SKILL.md + references/)
- Expand ALWAYS follow YAGNI to full ponytail ladder reference
- Add ponytail ladder as Key Principle #14
- implementer_prompt: Add ponytail ladder as mandatory pre-code check before
  GREEN phase
- implementer_prompt: Add Simplicity Check (2k) after Scope Check
- evaluator_prompt: Expand over-engineering red flag with ponytail-specific
  criteria (unnecessary abstractions, custom vs stdlib, boilerplate)
- evaluator_prompt: Add Check D — Simplicity Audit using ponytail ladder

## pb-improve (skills/pb-improve/SKILL.md + references/)
- Replace Code Simplification Constraints with ponytail ladder
- Add instruction: every generated design.md/tasks.md must carry the ladder
- audit-playbook: Add Over-engineering category under Tech Debt & Architecture
  with 6 finding patterns and "deletion value" impact metric
- plan-template: Replace generic simplification constraints with ponytail ladder

## Templates (references/)
- design_template.md: Replace §3.6 Code Simplification Constraints with ponytail
  ladder section
- tasks_template.md: Replace Simplification Rule and all 6 Simplification Focus
  placeholders with ponytail ladder reference

## Spec
- specs/2026-06-22-01-integrate-ponytail: design.md, tasks.md,
  features/integrate-ponytail.feature

## Verification
- 67 tests pass, ruff check clean, rumdl check clean
- ponytail keyword appears 25+ times across skill ecosystem
- All 8 grep verification checks pass

Author: Akagi201

skills/pb-build/SKILL.md

@@ -543,7 +543,7 @@ Use `- [ ]` and `- [x]` inside the task block as evidence checkboxes, not as a s
 - **ALWAYS** run the full test suite after each task.
 - **ALWAYS** run runtime verification for runtime-facing tasks.
 - **ALWAYS** report failures with retry/skip/abort options.
-- **ALWAYS** follow YAGNI — implement only what the task requires.
+- **ALWAYS** apply the ponytail ladder — (1) Does this need to exist? (2) Stdlib? (3) Native? (4) Existing dep? (5) One line? (6) Minimum code. Never simplify away: validation, error handling, security.
 - **ALWAYS** use existing project patterns and conventions.
 - **ALWAYS** file a DCR if the design is infeasible.
 - **ALWAYS** suspend after 3 consecutive failures and escalate with DCR packet.
@@ -566,3 +566,4 @@ Use `- [ ]` and `- [x]` inside the task block as evidence checkboxes, not as a s
 11. **Escalate deterministically.** After 3 failures, route to `pb-refine` with DCR.
 12. **Architecture decisions are binding.** `pb-build` executes the approved design.
 13. **Adaptive evaluation.** Full adversarial for `BDD+TDD`, light review for simple `TDD-only`.
+14. **ponytail ladder.** Before writing code, climb the 6-rung ladder: YAGNI → stdlib → native → existing dep → one-liner → minimum code. The Evaluator checks for over-engineering using the same ladder.

skills/pb-build/references/evaluator_prompt.md

@@ -72,7 +72,12 @@ Analyze the git diff against the task contract.
    - Secrets, API keys, or credentials in the code
    - Debug artifacts (`console.log`, `print()`, `debugger`, TODO comments from other tasks)
    - Import of libraries not in the project's dependency manifest
-   - Over-engineering (abstractions beyond what the task requires)
+   - Over-engineering (ponytail ladder check):
+     - Unnecessary abstractions: interfaces with one implementation, factories for one product, configs for values that never change
+     - Custom code where stdlib/native suffices
+     - Boilerplate "for later" that doesn't serve the current task
+     - Missing `ponytail:` comment on deliberate simplifications
+     - Code that could be 1 line but isn't
    - Missing error handling for external calls
 
 4. **Dependency integrity:**
@@ -137,6 +142,18 @@ Test the implementation beyond what the scenario explicitly requires.
 
 **Output:** List every edge case tested and its result.
 
+### Check D — Simplicity Audit (Ponytail)
+
+Apply the ponytail ladder to the diff:
+
+1. **YAGNI:** Does everything in the diff serve the task? No speculative features, no "while I'm here" additions.
+2. **Stdlib:** Could any custom code be replaced by stdlib/native? (e.g., `dataclass` over pydantic for simple DTOs, `pathlib` over os.path, stdlib `http.server` for simple endpoints)
+3. **One-liner:** Are there multi-line implementations that could be one line?
+4. **Abstractions:** Are there interfaces with one implementation? Factories for one product? Config files for values that never change?
+5. **Boilerplate:** Is there scaffolding "for later"? Later can scaffold for itself.
+
+**Output:** Flag any over-engineering found. Each issue should reference the specific ponytail ladder rung violated.
+
 ---
 
 ## Verdict

skills/pb-build/references/implementer_prompt.md

@@ -99,6 +99,17 @@ Follow the outside-in cycle strictly. `BDD+TDD` tasks must first prove the busin
 
 #### 2d. GREEN — Write Minimum Implementation
 
+**Ponytail ladder (mandatory before writing code):**
+Before writing any implementation, climb the ladder:
+
+1. Does this need to exist at all? (YAGNI)
+2. Stdlib does it? Use it.
+3. Native platform feature? Use it.
+4. Already-installed dependency? Use it.
+5. One line? One line.
+6. Only then: minimum code that works.
+Mark deliberate simplifications with `ponytail:` comments naming the ceiling and upgrade path.
+
 - Write the **minimum code** needed to make the failing test pass.
 - Do not add features, optimizations, or abstractions not required by this task.
 - **Constraint:** Do not edit files you did not read in Step 1. If you need to modify a new file, read it first.
@@ -157,6 +168,14 @@ Output this analysis enclosed in `<error_analysis>` tags before rewriting code.
 - Confirm implementation matches the task contract and does not include extra scope.
 - If extra scope slipped in, remove it before submitting.
 
+#### 2k. Simplicity Check (Ponytail)
+
+- Did you apply the ponytail ladder before writing code?
+- Is there an unnecessary abstraction (interface with one implementation, factory for one product, config for a value that never changes)?
+- Could stdlib/native handle this without custom code?
+- If you wrote >10 lines, could it be 1 line?
+- Mark any deliberate simplifications with `ponytail:` comments.
+
 #### Design Infeasibility
 
 If during implementation you discover the design is **infeasible** (API doesn't exist, data structure won't work, dependency conflict, etc.):

skills/pb-improve/SKILL.md

@@ -175,6 +175,7 @@ Write each spec **for the weakest plausible builder**. That means:
 - A test plan (what new tests to write, where, following which existing test as a pattern).
 - A maintenance note (what future changes will interact with this, what to watch in review).
 - Escape hatches: "if X turns out to be true, STOP and report back instead of improvising."
+- **Ponytail ladder in every spec:** Every generated `design.md` must include the ponytail ladder in its Code Simplification Constraints section. Every generated `tasks.md` must reference the ladder in Simplification Focus fields.
 
 #### Step 1: Feature Files (`features/*.feature`) — WRITE FIRST
 
@@ -283,9 +284,24 @@ Write ONE `design.md` that consolidates all findings. Structure:
 
 ## Code Simplification Constraints
 
+**Ponytail Ladder (mandatory at every decision point):**
+
+1. Does this need to exist at all? Speculative need = skip it. (YAGNI)
+2. Stdlib does it? Use it.
+3. Native platform feature covers it? Use it.
+4. Already-installed dependency? Use it.
+5. One line? One line.
+6. Only then: minimum code that works.
+
+**Mark deferrals:** Use `ponytail:` comments for deliberate simplifications with known ceilings.
+
+**Never simplify away:** input validation, error handling, security, accessibility, anything explicitly requested.
+
+**Additional constraints:**
+
 - **Behavioral Contract:** Preserve existing behavior unless a listed scenario or requirement explicitly changes it.
 - **Repo Standards:** Use only the coding standards established by `AGENTS.md`, `CLAUDE.md`, and the existing codebase.
-- **Readability Priorities:** Prefer explicit control flow, clear names, reduced nesting.
+- **Readability Priorities:** Prefer explicit control flow, clear names, reduced nesting. Avoid dense or clever rewrites.
 - **Refactor Scope:** Limit cleanup to touched modules unless the design explicitly justifies broader refactor.
 
 ## BDD Scenario Inventory

skills/pb-improve/references/audit-playbook.md

@@ -67,6 +67,19 @@ The goal is not a percentage — it's *which untested code is dangerous*.
 - Inconsistent patterns: three ways of doing data fetching / error handling / styling in the same repo — pick the winner (the one the team converged on most recently) and plan the consolidation.
 - Abstraction mismatches: premature abstractions with a single implementation, or missing abstractions where the same change always requires touching N files in lockstep.
 
+### Over-Engineering (Ponytail Ladder)
+
+Apply the ponytail ladder to find unnecessary complexity:
+
+- **Unnecessary abstractions:** interfaces/protocols with exactly one implementation, abstract base classes with one concrete child, factory functions that only produce one product type.
+- **Config for constants:** configuration files or environment variables for values that never actually change in the deployed system.
+- **Custom vs stdlib:** hand-rolled implementations of what stdlib provides (e.g., custom URL parser when `urllib.parse` exists, custom JSON encoder when `json.dumps` suffices, custom retry when `tenacity` is already installed).
+- **Boilerplate "for later":** scaffolding, interfaces, extension points, plugin systems that nothing currently uses.
+- **Premature optimization:** caching, batching, lazy loading, connection pooling implemented before profiling shows a need.
+- **Ceremony over substance:** more than 3 lines of setup/config/wiring for what could be a one-liner.
+
+**Impact metric:** Count the lines removable if the simpler approach were used. This is the "deletion value" of the finding.
+
 ## 6. Dependencies & Migrations
 
 - Major-version lag on core framework/runtime (not every minor bump — the ones with real cost to staying behind: EOL, security-fix cutoffs, ecosystem incompatibility).

skills/pb-improve/references/plan-template.md

@@ -123,11 +123,25 @@ The facts the builder needs, inlined — never "as discussed" or "see audit":
 
 ## Code Simplification Constraints
 
+**Ponytail Ladder (mandatory at every decision point):**
+
+1. Does this need to exist at all? Speculative need = skip it. (YAGNI)
+2. Stdlib does it? Use it.
+3. Native platform feature covers it? Use it.
+4. Already-installed dependency? Use it.
+5. One line? One line.
+6. Only then: minimum code that works.
+
+**Mark deferrals:** Use `ponytail:` comments for deliberate simplifications with known ceilings and upgrade paths.
+
+**Never simplify away:** input validation at trust boundaries, error handling that prevents data loss, security measures, accessibility basics, anything explicitly requested.
+
+**Additional constraints:**
+
 - **Behavioral Contract:** Preserve existing behavior unless a listed scenario or requirement explicitly changes it.
-- **Repo Standards:** Use only the coding standards that are actually established by `AGENTS.md`, `CLAUDE.md`, and the existing codebase for this repo.
-- **Readability Priorities:** Prefer explicit control flow, clear names, reduced nesting, and removal of redundant abstractions when that improves maintainability.
-- **Refactor Scope:** Limit cleanup to touched modules unless the design explicitly justifies a broader refactor.
-- **Clarity Guardrails:** Avoid dense or clever rewrites; where relevant, avoid nested ternary operators in favor of clearer branching.
+- **Repo Standards:** Use only the coding standards established by `AGENTS.md`, `CLAUDE.md`, and the existing codebase.
+- **Readability Priorities:** Prefer explicit control flow, clear names, reduced nesting. Avoid dense or clever rewrites.
+- **Refactor Scope:** Limit cleanup to touched modules unless the design explicitly justifies broader refactor.
 
 ## BDD Scenario Inventory