Working With Legacy Code — Fleet Worker Edition

Use when changing poorly tested existing code.

When to Use

An assigned change touches untested or tightly coupled code. Do not use to launch a rewrite or preserve a known bug over the spec.

Prerequisites

Before applying any guidance, load references/fleet-worker-policy.md in full using read_file. The approved spec and repository conventions override book heuristics. This documentation skill installs nothing and is platform-neutral; language/tool examples require the target repository's own supported environment.

Procedure

1. Confirm assigned scope, acceptance criteria, current head and relevant repository instructions. Completion: the intended behavior and permitted files are explicit.
2. Locate change points and observable sensing points; sketch affected outputs and state. Establish the smallest safe test seam at a real boundary. Characterize unaffected existing behavior, separately marking disputed observations. Test approved changed behavior with a failing regression, including relevant errors and authorization. Make minimal dependency-breaking edits only when needed, retain production wiring, and verify compatibility. A compiler is useful evidence, not exhaustive impact analysis of reflection, dynamic callers or external clients. Completion: the chosen change has a concrete task justification and defined checks.
3. Apply the smallest authorized change with patch; use terminal for real repository checks. Completion: each changed behavior and relevant error/auth path has evidence, or a named not-run/blocker reason; no fabricated results or numeric quality score.
4. Hand off the exact final head and evidence to SOL. Completion: worker report names outstanding gaps without claiming final acceptance. Terra is skipped. More than two failed SOL attempts on the same item triggers Opus actionable remediation, then renewed checks and SOL review at the new exact head.

References: Load Only the Applicable Detail

• case studies — use for case studies within the approved scope.
• change algorithm — use for change algorithm within the approved scope.
• characterization tests — use for characterization tests within the approved scope.
• dependency breaking — use for dependency breaking within the approved scope.
• seams — use for seams within the approved scope.

Pitfalls

No unsolicited features, refactors, redesign or infrastructure. Do not trade correct behavior for shorter functions, fewer arguments, empty-over-null substitutions, exceptions in a Result/Go-error codebase, or additional abstraction. Examples are illustrations, not verified results or settings for the target system.

Verification

Report assigned criteria, actual checks and their outcomes, relevant diffs, exact head and limitations. Tests and worker confidence do not replace SOL final review. See adaptation notes and upstream provenance for origin and changes.

---

Supporting files: this skill's supporting files are held in the docsite at docs/15-skills/_support/wondelai/working-with-legacy-code/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/wondelai/working-with-legacy-code/ · view source · Imported 2026-10-03. Supporting files (references, scripts) remain in the source repository.

version 1.4.0-fleet.1 · author Wondel.ai (wondelai), Hermes Agent · license MIT.

Published by Muse · 2026-10-03.