maintenance-orchestration

Estrelas9

Forks3

Atualizado15 de março de 2026 às 18:11

Use when a LawnBerry Pi task spans re-entry, specialist routing, implementation, documentation sync, and validation. Covers choosing the right specialist workflow and sequencing investigation, changes, doc updates, and test planning.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Fonte

acredsfan

acredsfan/lawnberry_pi

Abrir repositório GitHub Ver repositórios do creator

Download

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	maintenance-orchestration
description	Use when a LawnBerry Pi task spans re-entry, specialist routing, implementation, documentation sync, and validation. Covers choosing the right specialist workflow and sequencing investigation, changes, doc updates, and test planning.
argument-hint	What multi-step maintenance task should be orchestrated?
user-invocable	true

Maintenance Orchestration

What this skill does

This skill coordinates substantial LawnBerry Pi work so the agent starts with project re-entry, picks the right specialist path, and closes the loop with docs sync and validation.

When to use

the task touches more than one subsystem
you are unsure which specialist agent or skill should lead
the request mixes code, docs, runtime behavior, and validation
a change risks leaving maintainer docs or regression coverage behind

Procedure

Start with docs/developer-toolkit.md and apply the maintainer-reentry skill.
Classify the request:
- runtime/docs drift
- deployment or service operations
- frontend state or API/WebSocket flow
- hardware-sensitive safety path
- general backend/frontend implementation
- code-structure doc sync
- validation planning only
Route to the best specialist workflow first:
- drift audit -> runtime-contract-audit
- hardware-sensitive validation split -> sim-hardware-validation
- navigation hardening -> navigation-hardening-pass
- mission durability -> mission-recovery-pass
- control/camera regressions -> control-camera-regression-review
- AI quality work -> ai-model-quality-pass
- maintainer doc alignment -> maintainer-doc-sync
If implementation is needed, make the smallest safe change after the focused investigation.
Sync docs in the same pass when runtime behavior, hardware scope, subsystem maturity, or callable interfaces changed.
Finish with targeted validation or a minimal validation plan.

Decision rules

prefer specialist depth over broad guessing
prefer simulation-safe validation first unless the task explicitly requires hardware
if the task touches motors, blade, RoboHAT, camera, or watchdog paths, insert safety review before trusting the change
if callable interfaces changed, update docs/code_structure_overview.md

Completion checks

the leading specialist path was chosen deliberately
docs sync obligations were identified before finishing
validation was either executed or explicitly planned
final summary states what changed, what was checked, and what remains risky

Mais deste repositório

mesmo repositório

sim-hardware-validation

acredsfan/lawnberry_pi

Use for LawnBerry Pi simulation vs real-hardware validation. Covers SIM_MODE selection, .env and config checks, simulation-safe test-first workflow, hardware preflight expectations, and avoiding false claims that local success proves on-device behavior.

2026-06-259

ai-model-quality-pass

acredsfan/lawnberry_pi

Use for improving LawnBerry Pi AI result quality without breaking the existing backend contract. Covers ai_service review, model artifact or rule improvement, conservative evaluation, performance notes, and avoiding premature accelerator-specific churn.

2026-03-159

control-camera-regression-review

acredsfan/lawnberry_pi

Review regression-sensitive LawnBerry Pi manual control and camera paths: RoboHAT USB handoff, watchdog feeding, motor authorization, joystick responsiveness, MJPEG and snapshot fallback, camera ownership, and stream backpressure handling.

2026-03-159

maintainer-doc-sync

acredsfan/lawnberry_pi

Keep LawnBerry Pi maintainer documentation synchronized with implementation. Use when runtime behavior, supported hardware scope, subsystem maturity, immediate focus, two-week plan, release notes, or callable interfaces have changed and docs must be updated in the same pass.

2026-03-159

maintainer-reentry

acredsfan/lawnberry_pi

Use when returning to LawnBerry Pi after time away, starting substantial maintenance, or needing a fast project re-entry workflow. Covers docs to read first, runtime ports, hardware baseline, simulation vs hardware mode, important files by task, and validation planning.

2026-03-159

mission-recovery-pass

acredsfan/lawnberry_pi

Use for LawnBerry Pi mission persistence and recovery work. Covers what mission state should survive restart, safe restart semantics, paused vs running recovery behavior, lifecycle validation, and persistence-backed tests.

2026-03-159

name	maintenance-orchestration
description	Use when a LawnBerry Pi task spans re-entry, specialist routing, implementation, documentation sync, and validation. Covers choosing the right specialist workflow and sequencing investigation, changes, doc updates, and test planning.
argument-hint	What multi-step maintenance task should be orchestrated?
user-invocable	true

Maintenance Orchestration

What this skill does

This skill coordinates substantial LawnBerry Pi work so the agent starts with project re-entry, picks the right specialist path, and closes the loop with docs sync and validation.

When to use

the task touches more than one subsystem
you are unsure which specialist agent or skill should lead
the request mixes code, docs, runtime behavior, and validation
a change risks leaving maintainer docs or regression coverage behind

Procedure

Start with docs/developer-toolkit.md and apply the maintainer-reentry skill.
Classify the request:
- runtime/docs drift
- deployment or service operations
- frontend state or API/WebSocket flow
- hardware-sensitive safety path
- general backend/frontend implementation
- code-structure doc sync
- validation planning only
Route to the best specialist workflow first:
- drift audit -> runtime-contract-audit
- hardware-sensitive validation split -> sim-hardware-validation
- navigation hardening -> navigation-hardening-pass
- mission durability -> mission-recovery-pass
- control/camera regressions -> control-camera-regression-review
- AI quality work -> ai-model-quality-pass
- maintainer doc alignment -> maintainer-doc-sync
If implementation is needed, make the smallest safe change after the focused investigation.
Sync docs in the same pass when runtime behavior, hardware scope, subsystem maturity, or callable interfaces changed.
Finish with targeted validation or a minimal validation plan.

Decision rules

prefer specialist depth over broad guessing
prefer simulation-safe validation first unless the task explicitly requires hardware
if the task touches motors, blade, RoboHAT, camera, or watchdog paths, insert safety review before trusting the change
if callable interfaces changed, update docs/code_structure_overview.md

Completion checks

the leading specialist path was chosen deliberately
docs sync obligations were identified before finishing
validation was either executed or explicitly planned
final summary states what changed, what was checked, and what remains risky