gsd-pi 2.76.0 → 2.77.0-dev.2daa994b6

package/src/resources/extensions/voice/tests/linux-ready.test.ts

@@ -5,120 +5,136 @@
  *   - diagnoseSounddeviceError branch ordering (ModuleNotFoundError must NOT
  *     match the portaudio branch, even though it contains "sounddevice")
  *   - ensureVoiceVenv auto-creation
- *   - linuxPython venv detection
+ *
+ * Previous version used `createTestContext()` + a top-level `main()` call —
+ * those don't register with `node --test`, so the file ran at import time
+ * but the test runner saw zero tests. CI reporter showed no output for
+ * this file. Rewrite uses `node:test` so results are collected properly.
+ * See #4809 / #4784.
  */
 
-import { createTestContext } from "../../gsd/tests/test-helpers.ts";
-import { diagnoseSounddeviceError, ensureVoiceVenv } from "../linux-ready.ts";
-
-const { assertEq, assertTrue, report } = createTestContext();
-
-function main(): void {
-	// ── diagnoseSounddeviceError ──────────────────────────────────────────
-
-	// The critical regression: "ModuleNotFoundError: No module named 'sounddevice'"
-	// contains the word "sounddevice", so the old code matched the portaudio branch.
-	console.log("\n=== diagnoseSounddeviceError: ModuleNotFoundError must return missing-module ===");
-	{
-		const stderr = "Traceback (most recent call last):\n  File \"<string>\", line 1, in <module>\nModuleNotFoundError: No module named 'sounddevice'";
-		assertEq(diagnoseSounddeviceError(stderr), "missing-module",
-			"ModuleNotFoundError for sounddevice should be 'missing-module', not 'missing-portaudio'");
-	}
-
-	console.log("\n=== diagnoseSounddeviceError: 'No module named sounddevice' variant ===");
-	{
-		const stderr = "ImportError: No module named sounddevice";
-		assertEq(diagnoseSounddeviceError(stderr), "missing-module",
-			"'No module' substring should return missing-module");
-	}
-
-	console.log("\n=== diagnoseSounddeviceError: actual portaudio error ===");
-	{
-		const stderr = "OSError: PortAudio library not found";
-		assertEq(diagnoseSounddeviceError(stderr), "missing-portaudio",
-			"PortAudio library error should return missing-portaudio");
-	}
-
-	console.log("\n=== diagnoseSounddeviceError: lowercase portaudio error ===");
-	{
-		const stderr = "OSError: libportaudio.so.2: cannot open shared object file: No such file or directory";
-		assertEq(diagnoseSounddeviceError(stderr), "missing-portaudio",
-			"lowercase portaudio error should return missing-portaudio");
-	}
-
-	console.log("\n=== diagnoseSounddeviceError: unrelated error ===");
-	{
-		const stderr = "SyntaxError: invalid syntax";
-		assertEq(diagnoseSounddeviceError(stderr), "unknown",
-			"unrelated error should return unknown");
-	}
-
-	console.log("\n=== diagnoseSounddeviceError: empty stderr ===");
-	{
-		assertEq(diagnoseSounddeviceError(""), "unknown",
-			"empty stderr should return unknown");
-	}
+import { describe, test } from "node:test";
+import assert from "node:assert/strict";
 
-	// ── ensureVoiceVenv ──────────────────────────────────────────────────
-
-	console.log("\n=== ensureVoiceVenv: returns true when venv already exists ===");
-	{
-		const notifications: string[] = [];
-		const result = ensureVoiceVenv({
-			notify: (msg) => notifications.push(msg),
-			exists: () => true,
-			execFile: (() => Buffer.from("")) as any,
-		});
-		assertTrue(result, "should return true when venv exists");
-		assertEq(notifications.length, 0, "should not notify when venv exists");
-	}
-
-	console.log("\n=== ensureVoiceVenv: creates venv when missing ===");
-	{
-		const notifications: string[] = [];
-		const commands: string[][] = [];
-		let existsCalled = false;
-
-		const result = ensureVoiceVenv({
-			notify: (msg) => notifications.push(msg),
-			exists: () => { existsCalled = true; return false; },
-			execFile: ((cmd: string, args: string[]) => {
-				commands.push([cmd, ...args]);
-				return Buffer.from("");
-			}) as any,
-		});
-
-		assertTrue(result, "should return true after venv creation");
-		assertTrue(existsCalled, "should check if venv exists");
-		assertEq(commands.length, 2, "should run 2 commands (venv + pip)");
-		assertTrue(commands[0][0] === "python3", "first command is python3");
-		assertTrue(commands[0].includes("-m") && commands[0].includes("venv"),
-			"first command creates venv");
-		assertTrue(commands[1][0].endsWith("bin/pip"), "second command is pip");
-		assertTrue(commands[1].includes("sounddevice"), "pip installs sounddevice");
-		assertTrue(commands[1].includes("requests"), "pip installs requests");
-		assertTrue(notifications[0].includes("one-time setup"),
-			"notifies about one-time setup");
-	}
-
-	console.log("\n=== ensureVoiceVenv: returns false and notifies on failure ===");
-	{
-		const notifications: Array<{ msg: string; level: string }> = [];
-
-		const result = ensureVoiceVenv({
-			notify: (msg, level) => notifications.push({ msg, level }),
-			exists: () => false,
-			execFile: (() => { throw new Error("externally-managed-environment"); }) as any,
-		});
-
-		assertTrue(!result, "should return false on failure");
-		const errorNotif = notifications.find(n => n.level === "error");
-		assertTrue(errorNotif !== undefined, "should emit error notification");
-		assertTrue(errorNotif!.msg.includes("python3 -m venv"),
-			"error message should suggest manual venv creation");
-	}
-
-	report();
-}
+import { diagnoseSounddeviceError, ensureVoiceVenv } from "../linux-ready.ts";
 
