Menu
Covers pipeline orchestration for feature development including stages, handoffs, and artifact management. Use when coordinating work through the discovery to deployment pipeline.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | pipeline-conductor |
| description | Covers pipeline orchestration for feature development including stages, handoffs, and artifact management. Use when coordinating work through the discovery to deployment pipeline. |
This skill covers pipeline orchestration for feature development.
Use these commands to orchestrate the pipeline:
| Command | Description |
|---|---|
/pipeline start <name> | Start a new feature pipeline |
/pipeline status <id> | Check current stage and blockers |
/pipeline next <id> | Advance to next stage |
/pipeline list | Show all active pipelines |
/discover <description> | Quick-start feature discovery |
/review [feature-id] | Invoke code review |
/deploy <id> | Trigger deployment workflow |
See commands/ directory for detailed command documentation.
request → discovery → spec → pricing → design → ui-patterns →
implementation → test → review → deploy → document → announce
Some stages can run in parallel:
discovery
├── spec ──────────┐
└── pricing ───────┼── design
│
implementation: │
├── api-dev ───────┤ (parallel)
├── frontend-dev ──┤
└── sre ───────────┘
│
post-deploy: │
├── document ──────┤ (parallel)
└── announce ──────┘
| Input Type | Starting Stage |
|---|---|
| Feature idea | discovery |
| Clear requirements | spec |
| Bug fix | implementation |
| Doc update | document |
| Hotfix | implementation → deploy |
Approval required after:
Approve with: /pipeline approve <id> <gate>
All artifacts live in .claude/pipeline/:
.claude/pipeline/
├── requests/ # Feature requests
├── briefs/ # Discovery briefs
├── specs/ # Specifications
├── pricing/ # Pricing briefs
├── designs/ # Architecture designs
├── ui-patterns/ # UI specifications
├── triage/ # Support triage docs
└── comms/ # GTM content
Pattern: {id}-{name}.md
Example: feat-001-vm-snapshots.md
Each agent reads upstream artifacts and writes downstream:
| Agent | Reads | Writes |
|---|---|---|
| product-discovery | requests/ | briefs/ |
| product-planner | briefs/ | specs/ |
| commercial-strategist | briefs/, specs/ | pricing/ |
| architect | specs/, pricing/ | designs/ |
| api-dev | designs/ | code |
| code-reviewer | designs/, code | findings |
All pipeline artifacts MUST include structured handoff headers. See handoff-format.md for the complete schema.
Key fields:
context_summary: What this artifact representsdecisions_made: Key decisions with rationaleopen_questions: Unresolved items (blocking vs non-blocking)assumptions: What was assumed, with confidence levelsplatform_capabilities: Quota, insights, telemetry, activity decisionsSee templates/ for stage-specific templates with handoff headers:
templates/discovery-brief.md - Discovery phase outputtemplates/spec.md - Specification documenttemplates/pricing-brief.md - Commercial strategy outputtemplates/design.md - Architecture design documentRequired sections:
Required sections:
Required sections:
Covers GitHub conventions for pull requests, issues, and comments including linking, language style, formatting, and callout syntax. Use when creating PRs, writing issues, or posting comments on Datum Cloud repositories.
Turn raw engineering notes, PR/issue links, commit messages, or a one-line feature description into a changelog entry for Datum Cloud's GitHub Discussions Changelog category: a benefit-led title plus a markdown body, drafted for users and ready to hand off for final capture and publish. Use when someone says "write a changelog entry", "announce this in the changelog", or "post this to the changelog discussions" — this is the community-facing changelog POST, not the Keep a Changelog release file (that lives in `gtm-templates`).
Provides templates for go-to-market communications including blog posts, changelogs, social media, and enablement briefs. Use when writing launch announcements or marketing content.
Create a new GitHub release. Verifies CI is green on the release commit and refreshes the third-party NOTICE file before tagging, determines the next version from the latest tag, summarizes merged PRs since the last release, drafts release notes in the established style, and publishes via gh release create. Works for any datum-cloud service repository.
Scan a project repository for strict AGPL-3.0 license compliance across Go, Rust, and JavaScript/React codebases. Use this skill whenever the user asks to check, audit, verify, or enforce AGPL license compliance on a project, repo, or codebase. Triggers on phrases like "check agpl compliance", "audit license headers", "is this project agpl compliant", "scan for license headers", "check my license files", "agpl audit", or any request involving ensuring a project is properly licensed under AGPL. Always use this skill — don't wing AGPL compliance checks from general knowledge.
Covers producing weekly operational reports for the Datum AI Edge. Use when asked for an ops review, traffic report, latency analysis, provisioning report, or edge performance summary. Guides metric queries, anomaly detection, and publishing to datum-cloud/engineering.