📦 deps(thirdparty): update snapshots
This commit is contained in:
@@ -0,0 +1,30 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user