spawnpack 0.1.8 → 0.1.9

package/README.md

@@ -20,7 +20,7 @@ It generates BP/RP structure, optional Script API setup, optional rgl integratio
 - Optional AI setup:
   - `CLAUDE.md` for Claude
   - `AGENTS.md` for Other
-  - `.mcp.json`
+  - `.mcp.json` with keyless MCP servers
 
 ## Runtime Requirement
 
@@ -97,6 +97,18 @@ Depending on your choices, Spawnpack can generate:
 - `CLAUDE.md`
 - `AGENTS.md`
 - `.mcp.json`
+
+## AI MCP setup
+
+When AI setup is enabled, Spawnpack generates an `.mcp.json` that works out of the box without API keys.
+
+Generated MCP servers currently include:
+
+- Exa hosted MCP (`https://mcp.exa.ai/mcp`) for free, rate-limited web/documentation search
+- `grep_app` for code search
+- `context7` for library documentation context
+
+You can add your own Exa API key later if you need higher Exa limits, but it is not required for the generated scaffold.
 
 ## Marketplace structure mode
 
@@ -139,6 +151,7 @@ bun run build
 The npm package is configured to publish only:
 
 - `dist/spawnpack.js`
+- `bin/spawnpack.js`
 - `templates/CLAUDE.md`
 - `templates/AGENTS.md`
 - `README.md`

package/package.json

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

package/templates/AGENTS.md

@@ -160,6 +160,37 @@ For non-trivial changes: pause and ask "is there a more elegant way?" If a fix f
 Write code that reads like a human wrote it. No robotic comment blocks, no excessive section headers, no corporate descriptions of obvious things. If three experienced devs would all write it the same way, that's the way.
 </behavior>
 
+<code_style name="boring_durable_addon_code" priority="high">
+Prefer code that is easy for an add-on developer to read top-to-bottom. Use boring, linear code as the default; add durability machinery only at persistence, async timing, entity lifecycle, duplication, or data-loss boundaries.
+
+Style rules:
+- Write linear, imperative code by default: do A, then B, then C.
+- Prefer guard clauses and early returns over nested branching.
+- Keep behavior close to where it happens.
+- Avoid framework-like abstractions unless they clearly reduce repeated complexity.
+- Prefer explicit state names over clever generic names.
+- Make the happy path obvious.
+- Split code by real gameplay/lifecycle responsibility, not by abstract pattern.
+- Do not hide important game-state transitions behind vague helpers.
+- If durability/data-loss protection requires complexity, isolate it behind a small, boring API.
+- Keep normal gameplay code simple even when the persistence/lifecycle layer underneath is more defensive.
+- Do not copy another contributor's style blindly; use their readability as a reference while preserving correctness.
+- Prefer one obvious source of truth for each piece of state.
+- Before adding a new helper/class/system, ask: "Will this make the next maintainer understand the code faster?"
+</code_style>
+
+<implementation_preference name="minimal_safe_patch" priority="high">
+When fixing bugs:
+1. First find the smallest clear fix near the bug.
+2. Add stronger safety only where data loss, duplication, or invalid world state can happen.
+3. Avoid broad lifecycle rewrites unless the current lifecycle is the root cause.
+4. If a durable solution needs more machinery, keep the public flow simple and document the responsibility through naming, not comments.
+</implementation_preference>
+
+<behavior name="use_simplify_skill_for_maintainability" priority="high">
+Use the `simplify` skill for maintainability, not only cleanup. When the user asks to simplify, clean up, refactor for readability, reduce complexity, or make code easier to maintain, load `simplify` before planning or editing. For non-trivial implementation work, use `simplify` as a post-implementation review pass before final verification: check whether the new code can be made more obvious, boring, local, and behavior-preserving. In orchestrated workflows, explicitly include this maintainability review after implementation and before reporting completion. For broad codebase cleanup, audit first, propose small phases, and wait for approval before editing.
+</behavior>
+
 <behavior name="dead_code_hygiene" priority="medium">
 After refactoring or implementing changes:
 - Identify code that is now unreachable

package/templates/CLAUDE.md

@@ -160,6 +160,37 @@ For non-trivial changes: pause and ask "is there a more elegant way?" If a fix f
 Write code that reads like a human wrote it. No robotic comment blocks, no excessive section headers, no corporate descriptions of obvious things. If three experienced devs would all write it the same way, that's the way.
 </behavior>
 
+<code_style name="boring_durable_addon_code" priority="high">
+Prefer code that is easy for an add-on developer to read top-to-bottom. Use boring, linear code as the default; add durability machinery only at persistence, async timing, entity lifecycle, duplication, or data-loss boundaries.
+
+Style rules:
+- Write linear, imperative code by default: do A, then B, then C.
+- Prefer guard clauses and early returns over nested branching.
+- Keep behavior close to where it happens.
+- Avoid framework-like abstractions unless they clearly reduce repeated complexity.
+- Prefer explicit state names over clever generic names.
+- Make the happy path obvious.
+- Split code by real gameplay/lifecycle responsibility, not by abstract pattern.
+- Do not hide important game-state transitions behind vague helpers.
+- If durability/data-loss protection requires complexity, isolate it behind a small, boring API.
+- Keep normal gameplay code simple even when the persistence/lifecycle layer underneath is more defensive.
+- Do not copy another contributor's style blindly; use their readability as a reference while preserving correctness.
+- Prefer one obvious source of truth for each piece of state.
+- Before adding a new helper/class/system, ask: "Will this make the next maintainer understand the code faster?"
+</code_style>
+
+<implementation_preference name="minimal_safe_patch" priority="high">
+When fixing bugs:
+1. First find the smallest clear fix near the bug.
+2. Add stronger safety only where data loss, duplication, or invalid world state can happen.
+3. Avoid broad lifecycle rewrites unless the current lifecycle is the root cause.
+4. If a durable solution needs more machinery, keep the public flow simple and document the responsibility through naming, not comments.
+</implementation_preference>
+
+<behavior name="use_simplify_skill_for_maintainability" priority="high">
+Use the `simplify` skill for maintainability, not only cleanup. When the user asks to simplify, clean up, refactor for readability, reduce complexity, or make code easier to maintain, load `simplify` before planning or editing. For non-trivial implementation work, use `simplify` as a post-implementation review pass before final verification: check whether the new code can be made more obvious, boring, local, and behavior-preserving. In orchestrated workflows, explicitly include this maintainability review after implementation and before reporting completion. For broad codebase cleanup, audit first, propose small phases, and wait for approval before editing.
+</behavior>
+
 <behavior name="dead_code_hygiene" priority="medium">
 After refactoring or implementing changes:
 - Identify code that is now unreachable