Problem
The staleness and relevancy check added to design-and-plan in #345 is useful beyond that skill. Real-world scenarios that need the same underlying capability:
- Staleness — has the codebase evolved past a ticket's assumptions?
- Completeness — is the ticket's work already done (should it be closed)?
- Remaining scope — which acceptance criteria are still unmet?
These share a common pattern: resolve a ticket, examine the codebase, and compare. Currently the only way to do this is to invoke design-and-plan (which has a different purpose) or to manually instruct the agent each time.
Considerations
- The staleness check in
design-and-plan Phase 1 already implements the core pattern for one mode (staleness). Extracting it avoids duplication when other skills or ad-hoc requests need the same capability.
- The skill should be user-invocable for standalone use (e.g., "is this ticket still open?") and referenceable by other skills (e.g.,
design-and-plan delegates to it).
- The heuristic and override arguments (
--check-staleness / --skip-staleness) should remain in design-and-plan as gating logic for when to invoke the assessment — the new skill handles how.
- Assessment modes have different investigation strategies: staleness looks at commits in affected areas, completeness checks whether the described problem still exists, remaining scope walks acceptance criteria one by one.
Initial solution ideas
- A standalone skill (e.g.,
assess-ticket) that takes a ticket reference and an optional assessment mode (staleness, completeness, remaining-scope, or all).
- Default mode ("all") runs a general assessment covering all three aspects.
design-and-plan Phase 1 delegates the relevancy check to this skill instead of containing inline logic.- Output is a structured assessment the user (or calling skill) can act on.
Prior art
Problem
The staleness and relevancy check added to
design-and-planin #345 is useful beyond that skill. Real-world scenarios that need the same underlying capability:These share a common pattern: resolve a ticket, examine the codebase, and compare. Currently the only way to do this is to invoke
design-and-plan(which has a different purpose) or to manually instruct the agent each time.Considerations
design-and-planPhase 1 already implements the core pattern for one mode (staleness). Extracting it avoids duplication when other skills or ad-hoc requests need the same capability.design-and-plandelegates to it).--check-staleness/--skip-staleness) should remain indesign-and-planas gating logic for when to invoke the assessment — the new skill handles how.Initial solution ideas
assess-ticket) that takes a ticket reference and an optional assessment mode (staleness, completeness, remaining-scope, or all).design-and-planPhase 1 delegates the relevancy check to this skill instead of containing inline logic.Prior art
design-and-planPhase 1 (PR #345 Add staleness and relevancy check to design-and-plan skill #356) — inline staleness check with heuristic gating