Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

spec-driven-change

Sterne1

Forks0

Aktualisiert30. Juni 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

ianshank

ianshank/GCP-Drone-Comms-Unit

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·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)

Mehr aus diesem Repository

gleiches 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)