@complexthings/superpowers-agent 9.2.0 → 10.0.0

package/skills/meta/create-skill-json/SKILL.md

@@ -127,7 +127,7 @@ Aliases allow users to reference the skill with shorter names.
 ]
 ```
 
-**Optional:** Add a well-known abbreviation as a third alias if one exists (e.g., `"tdd"` for test-driven-development, `"sdd"` for subagent-driven-development). Only add an abbreviation if it's clearly recognized — don't invent aliases.
+**Optional:** Add a well-known abbreviation as a third alias only when it is clearly recognized — don't invent aliases.
 
 **Do NOT add random synonyms** — stick to the standard two aliases unless an obvious abbreviation exists.
 
@@ -244,7 +244,7 @@ metadata:
 - ❌ `keyConcepts` - Document in SKILL.md content
 - ❌ `overview` - Document in SKILL.md content
 
-### Discovery Fields (handled by find-skills)
+### Discovery Fields (handled by native skill discovery)
 - ❌ `tags` - Use SKILL.md frontmatter fields for search
 - ❌ `keywords` - Use SKILL.md content for search
 - ❌ `triggers` - Use SKILL.md `description` field
@@ -276,8 +276,8 @@ metadata:
 
 | Rationalization | Counter |
 |-----------------|---------|
-| "Adding `description` helps with discoverability" | NO. Description is in SKILL.md frontmatter. find-skills reads that. |
-| "`tags` make it easier to categorize and search" | NO. find-skills uses SKILL.md content and frontmatter. Path already indicates category. |
+| "Adding `description` helps with discoverability" | NO. Description is in SKILL.md frontmatter. Native skill discovery reads it. |
+| "`tags` make it easier to categorize and search" | NO. Native skill discovery uses SKILL.md content and frontmatter. Path already indicates category. |
 | "`capabilities` document what the skill does" | NO. That's what SKILL.md content is for. skill.json is for tooling, not documentation. |
 | "`triggers` help agents know when to use this" | NO. SKILL.md `description` field serves this purpose. Don't duplicate. |
 | "These fields might be useful for future features" | YAGNI violation. No imaginary consumers. Only add fields when tooling actually needs them. |

package/skills/meta/create-skill-json/skill.json

@@ -1,6 +1,6 @@
 {
   "version": "1.1.0",
-  "name": "superpowers:meta/create-skill-json",
+  "name": "create-skill-json",
   "title": "create-skill-json",
   "aliases": [
     "create-skill-json",

package/skills/meta/create-skill-json/test-scenarios.md

@@ -23,7 +23,7 @@ Agent adds fields like: `description`, `tags`, `capabilities`, `triggers`, `keyC
 
 ## Common Rationalizations to Block
 - "Adding description helps with discoverability" → NO, description is in SKILL.md
-- "Tags make it easier to find" → NO, find-skills uses SKILL.md frontmatter
+- "Tags make it easier to find" → NO, native skill discovery uses SKILL.md frontmatter
 - "Capabilities document what it does" → NO, that's in SKILL.md content
 - "These fields might be useful later" → YAGNI violation
 - "Other tools might use them" → No other tools exist, don't design for imaginary consumers

package/skills/setup-skills/SKILL.md

@@ -1,14 +1,12 @@
 ---
 name: setup-skills
-description: Run superpowers-agent setup-skills to initialize the skills infrastructure for a project. Use whenever starting a new project with AI agents, when skills symlinks are missing, when AGENTS.md lacks skills configuration, when a user asks to "set up skills", "install skills", "bootstrap skills", or "initialize superpowers". Also use when skills aren't being discovered or when you're about to create project-specific skills and the infrastructure doesn't exist yet. If there's any chance the project hasn't been set up for skills yet, run this skill.
+description: Run superpowers-agent setup-skills to detect which AI harnesses (Claude Code, GitHub Copilot, OpenCode, Pi, Codex) are present in a project and wire up its skills infrastructure — .agents/skills/, per-harness symlinks, and each harness's instruction file. Use whenever starting a new project with AI agents, when skills symlinks are missing, when AGENTS.md or CLAUDE.md lacks skills configuration, when a user asks to "set up skills", "install skills", "bootstrap skills", or "initialize superpowers". Also use when skills aren't being discovered, or before creating project-specific skills if the infrastructure doesn't exist yet.
 ---
 
 # Setup Skills
 
 This skill does one thing: run `superpowers-agent setup-skills` and follow the output it gives you exactly.
 
