superpipelines

Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.

Resolves agent `model_tier:` declarations into concrete platform-specific model strings and effort values via a 5-layer precedence chain, returning a serializable `resolved` object for dispatch. Use when `running-a-pipeline` Phase 0.45 needs to determine the concrete model + effort for each pipeline step on the active platform before dispatch.

Resolves the active runtime tier and provides the canonical DISPATCH contract for all pipeline step execution. Use when an orchestrator skill needs to dispatch pipeline steps — performs tier detection, loads the platform profile, and executes the Tier 2 inline loop when no subagent primitive is available.

Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.

Run, resume, or list installed Superpipelines workflows from the registry.

Provides canonical engineering standards for authoring agents, skills, hooks, and pipeline orchestration in Claude Code. Use when authoring or modifying agents, skills, hooks, or pipeline-orchestration artifacts — covers model-tier selection, prompt-cache discipline, frontmatter schemas, and progressive-disclosure rules.

Maps pipeline agent roles to intent-based model categories on Tier 1 (Claude Code). Use when a Tier 1 pipeline stage requires model assignment beyond the two-slot fast/deep abstraction — e.g., pure read-only audit agents, deep architectural planners, or visual-analysis roles. Non-CC tiers resolve models via platform_profile.model_tiers only; this skill must not be invoked on tier_1b/1c/1d/2.

Enforces root-cause investigation before any fix is proposed or implemented. Use when encountering a bug, test failure, or unexpected behavior, before proposing or implementing a fix.

Design and scaffold a new named Superpipelines workflow after scope, brief, topology, audit, and human approval gates.

Remove a step from an existing named Superpipelines workflow while preserving topology continuity.

Loaded by the pipeline-architect agent to design or mutate Superpipelines pipeline topology and data-only CAD artifacts.

Defines the six canonical pipeline topologies (Sequential, Parallel Fan-Out, Iterative Loop, Human-Gated, Spec-Driven, 4D Wrapper) and their capability requirements. Use when an orchestrator is selecting an execution pattern for a new pipeline, matching a task's information flow to a topology, or checking Q7 capability gates before pattern traversal.

Add a new step, capability, or agent to an existing named Superpipelines workflow.

Reassign Superpipelines model-tier preferences across user, workspace, and pipeline scopes.

Migrate a legacy old-root Superpipelines workflow into the data-only pipeline layout.

Optimize an existing named Superpipelines workflow for topology, model tiers, cost, latency, and reliability.

Loaded by the pipeline-auditor agent to audit Superpipelines pipeline bundles against compliance, CAD, topology, and bundle hygiene rules.

Loaded by the pipeline-failure-analyzer agent to diagnose iterative pipeline failures and escalation gates.

Loaded by the pipeline-optimizer agent to inspect an existing workflow and recommend optimization opportunities.

Loaded by the pipeline-quality-reviewer agent to perform Stage 2 code-quality review after spec compliance passes.

Loaded by the pipeline-spec-reviewer agent to perform Stage 1 spec-compliance review.

Loaded by the pipeline-task-executor agent to execute one assigned implementation task under the pipeline contract.

Loaded by pipeline creation and optimization workflows to harden briefs, confirm architecture, or reconcile optimization choices.

Resolves scope-aware absolute file paths for Superpipelines artifacts across local, project, and user scopes. Use when creating or accessing agents, skills, support files, temporary directories, or the pipeline registry, given a known scope and pipeline name.

Loaded by the skill-architect agent to design or revise Superpipelines-compatible skills.

Modify an existing step in a named Superpipelines workflow while preserving contracts and topology continuity.

Route Superpipelines requests to the right command workflow, reusable method skill, or direct codebase answer.

Defines the schema, storage layout, and recovery protocols for `pipeline-state.json`. Use when reading or writing pipeline state, resuming an interrupted run, or diagnosing a crashed orchestrator.

Enforces a mandatory 4-step safety protocol (Ignore, Setup, Baseline, Commit) for creating, managing, and destroying git worktrees in pipeline isolation contexts. Use when a pipeline step declares `isolation: worktree`, when parallel pattern tasks require branch isolation, or when the iterative or spec-driven patterns require atomic rollback capability.

Use when the user wants to run the parity-test-f pipeline on Tier 1d (Codex CLI) to analyze a pull request diff for code issues and produce a validated review report.

Loaded by the reporter agent to supply operating protocol and invariants for code review report generation in the parity-test-f pipeline. Not user-invocable.

Loaded by the reviewer agent to supply operating protocol and invariants for findings validation in the parity-test-f pipeline. Not user-invocable.

Brainstorming refines vague or exploratory requests into a validated design document through structured clarifying dialogue and trade-off analysis before any implementation begins. Use when a user's request is under-specified, involves new feature or component design, describes new pipeline behavior, or lacks an existing spec — including when loaded by creating-a-pipeline Phase 0 for exploratory briefs.

Structured integration protocol that enforces a test-verification gate and presents branch disposition options (merge, PR, keep, or discard). Use when implementation is complete, all tests pass, and an integration decision for the development branch is pending.

Provides a per-invocation four-phase processing wrapper (Deconstruct, Diagnose, Develop, Deliver) for structured request resolution. Use when an agent faces an ambiguous request, missing required slots, or feedback that requires re-entry into a specific processing phase.

Enforces hash-anchored line verification to prevent stale-line edits during file mutations. Use when any agent performs file mutations in a worktree — mandates that read lines carry content-identifier hashes and that those hashes are verified before an edit is committed.

Generates and maintains localized PIPELINE-CONTEXT.md files distributed across the project tree, producing token-efficient context maps that summarize directory purposes and architectural boundaries. Use when the `/superpipelines:init-deep` command runs, when the PREFLIGHT phase of a new pipeline creation requires context initialization, or when significant refactoring invalidates existing context maps.

Converts pre-v2.0 agent frontmatter (`model:` without `model_tier:`) to v2.0 schema with a git-backed safety checkpoint. Use when `running-a-pipeline` Phase 0.4 detects agents that have a concrete `model:` field, no `model_tier:` field, and either no `plugin_version` stamp or `plugin_version` < 2.0.0.

Defines HARD-GATE and EXTREMELY-IMPORTANT tag conventions, Red Flags lists, and Rationalization Tables for discipline-enforcing skills and protocol skills. Use when authoring a skill or agent protocol that must hold under time pressure, sunk cost, or "obvious answer" rationalization bias.

Establishes a formal spec→plan→tasks→implement contract for multi-step feature work. Use when authoring multi-step pipelines, building new features, refactoring systems, or when a request is too ambiguous for direct execution and a verified specification must precede implementation.