-main();
+describe("diagnoseSounddeviceError (#2403 branch ordering)", () => {
+  test("ModuleNotFoundError with 'sounddevice' in message → missing-module", () => {
+    // The critical regression: the stderr string contains "sounddevice",
+    // so a naive branch-order check would match the portaudio branch
+    // first. Correct classification is missing-module.
+    const stderr =
+      "Traceback (most recent call last):\n" +
+      '  File "<string>", line 1, in <module>\n' +
+      "ModuleNotFoundError: No module named 'sounddevice'";
+    assert.equal(diagnoseSounddeviceError(stderr), "missing-module");
+  });
+
+  test("ImportError: No module named sounddevice → missing-module", () => {
+    assert.equal(
+      diagnoseSounddeviceError("ImportError: No module named sounddevice"),
+      "missing-module",
+    );
+  });
+
+  test("PortAudio library not found → missing-portaudio", () => {
+    assert.equal(
+      diagnoseSounddeviceError("OSError: PortAudio library not found"),
+      "missing-portaudio",
+    );
+  });
+
+  test("libportaudio.so.2 cannot open → missing-portaudio (lowercase variant)", () => {
+    assert.equal(
+      diagnoseSounddeviceError(
+        "OSError: libportaudio.so.2: cannot open shared object file: No such file or directory",
+      ),
+      "missing-portaudio",
+    );
+  });
+
+  test("unrelated SyntaxError → unknown", () => {
+    assert.equal(
+      diagnoseSounddeviceError("SyntaxError: invalid syntax"),
+      "unknown",
+    );
+  });
+
+  test("empty stderr → unknown", () => {
+    assert.equal(diagnoseSounddeviceError(""), "unknown");
+  });
+});
+
+describe("ensureVoiceVenv", () => {
+  test("returns true without notifying when venv already exists", () => {
+    const notifications: string[] = [];
+    const result = ensureVoiceVenv({
+      notify: (msg) => notifications.push(msg),
+      exists: () => true,
+      execFile: (() => Buffer.from("")) as never,
+    });
+    assert.equal(result, true);
+    assert.equal(
+      notifications.length,
+      0,
+      "should not notify when venv already exists",
+    );
+  });
+
+  test("creates venv and installs sounddevice+requests when venv missing", () => {
+    const notifications: string[] = [];
+    const commands: string[][] = [];
+    let existsCalled = false;
+
+    const result = ensureVoiceVenv({
+      notify: (msg) => notifications.push(msg),
+      exists: () => {
+        existsCalled = true;
+        return false;
+      },
+      execFile: ((cmd: string, args: string[]) => {
+        commands.push([cmd, ...args]);
+        return Buffer.from("");
+      }) as never,
+    });
+
+    assert.equal(result, true);
+    assert.ok(existsCalled, "should check if venv exists first");
+    assert.equal(commands.length, 2, "should run 2 commands (venv + pip)");
+    assert.equal(commands[0]![0], "python3", "first command is python3");
+    assert.ok(
+      commands[0]!.includes("-m") && commands[0]!.includes("venv"),
+      "first command creates the venv",
+    );
+    assert.ok(
+      commands[1]![0]!.endsWith("bin/pip"),
+      "second command is pip from the new venv",
+    );
+    assert.ok(commands[1]!.includes("sounddevice"), "pip installs sounddevice");
+    assert.ok(commands[1]!.includes("requests"), "pip installs requests");
+    assert.ok(
+      notifications[0]!.includes("one-time setup"),
+      "notifies user this is one-time setup",
+    );
+  });
+
+  test("returns false and emits an error notification when venv creation fails", () => {
+    const notifications: Array<{ msg: string; level?: string }> = [];
+
+    const result = ensureVoiceVenv({
+      notify: (msg, level) => notifications.push({ msg, level }),
+      exists: () => false,
+      execFile: (() => {
+        throw new Error("externally-managed-environment");
+      }) as never,
+    });
+
+    assert.equal(result, false);
+    const errorNotif = notifications.find((n) => n.level === "error");
+    assert.ok(errorNotif, "must emit an error notification on failure");
+    assert.ok(
+      errorNotif!.msg.includes("python3 -m venv"),
+      "error notification suggests manual venv creation",
+    );
+  });
+});

