@chankov/agent-skills 0.2.0 → 0.3.2

package/.versions/0.3.0/skills/using-agent-skills/SKILL.md

@@ -0,0 +1,176 @@
+---
+name: using-agent-skills
+description: Discovers and invokes agent skills. Use when starting a session or when you need to discover which skill applies to the current task. This is the meta-skill that governs how all other skills are discovered and invoked.
+---
+
+# Using Agent Skills
+
+## Overview
+
+Agent Skills is a collection of engineering workflow skills organized by development phase. Each skill encodes a specific process that senior engineers follow. This meta-skill helps you discover and apply the right skill for your current task.
+
+## Skill Discovery
+
+When a task arrives, identify the development phase and apply the corresponding skill:
+
+```
+Task arrives
+    │
+    ├── Vague idea/need refinement? ──→ idea-refine
+    ├── New project/feature/change? ──→ spec-driven-development
+    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
+    ├── Implementing code? ────────────→ incremental-implementation
+    │   ├── UI work? ─────────────────→ frontend-ui-engineering
+    │   ├── API work? ────────────────→ api-and-interface-design
+    │   ├── Need better context? ─────→ context-engineering
+    │   └── Need doc-verified code? ───→ source-driven-development
+    ├── Writing/running tests? ────────→ test-driven-development
+    │   └── Browser-based? ───────────→ browser-testing-with-devtools
+    ├── Something broke? ──────────────→ debugging-and-error-recovery
+    ├── Reviewing code? ───────────────→ code-review-and-quality
+    │   ├── Security concerns? ───────→ security-and-hardening
+    │   └── Performance concerns? ────→ performance-optimization
+    ├── Committing/branching? ─────────→ git-workflow-and-versioning
+    ├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
+    ├── Writing docs/ADRs? ───────────→ documentation-and-adrs
+    ├── Authoring a new skill/persona? ─→ designing-agents
+    └── Deploying/launching? ─────────→ shipping-and-launch
+```
+
+## Core Operating Behaviors
+
+These behaviors apply at all times, across all skills. They are non-negotiable.
+
+### 1. Surface Assumptions
+
+Before implementing anything non-trivial, explicitly state your assumptions:
+
+```
+ASSUMPTIONS I'M MAKING:
+1. [assumption about requirements]
+2. [assumption about architecture]
+3. [assumption about scope]
+→ Correct me now or I'll proceed with these.
+```
+
+Don't silently fill in ambiguous requirements. The most common failure mode is making wrong assumptions and running with them unchecked. Surface uncertainty early — it's cheaper than rework.
+
+### 2. Manage Confusion Actively
+
+When you encounter inconsistencies, conflicting requirements, or unclear specifications:
+
+1. **STOP.** Do not proceed with a guess.
+2. Name the specific confusion.
+3. Present the tradeoff or ask the clarifying question.
+4. Wait for resolution before continuing.
+
+**Bad:** Silently picking one interpretation and hoping it's right.
+**Good:** "I see X in the spec but Y in the existing code. Which takes precedence?"
+
+### 3. Push Back When Warranted
+
+You are not a yes-machine. When an approach has clear problems:
+
+- Point out the issue directly
+- Explain the concrete downside (quantify when possible — "this adds ~200ms latency" not "this might be slower")
+- Propose an alternative
+- Accept the human's decision if they override with full information
+
+Sycophancy is a failure mode. "Of course!" followed by implementing a bad idea helps no one. Honest technical disagreement is more valuable than false agreement.
+
+### 4. Enforce Simplicity
+
+Your natural tendency is to overcomplicate. Actively resist it.
+
+Before finishing any implementation, ask:
+- Can this be done in fewer lines?
+- Are these abstractions earning their complexity?
+- Would a staff engineer look at this and say "why didn't you just..."?
+
+If you build 1000 lines and 100 would suffice, you have failed. Prefer the boring, obvious solution. Cleverness is expensive.
+
+### 5. Maintain Scope Discipline
+
+Touch only what you're asked to touch.
+
+Do NOT:
+- Remove comments you don't understand
+- "Clean up" code orthogonal to the task
+- Refactor adjacent systems as a side effect
+- Delete code that seems unused without explicit approval
+- Add features not in the spec because they "seem useful"
+
+Your job is surgical precision, not unsolicited renovation.
+
+### 6. Verify, Don't Assume
+
+Every skill includes a verification step. A task is not complete until verification passes. "Seems right" is never sufficient — there must be evidence (passing tests, build output, runtime data).
+
+## Failure Modes to Avoid
+
+These are the subtle errors that look like productivity but create problems:
+
+1. Making wrong assumptions without checking
+2. Not managing your own confusion — plowing ahead when lost
+3. Not surfacing inconsistencies you notice
+4. Not presenting tradeoffs on non-obvious decisions
+5. Being sycophantic ("Of course!") to approaches with clear problems
+6. Overcomplicating code and APIs
+7. Modifying code or comments orthogonal to the task
+8. Removing things you don't fully understand
+9. Building without a spec because "it's obvious"
+10. Skipping verification because "it looks right"
+
+## Skill Rules
+
+1. **Check for an applicable skill before starting work.** Skills encode processes that prevent common mistakes.
+
+2. **Skills are workflows, not suggestions.** Follow the steps in order. Don't skip verification steps.
+
+3. **Multiple skills can apply.** A feature implementation might involve `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `shipping-and-launch` in sequence.
+
+4. **When in doubt, start with a spec.** If the task is non-trivial and there's no spec, begin with `spec-driven-development`.
+
+## Lifecycle Sequence
+
+For a complete feature, the typical skill sequence is:
+
+```
+1. idea-refine                 → Refine vague ideas
+2. spec-driven-development     → Define what we're building
+3. planning-and-task-breakdown → Break into verifiable chunks
+4. context-engineering         → Load the right context
+5. source-driven-development   → Verify against official docs
+6. incremental-implementation  → Build slice by slice
+7. test-driven-development     → Prove each slice works
+8. code-review-and-quality     → Review before merge
+9. git-workflow-and-versioning → Clean commit history
+10. documentation-and-adrs     → Document decisions
+11. shipping-and-launch        → Deploy safely
+```
+
+Not every task needs every skill. A bug fix might only need: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.
+
+## Quick Reference
+
+| Phase | Skill | One-Line Summary |
+|-------|-------|-----------------|
+| Define | idea-refine | Refine ideas through structured divergent and convergent thinking |
+| Define | spec-driven-development | Requirements and acceptance criteria before code |
+| Plan | planning-and-task-breakdown | Decompose into small, verifiable tasks |
+| Build | incremental-implementation | Thin vertical slices, test each before expanding |
+| Build | source-driven-development | Verify against official docs before implementing |
+| Build | context-engineering | Right context at the right time |
+| Build | frontend-ui-engineering | Production-quality UI with accessibility |
+| Build | api-and-interface-design | Stable interfaces with clear contracts |
+| Verify | test-driven-development | Failing test first, then make it pass |
+| Verify | browser-testing-with-devtools | Chrome DevTools MCP for runtime verification |
+| Verify | debugging-and-error-recovery | Reproduce → localize → fix → guard |
+| Review | code-review-and-quality | Five-axis review with quality gates |
+| Review | security-and-hardening | OWASP prevention, input validation, least privilege |
+| Review | performance-optimization | Measure first, optimize only what matters |
+| Ship | git-workflow-and-versioning | Atomic commits, clean history |
+| Ship | ci-cd-and-automation | Automated quality gates on every change |
+| Ship | documentation-and-adrs | Document the why, not just the what |
+| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |
+| Author | designing-agents | Author a persona, workflow skill, or pi harness |

package/.versions/0.3.2/.claude/commands/build.md

@@ -0,0 +1,18 @@
+---
+description: Implement the next task incrementally — build, test, verify, commit
+---
+
+Invoke the agent-skills:incremental-implementation skill alongside agent-skills:test-driven-development.
+
+Pick the next pending task from the plan. For each task:
+
+1. Read the task's acceptance criteria
+2. Load relevant context (existing code, patterns, types)
+3. Write a failing test for the expected behavior (RED)
+4. Implement the minimum code to pass the test (GREEN)
+5. Run the full test suite to check for regressions
+6. Run the build to verify compilation
+7. Commit with a descriptive message
+8. Mark the task complete and move to the next one
+
+If any step fails, follow the agent-skills:debugging-and-error-recovery skill.

package/.versions/0.3.2/.claude/commands/code-simplify.md

@@ -0,0 +1,22 @@
+---
+description: Simplify code for clarity and maintainability — reduce complexity without changing behavior
+---
+
+Invoke the agent-skills:code-simplification skill.
+
+Simplify recently changed code (or the specified scope) while preserving exact behavior:
+
+1. Read CLAUDE.md and study project conventions
+2. Identify the target code — recent changes unless a broader scope is specified
+3. Understand the code's purpose, callers, edge cases, and test coverage before touching it
+4. Scan for simplification opportunities:
+   - Deep nesting → guard clauses or extracted helpers
+   - Long functions → split by responsibility
+   - Nested ternaries → if/else or switch
+   - Generic names → descriptive names
+   - Duplicated logic → shared functions
+   - Dead code → remove after confirming
+5. Apply each simplification incrementally — run tests after each change
+6. Verify all tests pass, the build succeeds, and the diff is clean
+
+If tests fail after a simplification, revert that change and reconsider. Use `code-review-and-quality` to review the result.

package/.versions/0.3.2/.claude/commands/design-agent.md

@@ -0,0 +1,14 @@
+---
+description: Design and write a new agent persona (agents/), workflow skill (skills/), or pi harness (.pi/harnesses/)
+---
+
+Invoke the agent-skills:designing-agents skill.
+
+Begin by understanding what the user wants to author:
+1. Is this a **persona** (a role/lens the agent adopts, e.g. a reviewer or auditor), a **skill** (a repeatable workflow with gated steps and verification), or a **pi harness** (a TypeScript pi extension that reshapes the session — footer, tool-call gate, new command, or orchestrator)?
+2. The one-sentence purpose and when it should be invoked
+3. The framework or steps — dimensions evaluated (persona), ordered workflow (skill), or session surface and events hooked (harness)
+4. Explicit non-goals and scope limits
+5. Output shape — what a typical invocation should produce
+
+Then scan the target location (`agents/`, `skills/`, or `.pi/harnesses/`) for overlap, draft the artifact using the matching template — four-block persona structure, the section order from `docs/skill-anatomy.md`, or the harness pattern in `skills/designing-agents/pi-harness-authoring.md` — verify the draft against `references/prompting-patterns.md`, and confirm with the user before writing the file(s).

package/.versions/0.3.2/.claude/commands/doctor-agent-skills.md

@@ -0,0 +1,13 @@
+---
+description: Scan agent-skills install targets for broken symlinks and stale persona references, then offer repairs
+---
+
+Invoke the Doctor scan from the `agent-skills:guided-workspace-setup` skill — Step 5 (the preflight scan) — without running the rest of the install flow. Use this when the user wants the repair pass on its own; the full `/setup-agent-skills` flow runs the same scan automatically as soon as it detects prior install state.
+
+Walk every install-target directory the chosen coding agent uses (`agents/`, `.claude/agents/`, `.opencode/agents/`, `.codex/agents/`, `.gemini/agents/`, `.github/agents/`, `.pi/agents/` and `pi-pi/`, `.claude/skills/`, `.opencode/skills/`, `.pi/skills/`, `.agents/skills`, `.claude/commands/`, `.opencode/commands/`, `.pi/prompts/`, `.claude/references/`, `.claude/hooks/`). For each broken symlink, resolve where it pointed, look for a canonical replacement in the source `agents/` and `skills/` trees, and offer to repoint or delete. Common stale names from the pre-merge persona layout: `reviewer` → `code-reviewer`, `red-team` → `security-auditor`.
+
+Also flag and offer to rewrite any YAML configs (`teams.yaml`, `agent-chain.yaml`, etc.) that still reference removed persona names.
+
+Present findings as a `# | Path | Issue | Suggested fix` table and ask the user to pick which fixes to apply.
+
+Never overwrite a regular file — only act on symlinks whose target is missing. Report `repaired`, `deleted`, and `skipped` counts, and append a `## doctor-runs` line to `.ai/agent-skills-setup.md` with the date, agent, phase (`standalone`), and counts.