-The command sets up the full skills infrastructure for a project — creating `.agents/`, symlinks for each AI platform, and updating `AGENTS.md` — and its output tells you everything that happened and what to do next.
-
 ## Run the Command
 
 From the project root:
@@ -17,18 +15,30 @@ From the project root:
 superpowers-agent setup-skills
 ```
 
+## What the Command Does
+
+- Creates `.agents/`, `.agents/skills/`, and `.agents/docs/SUPERPOWERS.md` (the reference doc every generated instruction file links to).
+- Detects harnesses by dot-folder existence or CLI binary on PATH: Claude Code (`.claude`/`claude`), GitHub Copilot (`.github`/`copilot`), OpenCode (`.opencode`/`opencode`), Pi (`.pi`/`pi`), Codex (`.codex`/`codex`).
+- Writes/updates `AGENTS.md` unconditionally (creating it if missing) with tool mappings for Copilot, OpenCode, Pi, and Codex.
+- Updates `CLAUDE.md` in place only if one already exists at the project root or in `.agents/` — it never creates a fresh `CLAUDE.md`.
+- Creates or updates `.github/copilot-instructions.md` only when GitHub Copilot is detected.
+- Keeps exactly one backup per instruction file it touches (dedupes old `*.backup*` files).
+- Symlinks each detected harness's skills dir back to `.agents/skills/`: `.claude/skills`, `.github/skills`, `.opencode/skill` (singular). Pi and Codex read `.agents/skills/` directly — no symlink.
+
 ## Follow the Output Exactly
 
-The command output is authoritative. Read it, act on it, and do not skip any steps it prescribes. It adapts to the platforms detected in your project and tells you precisely what was created, updated, or skipped.
+The command output is authoritative. Read it, act on it, and do not skip any steps it prescribes. It adapts to the harnesses detected in your project and tells you precisely what was created, updated, or skipped.
 
 If the command prints follow-up instructions, complete them before continuing with your task.
 
+If it fails for any reason other than not-found (e.g. permission denied, partial failure), surface the exact error and stop — do not continue or leave the project half-configured.
+
 ## If superpowers-agent Is Not Found
 
 Install it first, then rerun:
 
 ```bash
