showdar-skills 0.3.0 → 0.4.0

package/CHANGELOG.md

@@ -6,6 +6,37 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
+## [0.4.0]
+
+### Added
+
+- First-class workflow skill model: 15 primitives (`kind: primitive`) plus 4
+  workflows (`kind: workflow`) for 19 total installable skills.
+- `showdar-feature`: adaptive end-to-end feature implementation over
+  understand, requirements, plan, design, build, test, and review stages.
+- `showdar-bugfix`: adaptive defect resolution over understand, debug, build,
+  test, and review stages, including investigation-only mode.
+- `showdar-release`: release readiness versus execution separation over
+  quality, security, ship, and authority-gated ops stages.
+- `showdar-incident`: operational incident investigation and recovery over
+  understand, debug, recover, verification, and authority-gated ops stages.
+- `showdar add feature|bugfix|release|incident` installs workflows through the
+  existing installer; short names normalize like primitives.
+- Workflow composition and safety validation: stage references resolve to
+  known primitives, workflows never stage another workflow or themselves,
+  and workflow SKILL.md files stay lean by referencing primitives.
+
+### Changed
+
+- Catalog distinguishes primitive and workflow skills; `getSkill` and
+  `normalizeSkillName` resolve all 19 installable skills.
+- `showdar validate` reports primitive/workflow/total counts
+  (`15 primitives, 4 workflows, 19 total`).
+- `showdar add` normalization supports workflow IDs and short names.
+- OpenCode `skill.md` command lists all 19 skills with a whole-task versus
+  single-primitive selection guard.
+- AGENTS.md managed routing block includes workflow routes when installed.
+
 ## [0.3.0]
 
 ### Added

package/MIGRATION.md

@@ -1,3 +1,26 @@
+# Migrating to 0.4.0
+
+0.4.0 adds four optional workflow skills over the unchanged 15 primitives:
+
+```bash
+showdar add feature
+showdar add bugfix
+showdar add release
+showdar add incident
+```
+
+- 0.3.0 `.showdar.json` v2 configs remain valid; no config-version migration
+  is required.
+- All 15 primitive IDs remain unchanged.
+- Profile behavior and composition are unchanged: `minimal` (8), `developer`
+  (12), `backend` (14), `qa` (9), `product` (6), `full` (15 primitives).
+- Workflows are additive and optional; they complement rather than replace
+  primitives. Nothing is removed.
+- No Phase 6G routing migration is required; the authority engine and the
+  15-capability primitive taxonomy are unchanged.
+- Single primitive requests keep resolving to primitives; whole-task or
+  lifecycle requests may select a workflow.
+
 # Migrating to 0.3.0
 
 ## Skill install roots

package/README.md