package/.versions/0.3.2/.claude/commands/plan.md

@@ -0,0 +1,16 @@
+---
+description: Break work into small verifiable tasks with acceptance criteria and dependency ordering
+---
+
+Invoke the agent-skills:planning-and-task-breakdown skill.
+
+Read the existing spec (SPEC.md or equivalent) and the relevant codebase sections. Then:
+
+1. Enter plan mode — read only, no code changes
+2. Identify the dependency graph between components
+3. Slice work vertically (one complete path per task, not horizontal layers)
+4. Write tasks with acceptance criteria and verification steps
+5. Add checkpoints between phases
+6. Present the plan for human review
+
+Save the plan to the location the `planning-and-task-breakdown` skill defines (default `docs/plans/{area}/PLAN-{prd-name}-{phase}.md`, with the task list embedded — no separate todo file; overridable per project via `.ai/agent-skills-overrides.md`). Match the project's existing `docs`/`Docs` capitalization.

package/.versions/0.3.2/.claude/commands/prime.md

@@ -0,0 +1,22 @@
+---
+description: Load foundational context for the agent-skills repository
+---
+
+# Purpose
+
+Orient yourself in **agent-skills** — a collection of production-grade engineering skills
+for AI coding agents, plus pi extensions, specialist agent personas, and lifecycle
+commands that map to the software development lifecycle.
+
+## Workflow
+
+1. Run `git ls-files` to see the full project file tree
+2. Read `README.md` and `CLAUDE.md` for the project overview and conventions
+3. Read `docs/skill-anatomy.md` to learn the required skill format
+4. Skim `skills/*/SKILL.md` — the core skills, grouped by lifecycle phase
+   (Define → Plan → Build → Verify → Review → Ship)
+5. Read `agents/*.md` — the specialist review personas
+6. Read `docs/pi-extensions.md`, `.pi/extensions/*/README.md` (always-on utilities), and `.pi/harnesses/*/README.md` (selectable session harnesses)
+7. Summarize your understanding: purpose, structure, key files, and entry points
+
+Do this directly — read the files yourself rather than delegating to subagents.

