31 lines
1.1 KiB
Markdown
31 lines
1.1 KiB
Markdown
# Iteration Philosophy
|
|
|
|
The first skill package is a routeable baseline, not the final answer.
|
|
|
|
## Principle
|
|
|
|
Improve the skill by the smallest change that increases reliability more than it increases context cost.
|
|
|
|
## What Good Iteration Looks Like
|
|
|
|
- tighten boundary before adding prose
|
|
- improve description before enlarging the file tree
|
|
- add references only when they remove ambiguity
|
|
- add scripts only when deterministic logic repeats
|
|
- add gates only when risk justifies maintenance cost
|
|
- prefer one strong next step over five vague upgrades
|
|
|
|
## Default Priority Order
|
|
|
|
1. trigger clarity and exclusions
|
|
2. execution assets that remove repeated manual work
|
|
3. promotion, governance, and portability only when reuse justifies them
|
|
|
|
## First-Version Rule
|
|
|
|
After the initial package is created, always surface the three highest-value next iteration directions. This keeps the author focused on the best improvement path instead of expanding the skill in every direction at once.
|
|
|
|
## Anti-Pattern
|
|
|
|
Do not treat iteration as "make the package bigger." A larger package is only better when routing, execution, or governance becomes materially more reliable.
|