@@ -3,7 +3,7 @@
 [![npm version](https://img.shields.io/npm/v/showdar-skills?logo=npm)](https://www.npmjs.com/package/showdar-skills)
 [![Node >=20](https://img.shields.io/badge/node-%3E%3D20-339933?logo=node.js&logoColor=white)](https://nodejs.org/)
 [![MIT License](https://img.shields.io/badge/license-MIT-blue?logo=opensourceinitiative&logoColor=white)](./LICENSE)
-[![15 skills](https://img.shields.io/badge/skills-15-6f42c1)](#skill-catalog)
+[![19 skills](https://img.shields.io/badge/skills-19-6f42c1)](#skill-catalog)
 
 Production-grade software engineering skills for coding agents. Showdar covers
 the full lifecycle—from requirements and planning through implementation, QA,
@@ -42,7 +42,7 @@ you want all capabilities available.
 
 ## Why Showdar?
 
-- **15 focused skills** instead of one oversized agent prompt.
+- **15 focused primitive skills** plus 4 adaptive workflow skills (19 installable) instead of one oversized agent prompt.
 - **Lifecycle coverage** from product rules to implementation, verification,
   security, operations, release readiness, and Git completion.
 - **Intent-based discovery** that selects the workflow matching the request.
@@ -72,9 +72,12 @@ SKILL.md
           only when needed
 ```
 
-The 15 skills are not eagerly loaded as full prompts. Lightweight descriptions
-help the agent choose one skill; that skill then loads its workflow and deeper
-knowledge progressively.
+The 15 primitive skills are not eagerly loaded as full prompts. Lightweight
+descriptions help the agent choose one skill; that skill then loads its
+workflow and deeper knowledge progressively. Workflow skills add a portable
+orchestration layer: a workflow selects the lifecycle stages a task actually
+needs and composes primitives one at a time, without duplicating their
+instructions.
 
 ## Supported agents
 
@@ -130,8 +133,10 @@ paths are refreshed or removed.
 
 ## Profiles
 
-Role-specific profiles improve routing precision. `full` exposes every skill,
-but still does not eagerly load every skill body.
+Role-specific profiles improve routing precision. Profiles install primitive
+skill sets; workflow skills are opt-in through `showdar add <workflow>` and
+are not silently included in any profile. `full` exposes every primitive
+skill, but still does not eagerly load every skill body.
 
 | Profile | Skills | Best for |
 | --- | ---: | --- |
@@ -140,7 +145,7 @@ but still does not eagerly load every skill body.
 | `backend` | 14 | APIs, services, and runtime operations |
 | `qa` | 9 | Testing and quality workflows |
 | `product` | 6 | Product, requirements, and design work |
-| `full` | 15 | All capabilities |
+| `full` | 15 | All primitive capabilities |
 
 Legacy aliases remain compatible:
 
@@ -153,7 +158,8 @@ New manifests store the canonical `developer` profile.
 
 ## Skill catalog
 
-All 15 entries are first-class Showdar skills.
+All 15 primitive entries are first-class Showdar skills. Four workflow skills
+compose them; see [Workflow skills](#workflow-skills).
 
 ### Analysis and planning
 
@@ -195,6 +201,109 @@ All 15 entries are first-class Showdar skills.
 | `showdar-recover` | Interrupted or partial engineering work must be reconstructed from repository evidence before continuing. |
 | `showdar-git` | Performing local Git inspection, staging, commits, branch integration, conflicts, cleanup, or explicitly requested remote Git actions. |
 
+## Workflow skills
+
+Four workflow skills orchestrate primitives adaptively; they are not fixed
+pipelines and they grant no extra authority:
+
+| Skill | Use when |
+| --- | --- |
+| `showdar-feature` | Implementing a complete feature end-to-end. |
+| `showdar-bugfix` | Resolving an observed defect end-to-end. |
+| `showdar-release` | Preparing, validating, or executing a release lifecycle. |
+| `showdar-incident` | Investigating or recovering from an active operational incident. |
+
+How a workflow runs:
+
+```text
+Workflow
+  -> selects needed lifecycle stages
+  -> invokes/composes primitive skills one at a time
+  -> primitives retain their own semantics
+  -> Phase 6G remains the authority source
+```
+
+Properties:
+
+- Adaptive, not fixed pipelines: stages marked `?` below are skipped when
+  evidence permits.
+- Intended for whole-task and lifecycle requests.
+- Focused primitive requests remain primitive.
+- Workflow identity never grants mutation or deployment authority.
+- Risk and severity never grant production authority.
+- Workflows do not create a second router or authority engine.
+
+### showdar-feature
+
+```bash
+showdar add feature
+```
+
+Typical candidate flow:
+
+```text
+understand -> requirements? -> plan? -> design? -> build -> test -> review
+```
+
+Skip requirements when behavior is already defined, plan for genuinely
+focused work, and design when no architecture or UX decision exists.
+Verification is never skipped to move faster. Ops is not implied.
+
+### showdar-bugfix
+
+```bash
+showdar add bugfix
+```
+
+Typical:
+
+```text
+understand -> debug? -> build -> test -> review
+```
+
+If the root cause is already proven, debug may be skipped. If the request is
+diagnosis only, build is not implied and the workflow stops after
+`showdar-debug`.
+
+### showdar-release
+
+```bash
+showdar add release --scope global --ai claude
+```
+
+Typical:
+
+```text
+quality -> security? -> ship -> ops only with explicit target + authorization
+```
+
+Readiness must not imply deployment. `showdar-ship` stays delivery
+verification; `showdar-ops` loads only with an explicit target plus execution
+authorization.
+
+### showdar-incident
+
+```bash
+showdar add incident
+```
+
+Typical:
+
+```text
+understand -> debug -> recover -> verification -> ops only when explicitly authorized
+```
+
+Diagnose before mutating when the cause is unknown. Severity must not imply
+production mutation. The workflow never auto-deploys or restarts production
+from risk alone.
+
+Workflows compose primitives: they select only the stages the evidence
+requires, skip defined or decision-free stages, load one primitive at a time,
+and stop when evidence or authority is missing. Single primitive requests stay
+primitive (`showdar-review`, `showdar-debug`, `showdar-test`). Phase 6G remains
+the authority source; workflows consume it and never mint it. Workflows are
+opt-in through `showdar add <workflow>`; profiles install primitive sets only.
+
 ## A typical software workflow
 
 ```text
@@ -255,17 +364,23 @@ OpenCode exposes native commands after initialization with `--ai opencode` or
 
 ## Adding a single skill
 
-Install one primitive skill without re-running a whole profile:
+Install one skill without re-running a whole profile:
 
 ```bash
 showdar add debug
 showdar add showdar-security
 showdar add test --ai cursor
 showdar add review --scope global --ai claude
+showdar add feature
+showdar add bugfix --ai cursor
+showdar add release --scope global --ai claude
+showdar add incident
 ```
 
-Accepted names are the short form (`debug`) or the canonical form
-(`showdar-debug`). The release ships exactly 15 primitive skills. `showdar add`
+Accepted names are the short form (`debug`, `feature`) or the canonical form
+(`showdar-debug`, `showdar-feature`). The release ships exactly 15 primitive
+skills plus 4 workflow skills (19 installable total); profiles install
+primitive sets only. There is no `showdar workflow ...` command. `showdar add`
 is idempotent, preserves the configured profile, supports `--ai`/`--scope`
 overrides, and refuses to overwrite a foreign same-name skill directory that
 Showdar does not own.

package/bin/showdar.js

@@ -3,7 +3,7 @@ import path from 'node:path';
 import { homedir } from 'node:os';
 import { readFile } from 'node:fs/promises';
 import { fileURLToPath } from 'node:url';
-import { AI_TARGETS, PROFILE_ALIASES, PROFILES, SKILLS, canonicalProfile, isDeprecatedProfile, resolveProfile } from '../src/catalog.js';
+import { AI_TARGETS, PRIMITIVE_COUNT, PROFILE_ALIASES, PROFILES, SKILLS, TOTAL_COUNT, WORKFLOW_COUNT, canonicalProfile, isDeprecatedProfile, resolveProfile } from '../src/catalog.js';
 import { addSkill, globalManifestPath, initGlobal, initProject, inspectGlobal, inspectProject, removeGlobal, removeProject } from '../src/project.js';
 import { validateRepository } from '../src/validate.js';
 
@@ -69,7 +69,7 @@ async function main() {
 
   if (command === 'validate') {
     const result = await validateRepository(packageRoot);
-    if (result.ok) console.log(`Showdar validation OK (${SKILLS.length} skills).`);
+    if (result.ok) console.log(`Showdar validation OK (${PRIMITIVE_COUNT} primitives, ${WORKFLOW_COUNT} workflows, ${TOTAL_COUNT} total).`);
     else {
       console.log(`Showdar validation FAILED (${result.errors.length} errors).`);
       for (const error of result.errors) console.log(`- ${error}`);

package/commands/opencode/showdar/skill.md

@@ -1,6 +1,6 @@
 ---
 description: Invoke a specific Showdar flagship skill explicitly
 ---
-Select exactly one requested Showdar skill and follow it: `showdar-understand`, `showdar-plan`, `showdar-design`, `showdar-build`, `showdar-debug`, `showdar-test`, `showdar-review`, `showdar-upgrade`, `showdar-ship`, `showdar-recover`, `showdar-git`, `showdar-requirements`, `showdar-quality`, `showdar-security`, or `showdar-ops`. If the requested name is ambiguous, choose the smallest matching skill from this list and say which one was selected.
+Select exactly one requested Showdar skill and follow it: `showdar-understand`, `showdar-plan`, `showdar-design`, `showdar-build`, `showdar-debug`, `showdar-test`, `showdar-review`, `showdar-upgrade`, `showdar-ship`, `showdar-recover`, `showdar-git`, `showdar-requirements`, `showdar-quality`, `showdar-security`, `showdar-ops`, `showdar-feature`, `showdar-bugfix`, `showdar-release`, or `showdar-incident`. Whole-task intent (complete feature, end-to-end fix, release lifecycle, active incident) selects a workflow; single primitive intent stays primitive. If the requested name is ambiguous, choose the smallest matching skill from this list and say which one was selected.
 
 Request: $ARGUMENTS

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "showdar-skills",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Production-grade software engineering lifecycle skills for coding agents.",
   "type": "module",
   "bin": { "showdar": "./bin/showdar.js" },

package/skills/showdar-bugfix/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: showdar-bugfix
+description: Use when resolving an observed defect end-to-end, adaptively sequencing understand, debug, build, test, and review stages based on whether root cause is already proven.
+---
+
+# Showdar Bugfix
+
+## Purpose
+
+- Resolve an observed defect safely from evidence to verified fix.
+- Include diagnosis only when the root cause is actually unknown.
+- Skip implementation when the user asked only for investigation.
+- Hand work to one primitive at a time; load the next only when needed.
+
+## When to use
+
+- The user asks to resolve a defect end-to-end.
+- A failure is observed: crash, regression, wrong behavior, build failure, performance fault.
+- Examples: "fix the login crash", "resolve the checkout regression".
+
+## When not to use
+
+- Single primitive intent stays primitive: "why does this crash" is `showdar-debug` unless the user asks to fix it end-to-end.
+- Investigation-only requests stay at `showdar-debug`; do not force `showdar-build`.
+- Interrupted or broken work-state recovery is `showdar-recover`, not this workflow; use recover only for work-state semantics, not ordinary bugs.
+- Once this workflow is active, do not spawn another parent workflow unless the request contains a genuinely separate workflow task.
+- This workflow never recursively invokes itself.
+
+## Inputs and assumptions
+
+- Observed failure and reproduction path, when available.
+- Current repository conventions and change surface are discoverable.
+- Authority comes from the existing Phase 6G engine; this workflow consumes authority results and never mints authority.
+- Candidate stages: `showdar-understand`, `showdar-debug`, `showdar-build`, `showdar-test`, `showdar-review`.
+
+## Non-negotiable rules
+
+- Symptom description alone is not mutation authority.
+- Do not treat a symptom as permission to edit; require root-cause evidence or explicit fix authorization.
+- Investigation-only requests do not proceed to `showdar-build`.
+- End-to-end fixes always include verification; never skip it to move faster.
+- Stop when required evidence is missing instead of guessing.
+
+## Workflow
+
+### Phase 1 — determine needed stages
+
+- Root cause unknown: `showdar-understand`, then `showdar-debug`, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Root cause already proven: `showdar-understand`, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Investigation only: `showdar-debug` alone, then report findings without mutation.
+
+### Phase 2 — execute progressively
+
+- Load one primitive at a time; hand off only when its stop condition is met.
+- Each primitive's own SKILL.md governs its stage; do not copy primitive instructions here.
+- Track ephemeral state only: candidate stages, selected stages, active stage, completed evidence, next stage or complete.
+- No persistent checkpoint or resume infrastructure in this version.
+
+## Decision points
+
+- Is the root cause proven with evidence? If yes, `showdar-debug` may be skipped.
+- Did the user ask only for diagnosis? If yes, stop after `showdar-debug`.
+- Is the failure actually interrupted work-state? If yes, hand off to `showdar-recover` instead.
+- Auth, secrets, or exposure involved? Add `showdar-security` as an orthogonal specialist.
+
+## Stack detection
+
+- Defer to each selected primitive's own stack detection.
+
+## Failure modes
+
+- Editing from symptom description without root-cause evidence.
+- Forcing implementation when only diagnosis was requested.
+- Confusing ordinary bugs with work-state recovery.
+- Loading all primitives eagerly instead of progressively.
+
+## Stop conditions
+
+- Stop when the request is actually a single primitive task and hand off to that primitive.
+- Stop before destructive, irreversible, production, credential, publishing, or deployment actions unless explicitly authorized.
+- Stop when required evidence is missing.
+- Stop when the fix is verified and reviewed.
+
+## Escalation conditions
+
+- Ask for reproduction steps when the failure cannot be reproduced.
+- Ask for explicit fix authority when evidence is thin.
+- Escalate suspected security exposure with evidence, without exploit amplification.
+
+## Verification
+
+- Reproduce before and after where practical.
+- End-to-end fixes include `showdar-test` evidence and `showdar-review` findings addressed.
+- State what was executed and what remains unverified.
+
+## Output contract
+
+- Root-cause evidence and selected stages.
+- Fix location and behavior change.
+- Verification gaps or residual risk.
+
+## Anti-patterns
+
+- Symptom-to-patch without diagnosis.
+- Mandatory debug stage even when the cause is proven.
+- Mandatory build stage for investigation-only requests.
+- Copying primitive SKILL.md content into this file.
+
+## Example
+
+**Checkout total regressed after discount change**
+
+- Evidence: failure observed, root cause unknown.
+- Selected: `showdar-understand`, then `showdar-debug` (isolated to discount ordering), then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Investigation-only variant would stop after `showdar-debug` with findings and no mutation.

package/skills/showdar-feature/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: showdar-feature
+description: Use when implementing a complete feature end-to-end, adaptively sequencing understand, requirements, plan, design, build, test, and review stages based on existing definition.
+---
+
+# Showdar Feature
+
+## Purpose
+
+- Implement a complete feature end-to-end by sequencing primitive skills.
+- Select only the stages the current evidence actually requires.
+- Skip defined, trivial, or decision-free stages instead of running a fixed pipeline.
+- Hand work to one primitive at a time; load the next primitive only when needed.
+
+## When to use
+
+- The user asks to implement a complete feature or change spanning multiple lifecycle stages.
+- Whole-task intent exists: discovery plus definition plus implementation plus verification.
+- Examples: "add user search", "implement checkout flow", "build the export feature".
+
+## When not to use
+
+- Single primitive intent stays primitive: "review this diff" stays `showdar-review`, "run tests" stays `showdar-test`, "why does this crash" stays `showdar-debug` unless the user asks to fix it end-to-end.
+- A request that is only diagnosis, only planning, or only review is not this workflow.
+- Once this workflow is active, do not spawn another parent workflow unless the request contains a genuinely separate workflow task.
+- This workflow never recursively invokes itself.
+
+## Inputs and assumptions
+
+- User outcome in their own words.
+- Current repository conventions and change surface are discoverable.
+- Authority comes from the existing Phase 6G engine; this workflow consumes authority results and never mints authority.
+- Candidate stages: `showdar-understand`, `showdar-requirements`, `showdar-plan`, `showdar-design`, `showdar-build`, `showdar-test`, `showdar-review`.
+
+## Non-negotiable rules
+
+- This workflow does not grant extra authority. Deployment requires explicit authority.
+- Ops is NOT implied by feature work.
+- Never skip verification merely to move faster.
+- Security may load as an orthogonal primitive (`showdar-security`) when the change touches auth, secrets, trust boundaries, or exposure.
+- Stop when required evidence is missing instead of guessing.
+
+## Workflow
+
+### Phase 1 — determine needed stages
+
+- Start with `showdar-understand` when the repository, architecture, or impact is unfamiliar.
+- Skip requirements if behavior is already sufficiently defined.
+- Skip plan for genuinely focused or local work.
+- Skip design when no meaningful architecture, UX, or interface decision exists.
+- Small well-defined change: understand, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Undefined feature: understand, then `showdar-requirements`, then `showdar-plan`, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Architecture or UI-sensitive feature: understand, then `showdar-requirements`, then `showdar-plan`, then `showdar-design`, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+
+### Phase 2 — execute progressively
+
+- Load one primitive at a time; hand off only when its stop condition is met.
+- Each primitive's own SKILL.md governs its stage; do not copy primitive instructions here.
+- Track ephemeral state only: candidate stages, selected stages, active stage, completed evidence, next stage or complete.
+- No persistent checkpoint or resume infrastructure in this version.
+
+## Decision points
+
+- Behavior defined already? Skip `showdar-requirements`.
+- Change surface local and low-risk? Skip `showdar-plan`.
+- No architecture, UX, or interface trade-off? Skip `showdar-design`.
+- Auth, secrets, or exposure touched? Add `showdar-security` as an orthogonal specialist.
+- Deployment requested? Require explicit authority; this workflow alone never authorizes it.
+
+## Stack detection
+
+- Defer to each selected primitive's own stack detection.
+
+## Failure modes
+
+- Running every stage as a mandatory checklist.
+- Duplicating primitive instructions inside this workflow.
+- Treating feature intent as deployment authority.
+- Loading all primitives eagerly instead of progressively.
+
+## Stop conditions
+
+- Stop when the request is actually a single primitive task and hand off to that primitive.
+- Stop before destructive, irreversible, production, credential, publishing, or deployment actions unless explicitly authorized.
+- Stop when required evidence is missing.
+- Stop when the selected stages are complete and verified.
+
+## Escalation conditions
+
+- Ask for missing behavior definition when requirements cannot be skipped honestly.
+- Ask for explicit authority when deployment or production mutation appears.
+- Escalate suspected security exposure with evidence, without exploit amplification.
+
+## Verification
+
+- Every implementation stage ends with `showdar-test` evidence and `showdar-review` findings addressed.
+- State what was executed and what remains unverified.
+
+## Output contract
+
+- Selected stages with one-line justification for each skipped stage.
+- Completed evidence per stage.
+- Verification gaps or residual risk.
+
+## Anti-patterns
+
+- Fixed pipeline regardless of evidence.
+- Second authority engine or second intent resolver.
+- Custom autonomous agent behavior.
+- Copying primitive SKILL.md content into this file.
+
+## Example
+
+**Add workspace member search**
+
+- Evidence: behavior already defined in the ticket, local API plus UI change, no architecture trade-off.
+- Selected: `showdar-understand`, then `showdar-build`, then `showdar-test`, then `showdar-review`.
+- Skipped: requirements (defined), plan (local), design (no UX decision).
+- Verification: new search tests pass; review findings addressed.

package/skills/showdar-incident/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: showdar-incident
+description: Use when investigating and recovering from an active operational incident, adaptively sequencing understand, debug, recover, verification, and ops stages with strict mutation authority.
+---
+
+# Showdar Incident
+
+## Purpose
+
+- Handle an active operational failure or service-impacting incident.
+- Diagnose before mutating when the cause is unknown.
+- Recover work-state or service state through the right primitive.
+- Keep production mutation strictly authority-gated regardless of severity.
+
+## When to use
+
+- The user asks to investigate or recover from an active operational incident.
+- Service impact exists: outage, degraded service, failed deploy, data-risk event.
+- Examples: "production API is down", "recover the failed deploy", "checkout is erroring in prod".
+
+## When not to use
+
+- Single primitive intent stays primitive: a narrow debug question without recovery intent is `showdar-debug`.
+- Ordinary non-urgent bugs without operational impact belong to `showdar-bugfix`.
+- Once this workflow is active, do not spawn another parent workflow unless the request contains a genuinely separate workflow task.
+- This workflow never recursively invokes itself.
+
+## Inputs and assumptions
+
+- Incident symptoms, impact scope, and environment, when known.
+- Current repository conventions and change surface are discoverable.
+- Authority comes from the existing Phase 6G engine; this workflow consumes authority results and never mints authority.
+- Candidate stages: `showdar-understand`, `showdar-debug`, `showdar-recover`, `showdar-test`, `showdar-ops`.
+
+## Non-negotiable rules
+
+- Diagnosis before speculative mutation when the cause is unknown.
+- Emergency context does not erase authority boundaries.
+- Production mutation is never inferred from severity alone.
+- This workflow does NOT authorize production mutation by identity.
+- `showdar-ops` loads only when explicit environment plus action authority permits it.
+- This workflow never auto-deploys or restarts production from risk alone.
+- A security incident may load `showdar-security` as an orthogonal specialist.
+- Stop when required evidence or authority is missing instead of guessing.
+
+## Workflow
+
+### Phase 1 — determine needed stages
+
+- Typical path: `showdar-understand`, then `showdar-debug`, then `showdar-recover`, then verification.
+- Unknown cause: investigate first; no speculative mutation.
+- Interrupted or broken work-state: use `showdar-recover` for work-state semantics.
+- Verification uses `showdar-test` evidence or the relevant primitive's own verification.
+- Add `showdar-ops` only with explicit environment plus action authority.
+
+### Phase 2 — execute progressively
+
+- Load one primitive at a time; hand off only when its stop condition is met.
+- Each primitive's own SKILL.md governs its stage; do not copy primitive instructions here.
+- Track ephemeral state only: candidate stages, selected stages, active stage, completed evidence, next stage or complete.
+- No persistent checkpoint or resume infrastructure in this version.
+
+## Decision points
+
+- Is the cause known? If not, diagnose before any mutation.
+- Is this work-state recovery or service recovery? Choose `showdar-recover` versus `showdar-ops` accordingly, gated by authority.
+- Is explicit ops authority present? Without environment plus action permission, no ops step.
+- Is this a security incident? If yes, add `showdar-security` as an orthogonal specialist.
+
+## Stack detection
+
+- Defer to each selected primitive's own stack detection.
+
+## Failure modes
+
+- Mutating production from severity or urgency alone.
+- Auto-deploying or restarting from risk signals.
+- Skipping diagnosis to "move fast" during an incident.
+- Loading all primitives eagerly instead of progressively.
+
+## Stop conditions
+
+- Stop when the request is actually a single primitive task and hand off to that primitive.
+- Stop before production mutation, deployment, restart, or rollback without explicit authority.
+- Stop when required evidence is missing.
+- Stop when recovery is verified or the incident is handed off with evidence.
+
+## Escalation conditions
+
+- Ask for environment plus action authority before any ops step.
+- Ask for missing impact scope or logs when diagnosis is blocked.
+- Escalate suspected security exposure with evidence, without exploit amplification.
+
+## Verification
+
+- Verify recovery with fresh evidence, not assumptions.
+- State what was executed and what remains unverified.
+
+## Output contract
+
+- Diagnosis evidence and selected stages.
+- Recovery actions taken, each with its authority basis.
+- Verification gaps or residual risk.
+
+## Anti-patterns
+
+- Severity granting mutation authority.
+- Risk signals triggering auto-remediation.
+- Second authority engine or second intent resolver.
+- Copying primitive SKILL.md content into this file.
+
+## Example
+
+**Production checkout erroring after deploy**
+
+- Evidence: active incident, cause unknown, no ops authority stated.
+- Selected: `showdar-understand`, then `showdar-debug`, then `showdar-recover` for work-state triage, then verification.
+- Skipped: `showdar-ops` (no explicit environment plus action authority).
+- Output: diagnosis evidence, recovery state, and the exact authority needed for any production action.

package/skills/showdar-release/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: showdar-release
+description: Use when preparing, validating, or executing a release lifecycle, adaptively sequencing quality, security, ship, and ops stages with strict authority boundaries.
+---
+
+# Showdar Release
+
+## Purpose
+
+- Prepare and execute a software release through existing primitive boundaries.
+- Distinguish release readiness from release execution and deployment.
+- Default to safe verification; execute only with explicit authority.
+- Hand work to one primitive at a time; load the next only when needed.
+
+## When to use
+
+- The user asks to prepare, validate, or execute a release lifecycle.
+- Examples: "check if this is ready to release", "prepare v1.4.0", "release v1.4.0 to npm now" (execution only when authority permits).
+- Lifecycle-level requests spanning quality plus readiness plus possible execution.
+
+## When not to use
+
+- Single primitive intent stays primitive: a narrow "check this diff" is `showdar-review`, a test plan is `showdar-quality`, readiness alone may be `showdar-ship`.
+- "Check if this is ready to release" must NOT imply deployment.
+- Once this workflow is active, do not spawn another parent workflow unless the request contains a genuinely separate workflow task.
+- This workflow never recursively invokes itself.
+
+## Inputs and assumptions
+
+- Release scope, version, and target, when known.
+- Current repository conventions and change surface are discoverable.
+- Authority comes from the existing Phase 6G engine; this workflow consumes authority results and never mints authority.
+- Candidate stages: `showdar-quality`, `showdar-security`, `showdar-ship`, `showdar-ops`.
+
+## Non-negotiable rules
+
+- This workflow does NOT authorize deployment by identity. `showdar-release` never means deployment is automatically authorized.
+- `showdar-ship` remains delivery verification and release readiness, not execution.
+- `showdar-ops` loads only when an explicit target plus execution authorization exist.
+- The release noun alone never produces an ops step.
+- Security loads conditionally when the release touches auth, secrets, trust boundaries, exposure, or dependencies with risk.
+- Stop when required evidence or authority is missing instead of proceeding.
+
+## Workflow
+
+### Phase 1 — determine needed stages
+
+- Default safe path: `showdar-quality`, then conditional `showdar-security`, then `showdar-ship`.
+- Add `showdar-ops` only when explicit target plus execution authorization exist.
+- Readiness request ("check if ready"): quality, then security when applicable, then ship. No ops.
+- Execution request ("release v1.4.0 to npm now"): same readiness path first, then ops only when existing authority semantics authorize it.
+
+### Phase 2 — execute progressively
+
+- Load one primitive at a time; hand off only when its stop condition is met.
+- Each primitive's own SKILL.md governs its stage; do not copy primitive instructions here.
+- Track ephemeral state only: candidate stages, selected stages, active stage, completed evidence, next stage or complete.
+- No persistent checkpoint or resume infrastructure in this version.
+
+## Decision points
+
+- Is this readiness or execution? Readiness stops at `showdar-ship`.
+- Does execution have an explicit target plus authorization? Without both, no `showdar-ops`.
+- Does the release warrant security review? If yes, add `showdar-security`.
+- Do Git, ship, or ops safety boundaries block? Respect them; do not bypass.
+
+## Stack detection
+
+- Defer to each selected primitive's own stack detection.
+
+## Failure modes
+
+- Treating readiness as deployment permission.
+- Loading `showdar-ops` from the release noun alone.
+- Bypassing Git, ship, or ops safety boundaries.
+- Running security unconditionally or skipping it when risk exists.
+
+## Stop conditions
+
+- Stop when the request is actually a single primitive task and hand off to that primitive.
+- Stop before execution or deployment without explicit authority.
+- Stop when required evidence is missing.
+- Stop when readiness is verified (readiness path) or execution is verified (authorized execution path).
+
+## Escalation conditions
+
+- Ask for the explicit release target and execution authorization before any ops step.
+- Ask for missing release scope or version when it blocks verification.
+- Escalate suspected security exposure with evidence, without exploit amplification.
+
+## Verification
+
+- Readiness: `showdar-quality` scenarios plus `showdar-ship` checks with evidence.
+- Execution: authorized ops outcome plus fresh verification that the release landed.
+- State what was executed and what remains unverified.
+
+## Output contract
+
+- Readiness verdict or execution outcome.
+- Selected stages with justification for skipped or conditional stages.
+- Verification gaps or residual risk.
+
+## Anti-patterns
+
+- Readiness implying deployment.
+- Workflow identity granting mutation authority.
+- Fixed pipeline regardless of risk and authority.
+- Copying primitive SKILL.md content into this file.
+
+## Example
+
+**Check if v1.4.0 is ready to release**
+
+- Evidence: lifecycle-level readiness request, no execution authorization.
+- Selected: `showdar-quality`, then `showdar-security` (auth changes present), then `showdar-ship`.
+- Skipped: `showdar-ops` (no execution authority).
+- Output: readiness verdict with gaps; no deployment performed.

package/src/catalog.js

@@ -1,21 +1,38 @@
 export const SKILLS = [
-  { id: 'showdar-understand', domain: 'understand', description: 'Use when mapping an unfamiliar repository, architecture, dependencies, or impact before deciding what to change.' },
-  { id: 'showdar-plan', domain: 'plan', description: 'Use when agreed behavior needs a bounded implementation plan, change surface, task order, risks, or verification steps.' },
-  { id: 'showdar-design', domain: 'design', description: 'Use when product UI needs design direction, UX decisions, responsive layout, accessibility, or visual polish.' },
-  { id: 'showdar-build', domain: 'build', description: 'Use when implementing or refactoring an agreed application change within existing architecture and contracts.' },
-  { id: 'showdar-debug', domain: 'debug', description: 'Use when observed behavior fails through crashes, regressions, build failures, races, networking, memory, or performance issues.' },
-  { id: 'showdar-test', domain: 'test', description: 'Use when choosing or implementing automated tests for behavior, regressions, integration, E2E, or coverage.' },
-  { id: 'showdar-review', domain: 'review', description: 'Use when reviewing code or diffs for general correctness, architecture, performance, maintainability, or tests.' },
-  { id: 'showdar-upgrade', domain: 'upgrade', description: 'Use when upgrading dependencies, frameworks, runtimes, or native platforms and compatibility or rollback risk matters.' },
-  { id: 'showdar-ship', domain: 'ship', description: 'Use when checking whether a change, artifact, or release is ready for handoff or external release.' },
-  { id: 'showdar-recover', domain: 'recover', description: 'Use when interrupted or partial engineering work must be reconstructed from repository evidence before continuing.' },
-  { id: 'showdar-git', domain: 'git', description: 'Use when performing local Git inspection, staging, commits, branch integration, conflicts, cleanup, or explicitly requested remote Git actions.' },
-  { id: 'showdar-requirements', domain: 'requirements', description: 'Use when product or business input needs explicit behavior, rules, acceptance criteria, assumptions, or open decisions.' },
-  { id: 'showdar-quality', domain: 'quality', description: 'Use when planning QA/QC scenarios, risk coverage, regression scope, compatibility checks, or bug-report evidence.' },
-  { id: 'showdar-security', domain: 'security', description: 'Use when assessing threat models, attack surfaces, trust boundaries, auth/authz, secrets, exposure, or exploitability.' },
-  { id: 'showdar-ops', domain: 'ops', description: 'Use when inspecting or changing CI/CD, containers, environments, deployment, observability, rollback, or runtime operations.' },
+  { id: 'showdar-understand', kind: 'primitive', domain: 'understand', description: 'Use when mapping an unfamiliar repository, architecture, dependencies, or impact before deciding what to change.' },
+  { id: 'showdar-plan', kind: 'primitive', domain: 'plan', description: 'Use when agreed behavior needs a bounded implementation plan, change surface, task order, risks, or verification steps.' },
+  { id: 'showdar-design', kind: 'primitive', domain: 'design', description: 'Use when product UI needs design direction, UX decisions, responsive layout, accessibility, or visual polish.' },
+  { id: 'showdar-build', kind: 'primitive', domain: 'build', description: 'Use when implementing or refactoring an agreed application change within existing architecture and contracts.' },
+  { id: 'showdar-debug', kind: 'primitive', domain: 'debug', description: 'Use when observed behavior fails through crashes, regressions, build failures, races, networking, memory, or performance issues.' },
+  { id: 'showdar-test', kind: 'primitive', domain: 'test', description: 'Use when choosing or implementing automated tests for behavior, regressions, integration, E2E, or coverage.' },
+  { id: 'showdar-review', kind: 'primitive', domain: 'review', description: 'Use when reviewing code or diffs for general correctness, architecture, performance, maintainability, or tests.' },
+  { id: 'showdar-upgrade', kind: 'primitive', domain: 'upgrade', description: 'Use when upgrading dependencies, frameworks, runtimes, or native platforms and compatibility or rollback risk matters.' },
+  { id: 'showdar-ship', kind: 'primitive', domain: 'ship', description: 'Use when checking whether a change, artifact, or release is ready for handoff or external release.' },
+  { id: 'showdar-recover', kind: 'primitive', domain: 'recover', description: 'Use when interrupted or partial engineering work must be reconstructed from repository evidence before continuing.' },
+  { id: 'showdar-git', kind: 'primitive', domain: 'git', description: 'Use when performing local Git inspection, staging, commits, branch integration, conflicts, cleanup, or explicitly requested remote Git actions.' },
+  { id: 'showdar-requirements', kind: 'primitive', domain: 'requirements', description: 'Use when product or business input needs explicit behavior, rules, acceptance criteria, assumptions, or open decisions.' },
+  { id: 'showdar-quality', kind: 'primitive', domain: 'quality', description: 'Use when planning QA/QC scenarios, risk coverage, regression scope, compatibility checks, or bug-report evidence.' },
+  { id: 'showdar-security', kind: 'primitive', domain: 'security', description: 'Use when assessing threat models, attack surfaces, trust boundaries, auth/authz, secrets, exposure, or exploitability.' },
+  { id: 'showdar-ops', kind: 'primitive', domain: 'ops', description: 'Use when inspecting or changing CI/CD, containers, environments, deployment, observability, rollback, or runtime operations.' },
 ];
 
+export const WORKFLOW_SKILLS = [
+  { id: 'showdar-feature', kind: 'workflow', domain: 'feature', stages: ['showdar-understand', 'showdar-requirements', 'showdar-plan', 'showdar-design', 'showdar-build', 'showdar-test', 'showdar-review'], description: 'Use when implementing a complete feature end-to-end, adaptively sequencing understand, requirements, plan, design, build, test, and review stages based on existing definition.' },
+  { id: 'showdar-bugfix', kind: 'workflow', domain: 'bugfix', stages: ['showdar-understand', 'showdar-debug', 'showdar-build', 'showdar-test', 'showdar-review'], description: 'Use when resolving an observed defect end-to-end, adaptively sequencing understand, debug, build, test, and review stages based on whether root cause is already proven.' },
+  { id: 'showdar-release', kind: 'workflow', domain: 'release', stages: ['showdar-quality', 'showdar-security', 'showdar-ship', 'showdar-ops'], description: 'Use when preparing, validating, or executing a release lifecycle, adaptively sequencing quality, security, ship, and ops stages with strict authority boundaries.' },
+  { id: 'showdar-incident', kind: 'workflow', domain: 'incident', stages: ['showdar-understand', 'showdar-debug', 'showdar-recover', 'showdar-test', 'showdar-ops'], description: 'Use when investigating and recovering from an active operational incident, adaptively sequencing understand, debug, recover, verification, and ops stages with strict mutation authority.' },
+];
+
+export const PRIMITIVE_SKILLS = SKILLS;
+
+export const ALL_SKILLS = [...SKILLS, ...WORKFLOW_SKILLS];
+
+export const PRIMITIVE_COUNT = SKILLS.length;
+
+export const WORKFLOW_COUNT = WORKFLOW_SKILLS.length;
+
+export const TOTAL_COUNT = ALL_SKILLS.length;
+
 export const AI_TARGETS = ['codex', 'opencode', 'cursor', 'claude', 'universal', 'all'];
 
 const ids = (...values) => values;
@@ -53,16 +70,28 @@ export function resolveProfile(profile) {
 }
 
 export function getSkill(id) {
+  return ALL_SKILLS.find((skill) => skill.id === id) ?? null;
+}
+
+export function getPrimitive(id) {
   return SKILLS.find((skill) => skill.id === id) ?? null;
 }
 
+export function getWorkflow(id) {
+  return WORKFLOW_SKILLS.find((skill) => skill.id === id) ?? null;
+}
+
+export function isWorkflowSkill(id) {
+  return WORKFLOW_SKILLS.some((skill) => skill.id === id);
+}
+
 export function normalizeSkillName(name) {
   if (typeof name !== 'string' || !name.trim()) throw new Error('Skill name is required.');
   const trimmed = name.trim();
   const canonical = trimmed.startsWith('showdar-') ? trimmed : `showdar-${trimmed}`;
   const skill = getSkill(canonical);
   if (!skill) {
-    const known = SKILLS.map((s) => s.id.replace(/^showdar-/, '')).join(', ');
+    const known = ALL_SKILLS.map((s) => s.id.replace(/^showdar-/, '')).join(', ');
     throw new Error(`Unknown skill "${name}". Available skills: ${known}`);
   }
   return skill.id;

package/src/project.js

@@ -71,6 +71,10 @@ function managedBlock(skillIds) {
     ['plan QA scenarios, risk coverage, regression, compatibility, or bug evidence', 'showdar-quality'],
     ['assess threats, attack surface, trust boundaries, auth, secrets, exposure, or exploitability', 'showdar-security'],
     ['inspect or change CI/CD, containers, environments, deployment, observability, rollback, or runtime operations', 'showdar-ops'],
+    ['implement a complete feature end-to-end across multiple lifecycle stages', 'showdar-feature'],
+    ['resolve an observed defect end-to-end', 'showdar-bugfix'],
+    ['prepare, validate, or execute a release lifecycle', 'showdar-release'],
+    ['investigate or recover from an active operational incident', 'showdar-incident'],
   ].filter(([, id]) => skillIds.includes(id));
   const lines = routes.map(([intent, skill]) => `- ${intent} -> \`${skill}\``).join('\n');
   return `${START}\n## Showdar Skills routing\n\nUse the smallest Showdar skill that fully matches the current task. Do not load unrelated Showdar skills.\n\n${lines}\n\nFor debugging, gather evidence before modifying code. For shipping or destructive operations, require explicit user approval and fresh verification. Never print or commit secrets.\n${END}`;

package/src/validate.js

@@ -1,7 +1,7 @@
 import { access, readFile, readdir } from 'node:fs/promises';
 import path from 'node:path';
 import { spawnSync } from 'node:child_process';
-import { SKILLS, PROFILES } from './catalog.js';
+import { ALL_SKILLS, PRIMITIVE_COUNT, SKILLS, PROFILES, TOTAL_COUNT, WORKFLOW_COUNT, WORKFLOW_SKILLS } from './catalog.js';
 import { validateCapabilities } from './capabilities.js';
 import { CANONICAL_RUNTIME_FILE, VENDORED_RUNTIME_FILES } from './runtime.js';
 import { parseCsv } from '../engine/csv.mjs';
@@ -224,18 +224,36 @@ async function validateCsvFiles(skillDir, errors) {
 export async function validateRepository(packageRoot) {
   const errors = [];
   const warnings = [];
-  const known = new Set(SKILLS.map((skill) => skill.id));
+  const known = new Set(ALL_SKILLS.map((skill) => skill.id));
+  const primitives = new Set(SKILLS.map((skill) => skill.id));
   const skillsRoot = path.join(packageRoot, 'skills');
 
+  if (SKILLS.length !== PRIMITIVE_COUNT || PRIMITIVE_COUNT !== 15) errors.push(`primitive skill count must remain 15 (found ${SKILLS.length})`);
+  if (WORKFLOW_SKILLS.length !== WORKFLOW_COUNT || WORKFLOW_COUNT !== 4) errors.push(`workflow skill count must be 4 (found ${WORKFLOW_SKILLS.length})`);
+  if (ALL_SKILLS.length !== TOTAL_COUNT || TOTAL_COUNT !== 19) errors.push(`total installable skill count must be 19 (found ${ALL_SKILLS.length})`);
+
   for (const error of validateCapabilities().errors) errors.push(`capabilities: ${error}`);
 
-  for (const skill of SKILLS) {
+  for (const skill of ALL_SKILLS) {
     const dir = path.join(skillsRoot, skill.id);
     const result = await validateSkillDirectory(dir);
     for (const error of result.errors) errors.push(`${skill.id}: ${error}`);
     warnings.push(...result.warnings.map((warning) => `${skill.id}: ${warning}`));
   }
 
+  const primitiveIds = new Set(SKILLS.map((skill) => skill.id));
+  for (const workflow of WORKFLOW_SKILLS) {
+    if (!Array.isArray(workflow.stages) || !workflow.stages.length) {
+      errors.push(`${workflow.id}: workflow declares no candidate stages`);
+      continue;
+    }
+    for (const stage of workflow.stages) {
+      if (!primitiveIds.has(stage)) errors.push(`${workflow.id}: references unknown primitive stage ${stage}`);
+      if (stage === workflow.id) errors.push(`${workflow.id}: must not reference itself as a stage`);
+    }
+    if (new Set(workflow.stages).size !== workflow.stages.length) errors.push(`${workflow.id}: candidate stages contain duplicates`);
+  }
+
   let canonicalRuntime;
   try {
     canonicalRuntime = await readFile(path.join(packageRoot, CANONICAL_RUNTIME_FILE));
@@ -263,6 +281,7 @@ export async function validateRepository(packageRoot) {
     const seen = new Set();
     for (const id of ids) {
       if (!known.has(id)) errors.push(`profile ${profile} references unknown skill ${id}`);
+      if (!primitives.has(id)) errors.push(`profile ${profile} must reference only primitive skills (found ${id})`);
       if (seen.has(id)) errors.push(`profile ${profile} duplicates skill ${id}`);
       seen.add(id);
     }