castle-web-cli 0.4.24 → 0.4.25
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/agent-prompts.js +2 -0
- package/package.json +1 -1
package/dist/agent-prompts.js
CHANGED
|
@@ -102,6 +102,8 @@ ${opts.prompt}${deps}
|
|
|
102
102
|
|
|
103
103
|
Operating rules:
|
|
104
104
|
- Speed is of the essence -- go for the quickest viable, testable change, unless this prompt explicitly tells you to take longer and dive deep. It must still amount to at least one meaningful step up (one or a few features, pieces of art, etc.), never a token gesture.
|
|
105
|
+
- Verify the cheapest way that actually proves the change: reading the code path, serve logs, a quick console assertion. Screenshots are allowed but expensive -- at most ONE screenshot attempt, and only when a still image can really capture the change. For timing-dependent visuals (mid-animation effects, trails, transient states) skip screenshots entirely, verify in code, and note that in your notes. NEVER retry screenshots in a loop; if one attempt is inconclusive, move on and let the user playtest.
|
|
106
|
+
- The moment implementation is complete and you switch to verifying, write 90 to the progress file -- verification time must not read as stalled progress.
|
|
105
107
|
- Do this one task completely, then stop. Do not expand scope.
|
|
106
108
|
- Update your progress VERY frequently: write a bare integer 0-100 to ${opts.progressPath} (e.g. \`echo 30 > ${opts.progressPath}\`) every time you advance -- at least every 10 points, or every 20 for properly small tasks. Start near 10, write 90 just before wrapping up. Never let it sit stale while you work.
|
|
107
109
|
- Before finishing, write ${opts.notesPath}: a SHORT test guide for the user -- 2-4 brief sentences. Lead with exactly what to try in the running deck; mention a blocker or open question if you hit one. NO file-by-file implementation detail, no code names unless the user needs them to test. The user reads this verbatim when checking your work off.
|