Run any Skill in Manus with one click

spec-driven-change

Stars1

Forks0

UpdatedJune 30, 2026 at 23:43

Use when: starting a roadmap/initiative feature, new milestone work, a transport/codec/backend that adds behavior, or any change big enough to need a design. Author or update a spec under docs/specs first; code cites the spec by section.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

ianshank

ianshank/GCP-Drone-Comms-Unit

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	spec-driven-change
description	Use when: starting a roadmap/initiative feature, new milestone work, a transport/codec/backend that adds behavior, or any change big enough to need a design. Author or update a spec under docs/specs first; code cites the spec by section.
argument-hint	The feature/initiative, the milestone or plan track, and the seams it touches

Spec-Driven Change

When to Use

Beginning any ROADMAP milestone or initiative item, or a feature in docs/IMPLEMENTATION_PLAN.md.
Adding behavior that future agents must understand (new wire shape, safety path, service, backend, or non-trivial config surface).
Before — not after — writing the implementation.

Procedure

Read ../../../docs/CHARTER.md (scope + invariants), ../../../docs/ROADMAP.md (milestone), ../../../docs/IMPLEMENTATION_PLAN.md (track), and the nearest scoped AGENTS.md.
Copy ../../../docs/specs/TEMPLATE.md to docs/specs/<slug>.md. Fill every section — do not skip the config-field table (§5, no magic numbers), the wire/schema posture (§6), the test plan by category (§7), or the CHARTER §4 invariant checklist (§9).
Register the spec in ../../../docs/specs/README.md with status Definition.
Implement behind the seams (registry / Protocol / config); cite the spec's § numbers in docstrings (the FPV modules and meshsa.command already do this).
When the gates are green and coverage meets the spec floor, update CHANGELOG.md + NEXTSTEPS.md and move the spec status to Implemented (Validated after the spec's hardware/bench exit criteria pass).

Anti-patterns

Implementing first and back-filling a spec to match — the spec is the design, not a summary.
"No magic numbers" skipped: every operational value is a config field with an explicit default; fixed protocol constants are named module constants, not config.
Silently changing CHARTER/ROADMAP. If the work needs a scope change, stop and surface it (CHARTER §6) rather than editing the stable docs in passing.

References

docs/specs/README.md, docs/specs/TEMPLATE.md
docs/specs/PHASE1_SPEC_v1_1.md (worked example; code cites §5.1 etc.)
docs/IMPLEMENTATION_PLAN.md (the queued specs to author)
docs/CHARTER.md §4 (the invariant checklist every spec answers)

More from this repository

same repository

jetson-perception

ianshank/GCP-Drone-Comms-Unit

Use when: working in packages/jetson_yolo_gcs — adding a detector backend (YOLO/Hailo/ONNX/TensorRT), a tracker backend (Norfair/SORT), GStreamer camera/egress pipeline, the MAVLink LANDING_TARGET bridge, precision-landing safety, or the perception pipeline failure policy.

2026-07-161

pre-pr-validator

ianshank/GCP-Drone-Comms-Unit

Use when: running pre-PR checks, performing regression testing, validating ruff linting/formatting, verifying mypy type safety, and checking test coverage before pushing.

2026-07-161

meshsa-inference

ianshank/GCP-Drone-Comms-Unit

Use when: working on the optional NVIDIA Nemotron inference bridge — meshsa.inference, NemotronClient/InferenceService/NemotronConfig, MESHSA_INFERENCE_* env vars, aiohttp session reuse, [AI Insight] feedback-loop filter, or the aioresponses test mocks.

2026-07-081

meshsa-observability

ianshank/GCP-Drone-Comms-Unit

Use when: adding or changing metrics/health export — RouterMetrics, render_prometheus, per-transport counters, the /metrics or /healthz route, HealthConfig fields, or a Grafana golden-signal dashboard.

2026-07-081

meshsa-commanding-safety

ianshank/GCP-Drone-Comms-Unit

Use when: touching the supervised two-way command path (Initiative C) — meshsa.command.*, flightctl/run_commander.py, arm/disarm/RTL/set_mode, COMMAND_INT/ACK, force-disarm, operator confirmation, command audit log, or arm preconditions.

2026-06-301

meshsa-add-codec

ianshank/GCP-Drone-Comms-Unit

Use when: adding a meshsa codec, changing JSON/Compact/CoT encoding, wire format, codec registry, Envelope serialization, per-transport codec bridge, or decode compatibility.

2026-06-201

name	spec-driven-change
description	Use when: starting a roadmap/initiative feature, new milestone work, a transport/codec/backend that adds behavior, or any change big enough to need a design. Author or update a spec under docs/specs first; code cites the spec by section.
argument-hint	The feature/initiative, the milestone or plan track, and the seams it touches

Spec-Driven Change

When to Use

Beginning any ROADMAP milestone or initiative item, or a feature in docs/IMPLEMENTATION_PLAN.md.
Adding behavior that future agents must understand (new wire shape, safety path, service, backend, or non-trivial config surface).
Before — not after — writing the implementation.

Procedure

Read ../../../docs/CHARTER.md (scope + invariants), ../../../docs/ROADMAP.md (milestone), ../../../docs/IMPLEMENTATION_PLAN.md (track), and the nearest scoped AGENTS.md.
Copy ../../../docs/specs/TEMPLATE.md to docs/specs/<slug>.md. Fill every section — do not skip the config-field table (§5, no magic numbers), the wire/schema posture (§6), the test plan by category (§7), or the CHARTER §4 invariant checklist (§9).
Register the spec in ../../../docs/specs/README.md with status Definition.
Implement behind the seams (registry / Protocol / config); cite the spec's § numbers in docstrings (the FPV modules and meshsa.command already do this).
When the gates are green and coverage meets the spec floor, update CHANGELOG.md + NEXTSTEPS.md and move the spec status to Implemented (Validated after the spec's hardware/bench exit criteria pass).

Anti-patterns

Implementing first and back-filling a spec to match — the spec is the design, not a summary.
"No magic numbers" skipped: every operational value is a config field with an explicit default; fixed protocol constants are named module constants, not config.
Silently changing CHARTER/ROADMAP. If the work needs a scope change, stop and surface it (CHARTER §6) rather than editing the stable docs in passing.

References

docs/specs/README.md, docs/specs/TEMPLATE.md
docs/specs/PHASE1_SPEC_v1_1.md (worked example; code cites §5.1 etc.)
docs/IMPLEMENTATION_PLAN.md (the queued specs to author)
docs/CHARTER.md §4 (the invariant checklist every spec answers)