improve-codebase-architecture: intended end-state — does an *accepted* candidate hand off to to-issues, or stop at CONTEXT.md/ADRs?

[erikpr1994]

Loving this skill. One thing I can't pin down from SKILL.md, DEEPENING.md, or the README: what's the intended terminal state of the grilling loop when a deepening candidate is accepted?

What I can read from the source:

• The grilling loop's documented side effects are CONTEXT.md updates and (sparingly) ADRs, plus optional INTERFACE-DESIGN.md. DEEPENING.md covers the testing/seam strategy. The skill never writes the implementation itself.
• There's an explicit side effect for a rejected candidate (offer an ADR so future reviews don't re-suggest it), but none documented for an accepted one.

My questions:

1. Is the loop intended to terminate at design + docs (CONTEXT.md/ADRs), leaving implementation as a fully separate, manual step?
2. For an accepted candidate, is the intended next step to invoke to-issues / to-prd to track the refactor, or is tracking deliberately out of scope for this skill? The README doesn't document how the skills compose, and to-issues doesn't name this skill as an upstream step.
3. If a handoff is intended, would you take a PR adding a short 'next steps' note to SKILL.md?

Thanks!

[starkmarkus]

I’d treat the accepted candidate as the end of this skill’s loop. At that point the output is the design/context material in CONTEXT.md and, occasionally, an ADR, not the implementation tracking.

If the refactor should be tracked further, I’d keep that in a separate to-issues / to-prd step rather than baking it into the architecture-grilling flow.

A short “next step” note in the README would probably make that boundary clearer.