diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json
index b0e602e..e59201d 100644
--- a/.claude-plugin/plugin.json
+++ b/.claude-plugin/plugin.json
@@ -1,7 +1,7 @@
 {
   "name": "sys",
   "description": "Production-grade engineering skills created by Systango Technologies for AI coding agents — covering the full software development lifecycle from spec to ship.",
-  "version": "1.0.4",
+  "version": "1.1.0",
   "author": {
     "name": "Systango Technologies"
   },
diff --git a/.claude/commands/discover.md b/.claude/commands/discover.md
index 2af7feb..ade0ceb 100644
--- a/.claude/commands/discover.md
+++ b/.claude/commands/discover.md
@@ -31,3 +31,7 @@ Using discovered facts, create or update `CLAUDE.md` at project root with Tech S
 **Step 5: Verify (Mandatory)**
 
 Pick 3 specific claims from `.context/` files and verify them against actual code (e.g., check package.json matches stack.md, find a test file to verify conventions.md, read one route handler to verify architecture.md). Fix any incorrect claims before proceeding.
+
+**Mode: Targeted Reference Trace**
+
+If the task is finding all usages of a specific symbol, flag, or string (not broad mapping), skip the full discovery and run the **Targeted Reference Trace** workflow from the skill instead. Use exact search (`rg`/`grep`) first, classify results into definition/usage/test/config, and output a reference table.
diff --git a/.claude/commands/review.md b/.claude/commands/review.md
index 3a4f42a..b89cae1 100644
--- a/.claude/commands/review.md
+++ b/.claude/commands/review.md
@@ -4,6 +4,8 @@ description: Conduct a five-axis code review — correctness, readability, archi
 
 Invoke the sys:code-review-and-quality skill.
 
+Start from the full changeset diff (`git diff` or merge-base diff), not file-by-file. Write an executive summary of scope and risk areas first, then deep-dive only where needed.
+
 Review the current changes (staged or recent commits) across all five axes:
 
 1. **Correctness** — Does it match the spec? Edge cases handled? Tests adequate?
@@ -12,5 +14,5 @@ Review the current changes (staged or recent commits) across all five axes:
 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.
+Categorize findings as **Critical** (blocks merge), **Important** (should address), or **Suggestion** (optional).
 Output a structured review with specific file:line references and fix recommendations.
diff --git a/.claude/commands/ship.md b/.claude/commands/ship.md
index 0bba2cb..06f9c7c 100644
--- a/.claude/commands/ship.md
+++ b/.claude/commands/ship.md
@@ -7,6 +7,11 @@ Invoke the sys:shipping-and-launch skill.
 Run through the pre-launch checklist:
 
 1. **Review Gate** — Code reviewed and approved, no TODOs blocking launch, no console.logs
-2. **Documentation** — README current, ADRs written, changelog updated
+2. **Security** — Dependency 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. **Web Quality** — Meta tags complete, Open Graph set, Lighthouse >= 90, CWV within thresholds, accessibility audit clean, sitemap present, error tracking configured
+5. **Accessibility** — Keyboard nav works, screen reader compatible, contrast adequate, axe-core clean
+6. **Infrastructure** — Env vars set, migrations ready, monitoring configured
+7. **Documentation** — README current, ADRs written, changelog updated
 
 Report any failing checks and help resolve them before deployment.
diff --git a/.gitignore b/.gitignore
index 8f5b978..dd803f4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -27,3 +27,6 @@ build/
 
 # Logs
 *.log
+
+# Working documents (proposals, drafts)
+docs/proposal-*.md
diff --git a/AGENTS.md b/AGENTS.md
index b747b6e..a02d149 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -22,6 +22,7 @@ OpenCode uses a **skill-driven execution model** powered by the `skill` tool and
 The agent should automatically map user intent to skills:
 
 - Feature / new functionality → `spec-driven-development`, then `incremental-implementation`
+- Small task / bug fix / UI tweak / config change → `quick-task-execution`
 - Planning / breakdown → `planning-and-task-breakdown`
 - Bug / failure / unexpected behavior → `debugging-and-error-recovery`
 - Code review → `code-review-and-quality`
@@ -29,6 +30,14 @@ The agent should automatically map user intent to skills:
 - API or interface design → `api-and-interface-design`
 - UI work → `frontend-ui-engineering`
 - PM-first PRD/epic/work-item planning → `syspm` (mirrored workflow), with `pm-spec-and-prd`, `pm-epic-decomposition`, and `pm-jira-sync` available as split variants
+- Idea refinement / brainstorming a concept → `idea-refine`
+- Writing / generating tests → `generate-unit-tests`
+- Browser / E2E / visual testing → `browser-testing-with-devtools`
+- Documentation / ADRs / READMEs → `documentation-and-adrs`
+- Deprecation / migration / version upgrades → `deprecation-and-migration`
+- Git workflow / branching / versioning → `git-workflow-and-versioning`
+- Verifying against official docs / sources → `source-driven-development`
+- Pre-launch / deployment readiness → `shipping-and-launch`
 
 ### Lifecycle Mapping (Implicit Commands)
 
@@ -36,12 +45,16 @@ OpenCode does not support slash commands like `/spec` or `/plan`.
 
 Instead, the agent must internally follow this lifecycle:
 
+- DISCOVER → `brownfield-discovery`
 - DEFINE → `spec-driven-development`
 - PLAN → `planning-and-task-breakdown`
 - SYNC JIRA BOARD (when using Jira specs/plans) → `jira-board-sync` after refined `jira-spec/{story-id}/` artifacts exist
 - BUILD → `incremental-implementation`
 - VERIFY → `debugging-and-error-recovery`
 - REVIEW → `code-review-and-quality`
+- SHIP → `shipping-and-launch`
+- EXPLORE → `idea-refine` (refine raw ideas into actionable concepts with frameworks)
+- QUICK → `quick-task-execution` (small tasks — prefer this for bug fixes, UI tweaks, config changes)
 
 For PM-first SysPM workflows, use:
 
@@ -65,7 +78,7 @@ The following thoughts are incorrect and must be ignored:
 
 - "This is too small for a skill"
 - "I can just quickly implement this"
-- "I’ll gather context first"
+- "I'll gather context first"
 
 Correct behavior:
 
@@ -177,4 +190,4 @@ cp -r skills/{skill-name} ~/.claude/skills/
 **claude.ai:**
 Add the skill to project knowledge or paste SKILL.md contents into the conversation.
 
-If the skill requires network access, instruct users to add required domains at `claude.ai/settings/capabilities`.
\ No newline at end of file
+If the skill requires network access, instruct users to add required domains at `claude.ai/settings/capabilities`.
diff --git a/CLAUDE.md b/CLAUDE.md
index 2a3dfd1..bd8ba65 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -16,15 +16,18 @@ docs/         → Setup guides for different tools
 ## Skills by Phase
 
 **Discover:** brownfield-discovery
-**Define:** spec-driven-development, jira-spec-driven-development
-**Plan:** planning-and-task-breakdown, jira-planning-and-task-breakdown  
+**Define:** spec-driven-development, jira-spec-driven-development, source-driven-development
+**Plan:** planning-and-task-breakdown, jira-planning-and-task-breakdown
 **Sync Jira (after plan):** jira-board-sync
 **SysPM (PM workflow):** syspm, pm-spec-and-prd, pm-epic-decomposition, pm-jira-sync, pm-status-and-reporting
-**Build:** incremental-implementation, context-engineering, frontend-ui-engineering, api-and-interface-design  
-**Verify:** browser-testing-with-devtools, debugging-and-error-recovery
+**Build:** incremental-implementation, context-engineering, frontend-ui-engineering, api-and-interface-design
+**Verify:** generate-unit-tests, browser-testing-with-devtools, debugging-and-error-recovery
 **Review:** code-review-and-quality, code-simplification, security-and-hardening, performance-optimization
 **Ship:** documentation-and-adrs, shipping-and-launch, jira-shipping-and-launch
 **Ad-hoc:** quick-task-execution
+**Explore:** idea-refine
+
+**Maintain:** deprecation-and-migration, git-workflow-and-versioning
 
 ## Conventions
 
@@ -53,4 +56,3 @@ All skills are invoked via slash commands with the `sys:` prefix (e.g., `/discov
 - Always: Follow the skill-anatomy.md format for new skills
 - Never: Add skills that are vague advice instead of actionable processes
 - Never: Duplicate content between skills — reference other skills instead
-
diff --git a/docs/team-rollout.md b/docs/team-rollout.md
new file mode 100644
index 0000000..10ea0f3
--- /dev/null
+++ b/docs/team-rollout.md
@@ -0,0 +1,96 @@
+# Team Rollout Guide
+
+How to adopt `agent-skills` across a development team. This guide covers installation, prerequisites, and best practices for getting consistent results from AI coding agents.
+
+## Prerequisites
+
+Before rolling out to the team, ensure:
+
+1. **AI agent tool is configured** — Claude Code, Cursor with Claude, or another supported agent
+2. **Git workflow established** — the team uses branches, PRs, and code review
+3. **Linter and formatter configured** — ESLint, Prettier, or equivalent so agent output matches team style
+4. **CI pipeline exists** — automated build/test/lint on PR (agents verify locally, CI enforces)
+
+## Installation
+
+### Claude Code
+
+```bash
+# Install the plugin from the marketplace
+/plugin install sys@systango-agent-skills
+
+# Or install manually from the repo
+git clone https://github.com/SystangoTechnologies/agent-skills.git
+cp -r agent-skills/skills/ ~/.claude/skills/
+cp -r agent-skills/.claude/commands/ ~/.claude/commands/
+```
+
+### Cursor
+
+Add the skill files to your project's `.cursor/skills/` directory or reference them in workspace rules.
+
+### Other Agents (OpenCode, Copilot, etc.)
+
+Copy `AGENTS.md` into your repository root. The intent-to-skill mapping in that file guides any agent that reads it.
+
+## First-Day Setup for New Team Members
+
+1. **Install the plugin** (see above)
+2. **Run `/discover` on the project** — generates `.context/` files that help all subsequent skills understand the codebase
+3. **Read the Quick Reference** — know which command to use when (see below)
+
+## Quick Reference
+
+| I want to... | Command | Skill |
+|---|---|---|
+| Fix a bug, make a small change | `/quick` | `quick-task-execution` |
+| Understand a new codebase | `/discover` | `brownfield-discovery` |
+| Find all references to a symbol | `/discover` (trace mode) | `brownfield-discovery` |
+| Write a spec for a feature | `/spec` | `spec-driven-development` |
+| Break a feature into tasks | `/plan` | `planning-and-task-breakdown` |
+| Build the feature | `/build` | `incremental-implementation` |
+| Review a PR | `/review` | `code-review-and-quality` |
+| Simplify complex code | `/code-simplify` | `code-simplification` |
+| Prepare for deployment | `/ship` | `shipping-and-launch` |
+
+## Task Size Triage
+
+The most common mistake is using heavyweight workflows for small tasks. Use this decision tree:
+
+| Task Size | Examples | Workflow |
+|---|---|---|
+| **Small** (1-3 files, <100 lines, obvious approach) | Bug fix, UI tweak, config change, rename | `/quick` |
+| **Medium** (3-10 files, clear requirements) | Add a form, new API endpoint, component refactor | `/plan` → `/build` |
+| **Large** (>10 files, ambiguous requirements) | New feature, major refactor, architecture change | `/discover` → `/spec` → `/plan` → `/build` |
+
+**Default to small.** Escalate only when the task genuinely needs ceremony.
+
+## Stack-Specific Notes
+
+### Frontend
+
+The `frontend-ui-engineering` skill covers component architecture, design system adherence, accessibility, error boundaries, and common anti-patterns. It is framework-agnostic — agents read the project's actual dependencies and adapt accordingly.
+
+### Non-JavaScript / Non-Node Projects
+
+All skills use a **project-tooling-discovery** step instead of hardcoded `npm` commands. The agent checks `package.json`, `Makefile`, `pyproject.toml`, `go.mod`, `Cargo.toml`, and CI workflows to find the right build/test/lint commands. See `references/project-tooling-discovery.md` for details.
+
+## Quality Gates
+
+Before merging any PR, the agent should verify:
+
+1. **Build passes** (project-specific command)
+2. **Tests pass** (project-specific command)
+3. **Lint clean** (project-specific command)
+4. **Type check passes** (project-specific command)
+5. **No TODO comments that should be resolved**
+6. **No debugging statements** (`console.log`, `debugger`)
+7. **For FE launches:** SEO meta tags, Lighthouse >= 90, accessibility audit clean (see `/ship`)
+
+## Tips for Team Leads
+
+1. **Run `/discover` once** after setup and commit the `.context/` directory — it speeds up all subsequent agent interactions for the whole team
+2. **Set up `.cursor/rules/` or `AGENTS.md`** in each repo to guide the agent's behavior with project-specific conventions
+3. **Review agent output early** — the first few PRs from each team member using agents should get extra review to calibrate quality expectations
+4. **Use `/review` on agent-written code** — agents reviewing their own output catches issues that the initial generation missed
+5. **Don't skip `/quick` for small tasks** — the biggest productivity win is using the lightweight path for the 80% of tasks that are small
diff --git a/skills/brownfield-discovery/SKILL.md b/skills/brownfield-discovery/SKILL.md
index 66aad19..d4d0346 100644
--- a/skills/brownfield-discovery/SKILL.md
+++ b/skills/brownfield-discovery/SKILL.md
@@ -33,6 +33,34 @@ When you land in an unfamiliar codebase, you need to understand *what this thing
 - You already have `.context/` files and they're current (skip directly to the skill using them)
 - The codebase is tiny (one file) — reading it directly is faster
 
+## Targeted Reference Trace
+
+When the task is **finding all usages of a specific symbol, flag, env variable, or string** (not broad codebase mapping), use this focused workflow instead of the full 5-agent discovery:
+
+### Process
+
+1. **Start with exact search.** Use `rg` (ripgrep) or `grep -rn` with the exact string. Filter by relevant paths (`--glob 'apps/**'`, `--glob 'libs/**'`).
+2. **Classify each result.** For every match, categorize it:
+   - **Definition** — where the symbol is declared or created
+   - **Usage** — where it's consumed or called
+   - **Test** — test files referencing it
+   - **Config** — environment files, feature flag configs, CI pipelines
+3. **Follow the dependency chain.** From the definition site, trace imports to find all consumers. From consumers, check for indirect usages (re-exports, wrappers).
+4. **Output a reference table:**
+
+| File:Line | Category | One-line Context |
+|-----------|----------|-----------------|
+| `src/config/flags.ts:42` | Definition | `export const ENABLE_CART = process.env.FEATURE_CART === 'true'` |
+| `src/features/cart/CartPage.tsx:8` | Usage | `if (!ENABLE_CART) return <NotFound />` |
+| `tests/cart.test.ts:15` | Test | `beforeEach(() => process.env.FEATURE_CART = 'true')` |
+
+5. **Cross-reference with `.context/` files** (if they exist) to add architectural context — which module owns this code, what concerns exist.
+
+### When to Use Reference Trace vs Full Discovery
+
+- **"Where is X used?"** / **"Find all references to Y"** → Reference Trace
+- **"What does this codebase do?"** / **"I'm new to this project"** → Full Discovery (5 agents)
+
 ## Process
 
 ### Step 1: Decide Scope
@@ -158,6 +186,7 @@ If any claim is wrong, fix it now. Don't commit context docs that hallucinated d
 | "Parallel agents will miss details" | They're not writing a formal spec — they're writing *discoverable pointers to evidence*. Depth comes from agents reading `.context/` when building, not from a 200-page document. |
 | "This is overhead we can't afford" | It's not overhead. It's building the foundation that all subsequent skills depend on. Skip it, and `spec-driven-development`, `planning`, and `code-review` all become slower. |
 | ".context/ files will go stale" | That's fine. They're not gospel — they're starting points. When you find something wrong, fix it. If a file is stale enough to be harmful, re-run this skill. |
+| "I'll just use semantic search to find it" | Semantic search finds *related* code, not *exact* references. For symbols, flags, and specific strings, exact search (`rg`) first, then broaden only if needed. |
 
 ## Red Flags
 
diff --git a/skills/code-review-and-quality/SKILL.md b/skills/code-review-and-quality/SKILL.md
index 57fcf28..d9a7a34 100644
--- a/skills/code-review-and-quality/SKILL.md
+++ b/skills/code-review-and-quality/SKILL.md
@@ -61,7 +61,7 @@ Can another engineer (or agent) understand this code without the author explaini
 - Are there any "clever" tricks that should be simplified?
 - **Could this be done in fewer lines?** (1000 lines where 100 suffice is a failure)
 - **Are abstractions earning their complexity?** (Don't generalize until the third use case)
-- Would comments help clarify non-obvious intent? (But don't comment obvious code.)
+- Would comments help clarify non-obvious intent? (But don't comment obvious code.) Flag narration comments (`// set the value`, `// call the function`, `// return the result`) as Suggestion: remove.
 - Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
 
 ### 3. Architecture
@@ -73,6 +73,7 @@ Does the change fit the system's design?
 - Is there code duplication that should be shared?
 - Are dependencies flowing in the right direction (no circular dependencies)?
 - Is the abstraction level appropriate (not over-engineered, not too coupled)?
+- **Simplicity over DRY:** Small duplication is acceptable when a shared abstraction would add conditionals, indirection, or defensive branches that make the code harder to follow. Don't block a merge because two functions share 5 similar lines — block it when duplication causes real maintenance risk. For larger refactors, cite `code-simplification` as a follow-up, not a merge blocker.
 
 ### 4. Security
 
@@ -157,16 +158,23 @@ Tests reveal intent and coverage:
 
 ### Step 3: Review the Implementation
 
-Walk through the code with the five axes in mind:
+Review in two phases — changeset-first, then deep-dive only where needed:
 
-```
-For each file changed:
+**Phase 1: Changeset Pass**
+Start with the full diff (`git diff` or merge-base diff). Read `git diff --stat` for scope. Write an executive summary:
+- What changed and why (match against spec/ticket)
+- Cross-cutting concerns (shared types changed, API contract shifts, migration needed)
+- Risk areas (security-sensitive files, performance-critical paths, public API changes)
+
+**Phase 2: Deep Pass**
+Go file-by-file only where Phase 1 identified risk. For each flagged file, apply the five axes:
 1. Correctness: Does this code do what the test says it should?
 2. Readability: Can I understand this without help?
 3. Architecture: Does this fit the system?
 4. Security: Any vulnerabilities?
 5. Performance: Any bottlenecks?
-```
+
+Skip deep review for trivial changes (import reordering, formatting, comment updates) unless they mask logic changes.
 
 ### Step 4: Categorize Findings
 
@@ -176,8 +184,8 @@ Label every comment with its severity so the author knows what's required vs opt
 |--------|---------|---------------|
 | *(no prefix)* | Required change | Must address before merge |
 | **Critical:** | Blocks merge | Security vulnerability, data loss, broken functionality |
-| **Nit:** | Minor, optional | Author may ignore — formatting, style preferences |
-| **Optional:** / **Consider:** | Suggestion | Worth considering but not required |
+| **Important:** | Should address | Not a blocker but degrades quality if ignored |
+| **Suggestion:** | Minor, optional | Author may ignore — formatting, style preferences, simplification ideas |
 | **FYI** | Informational only | No action needed — context for future reference |
 
 This prevents authors from treating all feedback as mandatory and wasting time on optional suggestions.
diff --git a/skills/context-engineering/SKILL.md b/skills/context-engineering/SKILL.md
index a99202f..42dfc82 100644
--- a/skills/context-engineering/SKILL.md
+++ b/skills/context-engineering/SKILL.md
@@ -66,6 +66,8 @@ Create a rules file that persists across sessions. This is the highest-leverage
 - Lint: `npm run lint --fix`
 - Dev: `npm run dev`
 - Type check: `npx tsc --noEmit`   # only when this repo uses TypeScript and defines this step
+Discover actual commands from `package.json`, `Makefile`, CI config, or `.context/stack.md`.
+See `references/project-tooling-discovery.md`.
 
 ## Code Conventions
 - Functional components with hooks (no class components)
diff --git a/skills/documentation-and-adrs/SKILL.md b/skills/documentation-and-adrs/SKILL.md
index 8d2656f..830f9f8 100644
--- a/skills/documentation-and-adrs/SKILL.md
+++ b/skills/documentation-and-adrs/SKILL.md
@@ -184,6 +184,38 @@ For REST APIs, maintain an `openapi.yaml` spec alongside the implementation. At
 
 Every project README should cover: a one-paragraph description, Quick Start steps (clone → install → configure → run), a Commands table (dev/test/build/lint), an Architecture overview linking to ADRs, and Contributing guidelines.
 
+Populate the Commands table from actual project config, not defaults. See `references/project-tooling-discovery.md`.
+
+```markdown
+# Project Name
+
+One-paragraph description of what this project does.
+
+## Quick Start
+1. Clone the repo
+2. Install dependencies: `npm install`
+3. Set up environment: `cp .env.example .env`
+4. Run the dev server: `npm run dev`
+
+## Commands
+
+> Populate from actual project config. See `references/project-tooling-discovery.md`.
+
+| Command | Description |
+|---------|-------------|
+| `{project dev command}` | Start development server (e.g., `npm run dev`) |
+| `{project test command}` | Run tests (e.g., `npm test`) |
+| `{project build command}` | Production build (e.g., `npm run build`) |
+| `{project lint command}` | Run linter (e.g., `npm run lint`) |
+
+## Architecture
+Brief overview of the project structure and key design decisions.
+Link to ADRs for details.
+
+## Contributing
+How to contribute, coding standards, PR process.
+```
+
 ## Changelog Maintenance
 
 For shipped features:
diff --git a/skills/frontend-ui-engineering/SKILL.md b/skills/frontend-ui-engineering/SKILL.md
index cc70ced..4a87157 100644
--- a/skills/frontend-ui-engineering/SKILL.md
+++ b/skills/frontend-ui-engineering/SKILL.md
@@ -32,6 +32,55 @@ Build production-quality user interfaces that are accessible, performant, and vi
 - Adding interactivity or state management
 - Fixing visual or UX issues
 
+## Architecture Principles
+
+### Atomic Design
+
+Classify components by scope to enforce consistent granularity:
+
+```
+Atoms       → Button, Input, Badge, Icon (single-purpose, no business logic)
+Molecules   → SearchBar, FormField, NavLink (compose 2-3 atoms)
+Organisms   → Header, ProductCard, TaskList (self-contained sections, may fetch data)
+Templates   → DashboardLayout, AuthLayout (page shells, slot-based)
+Pages       → Route-level composition of organisms within a template
+```
+
+If a molecule needs its own data fetching, promote it to organism. If a component can't be named in 2 words, it does too much — split it.
+
+### SOLID for Frontend
+
+- **Single Responsibility:** `TaskList` renders tasks. `TaskFilter` filters. `TaskPage` composes both. One concern per component.
+- **Open/Closed:** Extend via props and composition, not by modifying source. Use variant props, compound components, render props.
+- **Dependency Inversion:** Components depend on hooks and context, not concrete imports. `useAuth()` not `import { firebaseAuth }`.
+
+### Separation of Concerns
+
+- **Presentation vs logic:** Container components handle data; presentation components handle rendering (pattern shown below)
+- **Data fetching vs rendering vs styling:** each in its own layer — never `fetch()` inside a render function
+- **Business logic lives in hooks/services, never in JSX.** If a handler exceeds 5 lines, extract it.
+
+### Module Boundaries
+
+Prefer feature-based folders over type-based:
+
+```
+src/features/
+  cart/
+    index.ts              # barrel — export only the public API
+    CartPage.tsx
+    CartItem.tsx
+    use-cart.ts
+    cart-api.ts
+    types.ts
+  product/
+    index.ts
+    ...
+src/shared/               # shared atoms, utilities, hooks
+```
+
+Dependency direction flows inward: `pages → features → shared → lib`. Features never import from other features directly — extract shared logic to `shared/`. Use path aliases (`@/features/cart`) over deep relative imports.
+
 ## Component Architecture
 
 ### File Structure
@@ -108,8 +157,8 @@ Local state (useState)           → Component-specific UI state
 Lifted state                     → Shared between 2-3 sibling components
 Context                          → Theme, auth, locale (read-heavy, write-rare)
 URL state (searchParams)         → Filters, pagination, shareable UI state
-Server state (React Query, SWR)  → Remote data with caching
-Global store (Zustand, Redux)    → Complex client state shared app-wide
+Server state (data-fetching library)    → Remote data with caching
+Global store (state management library) → Complex client state shared app-wide
 ```
 
 **Avoid prop drilling deeper than 3 levels.** If you're passing props through components that don't use them, introduce context or restructure the component tree.
@@ -267,9 +316,30 @@ function TaskListSkeleton() {
 // Optimistic updates — see [`patterns.md`](patterns.md) for a full `useMutation` implementation.
 ```
 
+## Error Boundaries
+
+- **Granularity:** One error boundary per feature section (cart, checkout, dashboard chart) — a crash in one section should not kill the whole page
+- Always show a recovery action: retry button, link to safe page, or fallback UI
+- Log errors to a tracking service inside the boundary's error handler
+- Anti-pattern: empty `catch` blocks that swallow errors silently
+
+## FE Anti-Patterns
+
+| Anti-Pattern | Why It Hurts | Fix |
+|---|---|---|
+| Prop drilling >3 levels | Fragile, hard to refactor | Context, composition, or state management library |
+| One global store for everything | Any state change re-renders everything | Slice per domain, use selectors |
+| `import _ from 'lodash'` | Full library in bundle | `import groupBy from 'lodash/groupBy'` or native |
+| Nested ternaries in JSX | Unreadable | Early returns, guard clauses, extracted components |
+| Business logic in components | Untestable, non-reusable | Extract to hooks or services |
+| Inline styles or arbitrary values | Breaks design system consistency | Use design system tokens |
+| No loading/error/empty states | Blank screens, user confusion | Handle all three for every async operation |
+| `any` as escape hatch | Defeats TypeScript | `unknown` + type guard, proper generics |
+| `as` type cast instead of guard | Unsafe, hides runtime bugs | Type predicate function |
+
 ## See Also
 
-For detailed accessibility requirements and testing tools, see `references/accessibility-checklist.md`.
+- For detailed accessibility requirements and testing tools, see `references/accessibility-checklist.md`
 
 ## Common Rationalizations
 
@@ -289,7 +359,10 @@ For detailed accessibility requirements and testing tools, see `references/acces
 - No keyboard navigation testing
 - Color as the sole indicator of state (red/green without text or icons)
 - Generic "AI look" (purple gradients, oversized cards, stock layouts)
-- Comment noise: blocks that restate markup, handlers, or `className` choices the code already expresses
+- Comment noise: blocks that restate markup, handlers, or class choices the code already expresses
+- No error boundary around crash-prone sections (charts, third-party widgets)
+- Hardcoded user-facing strings (blocks future i18n)
+- `any` or `// @ts-ignore` without a linked issue
 
 ## Verification
 
diff --git a/skills/incremental-implementation/SKILL.md b/skills/incremental-implementation/SKILL.md
index 67455d6..159ac38 100644
--- a/skills/incremental-implementation/SKILL.md
+++ b/skills/incremental-implementation/SKILL.md
@@ -234,6 +234,15 @@ AI-generated code often ships with redundant noise: line-by-line narration, comm
 
 Do **not** add comments for obvious or self-explanatory code. Prefer **clear names, small functions, and structure** so readers see intent without commentary.
 
+```
+BAD:  // Initialize the counter
+      // Fetch user data from the API
+      // Return the result
+
+GOOD: // Rate-limit to 100 req/s per tenant (see ADR-012)
+      // Must run before auth middleware — depends on parsed cookies
+```
+
 Do comment when something is **non-obvious**: real-world constraints, security or correctness invariants, performance tradeoffs, or *why* this approach was chosen over alternatives. Keep module- and API-level docs **concise and behavior-focused** — not a rehash of the implementation.
 
 ### Rule 1: One Thing at a Time
@@ -345,6 +354,8 @@ This skill does not prescribe when or how to commit. When the user or project ne
 - Creating test files or writing test code during the build phase (reserved for the `/test` phase)
 - Checking the `Tests written` checkbox in a task's Unit Tests section (only the `/test` phase does this)
 - Comments that restate the next line, obvious control flow, or types the reader already sees — prefer clearer code instead
+- Generating summary files (`IMPLEMENTATION_COMPLETE.md`, `BUILD_SUMMARY.md`, etc.) — the build record is the checked todo.md + git log, not a standalone summary file
+- Creating new spec or plan files for trivially small follow-up changes in the same session
 
 ## Verification
 
diff --git a/skills/jira-board-sync/SKILL.md b/skills/jira-board-sync/SKILL.md
index e7504a4..2f34826 100644
--- a/skills/jira-board-sync/SKILL.md
+++ b/skills/jira-board-sync/SKILL.md
@@ -14,6 +14,7 @@ Complements [`jira-spec-driven-development`](../jira-spec-driven-development/SKI
 - [Prerequisites](#prerequisites)
 - [Workflow](#workflow)
 - [See Also](#see-also)
+- [Jira MCP Integration](#jira-mcp-integration)
 - [Common Rationalizations](#common-rationalizations)
 - [Red Flags](#red-flags)
 - [Verification](#verification)
@@ -58,6 +59,27 @@ Todo blocks follow **`## Task [N]:`** in [`planning-and-task-breakdown`](../plan
 | Todo task template | [`planning-and-task-breakdown`](../planning-and-task-breakdown/SKILL.md) |
 | Launch comments (later phase) | [`jira-shipping-and-launch`](../jira-shipping-and-launch/SKILL.md) |
 
+## Jira MCP Integration
+
+This skill requires a Jira MCP server for API access. Supported servers:
+
+| Server | Language | Key Tools |
+|---|---|---|
+| `@mcpio/jira` | TypeScript | 52 tools, ADF conversion, bulk ops |
+| `scottlepp/jira-mcp` | TypeScript | REST v3, Agile API, worklogs |
+| `aforbco/Jira-cloud-mcp` | Python | 86 tools, admin, workflows |
+
+### Ticket Updates and Work Logging
+
+Beyond sync, teams commonly need agents to update ticket status, add comments, or log work:
+
+- **Transition tickets:** Use `jira_transition_issue` to move tickets through workflow states after build tasks complete
+- **Add comments:** Use `jira_add_comment` to post implementation notes or blockers
+- **Log work (Jira native):** Use `jira_add_worklog` to record time spent on tickets
+- **Log work (Tempo):** If using Tempo Timesheets, configure the Tempo MCP server (`TRANZACT/tempo-filler-mcp-server`) separately — it uses its own API token and provides `create_worklog`, `get_worklogs`, and bulk operations.
+
+All write operations require explicit user approval — never auto-transition tickets or log time without confirmation.
+
 ## Common Rationalizations
 
 | Rationalization | Reality |
@@ -71,7 +93,8 @@ Todo blocks follow **`## Task [N]:`** in [`planning-and-task-breakdown`](../plan
 
 - Any Jira **write** before **`sync.md`** exists and approval is explicit.
 - `sync.md` missing **Current** snapshots for story/tasks being updated.
-- Applying changes that don’t match what `sync.md` promised.
+- Applying changes that don't match what `sync.md` promised.
+- Auto-transitioning tickets or logging time without user confirmation.
 
 ## Verification
 
diff --git a/skills/jira-planning-and-task-breakdown/SKILL.md b/skills/jira-planning-and-task-breakdown/SKILL.md
index 4c43732..21d13ea 100644
--- a/skills/jira-planning-and-task-breakdown/SKILL.md
+++ b/skills/jira-planning-and-task-breakdown/SKILL.md
@@ -24,10 +24,12 @@ Extends `planning-and-task-breakdown` for Jira-tracked work. Follow the full `pl
 
 In **Step 1 (Enter Plan Mode)**, read `jira-spec/{story-id}/spec-{story-id}.md` instead of the generic spec path.
 
-In the **todo.md Template**, the header reference changes to:
-```markdown
-Detailed tasks for the plan in `plan-{story-id}.md`. Build one task at a time, top to bottom.
-```
+In the **todo.md Template**, use the same per-task template and field-by-field rules from `planning-and-task-breakdown` (see its [templates.md](../planning-and-task-breakdown/templates.md)), with these path differences:
+
+- Header: `Detailed tasks for the plan in plan-{story-id}.md.`
+- File name: `todo-{story-id}.md` (not `todo.md`)
+
+Discover project commands from `package.json`, `Makefile`, CI config, or `.context/stack.md`. See `references/project-tooling-discovery.md`.
 
 ### Jira Task Mapping
 
diff --git a/skills/planning-and-task-breakdown/SKILL.md b/skills/planning-and-task-breakdown/SKILL.md
index 340fa9e..782bb08 100644
--- a/skills/planning-and-task-breakdown/SKILL.md
+++ b/skills/planning-and-task-breakdown/SKILL.md
@@ -28,7 +28,7 @@ Decompose work into small, verifiable tasks with explicit acceptance criteria. G
 - You need to communicate scope to a human
 - The implementation order isn't obvious
 
-**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks.
+**When NOT to use:** Single-file changes with obvious scope, or when the spec already contains well-defined tasks. If the spec already contains well-defined tasks with acceptance criteria and the implementation order is obvious, you may skip generating `plan.md` and write only `todo.md`. `plan.md` adds value when there are architectural decisions, risk ordering, or parallel-work coordination not captured in the spec.
 
 ## The Planning Process
 
@@ -120,6 +120,8 @@ Each task in **todo.md** follows this structure:
 - [ ] Static / compile checks pass (type-check, analyzer, or equivalent the repo defines — same discovery reference)
 - [ ] Manual check: [description of what to verify]
 
+> Discover commands from `package.json`, `Makefile`, CI config, or `.context/stack.md`. See `references/project-tooling-discovery.md`.
+
 **Dependencies:** [Task numbers this depends on, or "None"]
 
 **Files likely touched:**
@@ -134,12 +136,12 @@ Each task in **todo.md** follows this structure:
 
 - **Acceptance criteria** — every item must use checkbox syntax (`- [ ]`), not plain bullets (`- `). Plain bullets are not trackable.
 - **Unit Tests (deferred)** — required for every task. The `- [ ] Tests written` line must use checkbox syntax (`- [ ]`), not a plain bullet. This checkbox is the contract between the planning and testing phases — the `/test` phase checks it after writing tests. The build phase skips this section entirely and does not create test files.
-- **Verification** — every item must use checkbox syntax (`- [ ]`), not plain bullets. Build-phase gates verify compilation and static analysis only — never the full **test suite** (`npm test`, `pnpm test`, `pytest`, `cargo test`, `go test ./...`, coverage thresholds, or equivalent).
+- **Verification** — every item must use checkbox syntax (`- [ ]`), not plain bullets. Build-phase gates verify compilation and static analysis only — never the full **test suite** (`npm test`, `pnpm test`, `pytest`, `cargo test`, `go test ./...`, coverage thresholds, or equivalent). Discover the project's actual build/type-check commands from `package.json`, `Makefile`, CI config, or `.context/stack.md` — see `references/project-tooling-discovery.md`.
 - **Domain skill** — required for every task. The planner knows the task's domain when writing it. Embed the classification so the builder doesn't have to re-derive it. Use `None` for pure infrastructure tasks (build config, utility functions, migrations with no auth surface). Tasks involving REST endpoints, HTTP status codes, request/response contracts, or middleware must specify `api-and-interface-design`. Tasks involving UI components, layouts, or state must specify `frontend-ui-engineering`. Tasks involving auth, validation, PII, or sessions must specify `security-and-hardening`. A task may list more than one skill if it spans domains.
 
-For the complete todo.md template with all required fields and examples, see [templates.md](templates.md).
+For the complete todo.md and plan.md templates with all required fields and examples, see [templates.md](templates.md).
 
-Every task block must include all fields. Do not abbreviate, do not use simplified bullets, do not omit the Unit Tests (deferred) section. If you find yourself shortening a task block to save space, stop — either the task belongs in the Task Index only (plan.md) or it needs its full detail here.
+`todo.md` is a flat stack of detailed task blocks — no extra prose, no simplified bullets. Every task from plan.md's Task Index appears here in full form, in the same order. Every task block must include all fields from the template. Do not abbreviate, do not use simplified bullets, do not omit the Unit Tests (deferred) section. If you find yourself shortening a task block to save space, stop — either the task belongs in the Task Index only (plan.md) or it needs its full detail here.
 
 ### Step 5: Validate Task List Structure
 
diff --git a/skills/planning-and-task-breakdown/templates.md b/skills/planning-and-task-breakdown/templates.md
index 2632b29..085a6b7 100644
--- a/skills/planning-and-task-breakdown/templates.md
+++ b/skills/planning-and-task-breakdown/templates.md
@@ -39,6 +39,8 @@ Detailed tasks for the plan in `plan.md`. Build one task at a time, top to botto
 - [ ] Static / compile checks pass (type-check, analyzer, or equivalent the repo defines — same discovery reference)
 - [ ] Manual check: [description of what to verify]
 
+> Discover commands from `package.json`, `Makefile`, CI config, or `.context/stack.md`. See `references/project-tooling-discovery.md`.
+
 **Dependencies:** None
 
 **Files likely touched:**
diff --git a/skills/quick-task-execution/SKILL.md b/skills/quick-task-execution/SKILL.md
index 6fd111c..e1be085 100644
--- a/skills/quick-task-execution/SKILL.md
+++ b/skills/quick-task-execution/SKILL.md
@@ -55,6 +55,8 @@ Create `specs/quick/{slug}.md` where `{slug}` is a short, lowercase, hyphen-sepa
 - [ ] Project-native **build** and **static/compile** checks (discover per `references/project-tooling-discovery.md`; do not assume npm/tsc)
 - [ ] {any task-specific checks}
 
+> Discover commands from `package.json`, `Makefile`, CI config, or `.context/stack.md`. See `references/project-tooling-discovery.md`.
+
 ## Noticed but not touched
 {Adjacent issues spotted during the work. Leave empty at start.}
 ```
@@ -74,7 +76,9 @@ State the loaded skill explicitly before writing code — e.g. *"Loading `api-an
 
 ### Step 3: Implement
 
-Apply the domain skill's patterns. Keep the codebase compilable throughout — don't leave the build broken between edits. Touch only what the goal requires.
+Apply the domain skill's patterns. Do not add comments that narrate what the code does (`// fetch the data`, `// return the result`). Comments explain *why*, not *what* — prefer expressive naming instead. Keep the codebase compilable throughout — don't leave the build broken between edits. Touch only what the goal requires.
+
+**Follow-up tasks in the same session:** If the user asks for a trivially small follow-up (e.g., "now add a button to that page") that is <20 lines, same domain, same feature area — do NOT create a new `specs/quick/*.md` file. Track it as a continuation of the current task's commit.
 
 **Comments:** Do not add comments for obvious or self-explanatory code. Prefer expressive naming and small, clear units. Comment only for non-obvious intent, invariants, or constraints — not line-by-line narration or restatements of the code.
 
@@ -112,6 +116,7 @@ No separate summary file, no state table — `git log` plus `specs/quick/` is th
 - Acceptance criteria boxes never got checked
 - Domain skill never named before implementation started
 - *Noticed but not touched* is empty after a non-trivial change — either nothing was spotted (plausible) or scope crept silently (check the diff)
+- Creating summary or completion files after the task — the commit + plan file IS the record
 
 ## Verification
 
diff --git a/skills/shipping-and-launch/SKILL.md b/skills/shipping-and-launch/SKILL.md
index f2731b5..df8d2cf 100644
--- a/skills/shipping-and-launch/SKILL.md
+++ b/skills/shipping-and-launch/SKILL.md
@@ -30,7 +30,63 @@ Ship with confidence. The review phase covers code quality, security, and perfor
 - [ ] No TODO comments that should be resolved before launch
 - [ ] No `console.log` debugging statements in production code
 
-### 2. Documentation
+### 2. Security
+
+- [ ] No secrets in code or version control
+- [ ] Dependency audit shows no critical or high vulnerabilities (run project audit command — see `references/project-tooling-discovery.md`)
+- [ ] Input validation on all user-facing endpoints
+- [ ] Authentication and authorization checks in place
+- [ ] Security headers configured (CSP, HSTS, etc.)
+- [ ] Rate limiting on authentication endpoints
+- [ ] CORS configured to specific origins (not wildcard)
+
+### 3. Performance
+
+- [ ] Core Web Vitals within "Good" thresholds
+- [ ] No N+1 queries in critical paths
+- [ ] Images optimized (compression, responsive sizes, lazy loading)
+- [ ] Bundle size within budget
+- [ ] Database queries have appropriate indexes
+- [ ] Caching configured for static assets and repeated queries
+
+### 4. Web Quality Gate (Frontend Launches)
+
+Run these checks before any user-facing deployment. Use project-discovered commands (see `references/project-tooling-discovery.md`).
+
+**SEO and Meta:**
+- [ ] Every page has unique `<title>` and `<meta name="description">`
+- [ ] Open Graph tags present (`og:title`, `og:description`, `og:image`, `og:url`)
+- [ ] Twitter Card tags present (`twitter:card`, `twitter:title`, `twitter:image`)
+- [ ] Canonical URLs set on all pages (`<link rel="canonical">`)
+- [ ] `robots.txt` exists and allows indexing of public pages
+- [ ] Sitemap exists (`/sitemap.xml`) and is linked in `robots.txt`
+- [ ] Structured data (JSON-LD) on key pages (product, article, FAQ, organization)
+- [ ] No `noindex` tags on pages that should be indexed
+- [ ] URL structure is semantic and human-readable
+
+**Core Web Vitals and Performance:**
+- [ ] Lighthouse Performance score >= 90 (`npx lhci autorun` or DevTools Lighthouse)
+- [ ] LCP <= 2.5s, INP <= 200ms, CLS <= 0.1
+- [ ] Bundle size within budget (check build output or `npx bundlesize`)
+- [ ] Images: WebP/AVIF format, responsive `srcset`, lazy loading below fold
+- [ ] Fonts: WOFF2, preloaded, `font-display: swap`
+- [ ] No render-blocking resources in `<head>`
+
+**Accessibility:**
+- [ ] Lighthouse Accessibility score >= 90
+- [ ] `axe-core` scan passes with zero critical issues
+- [ ] Keyboard navigation works for all interactive elements
+- [ ] Color contrast meets WCAG AA (4.5:1 normal text, 3:1 large)
+
+**Observability:**
+- [ ] Error tracking configured (Sentry, Datadog RUM, or equivalent)
+- [ ] Source maps uploaded to error tracker (not exposed publicly)
+- [ ] PII scrubbing enabled (no user emails/passwords in error reports)
+- [ ] Release tracking tied to git SHA or version
+
+For SEO metadata, ensure pages have proper `<title>`, `<meta name="description">`, and structured data (JSON-LD) appropriate to the framework.
+
+### 5. Documentation
 
 - [ ] README updated with any new setup requirements
 - [ ] API documentation current
@@ -40,4 +96,6 @@ Ship with confidence. The review phase covers code quality, security, and perfor
 
 ## Verification
 
-- [ ] Both checklist sections green (or failing items documented with resolution plan)
+- [ ] All checklist sections green (or failing items documented with resolution plan)
+- [ ] Lighthouse scores meet thresholds (Performance >= 90, Accessibility >= 90)
+- [ ] Error tracking is receiving events in staging before production deploy
diff --git a/skills/spec-driven-development/SKILL.md b/skills/spec-driven-development/SKILL.md
index 63a4892..cd2c561 100644
--- a/skills/spec-driven-development/SKILL.md
+++ b/skills/spec-driven-development/SKILL.md
@@ -26,7 +26,7 @@ Write a structured specification before writing any code. The spec is the shared
 - You're about to make an architectural decision
 - The task would take more than 30 minutes to implement
 
-**When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained.
+**When NOT to use:** Single-line fixes, typo corrections, or changes where requirements are unambiguous and self-contained. For bug fixes, minor UI changes, small refactors, or config changes — use `/quick` (`quick-task-execution`) instead.
 
 ## The Gated Workflow
 
@@ -73,10 +73,10 @@ Don't silently fill in ambiguous requirements. The spec's entire purpose is to s
 2. **Commands** — Discover from this repository (`references/project-tooling-discovery.md`). Record **exact** invocations in the spec. **Also** append or update the **`## Commands`** section in **`.context/stack.md`** when that file exists (or create `.context/stack.md` with that section) so future sessions read one canonical source — do not leave confirmed commands only in the spec. Example shape for a Node repo (replace with what you actually found):
 
    ```
-   Build: npm run build
-   Test: npm test -- --coverage
-   Lint: npm run lint --fix
-   Dev: npm run dev
+   Build: {project build command} (e.g., npm run build)
+   Test: {project test command} (e.g., npm test -- --coverage)
+   Lint: {project lint command} (e.g., npm run lint --fix)
+   Dev: {project dev command} (e.g., npm run dev)
    ```
 
 3. **Project Structure** — Where source code lives, where tests go, where docs belong.
@@ -179,7 +179,7 @@ Break the plan into discrete, implementable tasks:
 
 ### Phase 4: Implement
 
-Execute tasks one at a time following `incremental-implementation` and `test-driven-development` skills. Use `context-engineering` to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
+Execute tasks one at a time following `incremental-implementation` and `generate-unit-tests` skills. Use `context-engineering` to load the right spec sections and source files at each step rather than flooding the agent with the entire spec.
 
 ## Keeping the Spec Alive
 
diff --git a/skills/using-agent-skills/SKILL.md b/skills/using-agent-skills/SKILL.md
index d2f577e..c8bbec3 100644
--- a/skills/using-agent-skills/SKILL.md
+++ b/skills/using-agent-skills/SKILL.md
@@ -21,13 +21,27 @@ Agent Skills is a collection of engineering workflow skills organized by develop
 
 ## Skill Discovery
 
+When a task arrives, first assess its size before choosing a workflow:
+
+### Task Size Triage
+
+| Size | Characteristics | Workflow |
+|------|----------------|----------|
+| **Small** | Single concern, 1-3 files, obvious approach, <100 lines changed | `/quick` (quick-task-execution) |
+| **Medium** | Clear requirements, 3-10 files, one domain, no ambiguity about *what* | Skip `/spec`, go to `/plan` → `/build` |
+| **Large** | Multiple domains, ambiguous requirements, new public interfaces, >10 files | Full lifecycle: `/discover` → `/spec` → `/plan` → `/build` |
+
+**Default to small.** Most bug fixes, UI tweaks, config changes, and small refactors are `/quick` tasks. Escalate only when the task genuinely needs more ceremony.
+
 When a task arrives, identify the development phase and apply the corresponding skill:
 
 ```
 Task arrives
     │
-    ├── simple task/user doesn't want spec-driven? ──→ Don't apply Spec driven, continue normally
+    ├── Small & obvious? (bug fix, UI tweak, config, <3 files)
+    │   └──→ quick-task-execution (/quick)
     ├── Unfamiliar existing codebase, no .context/ docs? ──→ brownfield-discovery
+    ├── "Should we use X or Y?" / comparing approaches? ───→ solution-option-exploration
     ├── New project/feature/change? ──→ spec-driven-development
     ├── PM-first initiative planning? ─→ pm-spec-and-prd
     │   ├── Need epic work items? ────→ pm-epic-decomposition
@@ -44,7 +58,9 @@ Task arrives
     ├── Reviewing code? ───────────────→ code-review-and-quality
     │   ├── Security concerns? ───────→ security-and-hardening
     │   └── Performance concerns? ────→ performance-optimization
-    └── Writing docs/ADRs? ───────────→ documentation-and-adrs
+    ├── Writing docs/ADRs? ───────────→ documentation-and-adrs
+    ├── Commit msg / PR description / chat msg? ──→ engineering-artifact-generation
+    └── Preparing to deploy? ─────────→ shipping-and-launch
 ```
 
 ## Core Operating Behaviors
@@ -178,23 +194,32 @@ Not every task needs every skill. A bug fix might only need: `debugging-and-erro
 
 ## Quick Reference
 
-| Phase | Skill | One-Line Summary |
-|-------|-------|-----------------|
-| Discover | brownfield-discovery | Map tech, architecture, conventions, concerns of existing codebase |
-| 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 | 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 | generate-unit-tests | Create unit tests |
-| PM | pm-spec-and-prd | Build PRD and epic artifacts for SysPM |
-| PM | pm-epic-decomposition | Decompose epic into `T###` Jira-mappable work items |
-| PM | pm-jira-sync | Sync SysPM artifacts to Jira and write mapping keys |
-| PM | pm-status-and-reporting | Produce PM progress and blocker summaries |
-| 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 | documentation-and-adrs | Document the why, not just the what |
-| Ship | shipping-and-launch | Pre-launch checklist, monitoring, rollback plan |
+| Phase | Skill | Command | One-Line Summary |
+|-------|-------|---------|-----------------|
+| Ad-hoc | quick-task-execution | `/quick` | Fast path for small, obvious tasks (<3 files) |
+| Discover | brownfield-discovery | `/discover` | Map tech, architecture, conventions of existing codebase |
+| Explore | solution-option-exploration | — | Compare 2-4 engineering approaches with tradeoffs |
+| Explore | engineering-artifact-generation | — | Generate commit messages, PR descriptions, team chat messages |
+| Explore | idea-refine | — | Refine raw ideas into actionable concepts with frameworks |
+| Define | spec-driven-development | `/spec` | Requirements and acceptance criteria before code |
+| Define | source-driven-development | — | Verify implementation against official docs/sources |
+| Plan | planning-and-task-breakdown | `/plan` | Decompose into small, verifiable tasks |
+| Build | incremental-implementation | `/build` | Thin vertical slices, test each before expanding |
+| Build | context-engineering | — | Right context at the right time |
+| Build | frontend-ui-engineering | — | Production-quality UI with accessibility and design system adherence |
+| Build | api-and-interface-design | — | Stable interfaces with clear contracts |
+| Verify | generate-unit-tests | `/test` | Create unit tests |
+| Verify | browser-testing-with-devtools | — | Browser/E2E testing with DevTools integration |
+| Verify | debugging-and-error-recovery | — | Reproduce → localize → fix → guard |
+| PM | pm-spec-and-prd | `/pm-spec` | Build PRD and epic artifacts for SysPM |
+| PM | pm-epic-decomposition | `/pm-epic` | Decompose epic into `T###` Jira-mappable work items |
+| PM | pm-jira-sync | `/pm-sync` | Sync SysPM artifacts to Jira and write mapping keys |
+| PM | pm-status-and-reporting | — | Produce PM progress and blocker summaries |
+| Review | code-review-and-quality | `/review` | Five-axis review with changeset-first approach |
+| Review | code-simplification | `/code-simplify` | Reduce complexity while preserving behavior |
+| Review | security-and-hardening | — | OWASP prevention, input validation, least privilege |
+| Review | performance-optimization | — | Measure first, optimize only what matters |
+| Maintain | deprecation-and-migration | — | Deprecate APIs, migrate versions safely |
+| Maintain | git-workflow-and-versioning | — | Branching strategy, commit conventions, versioning |
+| Ship | documentation-and-adrs | — | Document the why, not just the what |
+| Ship | shipping-and-launch | `/ship` | Pre-launch checklist, web quality gate, monitoring, rollback |