feat(quick-dev): improve checkpoint 1 UX (#2217)
* feat(quick-dev): improve checkpoint 1 UX with clickable link, external editing note, and change detection Display spec file path as clickable CWD-relative link alongside the summary. Inform users they can open the spec in another session with any tool before approving. On approval, re-read the spec from disk and acknowledge any external edits before proceeding. * fix(quick-dev): tighten checkpoint 1 [A] flow wording - Remove stray 'and options' from the editing-note intro so the note's position relative to the [A]/[E] menu is unambiguous. - Restructure the [A] bullet into explicit missing/exists branches so the missing-file HALT cannot fall through to status updates and recreate a deleted spec. Addresses augmentcode review comments on PR #2217. * docs(quick-dev): rewrite checkpoint 1 editing-note - Drop boilerplate opener about the spec being a regular file. - Enumerate concrete options: editor, in-session Q&A, or bmad-advanced-elicitation / bmad-party-mode / bmad-code-review skills. - Flag that skills should ideally run in another session to avoid context bloat. - Change "add this note" to "display this note" for precision.
This commit is contained in:
parent
b744408783
commit
f9925eb180
|
|
@ -24,9 +24,21 @@ deferred_work_file: '{implementation_artifacts}/deferred-work.md'
|
|||
|
||||
### CHECKPOINT 1
|
||||
|
||||
Present summary. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem. HALT and ask human: `[A] Approve` | `[E] Edit`
|
||||
Present summary. Display the spec file path as a CWD-relative path (no leading `/`) so it is clickable in the terminal. If token count exceeded 1600 and user chose [K], include the token count and explain why it may be a problem.
|
||||
|
||||
- **A**: Set status `ready-for-dev` in `{spec_file}`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. Display the finalized spec path to the user as a CWD-relative path (no leading `/`) so it is clickable in the terminal. → Step 3.
|
||||
After presenting the summary, display this note:
|
||||
|
||||
---
|
||||
|
||||
Before approving, you can open the spec file in an editor or ask me questions and tell me what to change. You can also use `bmad-advanced-elicitation`, `bmad-party-mode`, or `bmad-code-review` skills, ideally in another session to avoid context bloat.
|
||||
|
||||
---
|
||||
|
||||
HALT and ask human: `[A] Approve` | `[E] Edit`
|
||||
|
||||
- **A**: Re-read `{spec_file}` from disk.
|
||||
- **If the file is missing:** HALT. Tell the user the spec file is gone and STOP — do not write anything to `{spec_file}`, do not set status, do not proceed to Step 3. Nothing below this point runs.
|
||||
- **If the file exists:** Compare the content to what you wrote. If it has changed since you wrote it, acknowledge the external edits — show a brief summary of what changed — and proceed with the updated version. Then set status `ready-for-dev` in `{spec_file}`. Everything inside `<frozen-after-approval>` is now locked — only the human can change it. → Step 3.
|
||||
- **E**: Apply changes, then return to CHECKPOINT 1.
|
||||
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue