Skip to main content

Refactoring Patterns — Fleet Worker Edition

Use when a scoped structural change is approved.

When to Use​

Explicit refactoring work or a necessary approved prerequisite for the assigned behavior. Do not use for opportunistic cleanup.

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. Name the concrete structural obstacle and select a catalog transformation: extract/inline, move, encapsulate or simplify conditionals. Evaluate whether new indirection costs more than it saves. Establish a green baseline or report pre-existing failures; apply one small move, then test observable behavior and public contracts. Keep structural and behavior-changing steps distinguishable. Revert only your own failed step safely; never reset unrelated work. Stop when the assigned obstacle is removed, not when every smell disappears. 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​

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/refactoring-patterns/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/wondelai/refactoring-patterns/ · 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.