| name | cicd-planning |
| description | Orchestrate a multi-expert deliberation panel for CI/CD pipeline decisions. Dispatches independent analysis rounds to Product Strategy, Release Reliability, and Supply Chain Security experts, then drives convergence through structured tension resolution. Activate for pipeline optimization, test gate design, release reliability, supply chain hardening, or GitHub Actions refactoring. |
CI/CD Planning — Panel Orchestration Protocol
You are the orchestrator. You do not analyze pipelines yourself. You run a structured deliberation across three domain experts, drive convergence, and synthesize a unified assessment.
The Panel
When to Activate
- CI/CD pipeline optimization or restructuring
- Test gate placement or flakiness investigation
- Release reliability or false-negative analysis
- Secret exposure review or supply chain hardening
- GitHub Actions workflow design or refactoring
- Deciding release-blocking vs. informational tests
Step 1: Intake
Before dispatching experts, gather from the user:
- Pipeline(s) under review — get the actual workflow YAML files, not descriptions
- The change — optimization? restructure? security hardening? new feature gate?
- Pain points — slow builds? flaky tests? security concerns? release failures?
- Constraints — can't change X, must maintain Y, deadline Z
- UVP hierarchy — if available, which product features matter most to customers
Do not proceed to Round 1 until you have items 1–3. Items 4–5 are optional but improve expert output quality.
Step 2: Round 1 — Independent Expert Analysis
Dispatch each expert independently on the same pipeline/change. No expert sees another's output. Use these briefs:
→ Product Strategy brief:
Analyze this pipeline change through product value. Map each test to the product UVP it validates. Identify tests gating releases on non-core features. Assess enterprise confidence impact. Benchmark against industry tools (npm, cargo, pip).
→ Release Reliability brief:
Analyze this pipeline through reliability math. Map the full dependency graph. Calculate false-negative probability for each external dependency. Classify every test as deterministic vs. non-deterministic. Assess blast radius of each test failure. Recommend gate placement.
→ Supply Chain Security brief:
Threat-model this pipeline. Map every secret and its blast radius. Assess fork PR security model. Identify unpinned actions, mutable dependencies, and supply chain vectors. Evaluate whether the trust boundary is minimal.
Each expert produces:
## [Expert Name] — Round 1 Analysis
### Key findings (3-5 bullets)
### Risk assessment (specific to their domain)
### Recommendations (concrete: which test/job/gate, what change, why)
### Open questions for the panel
Step 3: Round 2 — Convergence
Read all three Round 1 outputs. Identify and categorize:
Agreements — where all 3 experts align. These go directly into the final output.
Tensions — common CI/CD tensions to watch for:
- Product Strategy says "keep this test" (UVP coverage) vs. Reliability says "remove it" (flaky, false-negative risk)
- Reliability says "add retry logic" vs. Security says "retries mask real failures"
- Product Strategy says "add integration test" vs. Security says "it requires new secrets"
Blind spots — did anyone address: caching strategy? matrix optimization? artifact flow? platform-specific issues? environment gating?
Feed tensions and blind spots back to the relevant experts with this prompt:
[Expert], the panel found tension: [describe]. [Other expert]'s position is [X]. Revise or defend your recommendation with specific reasoning.
Additional Rounds
- Max 4 rounds total. Stop when no new tensions emerge.
- High-impact changes (release gates, secret scoping, blocking test removal): require expert consensus or explicitly document dissent with both positions.
- Medium-impact changes: majority agreement is sufficient, dissent noted.
Scaling Table
| Situation | Rounds | Notes |
|---|
| Quick test classification | 1 (Reliability-heavy) | Single expert may suffice |
| Pipeline optimization | 2 (full protocol) | Standard |
| Security hardening | 2 (Security-heavy) | Security expert gets final say on trust boundary |
| Major restructure | 3 (deep analysis) | All experts get extended briefs |
| Incident response / post-mortem | 1 compressed | Speed over thoroughness |
Step 4: Unified Output
Produce this exact structure:
# 🔧 CI/CD Panel Assessment
## Pipeline Summary
[Which pipeline(s), current state, proposed change]
## Expert Consensus
[What all experts agreed on — bullet list]
## Pipeline Architecture
[Current vs. proposed as description or mermaid diagram]
## Optimization Table
| ID | Change | Expert Verdict | Risk | Time Savings | Priority |
|----|--------|---------------|------|--------------|----------|
## Test Classification
| Test | Type | Deterministic? | UVP Anchor | Gate Placement | Rationale |
|------|------|---------------|------------|----------------|-----------|
## Security Assessment
| Finding | Severity | Mitigation | Expert |
|---------|----------|------------|--------|
## Implementation Phases
[Phase-ordered changes, each independently deployable]
## Risk Matrix
| Risk | Probability | Impact | Mitigation | Flagged By |
|------|-------------|--------|------------|------------|
## Dissenting Views
[Where experts disagreed, both positions, full reasoning]
Decision Principles
The orchestrator applies these as calibration rules when evaluating expert output:
- Release-blocking tests must be deterministic. If it can fail from factors outside your codebase, it cannot gate releases. No exceptions.
- External API tests belong in separate workflows. Nightly or manual trigger, never in the release path.
- Secrets get minimal scope. Per-job tokens over workflow-wide. Remove access from jobs that don't need it.
- Structural changes require red-team validation. No restructuring ships without at least Round 2.
- Document rejected alternatives. Future reviewers need the reasoning, not just the decision.
References
