@dccxx/auggiegw 1.0.28 → 1.0.30

package/dist/cli.js

@@ -3543,8 +3543,8 @@ function resolveInstallPaths(target, scope) {
 }
 async function savePromptToPath(prompt, skillsDir, commandsDir) {
   const markdownContent = `---
-description: ${prompt.name}
-type: "manual"
+name: ${prompt.name}
+description: ${prompt.description ?? prompt.name}
 ---
 
 ${prompt.content}`;
@@ -3650,6 +3650,66 @@ function resolveMultipleTargetPaths(targets, scope) {
     paths
   };
 }
+function resolveDeletePaths(installConfig) {
+  const deletePaths = [];
+  const homeDir = os.homedir();
+  const projectDir = process.cwd();
+  const selectedTargets = Object.keys(installConfig.paths);
+  for (const target of selectedTargets) {
+    if (target === "augment") {
+      deletePaths.push({
+        commands: path.join(homeDir, ".augment", "skills"),
+        commandsLegacy: path.join(homeDir, ".augment", "commands"),
+        agents: path.join(homeDir, ".augment", "agents")
+      });
+      deletePaths.push({
+        commands: path.join(projectDir, ".augment", "skills"),
+        commandsLegacy: path.join(projectDir, ".augment", "commands"),
+        agents: path.join(projectDir, ".augment", "agents")
+      });
+    } else if (target === "claude") {
+      deletePaths.push({
+        commands: path.join(homeDir, ".claude", "skills"),
+        commandsLegacy: path.join(homeDir, ".claude", "commands"),
+        agents: path.join(homeDir, ".claude", "agents")
+      });
+      deletePaths.push({
+        commands: path.join(projectDir, ".claude", "skills"),
+        commandsLegacy: path.join(projectDir, ".claude", "commands"),
+        agents: path.join(projectDir, ".claude", "agents")
+      });
+    } else if (target === "opencode") {
+      deletePaths.push({
+        commands: path.join(homeDir, ".config", "opencode", "skills"),
+        commandsLegacy: path.join(homeDir, ".config", "opencode", "commands"),
+        agents: path.join(homeDir, ".config", "opencode", "agents")
+      });
+      deletePaths.push({
+        commands: path.join(projectDir, ".opencode", "skills"),
+        commandsLegacy: path.join(projectDir, ".opencode", "commands"),
+        agents: path.join(projectDir, ".opencode", "agents")
+      });
+    }
+  }
+  return deletePaths;
+}
+async function deleteKitItems(deletedItems, deletePaths) {
+  let deletedCount = 0;
+  for (const name of deletedItems.prompts) {
+    for (const pathSet of deletePaths) {
+      await fs.rm(path.join(pathSet.commands, name), { recursive: true, force: true });
+      await fs.rm(path.join(pathSet.commandsLegacy, `${name}.md`), { force: true });
+    }
+    deletedCount++;
+  }
+  for (const name of deletedItems.subagents) {
+    for (const pathSet of deletePaths) {
+      await fs.rm(path.join(pathSet.agents, `${name}.md`), { force: true });
+    }
+    deletedCount++;
+  }
+  return deletedCount;
+}
 async function promptInput(question, hidden = false) {
   const rl = readline.createInterface({
     input: process.stdin,
@@ -4087,7 +4147,14 @@ async function handleKit(kitId, options = {}) {
         subagentsCount++;
       }
     }
-    let successMessage = `Successfully installed kit "${kit.name}": ${promptsCount} prompts, ${subagentsCount} subagents
+    let deletedCount = 0;
+    if (kit.deleted_items && (kit.deleted_items.prompts.length > 0 || kit.deleted_items.subagents.length > 0)) {
+      spinner.text = "Cleaning up deleted items...";
+      const deletePaths = resolveDeletePaths(installConfig);
+      deletedCount = await deleteKitItems(kit.deleted_items, deletePaths);
+    }
+    const deletedSuffix = deletedCount > 0 ? `, ${deletedCount} removed` : "";
+    let successMessage = `Successfully installed kit "${kit.name}": ${promptsCount} prompts, ${subagentsCount} subagents${deletedSuffix}
 
 Installed to:`;
     if (installConfig.paths.augment) {
@@ -4139,4 +4206,4 @@ program2.command("kit <kit-id>").description("Fetch and install a kit (prompts a
 });
 program2.parse();
 
-//# debugId=24CCB949527CC51D64756E2164756E21
+//# debugId=706C0DF49CFC16E464756E2164756E21

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-02-07

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/design.md

@@ -0,0 +1,69 @@
+## Context
+
+The CLI tool (`auggie`) fetches prompts from an API and saves them as Markdown files with YAML frontmatter. The current `savePromptToPath()` function writes incorrect frontmatter:
+
+```yaml
+---
+description: spec-apply    # ← This is actually the name, not a description
+type: "manual"             # ← Hardcoded, unnecessary
+---
+```
+
+The `PromptData` interface has three fields: `name`, `command`, `content`. There is no `description` field. The API response is cast directly to `PromptData` without transformation.
+
+Subagents (`saveSubagentToPath()`) already use the correct format with both `name` and `description` fields.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Emit correct YAML frontmatter with `name` field for skill files
+- Include `description` field in frontmatter when available
+- Remove the hardcoded `type: "manual"` field
+- Align prompt frontmatter style with subagent frontmatter style
+
+**Non-Goals:**
+- Migrating existing saved skill files to the new format (they'll update on next fetch/install)
+- Changing the API response structure
+- Changing subagent frontmatter (already correct)
+
+## Decisions
+
+### Decision 1: Add optional `description` field to `PromptData`
+
+**Choice:** Add `description?: string` to the `PromptData` interface.
+
+**Rationale:** The API may already return a `description` field that gets silently dropped by the current TypeScript interface (since `as` casts don't strip extra fields, the data is there at runtime but not typed). Adding it as optional ensures:
+- If the API provides it, it gets used
+- If the API doesn't provide it, we fall back gracefully
+
+**Alternative considered:** Making `description` required — rejected because we can't control the API response and don't want to break if it's absent.
+
+### Decision 2: Frontmatter template format
+
+**Choice:** New format:
+```yaml
+---
+name: <prompt.name>
+description: <prompt.description or prompt.name>
+---
+```
+
+**Rationale:**
+- `name` field is the primary identifier — must be present
+- `description` falls back to `name` if not available from API, ensuring the field is never empty
+- `type: "manual"` removed — it serves no purpose and isn't used by any consumer
+- Matches the pattern used by `saveSubagentToPath()` for consistency
+
+**Alternative considered:** Omitting `description` entirely when not available — rejected because having a consistent set of frontmatter fields is better for consumers.
+
+### Decision 3: Single function change, no structural refactor
+
+**Choice:** Modify `savePromptToPath()` in place. No new functions or abstractions.
+
+**Rationale:** This is a ~5 line fix. The function structure is fine; only the template string and interface need updating.
+
+## Risks / Trade-offs
+
+- **[Existing files have old format]** → Acceptable. Files update on next `fetch` or `kit` install. No migration needed.
+- **[API might not return description]** → Mitigated by making field optional and falling back to `name`.
+

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/proposal.md

@@ -0,0 +1,25 @@
+## Why
+
+The `savePromptToPath()` function writes incorrect YAML frontmatter when saving skill files. The prompt's `name` is written into the `description` field, the `name` field is missing entirely, and a hardcoded `type: "manual"` field is included unnecessarily. This means skills are saved without a proper `name` identifier and lack a real description.
+
+## What Changes
+
+- Fix YAML frontmatter in saved skill files to include a `name` field
+- Add `description` field to `PromptData` interface (if API provides it) or derive it from `name`
+- Remove the hardcoded `type: "manual"` field from frontmatter
+- Update the existing spec that codified the old (incorrect) format
+
+## Capabilities
+
+### New Capabilities
+- `skill-yaml-frontmatter`: Correct YAML frontmatter format for saved skill files, ensuring `name` and `description` fields are present and `type` is removed
+
+### Modified Capabilities
+- `skill-directory-structure`: The "Preserve file content format" requirement currently specifies the old buggy format (`description: <name>`, `type: "manual"`). This needs to be updated to reflect the corrected frontmatter format.
+
+## Impact
+
+- **Code**: `src/cli.ts` — `savePromptToPath()` function (~line 556-580), `PromptData` interface (~line 68-72)
+- **Saved files**: All skill files (`SKILL.md`) written by `auggie fetch`, `auggie fetch --refresh-commands`, and `auggie kit` commands will have the new frontmatter format
+- **Existing skills**: Previously saved skill files will retain the old format until re-fetched/re-installed
+

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/specs/skill-directory-structure/spec.md

@@ -0,0 +1,29 @@
+## MODIFIED Requirements
+
+### Requirement: Preserve file content format
+The system SHALL write skill files with YAML frontmatter containing `name` and `description` fields when saving to the directory structure.
+
+#### Scenario: File content format
+- **WHEN** saving a prompt with name "Test Prompt", description "A test prompt", and content "Hello world"
+- **THEN** `SKILL.md` contains:
+  ```
+  ---
+  name: Test Prompt
+  description: A test prompt
+  ---
+
+  Hello world
+  ```
+
+#### Scenario: File content format without description
+- **WHEN** saving a prompt with name "Test Prompt", no description, and content "Hello world"
+- **THEN** `SKILL.md` contains:
+  ```
+  ---
+  name: Test Prompt
+  description: Test Prompt
+  ---
+
+  Hello world
+  ```
+

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/specs/skill-yaml-frontmatter/spec.md

@@ -0,0 +1,61 @@
+## ADDED Requirements
+
+### Requirement: Skill files SHALL include name in YAML frontmatter
+The system SHALL write a `name` field in the YAML frontmatter of saved skill files, using the prompt's name value.
+
+#### Scenario: Skill file includes name field
+- **WHEN** saving a prompt with name "spec-apply"
+- **THEN** the SKILL.md frontmatter SHALL contain `name: spec-apply`
+
+### Requirement: Skill files SHALL include description in YAML frontmatter
+The system SHALL write a `description` field in the YAML frontmatter of saved skill files. If the prompt has a description, that value SHALL be used. If no description is available, the prompt's name SHALL be used as fallback.
+
+#### Scenario: Skill file with description from API
+- **WHEN** saving a prompt with name "spec-apply" and description "Apply spec changes to codebase"
+- **THEN** the SKILL.md frontmatter SHALL contain `description: Apply spec changes to codebase`
+
+#### Scenario: Skill file without description falls back to name
+- **WHEN** saving a prompt with name "spec-apply" and no description
+- **THEN** the SKILL.md frontmatter SHALL contain `description: spec-apply`
+
+### Requirement: Skill files SHALL NOT include type field
+The system SHALL NOT write a `type` field in the YAML frontmatter of saved skill files.
+
+#### Scenario: No type field in frontmatter
+- **WHEN** saving any prompt
+- **THEN** the SKILL.md frontmatter SHALL NOT contain a `type` field
+
+### Requirement: Complete frontmatter format
+The system SHALL write skill file frontmatter in the following format with name and description fields only.
+
+#### Scenario: Full frontmatter output
+- **WHEN** saving a prompt with name "My Skill" and description "Does something useful"
+- **THEN** `SKILL.md` SHALL contain:
+  ```
+  ---
+  name: My Skill
+  description: Does something useful
+  ---
+  ```
+
+#### Scenario: Full frontmatter output without description
+- **WHEN** saving a prompt with name "My Skill" and no description
+- **THEN** `SKILL.md` SHALL contain:
+  ```
+  ---
+  name: My Skill
+  description: My Skill
+  ---
+  ```
+
+### Requirement: PromptData SHALL support optional description
+The `PromptData` interface SHALL include an optional `description` field of type string to capture prompt descriptions from the API.
+
+#### Scenario: API returns description
+- **WHEN** the API response includes a `description` field for a prompt
+- **THEN** the value SHALL be available in `PromptData.description`
+
+#### Scenario: API does not return description
+- **WHEN** the API response does not include a `description` field for a prompt
+- **THEN** `PromptData.description` SHALL be `undefined`
+

package/openspec/changes/archive/2026-02-07-fix-skill-yaml-frontmatter/tasks.md

@@ -0,0 +1,14 @@
+## 1. Update PromptData Interface
+
+- [x] 1.1 Add optional `description` field to `PromptData` interface in `src/cli.ts` (~line 68-72)
+
+## 2. Fix Frontmatter Template
+
+- [x] 2.1 Update `savePromptToPath()` in `src/cli.ts` (~line 556-580) to write `name` field using `prompt.name`
+- [x] 2.2 Update `savePromptToPath()` to write `description` field using `prompt.description ?? prompt.name`
+- [x] 2.3 Remove `type: "manual"` from the frontmatter template
+
+## 3. Update Existing Spec
+
+- [x] 3.1 Update `openspec/specs/skill-directory-structure/spec.md` "Preserve file content format" requirement to reflect the new frontmatter format (name + description, no type)
+

package/openspec/changes/handle-kit-deleted-items/.openspec.yaml

@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-02-09

package/openspec/changes/handle-kit-deleted-items/design.md

@@ -0,0 +1,78 @@
+## Context
+
+The `kit` command in `src/cli.ts` fetches a kit from the API and saves prompts and subagents to local directories. The API now returns a `deleted_items` field:
+
+```json
+{
+  "deleted_items": {
+    "prompts": ["openspec-ff"],
+    "subagents": ["aaa"],
+    "rules": []
+  }
+}
+```
+
+These represent items that were deleted server-side and should be cleaned up locally. The current `handleKit()` function supports multiple AI targets (claude, augment, opencode) and two scopes (user `~/`, project `./`). Path resolution is handled by `resolveInstallPaths()` and `resolveMultipleTargetPaths()`.
+
+File locations per target:
+- **Prompts (new)**: `{base}/.{target}/skills/{name}/SKILL.md` (directory)
+- **Prompts (legacy)**: `{base}/.{target}/commands/{name}.md` (file)
+- **Subagents**: `{base}/.{target}/agents/{name}.md` (file)
+
+Where `{base}` is `~/` for user scope or `./` for project scope, and `{target}` is `augment`, `claude`, or `config/opencode` (user) / `opencode` (project).
+
+## Goals / Non-Goals
+
+**Goals:**
+- Delete locally stored prompts and subagents that appear in `deleted_items`
+- Delete from **selected targets** only (matching user's `--target` choice)
+- Delete from **both scopes** always (user + project), regardless of install scope selection
+- Handle missing files silently (no errors if file doesn't exist)
+- Show deletion count in success message
+- Skip `deleted_items.rules` entirely (no rules storage exists)
+
+**Non-Goals:**
+- Implementing rules storage or deletion
+- Deleting from targets the user didn't select
+- Scanning other project directories beyond `./` and `~/`
+- Adding a `--no-delete` flag to skip deletion
+- Prompting user for confirmation before deleting
+
+## Decisions
+
+### Decision 1: Delete from both scopes, always
+**Rationale**: If the server says an item is deleted, it should be removed everywhere the user might have it. Limiting deletion to only the selected scope would leave stale files in the other scope.
+
+**Trade-off**: We can only clean `~/` (user) and `./` (current project). Other projects that installed the same kit won't be cleaned. This is an acceptable limitation.
+
+### Decision 2: Delete from selected targets only
+**Rationale**: If a user chose `--target claude`, they're managing their Claude setup. We shouldn't touch their Augment or OpenCode directories without being asked.
+
+### Decision 3: Resolve delete paths separately from install paths
+**Rationale**: Install paths use the user's selected scope. Delete paths need both scopes. Rather than modifying `resolveInstallPaths()`, we build delete paths independently by calling the path resolution for both scopes and merging the results.
+
+**Approach**: Create a helper `resolveDeletePaths()` that takes the selected targets and returns paths for both user and project scopes. This keeps the existing install path logic untouched.
+
+### Decision 4: Delete after saving (not before)
+**Rationale**: If a prompt name appears in both `prompts` (to save) and `deleted_items.prompts` (to delete), the save should win — this would be a server-side data inconsistency, but saving is the safer default. However, in practice the server should never include the same name in both arrays.
+
+### Decision 5: Use fs.rm with force option for silent failure
+**Rationale**: Using `fs.rm(path, { force: true })` and `fs.rm(dir, { recursive: true, force: true })` handles the "file doesn't exist" case without try/catch. Clean and idiomatic.
+
+## Risks / Trade-offs
+
+**[Risk] Accidental deletion of user-created files** → Mitigation: We only delete files whose names match `deleted_items` entries. If a user manually created a skill with the same name as a deleted kit item, it would be removed. This is acceptable — the name collision means it was likely from the kit originally.
+
+**[Risk] Race condition with concurrent kit installs** → Mitigation: Extremely unlikely for a CLI tool. No mitigation needed.
+
+**[Risk] `deleted_items` field missing from older API versions** → Mitigation: Field is optional (`deleted_items?`). If missing, no deletion occurs. Full backward compatibility.
+
+## Migration Plan
+
+No migration needed. This is purely additive behavior:
+1. Update `KitData` interface
+2. Add `deleteKitItems()` function
+3. Call it from `handleKit()` after saving
+4. Update success message
+
+Existing kits without `deleted_items` work exactly as before.

package/openspec/changes/handle-kit-deleted-items/proposal.md

@@ -0,0 +1,26 @@
+## Why
+
+The kit API now returns a `deleted_items` field containing arrays of prompt names, subagent names, and rule names that were deleted server-side. Currently, the `kit` command only adds/overwrites items — it never removes anything. When a kit author deletes a prompt or subagent from their kit, users who re-install the kit still have the stale files locally. This creates confusion and potential conflicts.
+
+## What Changes
+
+- Update `KitData` interface to include the optional `deleted_items` field from the API response
+- Add deletion logic to `handleKit()` that processes `deleted_items.prompts` and `deleted_items.subagents`
+- Deletions apply to **selected targets** (claude/augment/opencode) but always across **both scopes** (user + project), regardless of which scope was chosen for installation
+- Rules are excluded from this change (no rules storage exists yet)
+- Files that don't exist are silently skipped (no errors)
+
+## Capabilities
+
+### New Capabilities
+- `kit-deleted-items`: Process `deleted_items` from kit API response to clean up locally deleted prompts and subagents
+
+### Modified Capabilities
+- `kit-command`: Existing kit command gains deletion behavior after saving new items
+
+## Impact
+
+- **Code**: `src/cli.ts` — `KitData` interface update, new `deleteKitItems()` function, `handleKit()` updated to call deletion logic
+- **Dependencies**: None
+- **Breaking Change**: None — deletion is additive behavior. Kits without `deleted_items` work exactly as before (field is optional)
+- **User Experience**: Users see a summary of deleted items in the success message. Stale files are automatically cleaned up on kit re-install

package/openspec/changes/handle-kit-deleted-items/specs/kit-deleted-items/spec.md

@@ -0,0 +1,115 @@
+## NEW Requirements
+
+### Requirement: Deleted Items Type Definition
+WHEN the kit API returns a response, THE SYSTEM SHALL support an optional `deleted_items` field in the `KitData` interface containing arrays of names for prompts, subagents, and rules to delete.
+
+#### Scenario: API response includes deleted_items
+- **WHEN** the API response contains a `deleted_items` object
+- **THEN** the system parses `deleted_items.prompts` as `string[]`
+- **AND** parses `deleted_items.subagents` as `string[]`
+- **AND** parses `deleted_items.rules` as `string[]`
+
+#### Scenario: API response without deleted_items
+- **WHEN** the API response does not contain a `deleted_items` field
+- **THEN** the system proceeds normally without any deletion (backward compatible)
+
+### Requirement: Delete Prompts from Local Storage
+WHEN `deleted_items.prompts` contains prompt names, THE SYSTEM SHALL delete the corresponding prompt files from the selected targets across both user and project scopes.
+
+#### Scenario: Delete prompt from skills directory (new format)
+- **WHEN** `deleted_items.prompts` contains `"openspec-ff"`
+- **AND** user selected target "claude"
+- **THEN** system deletes directory `~/.claude/skills/openspec-ff/` recursively (if exists)
+- **AND** deletes directory `./.claude/skills/openspec-ff/` recursively (if exists)
+
+#### Scenario: Delete prompt from commands directory (legacy format)
+- **WHEN** `deleted_items.prompts` contains `"openspec-ff"`
+- **AND** user selected target "claude"
+- **THEN** system deletes file `~/.claude/commands/openspec-ff.md` (if exists)
+- **AND** deletes file `./.claude/commands/openspec-ff.md` (if exists)
+
+#### Scenario: Delete prompt from multiple selected targets
+- **WHEN** `deleted_items.prompts` contains `"openspec-ff"`
+- **AND** user selected target "both" (augment + claude)
+- **THEN** system deletes from both augment and claude directories
+- **AND** deletes from both user (`~/`) and project (`./`) scopes for each target
+
+#### Scenario: Delete prompt file does not exist
+- **WHEN** `deleted_items.prompts` contains a name that has no corresponding local file
+- **THEN** system silently skips the deletion (no error)
+
+### Requirement: Delete Subagents from Local Storage
+WHEN `deleted_items.subagents` contains subagent names, THE SYSTEM SHALL delete the corresponding subagent files from the selected targets across both user and project scopes.
+
+#### Scenario: Delete subagent file
+- **WHEN** `deleted_items.subagents` contains `"aaa"`
+- **AND** user selected target "claude"
+- **THEN** system deletes file `~/.claude/agents/aaa.md` (if exists)
+- **AND** deletes file `./.claude/agents/aaa.md` (if exists)
+
+#### Scenario: Delete subagent from multiple selected targets
+- **WHEN** `deleted_items.subagents` contains `"aaa"`
+- **AND** user selected target "both" (augment + claude)
+- **THEN** system deletes from both augment and claude agent directories
+- **AND** deletes from both user (`~/`) and project (`./`) scopes for each target
+
+#### Scenario: Delete subagent file does not exist
+- **WHEN** `deleted_items.subagents` contains a name that has no corresponding local file
+- **THEN** system silently skips the deletion (no error)
+
+### Requirement: Rules Deletion Excluded
+THE SYSTEM SHALL NOT process `deleted_items.rules` in this change.
+
+#### Scenario: Rules array present but ignored
+- **WHEN** `deleted_items.rules` contains rule names
+- **THEN** system ignores the rules array entirely (no action taken)
+
+### Requirement: Deletion Scope Always Both
+REGARDLESS of the user's selected installation scope, THE SYSTEM SHALL always attempt deletion from both user-level (`~/`) and project-level (`./`) directories.
+
+#### Scenario: User selects project scope for install
+- **WHEN** user selects scope "project" for installation
+- **THEN** new items are installed to project scope only (`./`)
+- **BUT** deleted items are removed from both project (`./`) AND user (`~/`) scopes
+
+#### Scenario: User selects user scope for install
+- **WHEN** user selects scope "user" for installation
+- **THEN** new items are installed to user scope only (`~/`)
+- **BUT** deleted items are removed from both user (`~/`) AND project (`./`) scopes
+
+### Requirement: Deletion Targets Match Selected Targets
+THE SYSTEM SHALL only delete from the AI tool targets that the user selected for installation.
+
+#### Scenario: User selects only claude target
+- **WHEN** user selects target "claude"
+- **THEN** deleted items are removed only from claude directories (not augment or opencode)
+
+#### Scenario: User selects both targets
+- **WHEN** user selects target "both"
+- **THEN** deleted items are removed from both augment and claude directories
+
+### Requirement: Deletion Timing
+THE SYSTEM SHALL process deletions AFTER saving new/updated items.
+
+#### Scenario: Save then delete
+- **WHEN** kit contains both new prompts and deleted_items
+- **THEN** system saves all new prompts and subagents first
+- **THEN** system processes deleted_items
+
+## MODIFIED Requirements
+
+### Requirement: User Feedback (updated)
+WHILE fetching and installing the kit, THE SYSTEM SHALL display progress information including deletion counts.
+
+#### Scenario: Display deletion progress
+- **WHEN** processing deleted items
+- **THEN** system updates the spinner text to "Cleaning up deleted items..."
+
+#### Scenario: Display success message with deletions
+- **WHEN** installation completes with deletions
+- **THEN** system displays "Successfully installed kit \"{name}\": {promptsCount} prompts, {subagentsCount} subagents, {deletedCount} removed"
+- **AND** displays exact installation paths
+
+#### Scenario: Display success message without deletions
+- **WHEN** installation completes with no deleted_items (or empty arrays)
+- **THEN** system displays the existing success message format without deletion count

package/openspec/changes/handle-kit-deleted-items/tasks.md

@@ -0,0 +1,36 @@
+## 1. Update KitData Interface
+
+- [x] 1.1 Add optional `deleted_items` field to `KitData` interface in `src/cli.ts` (around line 107):
+  ```typescript
+  deleted_items?: {
+    prompts: string[];
+    subagents: string[];
+    rules: string[];
+  };
+  ```
+
+## 2. Create Delete Path Resolution Helper
+
+- [x] 2.1 Create `resolveDeletePaths()` function in `src/cli.ts` that takes selected targets (`KitInstallConfig`) and returns an array of path sets for BOTH scopes (user + project). It should:
+  - Extract which targets are selected from `installConfig.paths` (augment/claude/opencode)
+  - For each selected target, resolve paths for both `user` scope (`os.homedir()`) and `project` scope (`process.cwd()`)
+  - Return an array of `{ commands: string; commandsLegacy: string; agents: string }` objects representing all directories to delete from
+  - Handle opencode's special user-level path (`~/.config/opencode/`) vs project-level path (`./.opencode/`)
+
+## 3. Create deleteKitItems Function
+
+- [x] 3.1 Create `deleteKitItems()` async function
+- [x] 3.2 Implement prompt deletion logic
+- [x] 3.3 Implement subagent deletion logic
+- [x] 3.4 Skip `deleted_items.rules` entirely (no processing)
+- [x] 3.5 Return a count of deletion operations attempted
+
+## 4. Update handleKit Function
+
+- [x] 4.1 After the existing save prompts and save subagents blocks, add deleted_items processing
+- [x] 4.2 Update the success message to include deletion count when deletions occurred
+
+## 5. Quality Assurance
+
+- [x] 5.1 Run `bun run lint` and fix any issues (no `--unsafe` flag)
+- [x] 5.2 Run `bun run build` and verify it succeeds