nw-devops
The nw-devops skill designs infrastructure readiness for features by translating architecture decisions into operational specifications: CI/CD pipelines, environment matrices, monitoring contracts, deployment strategies, observability stacks, and branching models. Use this skill after DESIGN completes to ensure platform infrastructure prerequisites are met before acceptance testing and code implementation proceed.
git clone --depth 1 https://github.com/nWave-ai/nWave /tmp/nw-devops && cp -r /tmp/nw-devops/nWave/skills/nw-devops ~/.claude/skills/nw-devopsSKILL.md
# NW-DEVOPS: Platform Readiness and Infrastructure Design **Wave**: DEVOPS (wave 4 of 6) | **Agent**: Apex (nw-platform-architect) | **Command**: `/nw-devops` ## Overview Execute DEVOPS wave: platform readiness|CI/CD pipeline setup|observability design|infrastructure preparation. Positioned between DESIGN and DISTILL (DISCOVER > DISCUSS > SPIKE > DESIGN > DEVOPS > DISTILL > DELIVER), ensures infrastructure is ready before acceptance tests and code. Apex translates DESIGN architecture decisions into operational infrastructure: CI/CD pipelines|logging|monitoring|alerting|observability. ## Output Tiers (per D2) Provenance: feature `lean-wave-documentation` — D2 (schema-typed sections), D10 (one-line expansion descriptions). Tier-1 [REF] sections (always emitted) + Tier-2 EXPANSION CATALOG items (lazy, on-demand) are the two output bands. Full contract: `nWave/skills/nw-density-resolution-contract/SKILL.md`. ### Tier-1 [REF] — always emitted Under `## Wave: DEVOPS / [REF] <Section>` headings: - Environment matrix — table of target environments with platform + preconditions - CI/CD pipeline outline — stage list with trigger rules per branch - Monitoring contracts — KPI-to-instrument mapping (one row per outcome KPI) - Deployment strategy — chosen strategy + rollback contract (one paragraph) - Mutation testing strategy — selected mode (per-feature/nightly-delta/pre-release/disabled) - Observability stack — chosen tools per signal class (logs/metrics/traces) - Branching strategy — selected model + CI trigger alignment - Coexistence matrix — tools that must continue to work alongside deployment - Pre-requisites — DESIGN constraints the platform must satisfy ### Tier-2 EXPANSION CATALOG — lazy, on-demand (per D10) Rendered under `## Wave: DEVOPS / [WHY|HOW] <Section>` only when requested via `--expand <id>` (DDD-2), the wave-end menu (`expansion_prompt = "ask"`), `mode = "full"` auto-expansion, or an ad-hoc user request mid-session. | Expansion ID | Tier label | One-line description | |---|---|---| | `infra-cost-analysis` | [WHY] | Per-environment monthly cost estimate with vendor pricing assumptions | | `alternative-deploy-targets` | [WHY] | Cloud/on-prem/hybrid options weighed and rejected with one-paragraph reason | | `observability-deep-dive` | [HOW] | Detailed metric/log/trace schemas, alert thresholds, dashboard layouts | | `runbook-drafts` | [HOW] | Incident response runbooks for the top failure modes | | `kpi-instrumentation-recipes` | [HOW] | Per-KPI data collection recipe (event names, log fields, metric labels) | | `ci-pipeline-yaml` | [HOW] | Full CI/CD pipeline YAML with comments per stage | | `disaster-recovery-plan` | [HOW] | Backup, restore, and DR procedures with RPO/RTO targets | | `expansion-catalog-rationale` | [WHY] | Why this set of expansions, why these defaults, why D10 enforces one-line descriptions | ## Density resolution (per D12) Call `resolve_density(global_config)` from `scripts/shared/density_config.py` after reading `~/.nwave/global-config.json` (missing/malformed = empty dict). Returns `mode` (`"lean"` | `"full"`) + `expansion_prompt` (`"ask"` | `"always-skip"` | `"always-expand"` | `"smart"`) per the D12 cascade (resolver-internal, DDD-5 — do NOT replicate locally). Branch on `density.mode` for what to emit; branch on `density.expansion_prompt` at wave end for menu behaviour. Full cascade detail, branch semantics, ad-hoc override workflow: `nWave/skills/nw-density-resolution-contract/SKILL.md`. ## Telemetry (per D4 + DDD-6) Every expansion choice emits a `DocumentationDensityEvent` (dataclass at `src/des/domain/telemetry/documentation_density_event.py`) via `event.to_audit_event()` → `JsonlAuditLogWriter().log_event(...)`. Schema fields per D4: `feature_id`, `wave`, `expansion_id`, `choice`, `timestamp`. For this wave the schema declares `"wave": "DEVOPS"`. Use helper `scripts/shared/telemetry.py:write_density_event(...)` — do NOT write JSONL directly. Wave-specific signal: DISTILL consuming a lean DEVOPS environment matrix — downstream `--expand` requests for runbook drafts or alternative deploy targets indicate the `[REF]` baseline was insufficient. Full emission rules: `nWave/skills/nw-density-resolution-contract/SKILL.md`. ## Interactive Decision Points Before proceeding, the orchestrator asks: ### Decision 1: Deployment Target **Question**: What is the deployment target? **Options**: 1. Cloud-native -- AWS, GCP, Azure managed services 2. On-premise -- self-hosted infrastructure 3. Hybrid -- mix of cloud and on-premise 4. Edge -- distributed edge deployment 5. Other -- user provides custom input ### Decision 2: Container Orchestration **Question**: Container orchestration approach? **Options**: 1. Kubernetes -- full orchestration 2. Docker Compose -- lightweight container management 3. Serverless -- function-as-a-service, no containers 4. None -- bare metal or VM-based deployment ### Decision 3: CI/CD Platform **Question**: CI/CD platform preference? **Options**: 1. GitHub Actions 2. GitLab CI 3. Jenkins 4. Azure DevOps 5. Other -- user provides custom input ### Decision 4: Existing Infrastructure **Question**: Is there existing infrastructure or CI/CD to integrate with? **Options**: 1. Yes, both -- describe existing infrastructure and CI/CD (user provides details) 2. Existing infra only -- infrastructure exists, CI/CD is greenfield 3. Existing CI/CD only -- CI/CD exists, infrastructure is greenfield 4. No -- greenfield, design everything from scratch ### Decision 5: Observability and Logging **Question**: What observability and logging approach? **Options**: 1. Prometheus + Grafana (metrics) with structured JSON logs 2. Datadog (full-stack observability including logs) 3. ELK stack (Elasticsearch, Logstash, Kibana for logs and metrics) 4. OpenTelemetry (vendor-agnostic telemetry) with provider of choice 5. CloudWatch (AWS-native metrics and logging) 6. Custom -- user provides details 7. None -- defer observability setup ### Decision
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Review dimensions for validating agent quality - template compliance, safety, testing, and priority validation
Review dimensions for acceptance test quality - happy path bias, GWT compliance, business language purity, coverage completeness, walking skeleton user-centricity, priority validation, observable behavior assertions, traceability coverage, and walking skeleton boundary proof
Detailed 5-phase workflow for creating agents - from requirements analysis through validation and iterative refinement
5-layer testing approach for agent validation including adversarial testing, security validation, and prompt injection resistance
Architectural style selection decision matrices, trade-off analysis, structural enforcement rules, and combination patterns. Load when choosing or evaluating architecture styles.
Comprehensive architecture patterns, methodologies, quality frameworks, and evaluation methods for solution architects. Load when designing system architecture or selecting patterns.
Canonical AT completeness gate — research-anchored 7-category taxonomy (C1-C7) + 15-item mechanical checklist. Paradigm-neutral. Drives acceptance-designer reviewer verdict deterministically.