Software Design Philosophy — Fleet Worker Edition

Use when designing scoped module interfaces.

When to Use

Assigned module or API work with demonstrable interface complexity. Do not use as permission to redesign architecture.

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. Identify change amplification, cognitive load and hidden dependencies. Compare the existing interface with the smallest interface covering approved current needs. Hide implementation knowledge inside an existing ownership boundary; retain adapters that enforce security, compatibility or observability. Prefer a deep cohesive module only where it reduces caller burden without merging independent responsibilities. Document interface contracts and intentional configuration. Reject speculative generality and guessed defaults. 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

• comments as design — use for comments as design within the approved scope.
• complexity symptoms — use for complexity symptoms within the approved scope.
• deep modules — use for deep modules within the approved scope.
• general vs special — use for general vs special within the approved scope.
• information hiding — use for information hiding within the approved scope.
• strategic programming — use for strategic programming 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/software-design-philosophy/ — fetch them fresh from jknash/docsite main alongside this page. Source: jknash/hermes-shared-skills · branch hermes-jkdev001 @ 1d0d545c3970 · skills/wondelai/software-design-philosophy/ · 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.