gsd-pi 2.78.0 → 2.78.1-dev.82bcf6b71

package/src/resources/skills/create-gsd-extension/workflows/create-extension.md

@@ -34,22 +34,19 @@ Identify what the extension needs from the user's description:
 
 ## Step 3: Choose Extension Structure
 
-**Single file** — for small extensions (1-2 tools/commands, simple hooks):
-```
-~/.pi/agent/extensions/my-extension.ts
-```
-
-**Directory with index.ts** — for multi-file extensions:
+**Directory with index.ts** — the standard pattern for all extensions:
 ```
 ~/.pi/agent/extensions/my-extension/
-├── index.ts
-├── tools.ts
-└── utils.ts
+├── extension-manifest.json   # Required — declares capabilities
+├── index.ts                  # Entry point (must export default function)
+├── tools.ts                  # Optional — tool implementations
+└── utils.ts                  # Optional — shared utilities
 ```
 
 **Package with dependencies** — when npm packages are needed:
 ```
 ~/.pi/agent/extensions/my-extension/
+├── extension-manifest.json
 ├── package.json
 ├── src/index.ts
 └── node_modules/
@@ -64,12 +61,34 @@ For packages, `package.json` needs:
 }
 ```
 
+## Step 3b: Create the Extension Manifest
+
+Every extension must include an `extension-manifest.json`:
+
+```json
+{
+  "id": "my-extension",
+  "name": "My Extension",
+  "version": "1.0.0",
+  "description": "What this extension does in one line",
+  "tier": "community",
+  "requires": { "platform": ">=2.29.0" },
+  "provides": {
+    "tools": ["my_tool"],
+    "commands": ["mycommand"],
+    "hooks": ["session_start"]
+  }
+}
+```
+
+Only include non-empty arrays in `provides`. See `docs/extension-sdk/manifest-spec.md` for the full spec.
+
 ## Step 4: Write the Extension
 
 Start with the skeleton:
 
 ```typescript
-import type { ExtensionAPI } from "@mariozechner/pi-coding-agent";
+import type { ExtensionAPI } from "@gsd/pi-coding-agent";
 
 export default function (pi: ExtensionAPI) {
   // Register events, tools, commands here
@@ -81,7 +100,7 @@ Then add capabilities based on Step 2. Reference the appropriate reference files
 **Tool registration pattern:**
 ```typescript
 import { Type } from "@sinclair/typebox";
-import { StringEnum } from "@mariozechner/pi-ai";
+import { StringEnum } from "@gsd/pi-ai";
 
 pi.registerTool({
   name: "my_tool",
@@ -144,7 +163,8 @@ Fix issues, add features, refine. Use `/reload` for hot-reload during developmen
 
 <success_criteria>
 Extension creation is complete when:
-- [ ] Extension file(s) written to correct location
+- [ ] Extension directory created with index.ts and extension-manifest.json
+- [ ] Manifest `provides` accurately lists all registered tools, commands, hooks, shortcuts
 - [ ] All imports resolve (TypeBox, pi-ai, pi-coding-agent, pi-tui as needed)
 - [ ] Tools use `StringEnum` for string enums (not `Type.Union`/`Type.Literal`)
 - [ ] Tool output is truncated if variable-length

package/src/resources/skills/lint/SKILL.md

@@ -7,6 +7,10 @@ description: Lint and format code. Auto-detects ESLint, Biome, Prettier, or lang
 Lint and format code in the current project. Auto-detect the project's linter and formatter toolchain, run them against the target files, and report results grouped by severity with actionable fix suggestions.
 </objective>
 
+<working_directory_awareness>
+**Before running any `git` or build command:** check whether your dispatch context specifies a working directory (look for "Working directory:" in your initial prompt). If it does and `pwd` does not match it, prefix every git invocation with `-C <that path>` (e.g. `git -C /path/to/worktree diff --name-only`) and run linters/formatters with the explicit path argument. Linting the wrong directory is a silent failure mode.
+</working_directory_awareness>
+
 <arguments>
 This skill accepts optional arguments after `/lint`:
 

package/src/resources/skills/review/SKILL.md

@@ -23,6 +23,10 @@ The reviewer reads both the diff and the surrounding source files to understand
 The purpose is to review and report findings. Making changes during review conflates the reviewer and author roles. Present findings and let the user decide what to act on.
 </analysis_only_rule>
 
+<working_directory_awareness>
+**Before running any `git` command:** check whether your dispatch context specifies a working directory (look for "Working directory:" in your initial prompt). If it does and `pwd` does not match it, prefix every git invocation with `-C <that path>` (e.g. `git -C /path/to/worktree diff --cached`). Reviewing the wrong directory's diff is a silent failure mode — the review will look correct but cover the wrong code.
+</working_directory_awareness>
+
 <quick_start>
 
 <determine_review_scope>

package/src/resources/skills/test/SKILL.md

@@ -151,6 +151,9 @@ Failures:
 **Suggest what to test when no arguments are given.**
 
 **A. Check recent changes:**
+
+> **Working directory check:** if your dispatch context specifies a working directory and `pwd` does not match it, prefix the git commands below with `-C <that path>` (e.g. `git -C /path/to/worktree diff --name-only HEAD~5`).
+
 - Run `git diff --name-only HEAD~5` to find recently changed files
 - Run `git diff --name-only --cached` for staged files
 - Filter to source files (exclude configs, docs, lockfiles)