package/src/resources/skills/api-design/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: api-design
+description: Design or review an HTTP/REST/GraphQL API for versioning, pagination, error shapes, idempotency, auth, and evolvability. Use when asked to "design an API", "shape the endpoints", "design the schema", "add a new endpoint", "review this API", or when building/modifying a public or internal HTTP surface. Complements `design-an-interface` (which is interface-agnostic) by covering HTTP-specific concerns like status codes, cache headers, and breaking-change management.
+---
+
+<objective>
+Shape an HTTP or GraphQL API so callers get predictable, evolvable, and honest semantics. The deliverable is a concrete endpoint/schema sketch with: URL or operation names, method/verb, request shape, response shape, error shape, auth model, pagination strategy, and versioning stance. Optimize for "clients that exist in 2 years" over "client that's easy to write today".
+</objective>
+
+<context>
+GSD-2 has `design-an-interface` for general module-interface design; this skill is the HTTP/GraphQL specialization. REST and GraphQL carry baggage — status codes, verbs, nullability, pagination — that a generic interface-design discussion glosses over.
+
+Invocation points:
+- Adding a new public API endpoint
+- Redesigning an internal API boundary between services
+- Code review of a PR that introduces HTTP handlers
+- A slice whose acceptance criteria include "the API works"
+- A GraphQL schema change
+</context>
+
+<core_principle>
+**CALLERS OUTLIVE YOUR ASSUMPTIONS.** An API you ship today has to keep working when your internals change, when the mobile app version two is still in use, and when a third party integrates against it. Design for extension, not just for the current caller.
+
+**HONEST STATUS CODES.** 200 OK with `{"error": "not found"}` is a lie. 404 says not found. Use the HTTP semantics the protocol offers — HTTP clients, caches, and intermediaries rely on them.
+
+**PAGINATION IS NON-OPTIONAL.** Any list endpoint that doesn't paginate will eventually get a request for "all records" that kills your database.
+</core_principle>
+
+<process>
+
+## Step 1: Gather the contract
+
+Answer, or ask (one round, 1–3 questions):
+
+1. **Who are the callers?** Internal service / mobile app / public third-party / same-repo frontend.
+2. **What's the versioning stance?** None / URL-path (`/v1/`) / header-based / GraphQL schema evolution.
+3. **Auth model?** Public / API key / OAuth / session cookie / mTLS / none-but-internal-only.
+4. **Idempotency expectation?** Is a retry safe? Required?
+5. **Consistency model?** Read-your-writes, eventual, serializable?
+
+## Step 2: Resource and operation naming
+
+### REST
+
+- Nouns not verbs in URLs: `POST /users`, not `POST /createUser`.
+- Plural resources: `/users/42`, not `/user/42`.
+- Nested only when the relationship is hierarchical and the child has no independent identity: `/users/42/sessions/3`. Otherwise flat: `/sessions/3?userId=42`.
+- Use subresources for actions that don't fit CRUD: `POST /users/42:deactivate` (colon syntax) or `POST /users/42/actions/deactivate`.
+
+### GraphQL
+
+- Queries are nouns; mutations are verbs: `user(id)`, `createUser(input)`, `deactivateUser(id)`.
+- Group related mutations under an input type: `createUser(input: CreateUserInput!)`.
+- Return the affected object plus any derived/computed fields from mutations — lets clients avoid a refetch.
+
+## Step 3: Methods and status codes
+
+### REST
+
+| Method | Intent | Idempotent? | Default success |
+|---|---|---|---|
+| GET | Read | Yes | 200, or 304 if conditional |
+| POST | Create or non-idempotent action | No | 201 with `Location` on create, 200 on action |
+| PUT | Replace (full-object) | Yes | 200 with body, or 204 |
+| PATCH | Partial update | No (usually) | 200 with body |
+| DELETE | Remove | Yes | 204 |
+
+Errors:
+- 400: caller screwed up the request shape
+- 401: no/invalid auth
+- 403: authed but not allowed
+- 404: resource doesn't exist
+- 409: conflict (version mismatch, unique constraint)
+- 410: gone (vs 404 when the resource previously existed and you want to signal that)
+- 422: validation failed
+- 429: rate-limited — include `Retry-After`
+- 500: genuinely unexpected server error
+- 503: service down or overloaded — include `Retry-After`
+
+Never 200-with-error-body. Never 500 for a 4xx cause.
+
+### GraphQL
+
+- Top-level errors (`errors[]`) for transport-level failures. Domain errors (validation, not-found, forbidden) go in the typed return — use a union or result type.
+- Partial results are expected; design the schema so `null` on a field is meaningful, not a signal of generic failure.
+
+## Step 4: Pagination
+
+- **Cursor-based by default.** Opaque cursor string, `limit`, return `nextCursor` when more exists. Scales, stable under writes.
+- **Offset-based only when:** dataset is small, user needs jump-to-page semantics (admin tables), and you're willing to accept stability drift.
+- **Never "return everything"** as default. Put a hard upper bound on `limit` (e.g., 200).
+- GraphQL: use Relay-style connections (`edges`, `pageInfo`) if the ecosystem expects it; otherwise a simpler `{items, nextCursor}` is fine.
+
+## Step 5: Error shape
+
+Standardize one shape and use it everywhere. Example REST:
+
+```json
+{
+  "error": {
+    "code": "user_not_found",
+    "message": "No user with id 42",
+    "details": { "userId": 42 },
+    "requestId": "req_abc123"
+  }
+}
+```
+
+- `code` is machine-readable; stable; documented.
+- `message` is human-readable; can change.
+- `details` carries structured context.
+- `requestId` lets callers report bugs.
+
+Errors don't leak stack traces, file paths, or internal queries.
+
+## Step 6: Idempotency, caching, concurrency
+
+- **Idempotency keys** for POST operations that mustn't double-execute on retry. Caller passes `Idempotency-Key: <uuid>`; server dedupes for a window.
+- **ETags** for GET + conditional updates (`If-Match` on PUT/PATCH).
+- **Cache-Control** on GETs that are safely cacheable.
+- **Optimistic concurrency:** when multiple writers collide, 409 with the current state. Don't silently clobber.
+
+## Step 7: Versioning and evolution
+
+- **Additive changes are free:** new optional fields, new endpoints, new optional query params.
+- **Breaking changes need a plan:** path-versioned (`/v2/`), sunset headers on `/v1/`, deprecation window communicated. Or, for GraphQL, `@deprecated` on fields with a migration note.
+- **Document the contract:** OpenAPI/GraphQL SDL. Keep it in the repo. Make it part of the PR that introduces the change.
+
+## Step 8: Review or write it up
+
+If this is a review, produce findings in the same shape as `security-review` / `review` — file:line, category, recommendation.
+
+If this is a new design, produce:
+
+```markdown
+## <API name>
+
+### Scope
+<what the API is for, who calls it>
+
+### Endpoints / Operations
+- `POST /users` — create user. Request: `{email, name}`. Response 201: `{id, email, name, createdAt}` + `Location: /users/<id>`. Errors: 409 email taken, 422 invalid.
+- ...
+
+### Auth
+<model + where to put the credential>
+
+### Pagination
+<cursor shape, max limit>
+
+### Error shape
+<one canonical shape>
+
+### Idempotency / concurrency
+<rules>
+
+### Versioning
+<stance + how breaking changes will be handled>
+
+### OpenAPI / SDL
+<link or inline>
+```
+
+Append architectural decisions to `.gsd/DECISIONS.md`.
+
+</process>
+
+<anti_patterns>
+
+- **200 OK with `{"error": "..."}`.** Lies to caches, proxies, retry libraries.
+- **Unbounded list endpoints.** `GET /users` without a `limit` cap will bite you.
+- **Offset pagination at scale.** Drifts under writes; slow at high offsets.
+- **Free-form error messages with no code.** Machine callers can't branch on prose.
+- **Breaking changes in-place.** Callers break; versioning exists for a reason.
+- **Ignoring idempotency on retriable POSTs.** Double-charges, duplicate records.
+- **Auth checks at the handler only, not the service layer.** Defense in depth.
+
+</anti_patterns>
+
+<success_criteria>
+
+- [ ] Every endpoint/operation has named request, response, and error shapes.
+- [ ] Status codes match HTTP semantics — no 200-with-error.
+- [ ] List endpoints paginate; max limit is documented.
+- [ ] A single error shape is used everywhere, with a machine-readable code.
+- [ ] Versioning stance is stated — even if the answer is "additive only for now."
+- [ ] OpenAPI/SDL reflects the design and lives in the repo.
+- [ ] Decisions appear in `.gsd/DECISIONS.md`.
+
+</success_criteria>

