feat(ase-task-implement): add incremental step mode (--mode steps)#65
Open
Brusdeylins wants to merge 2 commits into
Open
feat(ase-task-implement): add incremental step mode (--mode steps)#65Brusdeylins wants to merge 2 commits into
Brusdeylins wants to merge 2 commits into
Conversation
Port the steps-mode feature onto the restructured ase-task-implement skill, expressed in the current skill DSL (custom-dialog, if/elseif/ else, getopt option declaration) rather than the older user-dialog/if constructs the original feature branch was built on. - new --mode|-m=(ask|all|steps) getopt option (and argument-hint) - new "Determine Mode" procedure step: resume an interrupted steps run (open IMPLEMENTATION STEPS checkboxes), honor a pre-selected --mode, fall back to all in headless contexts, else ask via a custom-dialog - "Create Implementation" split into an <if mode=all> single-pass branch (the previous behavior) and an <if mode=steps> branch that restructures the plan into review-ready increments persisted as an IMPLEMENTATION STEPS section inside the plan, implements each increment, records a per-step summary, and pauses at a custom-dialog review gate (CONTINUE/DISCUSS/DONE) carrying a one-line summary gist - the IMPLEMENTATION STEPS section is removed again after the last increment, returning the plan to its canonical format - help.md documents the modes, the --mode option, and an example Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
… gate - emit an invariant step report per increment: production-file table (Status/File/What), tests named separately, verification result citing known pre-existing failures, and explicit staging status - extend the IMPLEMENTATION STEPS ledger with a BASELINE bullet (pre-existing failures) and resequencing rules (rationale recorded, deferred work must name its target increment) - add [measure] and [live] increment types: measurements gate dependent increments (build or cancel), live verifications are user-driven - match verification to the increment type and check harness realism (advancing clock, concurrency, reconnects) - bind the loop to four contract rules: one increment at a time, implementing is the default, git sovereignty (never commit, stage only on explicit STAGE gate choice), no silent deferrals Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds an opt-in step mode to the
ase-task-implementskill: instead of one single-pass change set (--mode all, unchanged default behavior), the plan is restructured into small, individually verifiable increments -- each the smallest landable unit (one reviewable diff plus its test, ending "compiles + tests green + report") -- with a hard review gate after every increment.How it works
--mode|-m ask|all|steps(defaultask-> interactive dialog; headless contexts fall back toall). A plan containing an openIMPLEMENTATION STEPSchecklist resumes step mode automatically -- the re-entry path after a discussion pause or session restart.IMPLEMENTATION STEPSsection (checkbox list plus aBASELINEbullet naming known pre-existing failures, so green/red verdicts stay interpretable). Increments may be resequenced with recorded rationale; deferred work must name its target increment. The section is removed again once all increments are done.CONTINUE,STAGE(stage exactly this step's not-yet-staged files, then continue),DISCUSS(pause; re-invoke to resume), orDONE. The gate reviews results -- implementing the next increment is the default, permission is never re-asked.[measure]probes whose measured result builds or cancels dependent increments, and[live]verifications driven by the user running the application. Verification matches the increment type and checks harness realism (advancing clock, concurrency, reconnects).STAGEgate choice.--mode steps --next ...composes: the--nexttokens apply only to the final next-step dialog, the per-increment gates stay deliberately interactive.Verification
Verified end-to-end with a toy 4-step plan (Claude Code, dev install): step list derivation and persistence, invariant step reports, review gates,
[measure]gating (dependent increment cancelled with recorded rationale),DISCUSSpause, resume across a plugin reload at the first open increment, ledger removal on completion, and theDELETEhand-off toase-task-delete.markdownlint+eslint(plugin lint target) pass. TheSTAGEgate branch itself has not been exercised in a live git repo yet.No CHANGELOG entry included on purpose.
🤖 Generated with Claude Code