symphony-trello: Skill for Codex

Java Optionals Eval Capture

Goal

When a Symphony for Trello change provides a reusable Optional or adjacent absence/fallback strategy-selection lesson, preserve the teaching example for the Java Optionals skill. Capture the reusable absence-handling shape without generalizing an unrelated container or context migration. Create or update an issue in martinfrancois/java-optionals-skill that stands on its own: it must include the relevant code before the prompt, the prompt or review request that triggered the change, the intermediate or rejected implementation when one exists, the final preferred code, and why the final code is better.

When the Optional improvement is prompted by a reviewer or user after Codex introduced the weaker Optional shape, also capture the earlier prompt that caused Codex to write that shape. The eval issue must make the trigger failure explicit: the Optionals skill should have activated during the original implementation prompt, not only during the later refactor request.

When a later request reveals only that activation or eval capture was missed, even though the implementation was already preferred, capture both prompts and state that no code correction was needed. The eval must reward recognizing and capturing the reusable lesson without inventing a defect.

When an Optional refactor is later found to be non-equivalent, over-abstracted, or worse than the original code, capture the full correction chain. Include the original code, the prompt that produced the weaker Optional code, the weaker code, the later correction/revert prompt, and the final code. The eval must teach the skill to preserve behavior by default, and to call out any laziness, exception, side-effect, nullability, prompt, or checked-boundary change explicitly before recommending it.

When To Use

Use this skill whenever you:

• replace isPresent() / get() / orElseThrow() control flow with clearer Optional APIs;
• replace orElse(null), null checks, fake streams, or generic Optional helpers with a direct Optional shape;
• improve map, flatMap, or, orElseGet, ifPresent, or ifPresentOrElse usage;
• simplify nullable, absent, fallback, or default strategy selection on an adjacent owning API such as ScopedValue.orElse(...) when choosing and invoking the strategy is a reusable lesson, even when the final code contains no java.util.Optional;
• preserve checked-exception or side-effect boundaries while improving Optional readability;
• accept a user-provided Optional refactor;
• correct an Optional refactor after review feedback;
• revert or repair an Optional refactor because it changed behavior, laziness, exception handling, side effects, nullability, prompt ordering, or a checked boundary.