package/src/resources/skills/create-mcp-server/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: create-mcp-server
+description: Build, iterate, and evaluate Model Context Protocol (MCP) servers that expose external services as tools an LLM can call. Use when asked to "build an MCP server", "create an MCP tool", "wrap this API as MCP", "expose X to Claude", or when extending GSD with custom tool integrations. Covers research, schema/tool design, error handling, pagination, testing via MCP Inspector, and producing a 10-question eval set that proves the server actually enables real work.
+---
+
+<objective>
+Produce a high-quality MCP server that an LLM can actually use — not one that merely parses spec-compliant. Quality is measured by how well the server enables real-world task completion, which means the tool descriptions, error messages, and pagination behave under model reasoning, not just at the wire level.
+</objective>
+
+<context>
+GSD-2 consumes MCP heavily — see `src/resources/extensions/mcp-client/`, `src/resources/extensions/gsd/mcp-project-config.ts`, `src/resources/extensions/gsd/workflow-mcp.ts`, and `/gsd mcp` commands. Users frequently want to extend GSD with project-specific MCP servers (internal APIs, data sources, domain tools). This skill fills the authoring gap between "MCP exists" and "I have a working server."
+
+Invocation points:
+- User describes a service or API they want an LLM to reach
+- `/gsd mcp init` scaffolds config but there's a tool integration to build
+- Replacing a hand-rolled extension with a standard MCP server
+</context>
+
+<core_principle>
+**THE QUALITY METRIC IS TASK COMPLETION, NOT SCHEMA VALIDITY.** A server that lists 30 tools with cryptic names and empty descriptions passes the protocol but fails the point. The tool description is the only thing an LLM has to decide whether to call it — write it like documentation for a stranger under time pressure.
+
+**DESIGN FOR THE MODEL, NOT THE API.** A raw REST endpoint is rarely the right tool. Group, filter, and pre-shape responses so the model gets what it needs to reason, not a 40KB JSON blob it has to summarize. Fewer, deeper tools beat many, shallow ones.
+</core_principle>
+
+<process>
+
+## Step 1: Research and scope
+
+1. **Study modern MCP design.** Read the latest MCP protocol docs (not training data — fetch them). Read 2–3 reference implementations to see current patterns.
+2. **Pick a framework.** TypeScript is the default — the reference SDK is the most mature. Python is fine for data-heavy or ML adjacencies.
+3. **Analyze the target API.** Map the external service's endpoints, auth, rate limits, pagination, error shapes. Identify what a human workflow on top of it actually looks like — that's the cut line for tool design.
+4. **Produce a brief.** One page: what the server does, who calls it, the 5–10 tools you plan to expose, and the top 3 design trade-offs. Confirm with the user.
+
+## Step 2: Set up the project
+
+Skeleton:
+
+```text
+server/
+  src/
+    index.ts         # MCP entry point — stdio or sse transport
+    client.ts        # API client with auth, retries, typed errors
+    tools/           # one file per tool, or grouped by domain
+    pagination.ts    # shared cursor handling
+    errors.ts        # MCP-friendly error formatting
+  package.json       # @modelcontextprotocol/sdk as dep
+  tsconfig.json
+  README.md          # how to run, env vars, rate-limit notes
+  evals.xml          # 10 eval questions (Phase 4)
+```
+
+Core infrastructure goes first: API client with typed errors, pagination helpers, consistent retry/timeout behavior. Do not inline these per tool.
+
+## Step 3: Implement tools
+
+For each tool:
+
+1. **Name:** verb-noun, lowercase, snake_case. `search_issues`, `get_customer`, `create_deployment`. Not `do_thing` or `api_v2_post`.
+2. **Description (frontmatter):** 2–4 sentences. State what the tool does, when to use it, when NOT to use it, and any required fields or quirks. This is the model's entire interface to the tool — write it carefully.
+3. **Input schema (JSON Schema):** required fields marked, every field has a description, enums enumerated, examples included for free-form strings.
+4. **Output shape:** typed, minimal, decision-ready. If the raw API returns 40 fields and only 6 matter for follow-up calls, return 6.
+5. **Error handling:** never return raw HTTP errors. Translate to human-readable messages: "Rate limit exceeded (retry in 30s)", "Authorization expired", "No record found for ID X". Include the action the caller should take next.
+6. **Pagination:** expose cursors explicitly. Do not leak "page N of M" into the model — leak "more results available, pass `cursor: abc123` to continue."
+
+## Step 4: Build and test with MCP Inspector
+
+1. Run the server under MCP Inspector. Verify it registers, every tool lists with its description, inputs schema-validate, outputs shape correctly.
+2. Call every tool at least once manually through the Inspector UI. Check error paths.
+3. Fix any "looks fine in isolation, breaks under the Inspector's framing" issues.
+
+## Step 5: Produce the eval set
+
+Write 10 evaluation questions in `evals.xml` that exercise the server end-to-end. Each question should require 2+ tool calls and at least one decision the model has to make based on earlier output. Cover:
+
+- Happy path (2–3 questions)
+- Error recovery (2 questions — "the first call failed, what next?")
+- Pagination (1 question)
+- Decision under partial information (2–3 questions)
+- Cross-tool composition (1–2 questions)
+
+Format:
+
+```xml
+<evals>
+  <eval id="1">
+    <question>...user request...</question>
+    <expected>...concrete observable answer or tool-call sequence...</expected>
+  </eval>
+</evals>
+```
+
+Run the evals. If the model can't complete them, the server — not the model — needs work. Iterate on descriptions, error messages, and tool granularity.
+
+## Step 6: Wire into GSD
+
+Write the project's `.mcp.json` entry using `/gsd mcp init` as a starting point. Document env vars and startup in README.md. If the server is globally useful, suggest the user file it as a durable skill via `spike-wrap-up` or publish it.
+
+</process>
+
+<anti_patterns>
+
+- **One-to-one REST mapping.** If the API has 30 endpoints, you likely want 6 tools.
+- **Empty or auto-generated descriptions.** "Calls the /users endpoint" tells the model nothing it can reason with.
+- **Raw error passthrough.** `{"error": "500"}` is useless. Translate.
+- **Page-based pagination leaked as "page 1 of 5".** Use opaque cursors.
+- **Skipping the Inspector.** If you didn't run it under the Inspector, you didn't test it.
+- **No evals.** Without evals you have no signal on whether real task completion works.
+
+</anti_patterns>
+
+<success_criteria>
+
+- [ ] Every tool has a description that could guide a cold-start model correctly.
+- [ ] Errors are translated to actionable, human-readable messages.
+- [ ] Pagination uses opaque cursors; no leaked page numbers.
+- [ ] `evals.xml` has 10 questions; the model completes ≥8 without handholding.
+- [ ] MCP Inspector test passes cleanly.
+- [ ] README documents env, startup, and rate-limit behavior.
+- [ ] Server is reachable from GSD via `.mcp.json` entry.
+
+</success_criteria>

