spawnpack 0.1.7 → 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/dist/spawnpack.js

@@ -1897,16 +1897,9 @@ function generateReadme(config) {
   const aiDocFilename = getAiDocFilename(config.aiSetup);
   const aiSection = aiDocFilename !== null ? `## AI Tooling
 
-Spawnpack generated \`${aiDocFilename}\` and \`.mcp.json\` for AI-assisted development.
+Spawnpack generated \`${aiDocFilename}\` and \`.mcp.json\` for AI-assisted development. The configured MCP servers work out of the box — no API keys required.
 
-Add your own API keys before using the MCP tools:
-
-- Exa API keys: https://dashboard.exa.ai/api-keys
-- Exa API key docs: https://exa.ai/docs/reference/team-management/create-api-key
-- Browser Use API keys: https://cloud.browser-use.com/settings?tab=api-keys&new=1
-- Browser Use MCP docs: https://docs.browser-use.com/cloud/guides/mcp-server
-
-Update the placeholder values in \`.mcp.json\` with your own tokens.
+Exa's hosted MCP runs on a rate-limited free tier. If you need higher limits, you can add your own Exa API key to \`.mcp.json\` (optional): https://dashboard.exa.ai/api-keys
 
 ` : "";
   const scriptPackageSection = config.scripting !== "none" ? `## Script Packages
@@ -2120,21 +2113,7 @@ import { join as join2 } from "node:path";
 function buildMcpServers() {
   return {
     exa: {
-      command: "npx",
-      args: ["-y", "exa-mcp-server"],
-      env: {
-        EXA_API_KEY: "YOUR_EXA_API_KEY"
-      }
-    },
-    "browser-use": {
-      url: "https://api.browser-use.com/v3/mcp",
-      headers: {
-        "x-browser-use-api-key": "YOUR_BROWSER_USE_API_KEY"
-      }
-    },
-    "sequential-thinking": {
-      command: "npx",
-      args: ["-y", "@modelcontextprotocol/server-sequential-thinking"]
+      url: "https://mcp.exa.ai/mcp"
     },
     grep_app: {
       command: "npx",
@@ -2502,9 +2481,7 @@ function showPostGeneration(config) {
   }
   if (config.aiSetup !== "none") {
     usefulCommands.push("");
-    usefulCommands.push(`${teal(import_picocolors.default.bold("Note"))} ${import_picocolors.default.dim("Add your own Exa and Browser Use MCP API keys in .mcp.json before using the AI tooling.")}`);
-    usefulCommands.push(`  ${import_picocolors.default.dim("Exa:")} ${import_picocolors.default.cyan("https://dashboard.exa.ai/api-keys")}`);
-    usefulCommands.push(`  ${import_picocolors.default.dim("Browser Use:")} ${import_picocolors.default.cyan("https://cloud.browser-use.com/settings?tab=api-keys&new=1")}`);
+    usefulCommands.push(`${teal(import_picocolors.default.bold("Note"))} ${import_picocolors.default.dim(".mcp.json is ready to use — the configured MCP servers need no API keys.")}`);
   }
   O2.message([...nextSteps, "", ...usefulCommands].join(`
 `), {

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "spawnpack",
-    "version": "0.1.7",
+    "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

@@ -36,45 +36,6 @@ The governing loop for all work: **gather context → take action → verify wor
 VIOLATION CHECK: If you wrote library/framework code from memory without searching Exa first, you violated this rule.
 </rule>
 
-<rule name="browser_use_mcp_for_web" priority="high">
-**The Rule:** When you need to interact with live web pages beyond simple doc lookups, use Browser Use MCP. It provides Browser Use Cloud automation via MCP (`https://api.browser-use.com/v3/mcp`) with managed browser sessions, structured extraction, live session URLs, and follow-up tasks.
-
-**Browser Use MCP tools:**
-
-| Tool | Purpose |
-|---|---|
-| `run_session` | Create a browser session and run a natural-language web automation/extraction task |
-| `get_session` | Poll session status/output, step count, cost breakdown, and live URL |
-| `send_task` | Send a follow-up task to an idle keep-alive session |
-| `stop_session` | Stop the current task or destroy the browser session sandbox |
-| `get_session_messages` | Inspect browser actions, reasoning, and results from a session |
-| `list_sessions` | List recent Browser Use sessions |
-| `list_browser_profiles` | List available authenticated browser profiles |
-
-**When to use Browser Use MCP (NOT Exa):**
-- Scraping full page content, not just searching for it
-- Extracting structured data (JSON) from complex/messy HTML (e.g. Minecraft wiki tables, addon schemas)
-- Crawling or traversing multiple linked pages on a site (e.g. crawling all Script API event pages)
-- Interacting with pages: clicking buttons, filling forms, navigating flows
-- Accessing protected/anti-bot sites where managed browser infrastructure helps
-- Taking screenshots or using live browser session evidence
-- Any task that requires a real browser session
-
-**When to use Exa instead:**
-- Quick doc lookups for `@minecraft/server`, `@minecraft/math`, etc.
-- Finding the right URL or page for a topic
-- Lightweight search queries
-
-**Workflow — Exa finds it, Browser Use MCP reads/interacts with it:**
-1. `web_search_exa` → find the right URL
-2. `run_session` → extract deep content, automate navigation, or collect structured data
-3. `get_session` / `get_session_messages` → inspect completion, output, live URL, and action trace
-4. `send_task` → continue in the same keep-alive browser session if follow-up interaction is needed
-5. `stop_session` → cleanly stop/destroy the Browser Use session when finished
-
-VIOLATION CHECK: If you manually scraped or parsed HTML when Browser Use MCP could have done it cleanly, you violated this rule.
-</rule>
-
 <rule name="no_comments" priority="high">
 DO NOT WRITE ANY COMMENTS OR JSDOCS unless explicitly requested.
 </rule>
@@ -199,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
@@ -606,12 +598,11 @@ POTENTIAL CONCERNS:
 13. Editing files from stale context without re-reading first
 14. Duplicating state instead of fixing the real problem
 15. Writing library/framework code from memory without searching Exa for current docs first
-16. Manually scraping or parsing HTML when Browser Use MCP could extract it cleanly
-17. Using try-catch in Minecraft Script API code
-18. Creating custom math functions when @minecraft/math has them available
-19. Using raw strings instead of @minecraft/vanilla-data typed identifiers
-20. Writing BP/RP JSON files without schema validation
-21. Adding attribution or AI-style report trailers to Git commit messages
+16. Using try-catch in Minecraft Script API code
+17. Creating custom math functions when @minecraft/math has them available
+18. Using raw strings instead of @minecraft/vanilla-data typed identifiers
+19. Writing BP/RP JSON files without schema validation
+20. Adding attribution or AI-style report trailers to Git commit messages
 </failure_modes_to_avoid>
 
 <meta>
@@ -621,18 +612,16 @@ You have unlimited stamina. The human does not. Use your persistence wisely —
 
 **Priority Hierarchy:**
 1. **EXA FOR DOCS** — Always search library/framework docs via Exa before implementing
-2. **BROWSER USE MCP FOR WEB** — Use Browser Use MCP for scraping, crawling, structured extraction, and browser automation
-3. **VERIFY BEFORE DONE** — Type-check, lint, test before claiming success
-4. **PLAN BEFORE BUILD** — Spec and approval before implementation
-5. **GUARD CLAUSES** — Never use try-catch in Minecraft code
-6. **VANILLA-DATA** — Use typed identifiers from @minecraft/vanilla-data
-7. **MINECRAFT-MATH** — Use @minecraft/math library for math operations
-8. **JSON SCHEMAS** — Validate BP/RP JSONs with Rockide/schemas
-9. **NATURAL COMMITS** - Write human commit messages; no attribution or AI-style report trailers
+2. **VERIFY BEFORE DONE** — Type-check, lint, test before claiming success
+3. **PLAN BEFORE BUILD** — Spec and approval before implementation
+4. **GUARD CLAUSES** — Never use try-catch in Minecraft code
+5. **VANILLA-DATA** — Use typed identifiers from @minecraft/vanilla-data
+6. **MINECRAFT-MATH** — Use @minecraft/math library for math operations
+7. **JSON SCHEMAS** — Validate BP/RP JSONs with Rockide/schemas
+8. **NATURAL COMMITS** - Write human commit messages; no attribution or AI-style report trailers
 
 **Violation Checks:**
 - ❌ Wrote library/framework code without searching Exa first? → Violated Exa-for-docs rule
-- ❌ Manually scraped/parsed HTML when Browser Use MCP could do it? → Violated Browser-Use-MCP-for-web rule
 - ❌ Said "Done!" without running type-check/lint/tests? → Violated forced verification rule
 - ❌ Edited a file from memory after 10+ messages without re-reading? → Violated context decay rule
 - ❌ Started building without plan approval on a non-trivial task? → Violated plan-build separation

package/templates/CLAUDE.md

@@ -36,45 +36,6 @@ The governing loop for all work: **gather context → take action → verify wor
 VIOLATION CHECK: If you wrote library/framework code from memory without searching Exa first, you violated this rule.
 </rule>
 
-<rule name="browser_use_mcp_for_web" priority="high">
-**The Rule:** When you need to interact with live web pages beyond simple doc lookups, use Browser Use MCP. It provides Browser Use Cloud automation via MCP (`https://api.browser-use.com/v3/mcp`) with managed browser sessions, structured extraction, live session URLs, and follow-up tasks.
-
-**Browser Use MCP tools:**
-
-| Tool | Purpose |
-|---|---|
-| `run_session` | Create a browser session and run a natural-language web automation/extraction task |
-| `get_session` | Poll session status/output, step count, cost breakdown, and live URL |
-| `send_task` | Send a follow-up task to an idle keep-alive session |
-| `stop_session` | Stop the current task or destroy the browser session sandbox |
-| `get_session_messages` | Inspect browser actions, reasoning, and results from a session |
-| `list_sessions` | List recent Browser Use sessions |
-| `list_browser_profiles` | List available authenticated browser profiles |
-
-**When to use Browser Use MCP (NOT Exa):**
-- Scraping full page content, not just searching for it
-- Extracting structured data (JSON) from complex/messy HTML (e.g. Minecraft wiki tables, addon schemas)
-- Crawling or traversing multiple linked pages on a site (e.g. crawling all Script API event pages)
-- Interacting with pages: clicking buttons, filling forms, navigating flows
-- Accessing protected/anti-bot sites where managed browser infrastructure helps
-- Taking screenshots or using live browser session evidence
-- Any task that requires a real browser session
-
-**When to use Exa instead:**
-- Quick doc lookups for `@minecraft/server`, `@minecraft/math`, etc.
-- Finding the right URL or page for a topic
-- Lightweight search queries
-
-**Workflow — Exa finds it, Browser Use MCP reads/interacts with it:**
-1. `web_search_exa` → find the right URL
-2. `run_session` → extract deep content, automate navigation, or collect structured data
-3. `get_session` / `get_session_messages` → inspect completion, output, live URL, and action trace
-4. `send_task` → continue in the same keep-alive browser session if follow-up interaction is needed
-5. `stop_session` → cleanly stop/destroy the Browser Use session when finished
-
-VIOLATION CHECK: If you manually scraped or parsed HTML when Browser Use MCP could have done it cleanly, you violated this rule.
-</rule>
-
 <rule name="no_comments" priority="high">
 DO NOT WRITE ANY COMMENTS OR JSDOCS unless explicitly requested.
 </rule>
@@ -199,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
@@ -606,12 +598,11 @@ POTENTIAL CONCERNS:
 13. Editing files from stale context without re-reading first
 14. Duplicating state instead of fixing the real problem
 15. Writing library/framework code from memory without searching Exa for current docs first
-16. Manually scraping or parsing HTML when Browser Use MCP could extract it cleanly
-17. Using try-catch in Minecraft Script API code
-18. Creating custom math functions when @minecraft/math has them available
-19. Using raw strings instead of @minecraft/vanilla-data typed identifiers
-20. Writing BP/RP JSON files without schema validation
-21. Adding attribution or AI-style report trailers to Git commit messages
+16. Using try-catch in Minecraft Script API code
+17. Creating custom math functions when @minecraft/math has them available
+18. Using raw strings instead of @minecraft/vanilla-data typed identifiers
+19. Writing BP/RP JSON files without schema validation
+20. Adding attribution or AI-style report trailers to Git commit messages
 </failure_modes_to_avoid>
 
 <meta>
@@ -621,18 +612,16 @@ You have unlimited stamina. The human does not. Use your persistence wisely —
 
 **Priority Hierarchy:**
 1. **EXA FOR DOCS** — Always search library/framework docs via Exa before implementing
-2. **BROWSER USE MCP FOR WEB** — Use Browser Use MCP for scraping, crawling, structured extraction, and browser automation
-3. **VERIFY BEFORE DONE** — Type-check, lint, test before claiming success
-4. **PLAN BEFORE BUILD** — Spec and approval before implementation
-5. **GUARD CLAUSES** — Never use try-catch in Minecraft code
-6. **VANILLA-DATA** — Use typed identifiers from @minecraft/vanilla-data
-7. **MINECRAFT-MATH** — Use @minecraft/math library for math operations
-8. **JSON SCHEMAS** — Validate BP/RP JSONs with Rockide/schemas
-9. **NATURAL COMMITS** - Write human commit messages; no attribution or AI-style report trailers
+2. **VERIFY BEFORE DONE** — Type-check, lint, test before claiming success
+3. **PLAN BEFORE BUILD** — Spec and approval before implementation
+4. **GUARD CLAUSES** — Never use try-catch in Minecraft code
+5. **VANILLA-DATA** — Use typed identifiers from @minecraft/vanilla-data
+6. **MINECRAFT-MATH** — Use @minecraft/math library for math operations
+7. **JSON SCHEMAS** — Validate BP/RP JSONs with Rockide/schemas
+8. **NATURAL COMMITS** - Write human commit messages; no attribution or AI-style report trailers
 
 **Violation Checks:**
 - ❌ Wrote library/framework code without searching Exa first? → Violated Exa-for-docs rule
-- ❌ Manually scraped/parsed HTML when Browser Use MCP could do it? → Violated Browser-Use-MCP-for-web rule
 - ❌ Said "Done!" without running type-check/lint/tests? → Violated forced verification rule
 - ❌ Edited a file from memory after 10+ messages without re-reading? → Violated context decay rule
 - ❌ Started building without plan approval on a non-trivial task? → Violated plan-build separation