Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

spec-driven-change

Étoiles1

Forks0

Mis à jour30 juin 2026 à 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

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.

Exécuter dans Manus

Source

ianshank

ianshank/GCP-Drone-Comms-Unit

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·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)

Plus depuis ce dépôt

même dépôt

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)