Help us improve
Share bugs, ideas, or general feedback.
From deployment-pipeline
Applies agentic design patterns to CD orchestration and state-machine deployment workflows, enhancing prompt chaining, planning, exception handling, HITL gates, and guardrails.
npx claudepluginhub markus41/claude --plugin deployment-pipelineHow this skill is triggered — by the user, by Claude, or both
Slash command
/deployment-pipeline:agentic-patternsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> Patterns from "Agentic Design Patterns" (Gulli & Sauco, 2025) applied to CD orchestration and state-machine deployment workflows
Designs multi-stage CI/CD pipelines with source/build/test/staging/approval/production stages, manual/time-based/multi-approver gates, and strategies like rolling, canary, blue-green. Includes GitHub Actions, GitLab CI, Azure Pipelines examples.
Outlines CI/CD pipelines with local quality gates, GitHub Actions patterns, branch strategies, and progressive deployments like canary/blue-green. For designing deployment workflows.
Orchestrates multi-stage deployment pipelines with Kubernetes, CI/CD platforms, and strategies like blue-green, canary, rolling updates across dev/staging/prod.
Share bugs, ideas, or general feedback.
Patterns from "Agentic Design Patterns" (Gulli & Sauco, 2025) applied to CD orchestration and state-machine deployment workflows
Relevance: Deployment pipelines are inherently sequential — each stage must succeed before the next begins, making prompt chaining the foundational pattern.
Current Implementation: The start command triggers a linear pipeline of validate → build → deploy → verify stages, each passing state to the next.
Enhancement: Model each stage transition as a structured chain link with explicit input/output schemas. The output of the validate stage (manifest, checksums, env config) becomes the structured prompt input to the build stage, ensuring context is never lost across stage boundaries.
Relevance: Before initiating a deployment, the orchestrator must devise a strategy that accounts for environment, risk level, rollout type (canary, blue-green, rolling), and SLA windows.
Current Implementation: The orchestrator.md agent selects deployment strategies, but strategy selection is implicit.
Enhancement: Add an explicit planning phase that emits a deployment plan artifact (target envs, rollout %, health check thresholds, estimated duration, rollback triggers) before any execution begins. The plan is approved (by HITL or auto) before the pipeline proceeds.
Relevance: Deployment failures are not exceptional — they are expected scenarios that require structured recovery, not ad-hoc responses.
Current Implementation: The rollback.md agent and rollback command handle failure recovery; the validator.md agent detects issues.
Enhancement: Wrap each pipeline stage in a try/catch pattern with typed exception classes: ValidationError, BuildError, HealthCheckFailure, TimeoutError. Each exception type maps to a predefined recovery action (retry, rollback, notify, halt). The rollback agent receives the exception type as input context.
Relevance: Production deployments and rollbacks to critical environments require human authorization gates before proceeding.
Current Implementation: The approve command provides a manual approval mechanism at the pipeline level.
Enhancement: Formalize HITL as a blocking gate with configurable placement: pre-deploy approval, post-canary validation approval, and rollback confirmation. Each gate presents a structured summary (diff, risk score, affected services, estimated impact) and records the approver identity and timestamp in the deployment history.
Relevance: Deployments must enforce hard constraints — never deploy to production without passing health checks, never exceed a change-failure-rate threshold, never skip required approval stages.
Current Implementation: The validator.md agent checks pre-conditions; the pipeline has validation stages.
Enhancement: Extract guardrails into a declarative constraint layer evaluated before and after every stage. Guardrails include: artifact integrity checks, environment drift detection, concurrent deployment prevention (mutex lock), SLA window enforcement, and rollback-eligibility verification. Constraint violations immediately halt the pipeline with a structured error report.
Relevance: A deployment is successful only when it meets defined SLA targets — latency, error rate, availability — not simply when the deployment command exits 0.
Current Implementation: The pipeline tracks deploy status but success/failure is binary (command success vs. failure).
Enhancement: Define deployment goals as measurable SLA criteria attached to the pipeline plan. After deploy, the orchestrator evaluates whether goals are met (p99 latency < X ms, error rate < Y%, all health checks green for Z minutes). Only when goals are satisfied does the pipeline transition to COMPLETE; otherwise it triggers exception handling.
Relevance: Each deployment run is a data point. Evaluating outcomes over time improves future deployment decisions and detects degrading patterns.
Current Implementation: The history command surfaces past deployments, but evaluation is manual.
Enhancement: After each pipeline completion, emit a structured evaluation report: goal achievement (met/missed/partial), stage durations, rollback count, MTTR for failures, and change-failure rate trend. Store these in the deployment history for trend analysis and use them as context in the planning phase of subsequent deployments.
Relevance: Complex deployment workflows exceed the capability of a single agent — orchestration, validation, and rollback are distinct responsibilities requiring specialized agents.
Current Implementation: Three specialized agents exist — orchestrator.md, validator.md, rollback.md — with defined roles.
Enhancement: Formalize the multi-agent topology with explicit communication contracts: the orchestrator is the sole coordinator; validator and rollback agents are workers that receive structured task requests and return structured results. Add a monitoring agent that runs concurrently during deployment, watching health signals and alerting the orchestrator if guardrail thresholds are approached before they are breached.
User Request
│
▼
[Planning] ──────────────────────────────────────────────────────┐
Emit deployment plan (strategy, goals, guardrails config) │
│ │
▼ │
[HITL Gate] ← human approves plan │
│ │
▼ │
[Prompt Chaining] — stage-by-stage execution │
├── Stage N input = Stage N-1 structured output │
├── [Guardrails] checked at every stage boundary │
└── [Multi-Agent] Orchestrator ↔ Validator ↔ Monitor agents │
│ (concurrent monitoring during execution) │
▼ │
[Exception Handling] │
├── Typed exceptions → recovery map │
└── Rollback agent activated with exception context │
│ │
▼ │
[Goal Setting] — evaluate post-deploy SLA metrics │
│ │
▼ │
[Evaluation] — emit structured deployment report ←──────────────┘
Feeds back into Planning context for next deployment