spawnpack 0.1.18 → 0.1.19

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "spawnpack",
-    "version": "0.1.18",
+    "version": "0.1.19",
     "description": "Minecraft Bedrock addon project generator — scaffold your BP+RP in seconds",
     "author": "veedy-dev",
     "license": "MIT",

package/templates/AGENTS.md

@@ -34,7 +34,7 @@
 - Prefer boring, linear code, guard clauses, explicit state names, and one source of truth.
 - Do not build speculative flexibility. Avoid one-implementation interfaces, factories for one product, and helpers used once unless they materially clarify the code.
 - Preserve input validation, security boundaries, and protections against data loss, duplication, or invalid world state.
-- Use naming instead of explanatory comments. Keep comments only for non-obvious invariants, external constraints, or unavoidable workarounds. Do not add comments that restate the code, narrate implementation steps, reference plans/tasks, use decorative section banners, or read like generated walkthrough prose.
+- Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.
 - Validate predictable invalid states before calling an API. Use `try-catch` only for a documented or observed unguardable failure when the catch performs meaningful recovery, cleanup, translation, or contextual rethrow. Keep the `try` block narrow; never silently swallow errors.
 - Avoid repeated allocation, copying, logging, or exception handling in tick handlers and other hot paths.
 - Follow the existing TypeScript configuration and style. Do not introduce unused imports, variables, or exports.

package/templates/CLAUDE.md

@@ -34,7 +34,7 @@
 - Prefer boring, linear code, guard clauses, explicit state names, and one source of truth.
 - Do not build speculative flexibility. Avoid one-implementation interfaces, factories for one product, and helpers used once unless they materially clarify the code.
 - Preserve input validation, security boundaries, and protections against data loss, duplication, or invalid world state.
-- Use naming instead of explanatory comments. Keep comments only for non-obvious invariants, external constraints, or unavoidable workarounds. Do not add comments that restate the code, narrate implementation steps, reference plans/tasks, use decorative section banners, or read like generated walkthrough prose.
+- Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.
 - Validate predictable invalid states before calling an API. Use `try-catch` only for a documented or observed unguardable failure when the catch performs meaningful recovery, cleanup, translation, or contextual rethrow. Keep the `try` block narrow; never silently swallow errors.
 - Avoid repeated allocation, copying, logging, or exception handling in tick handlers and other hot paths.
 - Follow the existing TypeScript configuration and style. Do not introduce unused imports, variables, or exports.