package/src/resources/skills/create-skill/SKILL.md

@@ -88,8 +88,8 @@ Then proceed directly to the workflow.
 ## Skill Structure Quick Reference
 
 **Skill directories:**
-- Global: `~/.gsd/agent/skills/{skill-name}/`
-- Project-local: `.pi/agent/skills/{skill-name}/`
+- Global: `~/.agents/skills/{skill-name}/`
+- Project-local: `.agents/skills/{skill-name}/`
 
 **Simple skill (single file):**
 ```yaml

package/src/resources/skills/create-skill/references/gsd-skill-ecosystem.md

@@ -5,13 +5,13 @@ GSD-specific skill ecosystem details: directory conventions, discovery mechanics
 <skill_directories>
 GSD supports two skill directories, checked in order:
 
-**User-scope (global):** `~/.gsd/agent/skills/`
+**User-scope (global):** `~/.agents/skills/`
 - Available in every GSD session regardless of working directory
-- Installed by default or by the user
+- Installed via [skills.sh](https://skills.sh) or manually
 
-**Project-scope (local):** `.pi/agent/skills/`
+**Project-scope (local):** `.agents/skills/`
 - Available only when GSD runs inside the project directory
-- The project-local directory uses `.pi` (inherited from the pi base), **not** `.gsd`
+- Committable to version control so team members share the same skill set
 - Ideal for project-specific workflows, deploy scripts, or conventions
 
 Skills in both directories follow the same SKILL.md format and router pattern conventions.

package/src/resources/skills/create-skill/workflows/audit-skill.md

@@ -16,22 +16,22 @@
 Enumerate skills from both directories:
 ```bash
 echo "=== Global skills ==="
