Agent Skills › TNTcraftHIM/Piik › ponytail

ponytail

GitHub

指导实现最小化连贯设计，优先复用和标准库，减少维护负担。用于代码审查、重构及实现设计决策，确保边界正确与依赖精简。

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

Trigger Scenarios

请求代码审查或重构涉及功能实现设计选择技术依赖时

Install

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

More Options

Non-standard path

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

Use without installing

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.