Agent Skills › TNTcraftHIM/Piik › ponytail

ponytail

GitHub

Ponytail是一种极简主义开发方法论，旨在通过YAGNI原则选择最小可行实现。它指导开发者在编码、重构和设计时，优先复用现有代码和标准库，避免过度工程，确保交付完整体验的同时保持代码简洁和低维护成本。

.agents/skills/ponytail/SKILL.md TNTcraftHIM/Piik

触发场景

用户要求最小化实现或遵循YAGNI原则进行代码审查、重构或实施设计决策需要评估依赖选择以减少系统复杂性

安装

npx skills add TNTcraftHIM/Piik --skill ponytail -g -y

更多选项

非标准路径

npx skills add https://github.com/TNTcraftHIM/Piik/tree/main/.agents/skills/ponytail -g -y

不安装直接使用

npx skills use TNTcraftHIM/Piik@ponytail

指定 Agent (Claude Code)

npx skills add TNTcraftHIM/Piik --skill ponytail -a claude-code -g -y

安装 repo 全部 skill

npx skills add TNTcraftHIM/Piik --all -g -y

预览 repo 内 skill

npx skills add TNTcraftHIM/Piik --list

SKILL.md

Frontmatter

{
    "name": "ponytail",
    "license": "MIT",
    "description": "Choose the smallest coherent implementation for Piik coding, code review, refactoring and implementation design, including dependency choices. Also use when Ponytail or YAGNI is requested; not for ordinary prose or status.\n"
}

Ponytail · Piik

Reduce what Piik must own while delivering the complete requested experience. This is an implementation method under AGENTS.md, not permission to reduce scope or defer design. The repo adaptation and license are documented in UPSTREAM.md.

Understand The Responsibility

Read the affected owner and actual flow before choosing a solution. Establish the user outcome, state/resource lifetime and consumers that must keep working. For a bug, trace where the incorrect fact or action first arises and check sibling callers of that owner. Correct that boundary instead of adding a guard to each symptom. A shared guard is useful only if it restores the real contract.

For UI, inspect the existing interaction and visual primitives before adding a control, panel, status or animation. A reused component must still have the right meaning, placement and lifecycle; reuse alone does not establish design quality. Different responsibilities need not look or behave identically.

Choose The Smallest Coherent Design

Use this order to find a sufficient solution, not as a mandatory research tour:

Remove speculative additions that the requested outcome does not need.
Reuse the existing owner, component or helper when its semantics and lifetime fit.
Prefer standard-library, native-platform or already-installed capabilities.
Use a mature dependency when it reduces total ownership more than custom code.
Implement the remaining behavior in a cohesive module with a narrow interface.

Compare user effort, state, dependencies and maintenance, not just lines or file count. A larger correction is justified when it removes competing writers or finishes the affected flow. Keep readable code and clear boundaries rather than compressing logic into a one-liner or one oversized file.

Apply the shared implementation rules for helper boundaries, typed validation, comments and generated sources rather than maintaining separate coding rules in this skill. Preserve useful provenance and required license notices when removing replaced paths.

Verify And Finish

Verify the requested behavior at the affected boundary using the project's existing checks. New mechanisms need evidence for their actual success, failure and lifecycle behavior; a test for each branch or helper is not the goal. Use Stop That Shit to keep verification proportionate; required checks and delivery remain in CONTRIBUTING.md.

Check the result against the intended experience and remove unnecessary additions. Report the outcome, meaningful evidence and material limits at the detail the user needs. Do not ship an easier subset as completion or impose a fixed response length.

Optional Intensity

Default full applies the method above. If requested, lite focuses on the scoped implementation and obvious reuse; ultra more aggressively removes unnecessary ownership within that scope. These levels change simplification effort, never the requested result, design quality, authority or verification.