-@npm install -g @complexthings/superpowers-agent
+npm install -g @complexthings/superpowers-agent
 superpowers-agent setup-skills
 ```
 
@@ -36,12 +46,9 @@ superpowers-agent setup-skills
 
 Project-specific skills belong in `.agents/skills/`. All AI agents working in the project discover them automatically via the symlinks the command created.
 
-To verify:
-```bash
-superpowers-agent find-skills
-```
+To verify, use your platform's native skill tool and confirm the project skills are available.
 
 ## Related Skills
 
-- **finding-skills** — Discover available skills after setup
-- **using-superpowers** — How the full skills system works
+- Use your platform's native skill tool to discover available skills after setup.
+- Follow your platform's skill guidance for loading and applying them.

package/skills/setup-skills/skill.json

@@ -0,0 +1,8 @@
+{
+  "version": "1.0.0",
+  "name": "setup-skills",
+  "title": "setup-skills",
+  "aliases": [
+    "setup-skills"
+  ]
+}

package/.agents/skills/caveman/SKILL.md

@@ -1,49 +0,0 @@
----
-name: caveman
-description: >
-  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
-  filler, articles, and pleasantries while keeping full technical accuracy.
-  Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
----
-
-Respond terse like smart caveman. All technical substance stay. Only fluff die.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
-
-## Rules
-
-Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
-
-Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
-
-Pattern: `[thing] [action] [reason]. [next step].`
-
-Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
-Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
-
-### Examples
-
-**"Why React component re-render?"**
-
-> Inline obj prop -> new ref -> re-render. `useMemo`.
-
-**"Explain database connection pooling."**
-
-> Pool = reuse DB conn. Skip handshake -> fast under load.
-
-## Auto-Clarity Exception
-
-Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
-
-Example -- destructive op:
-
-> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
->
-> ```sql
-> DROP TABLE users;
-> ```
->
-> Caveman resume. Verify backup exist first.

package/.agents/skills/improve-codebase-architecture/LANGUAGE.md

@@ -1,53 +0,0 @@
-# Language
-
-Shared vocabulary for every suggestion this skill makes. Use these terms exactly — don't substitute "component," "service," "API," or "boundary." Consistent language is the whole point.
-
-## Terms
-
-**Module**
-Anything with an interface and an implementation. Deliberately scale-agnostic — applies equally to a function, class, package, or tier-spanning slice.
-_Avoid_: unit, component, service.
-
-**Interface**
-Everything a caller must know to use the module correctly. Includes the type signature, but also invariants, ordering constraints, error modes, required configuration, and performance characteristics.
-_Avoid_: API, signature (too narrow — those refer only to the type-level surface).
-
-**Implementation**
-What's inside a module — its body of code. Distinct from **Adapter**: a thing can be a small adapter with a large implementation (a Postgres repo) or a large adapter with a small implementation (an in-memory fake). Reach for "adapter" when the seam is the topic; "implementation" otherwise.
-
-**Depth**
-Leverage at the interface — the amount of behaviour a caller (or test) can exercise per unit of interface they have to learn. A module is **deep** when a large amount of behaviour sits behind a small interface. A module is **shallow** when the interface is nearly as complex as the implementation.
-
-**Seam** _(from Michael Feathers)_
-A place where you can alter behaviour without editing in that place. The *location* at which a module's interface lives. Choosing where to put the seam is its own design decision, distinct from what goes behind it.
-_Avoid_: boundary (overloaded with DDD's bounded context).
-
-**Adapter**
-A concrete thing that satisfies an interface at a seam. Describes *role* (what slot it fills), not substance (what's inside).
-
-**Leverage**
-What callers get from depth. More capability per unit of interface they have to learn. One implementation pays back across N call sites and M tests.
-
-**Locality**
-What maintainers get from depth. Change, bugs, knowledge, and verification concentrate at one place rather than spreading across callers. Fix once, fixed everywhere.
-
-## Principles
-
-- **Depth is a property of the interface, not the implementation.** A deep module can be internally composed of small, mockable, swappable parts — they just aren't part of the interface. A module can have **internal seams** (private to its implementation, used by its own tests) as well as the **external seam** at its interface.
-- **The deletion test.** Imagine deleting the module. If complexity vanishes, the module wasn't hiding anything (it was a pass-through). If complexity reappears across N callers, the module was earning its keep.
-- **The interface is the test surface.** Callers and tests cross the same seam. If you want to test *past* the interface, the module is probably the wrong shape.
-- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a seam unless something actually varies across it.
-
-## Relationships
-
-- A **Module** has exactly one **Interface** (the surface it presents to callers and tests).
-- **Depth** is a property of a **Module**, measured against its **Interface**.
-- A **Seam** is where a **Module**'s **Interface** lives.
-- An **Adapter** sits at a **Seam** and satisfies the **Interface**.
-- **Depth** produces **Leverage** for callers and **Locality** for maintainers.
-
-## Rejected framings
-
-- **Depth as ratio of implementation-lines to interface-lines** (Ousterhout): rewards padding the implementation. We use depth-as-leverage instead.
-- **"Interface" as the TypeScript `interface` keyword or a class's public methods**: too narrow — interface here includes every fact a caller must know.
-- **"Boundary"**: overloaded with DDD's bounded context. Say **seam** or **interface**.

package/.agents/skills/karpathy-guidelines/SKILL.md

@@ -1,75 +0,0 @@
----
-name: karpathy-guidelines
-description: Behavioral guardrails against common LLM coding mistakes — overcomplication, sprawling diffs, hidden assumptions, fuzzy success. Use whenever adding a feature, fixing a bug, refactoring, handling an ambiguous request, or planning a multi-step change. Apply even when the path feels obvious, and before writing code for any underspecified ask.
-license: MIT
----
-
-# Karpathy Guidelines
-
-Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
-
-**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
-
-## 1. Think Before Coding
-
-**Don't assume. Don't hide confusion. Surface tradeoffs.**
-
-LLMs tend to resolve ambiguity by silently picking the most statistically likely interpretation and proceeding as if it were stated, which buries decisions the user never got to make.
-
-Before implementing:
-- State your assumptions explicitly. If uncertain, ask.
-- If multiple interpretations exist, present them - don't pick silently.
-- If a simpler approach exists, say so. Push back when warranted.
-- If something is unclear, stop. Name what's confusing. Ask.
-
-## 2. Simplicity First
-
-**Minimum code that solves the problem. Nothing speculative.**
-
-Models pattern-match toward "complete-looking" solutions seen in training — adding config flags, error branches, and abstractions that match the shape of production code rather than the actual ask.
-
-- No features beyond what was asked.
-- No abstractions for single-use code.
-- No "flexibility" or "configurability" that wasn't requested.
-- No error handling for impossible scenarios.
-- If you write 200 lines and it could be 50, rewrite it.
-
-Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
-
-## 3. Surgical Changes
-
-**Touch only what you must. Clean up only your own mess.**
-
-A common failure mode is opportunistic refactoring: while in a file, the model "tidies" adjacent code it judges suboptimal, producing diffs the user can't review against their original intent.
-
-When editing existing code:
-- Don't "improve" adjacent code, comments, or formatting.
-- Don't refactor things that aren't broken.
-- Match existing style, even if you'd do it differently.
-- If you notice unrelated dead code, mention it - don't delete it.
-
-When your changes create orphans:
-- Remove imports/variables/functions that YOUR changes made unused.
-- Don't remove pre-existing dead code unless asked.
-
-The test: Every changed line should trace directly to the user's request.
-
-## 4. Goal-Driven Execution
-
-**Define success criteria. Loop until verified.**
-
-Without an external check, LLMs tend to declare success based on whether the output looks right rather than whether it behaves right, since the training signal rewards plausible-looking completions over verified ones.
-
-Transform tasks into verifiable goals:
-- "Add validation" → "Write tests for invalid inputs, then make them pass"
-- "Fix the bug" → "Write a test that reproduces it, then make it pass"
-- "Refactor X" → "Ensure tests pass before and after"
-
-For multi-step tasks, state a brief plan:
-```
-1. [Step] → verify: [check]
-2. [Step] → verify: [check]
-3. [Step] → verify: [check]
-```
-
-Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

package/.agents/skills/review/SKILL.md

@@ -1,78 +0,0 @@
----
-name: review
-description: Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".
----
-
-# Review
-
-Two-axis review of the diff between `HEAD` and a fixed point the user supplies:
-
-- **Standards** — does the code conform to this repo's documented coding standards?
-- **Spec** — does the code faithfully implement the originating issue / PRD / spec?
-
-Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings.
-
-The issue tracker should have been provided to you — run `/setup-matt-pocock-skills` if `docs/agents/issue-tracker.md` is missing.
-
-## Process
-
-### 1. Pin the fixed point
-
-Whatever the user said is the fixed point — a commit SHA, branch name, tag, `main`, `HEAD~5`, etc. Don't be opinionated; pass it through. If they didn't specify one, ask: "Review against what — a branch, a commit, or `main`?" Don't proceed until you have it.
-
-Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, so the comparison is against the merge-base). Also note the list of commits via `git log <fixed-point>..HEAD --oneline`.
-
-### 2. Identify the spec source
-
-Look for the originating spec, in this order:
-
-1. Issue references in the commit messages (`#123`, `Closes #45`, GitLab `!67`, etc.) — fetch via the workflow in `docs/agents/issue-tracker.md`.
-2. A path the user passed as an argument.
-3. A PRD/spec file under `docs/`, `specs/`, or `.scratch/` matching the branch name or feature.
-4. If nothing is found, ask the user where the spec is. If they say there isn't one, the **Spec** sub-agent will skip and report "no spec available".
-
-### 3. Identify the standards sources
-
-Anything in the repo that documents how code should be written. Common locations:
-
-- `CLAUDE.md`, `AGENTS.md`
-- `CONTRIBUTING.md`
-- `CONTEXT.md`, `CONTEXT-MAP.md`, per-context `CONTEXT.md` files
-- `docs/adr/` (architectural decisions are standards)
-- `.editorconfig`, `eslint.config.*`, `biome.json`, `prettier.config.*`, `tsconfig.json` (machine-enforced standards — note them but don't re-check what tooling already checks)
-- Any `STYLE.md`, `STANDARDS.md`, `STYLEGUIDE.md`, or similar at the repo root or under `docs/`
-
-Collect the list of files. The **Standards** sub-agent will read them.
-
-### 4. Spawn both sub-agents in parallel
-
-Send a single message with two `Agent` tool calls. Use the `general-purpose` subagent for both.
-
-**Standards sub-agent prompt** — include:
-
-- The full diff command and commit list.
-- The list of standards-source files you found in step 3.
-- The brief: "Read the standards docs. Then read the diff. Report — per file/hunk where relevant — every place the diff violates a documented standard. Cite the standard (file + the rule). Distinguish hard violations from judgement calls. Skip anything tooling enforces. Under 400 words."
-
-**Spec sub-agent prompt** — include:
-
-- The diff command and commit list.
-- The path or fetched contents of the spec.
-- The brief: "Read the spec. Then read the diff. Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."
-
-If the spec is missing, skip the Spec sub-agent and note this in the final report.
-
-### 5. Aggregate
-
-Present the two reports under `## Standards` and `## Spec` headings, verbatim or lightly cleaned. Do **not** merge or rerank findings — the two axes are deliberately separate so the user can see them independently.
-
-End with a one-line summary: total findings per axis, and the worst single issue (if any) flagged.
-
-## Why two axes
-
-A change can pass one axis and fail the other:
-
-- Code that follows every standard but implements the wrong thing → **Standards pass, Spec fail.**
-- Code that does exactly what the issue asked but breaks the project's conventions → **Spec pass, Standards fail.**
-
-Reporting them separately stops one axis from masking the other.

package/.agents/skills/tdd/deep-modules.md

@@ -1,33 +0,0 @@
-# Deep Modules
-
-From "A Philosophy of Software Design":
-
-**Deep module** = small interface + lots of implementation
-
-```
-┌─────────────────────┐
-│   Small Interface   │  ← Few methods, simple params
-├─────────────────────┤
-│                     │
-│                     │
-│  Deep Implementation│  ← Complex logic hidden
-│                     │
-│                     │
-└─────────────────────┘
-```
-
-**Shallow module** = large interface + little implementation (avoid)
-
-```
-┌─────────────────────────────────┐
-│       Large Interface           │  ← Many methods, complex params
-├─────────────────────────────────┤
-│  Thin Implementation            │  ← Just passes through
-└─────────────────────────────────┘
-```
-
-When designing interfaces, ask:
-
-- Can I reduce the number of methods?
-- Can I simplify the parameters?
-- Can I hide more complexity inside?

package/.agents/skills/tdd/interface-design.md

@@ -1,31 +0,0 @@
-# Interface Design for Testability
-
-Good interfaces make testing natural:
-
-1. **Accept dependencies, don't create them**
-
-   ```typescript
-   // Testable
-   function processOrder(order, paymentGateway) {}
-
-   // Hard to test
-   function processOrder(order) {
-     const gateway = new StripeGateway();
-   }
-   ```
-
-2. **Return results, don't produce side effects**
-
-   ```typescript
-   // Testable
-   function calculateDiscount(cart): Discount {}
-
-   // Hard to test
-   function applyDiscount(cart): void {
-     cart.total -= discount;
-   }
-   ```
-
-3. **Small surface area**
-   - Fewer methods = fewer tests needed
-   - Fewer params = simpler test setup

package/.agents/skills/tdd/refactoring.md

@@ -1,10 +0,0 @@
-# Refactor Candidates
-
-After TDD cycle, look for:
-
-- **Duplication** → Extract function/class
-- **Long methods** → Break into private helpers (keep tests on public interface)
-- **Shallow modules** → Combine or deepen
-- **Feature envy** → Move logic to where data lives
-- **Primitive obsession** → Introduce value objects
-- **Existing code** the new code reveals as problematic

package/.agents/skills/to-issues/SKILL.md

@@ -1,83 +0,0 @@
----
-name: to-issues
-description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
----
-
-# To Issues
-
-Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
-
-The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
-
-## Process
-
-### 1. Gather context
-
-Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
-
-### 2. Explore the codebase (optional)
-
-If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
-
-### 3. Draft vertical slices
-
-Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
-
-Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
-
-<vertical-slice-rules>
-- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
-- A completed slice is demoable or verifiable on its own
-- Prefer many thin slices over few thick ones
-</vertical-slice-rules>
-
-### 4. Quiz the user
-
-Present the proposed breakdown as a numbered list. For each slice, show:
-
-- **Title**: short descriptive name
-- **Type**: HITL / AFK
-- **Blocked by**: which other slices (if any) must complete first
-- **User stories covered**: which user stories this addresses (if the source material has them)
-
-Ask the user:
-
-- Does the granularity feel right? (too coarse / too fine)
-- Are the dependency relationships correct?
-- Should any slices be merged or split further?
-- Are the correct slices marked as HITL and AFK?
-
-Iterate until the user approves the breakdown.
-
-### 5. Publish the issues to the issue tracker
-
-For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. These issues are considered ready for AFK agents, so publish them with the correct triage label unless instructed otherwise.
-
-Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
-
-<issue-template>
-## Parent
-
-A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
-
-## What to build
-
-A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
-
-Avoid specific file paths or code snippets — they go stale fast. Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it here and note briefly that it came from a prototype. Trim to the decision-rich parts — not a working demo, just the important bits.
-
-## Acceptance criteria
-
-- [ ] Criterion 1
-- [ ] Criterion 2
-- [ ] Criterion 3
-
-## Blocked by
-
-- A reference to the blocking ticket (if any)
-
-Or "None - can start immediately" if no blockers.
-
-</issue-template>
-
-Do NOT close or modify any parent issue.

package/.agents/skills/zoom-out/SKILL.md

@@ -1,7 +0,0 @@
----
-name: zoom-out
-description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
-disable-model-invocation: true
----
-
-I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.

package/skills/architecture/ABOUT.md

@@ -1,20 +0,0 @@
-# Architecture Skills - Attribution
-
-This skill was derived from agent patterns in the [Amplifier](https://github.com/microsoft/amplifier) project.
-
-**Source Repository:**
-- Name: Amplifier
-- URL: https://github.com/microsoft/amplifier
-- Commit: 2adb63f858e7d760e188197c8e8d4c1ef721e2a6
-- Date: 2025-10-10
-
-## Skills Derived from Amplifier Agents
-
-**From ambiguity-guardian agent:**
-- preserving-productive-tensions - Recognizing when disagreements reveal valuable context, preserving multiple valid approaches instead of forcing premature resolution
-
-## What Was Adapted
-
-The ambiguity-guardian agent preserves productive contradictions and navigates uncertainty as valuable features of knowledge. This skill extracts the core pattern-recognition capability: distinguishing when tensions should be preserved (context-dependent trade-offs) vs resolved (clear technical superiority).
-
-Adapted as scannable guide with symptom-based triggers ("going back and forth", "keep changing mind") and practical preservation patterns (configuration, parallel implementations, documented trade-offs).