package/.versions/0.3.2/.claude/commands/review.md

@@ -0,0 +1,16 @@
+---
+description: Conduct a five-axis code review — correctness, readability, architecture, security, performance
+---
+
+Invoke the agent-skills:code-review-and-quality skill.
+
+Review the current changes (staged or recent commits) across all five axes:
+
+1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
+2. **Readability** — Clear names? Straightforward logic? Well-organized?
+3. **Architecture** — Follows existing patterns? Clean boundaries? Right abstraction level?
+4. **Security** — Input validated? Secrets safe? Auth checked? (Use security-and-hardening skill)
+5. **Performance** — No N+1 queries? No unbounded ops? (Use performance-optimization skill)
+
+Categorize findings as Critical, Important, or Suggestion.
+Output a structured review with specific file:line references and fix recommendations.

package/.versions/0.3.2/.claude/commands/setup-agent-skills.md

@@ -0,0 +1,19 @@
+---
+description: Guided setup — install agent-skills artifacts into a workspace for a chosen coding agent
+---
+
+Invoke the agent-skills:guided-workspace-setup skill.
+
+Run the guided install for a target workspace. If the user passed a workspace path, use it; otherwise ask for it. Detect the running coding agent and confirm it with the user.
+
+Analyse the workspace. If prior install state is found (`.ai/agent-skills-setup.md` or a populated agent directory), run the **Doctor preflight** first (Step 5) — scan for broken symlinks and stale persona references, present findings as a table, and apply the fixes the user picks before continuing.
+
+Then present the install menu as **one multi-select per group** (18 groups across skills, personas, commands, pi extensions/harnesses, references, hooks) with `★` marking recommendations. Each group renders as a `Pick | Item | Status | Rec | Purpose` table; every row carries an explicit status text — `installed · up to date`, `installed · outdated`, `installed · modified`, `not installed`, or `broken · skipped in preflight`. Installed items are **pre-checked `[x]`** so unchecking = remove; not-installed items start `[ ]`. Per-group reply shortcuts: `all`, `recommended` (adds `★` items on top of the pre-selection — never unticks installed ones), `none`, `keep` (accept the pre-selection unchanged), or a list of picks. Never offer `setup`, `doctor`, or `guided-workspace-setup` — those are installer-only and live in the source agent-skills repo.
+
+Unchecking an installed item means *remove it*, but **removal is scoped**: only act on items whose name is in the agent-skills inventory **and** that are recorded in `## install-status` (or are symlinks resolving into the source repo). User-authored skills, custom commands, third-party plugins, and unrelated settings/env keys are left untouched and logged as "Skipped — not owned by agent-skills".
+
+**No cross-tool substitution.** Each row is offered only when the source file the chosen agent needs already exists — for `pi`, that means `.pi/prompts/<name>.md`, `.pi/extensions/<name>/`, etc. Never fall back to `.claude/commands/` (or another agent's tree) to satisfy a pi prompt request; items missing their per-agent source are filtered out of the menu entirely.
+
+**No mid-apply overwrite prompts.** The Step 6 status text already warns that `installed · modified` rows will have local edits overwritten if kept ticked. The user's tick is the consent; the Step 9 confirmation is the single gate. During apply, refresh ticked items unconditionally — never pause to ask "should I overwrite this file?". Genuine errors (permission denied, missing source) still stop and report.
+
+Offer override sections for the workspace's `.ai/agent-skills-overrides.md` based on the analysis, and record what was installed in `.ai/agent-skills-setup.md`. Summarise the full plan and wait for explicit confirmation before writing anything, then perform the setup, re-scan for any new breakage, and report what changed.

package/.versions/0.3.2/.claude/commands/ship.md

@@ -0,0 +1,17 @@
+---
+description: Run the pre-launch checklist and prepare for production deployment
+---
+
+Invoke the agent-skills:shipping-and-launch skill.
+
+Run through the complete pre-launch checklist:
+
+1. **Code Quality** — Tests pass, build clean, lint clean, no TODOs, no console.logs
+2. **Security** — npm audit clean, no secrets in code, auth in place, headers configured
+3. **Performance** — Core Web Vitals good, no N+1 queries, images optimized, bundle sized
+4. **Accessibility** — Keyboard nav works, screen reader compatible, contrast adequate
+5. **Infrastructure** — Env vars set, migrations ready, monitoring configured
+6. **Documentation** — README current, ADRs written, changelog updated
+
+Report any failing checks and help resolve them before deployment.
+Define the rollback plan before proceeding.

package/.versions/0.3.2/.claude/commands/spec.md

@@ -0,0 +1,15 @@
+---
+description: Start spec-driven development — write a structured specification before writing code
+---
+
+Invoke the agent-skills:spec-driven-development skill.
+
+Begin by understanding what the user wants to build. Ask clarifying questions about:
+1. The objective and target users
+2. Core features and acceptance criteria
+3. Tech stack preferences and constraints
+4. Known boundaries (what to always do, ask first about, and never do)
+
+Then generate a structured spec covering all six core areas: objective, commands, project structure, code style, testing strategy, and boundaries.
+
+Save the spec to the location the `spec-driven-development` skill defines (default `docs/prds/{area}/PRD{n}-{topic}.md`; overridable per project via `.ai/agent-skills-overrides.md`). Confirm with the user before proceeding.

package/.versions/0.3.2/.claude/commands/test.md

@@ -0,0 +1,19 @@
+---
+description: Run TDD workflow — write failing tests, implement, verify. For bugs, use the Prove-It pattern.
+---
+
+Invoke the agent-skills:test-driven-development skill.
+
+For new features:
+1. Write tests that describe the expected behavior (they should FAIL)
+2. Implement the code to make them pass
+3. Refactor while keeping tests green
+
+For bug fixes (Prove-It pattern):
+1. Write a test that reproduces the bug (must FAIL)
+2. Confirm the test fails
+3. Implement the fix
+4. Confirm the test passes
+5. Run the full test suite for regressions
+
+For browser-related issues, also invoke agent-skills:browser-testing-with-devtools to verify with Chrome DevTools MCP.

package/.versions/0.3.2/.opencode/commands/as-build.md

@@ -0,0 +1,17 @@
+---
+description: Implement the next task incrementally - build, test, verify, commit
+---
+
+Invoke the `incremental-implementation` skill and the `test-driven-development` skill via the `skill` tool.
+
+Pick the next pending task from the plan. For each task:
+
+1. Read the task's acceptance criteria.
+2. Load relevant context: existing code, patterns, and types.
+3. Write a failing test for the expected behavior.
+4. Implement the minimum code to pass the test.
+5. Run the relevant test suite to check for regressions.
+6. Run the build to verify compilation.
+7. Mark the task complete and move to the next one.
+
+If any step fails, invoke the `debugging-and-error-recovery` skill via the `skill` tool.

package/.versions/0.3.2/.opencode/commands/as-code-simplify.md

@@ -0,0 +1,16 @@
+---
+description: Simplify code for clarity and maintainability without changing behavior
+---
+
+Invoke the `code-simplification` skill via the `skill` tool.
+
+Simplify recently changed code, or the scope specified in `$ARGUMENTS`, while preserving exact behavior:
+
+1. Read the project's agent instructions and study project conventions.
+2. Identify the target code: recent changes unless a broader scope is specified.
+3. Understand the code's purpose, callers, edge cases, and test coverage before touching it.
+4. Scan for simplification opportunities: deep nesting, long functions, nested ternaries, generic names, duplicated logic, or dead code.
+5. Apply each simplification incrementally and run relevant tests after each change.
+6. Verify tests pass, the build succeeds, and the diff is clean.
+
+If tests fail after a simplification, revert only that simplification and reconsider. Invoke `code-review-and-quality` via the `skill` tool to review the result.

package/.versions/0.3.2/.opencode/commands/as-design-agent.md

@@ -0,0 +1,15 @@
+---
+description: Design and write a new agent persona, workflow skill, or pi harness
+---
+
+Invoke the `designing-agents` skill via the `skill` tool.
+
+Begin by understanding what the user wants to author:
+
+1. Is this a persona (a role or lens the agent adopts), a skill (a repeatable workflow with gated steps and verification), or a pi harness (a TypeScript pi extension that reshapes the session)?
+2. What is the one-sentence purpose and when should it be invoked?
+3. What framework or steps should it follow?
+4. What are the explicit non-goals and scope limits?
+5. What output shape should a typical invocation produce?
+
+Then scan the target location — `agents/`, `skills/`, or `.pi/harnesses/` — for overlap. Draft the artifact using the matching template, verify the draft against prompting guidance when available, and confirm with the user before writing the file(s).

package/.versions/0.3.2/.opencode/commands/as-doctor-agent-skills.md

@@ -0,0 +1,11 @@
+---
+description: Scan agent-skills install targets for broken symlinks and stale persona references, then offer repairs
+---
+
+Invoke the Doctor step from the `guided-workspace-setup` skill (Step 10) via the `skill` tool — without running the rest of the install flow.
+
+Walk every install-target directory the chosen coding agent uses (`agents/`, `.claude/agents/`, `.opencode/agents/`, `.codex/agents/`, `.gemini/agents/`, `.github/agents/`, `.pi/agents/` and `pi-pi/`, `.claude/skills/`, `.opencode/skills/`, `.pi/skills/`, `.agents/skills`, `.claude/commands/`, `.opencode/commands/`, `.pi/prompts/`, `.claude/references/`, `.claude/hooks/`). For each broken symlink, resolve where it pointed, look for a canonical replacement in the source `agents/` and `skills/` trees, and offer to repoint or delete. Common stale names from the pre-merge persona layout: `reviewer` → `code-reviewer`, `red-team` → `security-auditor`.
+
+Also flag and offer to rewrite any YAML configs (`teams.yaml`, `agent-chain.yaml`, etc.) that still reference removed persona names.
+
+Never overwrite a regular file — only act on symlinks whose target is missing. Report `repaired`, `deleted`, and `skipped` counts, and append a `## doctor-runs` line to `.ai/agent-skills-setup.md` with the date and counts.

package/.versions/0.3.2/.opencode/commands/as-plan.md

@@ -0,0 +1,16 @@
+---
+description: Break work into small verifiable tasks with acceptance criteria and dependency ordering
+---
+
+Invoke the `planning-and-task-breakdown` skill via the `skill` tool.
+
+Read the existing spec, such as `SPEC.md`, and relevant codebase sections. Then:
+
+1. Enter planning mode: read only, no code changes.
+2. Identify the dependency graph between components.
+3. Slice work vertically, with one complete path per task rather than horizontal layers.
+4. Write tasks with acceptance criteria and verification steps.
+5. Add checkpoints between phases.
+6. Present the plan for human review.
+
+Save the plan to the location the `planning-and-task-breakdown` skill defines (default `docs/plans/{area}/PLAN-{prd-name}-{phase}.md`, with the task list embedded — no separate todo file; overridable per project via `.ai/agent-skills-overrides.md`), only after the user confirms the plan should be written.

package/.versions/0.3.2/.opencode/commands/as-prime.md

@@ -0,0 +1,22 @@
+---
+description: Load foundational context for the agent-skills repository
+---
+
+# Purpose
+
+Orient yourself in **agent-skills** — a collection of production-grade engineering skills
+for AI coding agents, plus pi extensions, specialist agent personas, and lifecycle
+commands that map to the software development lifecycle.
+
+## Workflow
+
+1. Run `git ls-files` to see the full project file tree
+2. Read `README.md` and `CLAUDE.md` for the project overview and conventions
+3. Read `docs/skill-anatomy.md` to learn the required skill format
+4. Skim `skills/*/SKILL.md` — the core skills, grouped by lifecycle phase
+   (Define → Plan → Build → Verify → Review → Ship)
+5. Read `agents/*.md` — the specialist review personas
+6. Read `docs/pi-extensions.md`, `.pi/extensions/*/README.md` (always-on utilities), and `.pi/harnesses/*/README.md` (selectable session harnesses)
+7. Summarize your understanding: purpose, structure, key files, and entry points
+
+Do this directly — read the files yourself rather than delegating to subagents.

package/.versions/0.3.2/.opencode/commands/as-review.md

@@ -0,0 +1,15 @@
+---
+description: Conduct a five-axis code review - correctness, readability, architecture, security, performance
+---
+
+Invoke the `code-review-and-quality` skill via the `skill` tool.
+
+Review the current changes, staged changes, or scope specified in `$ARGUMENTS` across these axes:
+
+1. Correctness: Does it match the spec? Are edge cases handled? Are tests adequate?
+2. Readability: Are names clear? Is the logic straightforward and well organized?
+3. Architecture: Does it follow existing patterns? Are boundaries clean? Is the abstraction level right?
+4. Security: Is input validated? Are secrets safe? Is authorization checked? Invoke `security-and-hardening` via the `skill` tool when relevant.
+5. Performance: Are there N+1 queries, unbounded operations, or avoidable frontend regressions? Invoke `performance-optimization` via the `skill` tool when relevant.
+
+Categorize findings as Critical, Important, or Suggestion. Output a structured review with specific file and line references plus fix recommendations.

package/.versions/0.3.2/.opencode/commands/as-setup-agent-skills.md

@@ -0,0 +1,11 @@
+---
+description: Guided setup — install agent-skills artifacts into a workspace for a chosen coding agent
+---
+
+Invoke the `guided-workspace-setup` skill via the `skill` tool.
+
+Run the guided install for a target workspace. If the user passed a workspace path, use it; otherwise ask for it. Detect the running coding agent and confirm it with the user.
+
+Analyse the workspace, then present a checklist of installable artifacts — skills, agent personas, commands/prompts, pi extensions and harnesses, references, and hooks — marking what is already installed.
+
+Offer override sections for the workspace's `.ai/agent-skills-overrides.md` based on a brief analysis of the project, and record what was installed in `.ai/agent-skills-setup.md`. Summarise the full plan and wait for explicit confirmation before writing anything, then perform the setup and report what changed.

package/.versions/0.3.2/.opencode/commands/as-ship.md

@@ -0,0 +1,16 @@
+---
+description: Run the pre-launch checklist and prepare for production deployment
+---
+
+Invoke the `shipping-and-launch` skill via the `skill` tool.
+
+Run through the complete pre-launch checklist:
+
+1. Code quality: tests pass, build clean, lint clean, no stray TODOs or console logs.
+2. Security: dependency audit checked, no secrets in code, auth in place, headers configured where applicable.
+3. Performance: Core Web Vitals or relevant performance checks are acceptable, no N+1 queries, images and bundles are reasonable.
+4. Accessibility: keyboard navigation works, screen reader semantics are acceptable, contrast is adequate.
+5. Infrastructure: environment variables are set, migrations are ready, monitoring is configured.
+6. Documentation: README is current, ADRs are written when needed, changelog is updated when relevant.
+
+Report any failing checks and help resolve them before deployment. Define the rollback plan before proceeding.

package/.versions/0.3.2/.opencode/commands/as-spec.md

@@ -0,0 +1,16 @@
+---
+description: Start spec-driven development by writing a structured specification before code
+---
+
+Invoke the `spec-driven-development` skill via the `skill` tool.
+
+Begin by understanding what the user wants to build. Ask clarifying questions about:
+
+1. The objective and target users.
+2. Core features and acceptance criteria.
+3. Tech stack preferences and constraints.
+4. Known boundaries: what to always do, ask first about, and never do.
+
+Then generate a structured spec covering objective, commands, project structure, code style, testing strategy, and boundaries.
+
+Confirm with the user before saving, then save the spec to the location the `spec-driven-development` skill defines (default `docs/prds/{area}/PRD{n}-{topic}.md`; overridable per project via `.ai/agent-skills-overrides.md`).

package/.versions/0.3.2/.opencode/commands/as-test.md

@@ -0,0 +1,21 @@
+---
+description: Run a TDD workflow - write failing tests, implement, verify
+---
+
+Invoke the `test-driven-development` skill via the `skill` tool.
+
+For new features:
+
+1. Write tests that describe the expected behavior and confirm they fail.
+2. Implement the code to make them pass.
+3. Refactor while keeping tests green.
+
+For bug fixes, use the Prove-It pattern:
+
+1. Write a test that reproduces the bug and must fail.
+2. Confirm the test fails.
+3. Implement the fix.
+4. Confirm the test passes.
+5. Run the relevant full test suite for regressions.
+
+For browser-related issues, also invoke `browser-testing-with-devtools` via the `skill` tool to verify with Chrome DevTools MCP.

package/.versions/0.3.2/.pi/agents/agent-chain.yaml

@@ -0,0 +1,49 @@
+plan-build-review:
+  description: "Plan, implement, and review — the standard development cycle"
+  steps:
+    - agent: planner
+      prompt: "Plan the implementation for: $INPUT"
+    - agent: builder
+      prompt: "Implement the following plan:\n\n$INPUT"
+    - agent: code-reviewer
+      prompt: "Review this implementation for bugs, style, and correctness:\n\n$INPUT"
+
+plan-build:
+  description: "Plan then build — fast two-step implementation without review"
+  steps:
+    - agent: planner
+      prompt: "Plan the implementation for: $INPUT"
+    - agent: builder
+      prompt: "Based on this plan, implement:\n\n$INPUT"
+
+scout-flow:
+  description: "Triple-scout deep recon — explore, validate, verify"
+  steps:
+    - agent: scout
+      prompt: "Explore the codebase and investigate: $INPUT\n\nReport your findings with structure, key files, and patterns."
+    - agent: scout
+      prompt: "Validate and cross-check the following analysis. Look for anything missed, incorrect, or incomplete:\n\n$INPUT\n\nOriginal request: $ORIGINAL"
+    - agent: scout
+      prompt: "Final review pass. Verify the analysis below is accurate and complete. Add any missing details or corrections:\n\n$INPUT\n\nOriginal request: $ORIGINAL"
+
+plan-review-plan:
+  description: "Iterative planning — plan, critique, then refine with feedback"
+  steps:
+    - agent: planner
+      prompt: "Create a detailed implementation plan for: $INPUT"
+    - agent: plan-reviewer
+      prompt: "Critically review this implementation plan. Challenge assumptions, find gaps, and suggest improvements:\n\n$INPUT\n\nOriginal request: $ORIGINAL"
+    - agent: planner
+      prompt: "Revise and improve your implementation plan based on this critique. Address every issue raised and incorporate the recommendations:\n\nOriginal request: $ORIGINAL\n\nCritique:\n$INPUT"
+
+full-review:
+  description: "End-to-end pipeline — scout, plan, build, and review"
+  steps:
+    - agent: scout
+      prompt: "Explore the codebase and identify: $INPUT"
+    - agent: planner
+      prompt: "Based on this analysis, create a plan:\n\n$INPUT"
+    - agent: builder
+      prompt: "Implement this plan:\n\n$INPUT"
+    - agent: code-reviewer
+      prompt: "Review this implementation:\n\n$INPUT"