-ls ~/.gsd/agent/skills/ 2>/dev/null || echo "(none)"
+ls ~/.agents/skills/ 2>/dev/null || echo "(none)"
 
 echo "=== Project-local skills ==="
-ls .pi/agent/skills/ 2>/dev/null || echo "(none)"
+ls .agents/skills/ 2>/dev/null || echo "(none)"
 ```
 
 Present as:
 ```
 Available skills:
 
-Global (~/.gsd/agent/skills/):
+Global (~/.agents/skills/):
 1. create-skill
 2. manage-stripe
 ...
 
-Project-local (.pi/agent/skills/):
+Project-local (.agents/skills/):
 3. project-deploy
 ...
 ```

package/src/resources/skills/create-skill/workflows/create-new-skill.md

@@ -15,8 +15,8 @@
 **Ask the user:**
 "Should this skill be global or project-local?"
 
-1. **Global** (`~/.gsd/agent/skills/`) — Available in all GSD sessions
-2. **Project-local** (`.pi/agent/skills/`) — Available only in this project
+1. **Global** (`~/.agents/skills/`) — Available in all GSD sessions
+2. **Project-local** (`.agents/skills/`) — Available only in this project
 
 ## Step 2: Adaptive Requirements Gathering
 
@@ -99,11 +99,11 @@ See references/recommended-structure.md for templates.
 ## Step 5: Create Directory
 
 Use the scope selected in Step 1 to determine the base path:
-- **Global:** `~/.gsd/agent/skills/{skill-name}`
-- **Project-local:** `.pi/agent/skills/{skill-name}`
+- **Global:** `~/.agents/skills/{skill-name}`
+- **Project-local:** `.agents/skills/{skill-name}`
 
 ```bash
-BASE_PATH="{selected-base}/agent/skills/{skill-name}"
+BASE_PATH="{selected-base}/skills/{skill-name}"
 mkdir -p $BASE_PATH
 # If complex:
 mkdir -p $BASE_PATH/workflows