maintainer-reentry

星标9

分支3

更新时间2026年3月15日 18:11

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.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

acredsfan

acredsfan/lawnberry_pi

打开 GitHub 仓库查看创作者相关仓库

下载

Maintainer Re-entry

What this skill does

This skill turns docs/developer-toolkit.md into a repeatable re-entry checklist so the agent regains project context before making changes.

When to use

starting substantial maintenance after a gap
planning work on runtime behavior, hardware scope, safety, navigation, mission, or AI
triaging a bug when you are not yet sure which subsystem owns it
checking current ports, source-of-truth docs, or supported hardware before implementation

Procedure

Read these sources first, in this order unless the user narrows scope:
- README.md
- docs/OPERATIONS.md
- docs/TESTING.md
- docs/hardware-integration.md
- spec/hardware.yaml
- docs/code_structure_overview.md
- docs/RELEASE_NOTES.md
- docs/hallucination-audit.md
- CONTRIBUTING.md
- .github/copilot-instructions.md
Lock in the current runtime contract before assuming old defaults:
- backend API: 8081
- frontend dev/deployed UI: 3000
- Playwright preview: 4173
Decide whether the task is simulation-safe or hardware-sensitive.
- prefer SIM_MODE=1 for local development, CI, and first-pass validation
- treat SIM_MODE=0 as real-hardware mode with Pi/device expectations
Map the task to the most relevant subsystem and files.
- startup/runtime wiring: backend/src/main.py, backend/src/core/config_loader.py, config/, docs/OPERATIONS.md
- safety/manual control: backend/src/safety/, backend/src/services/robohat_service.py, backend/src/services/blade_service.py
- telemetry/GPS/RTK: backend/src/services/sensor_manager.py, telemetry services, RTK scripts, NTRIP docs
- manual control/operator UI: frontend/src/views/ControlView.vue, frontend/src/stores/control.ts, API and WebSocket services
- maps/planning/mission: frontend/src/views/MapsView.vue, PlanningView.vue, MissionPlannerView.vue, mission/navigation services
Build a short execution checklist before editing.
Prefer the smallest change that restores shared reality rather than speculative feature sprawl.

Decision points

If docs and code disagree, trust code, config, service units, and spec/hardware.yaml over prose.
If hardware is not explicitly required, stay simulation-safe first.
If runtime behavior, subsystem maturity, or supported hardware changed, update docs/developer-toolkit.md in the same pass.
If callable interfaces changed in backend/src/**, frontend/src/**, or scripts/**, update docs/code_structure_overview.md too.

Completion checks

current port contract is stated explicitly
hardware baseline came from spec/hardware.yaml, not assumption
simulation vs hardware mode was chosen deliberately
affected files and tests are identified before editing
follow-up doc sync requirements are known up front

同仓库更多 Skills

同仓库

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

maintenance-orchestration

acredsfan/lawnberry_pi

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.

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	maintainer-reentry
description	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.
argument-hint	What task or subsystem are you re-entering for?
user-invocable	true

Maintainer Re-entry

What this skill does

This skill turns docs/developer-toolkit.md into a repeatable re-entry checklist so the agent regains project context before making changes.

When to use

starting substantial maintenance after a gap
planning work on runtime behavior, hardware scope, safety, navigation, mission, or AI
triaging a bug when you are not yet sure which subsystem owns it
checking current ports, source-of-truth docs, or supported hardware before implementation

Procedure

Read these sources first, in this order unless the user narrows scope:
- README.md
- docs/OPERATIONS.md
- docs/TESTING.md
- docs/hardware-integration.md
- spec/hardware.yaml
- docs/code_structure_overview.md
- docs/RELEASE_NOTES.md
- docs/hallucination-audit.md
- CONTRIBUTING.md
- .github/copilot-instructions.md
Lock in the current runtime contract before assuming old defaults:
- backend API: 8081
- frontend dev/deployed UI: 3000
- Playwright preview: 4173
Decide whether the task is simulation-safe or hardware-sensitive.
- prefer SIM_MODE=1 for local development, CI, and first-pass validation
- treat SIM_MODE=0 as real-hardware mode with Pi/device expectations
Map the task to the most relevant subsystem and files.
- startup/runtime wiring: backend/src/main.py, backend/src/core/config_loader.py, config/, docs/OPERATIONS.md
- safety/manual control: backend/src/safety/, backend/src/services/robohat_service.py, backend/src/services/blade_service.py
- telemetry/GPS/RTK: backend/src/services/sensor_manager.py, telemetry services, RTK scripts, NTRIP docs
- manual control/operator UI: frontend/src/views/ControlView.vue, frontend/src/stores/control.ts, API and WebSocket services
- maps/planning/mission: frontend/src/views/MapsView.vue, PlanningView.vue, MissionPlannerView.vue, mission/navigation services
Build a short execution checklist before editing.
Prefer the smallest change that restores shared reality rather than speculative feature sprawl.

Decision points

If docs and code disagree, trust code, config, service units, and spec/hardware.yaml over prose.
If hardware is not explicitly required, stay simulation-safe first.
If runtime behavior, subsystem maturity, or supported hardware changed, update docs/developer-toolkit.md in the same pass.
If callable interfaces changed in backend/src/**, frontend/src/**, or scripts/**, update docs/code_structure_overview.md too.

Completion checks

current port contract is stated explicitly
hardware baseline came from spec/hardware.yaml, not assumption
simulation vs hardware mode was chosen deliberately
affected files and tests are identified before editing
follow-up doc sync requirements are known up front