You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Question: Is there a recommended planning completion gate and lifecycle for .scratch?
#712
First of all, thank you for building and maintaining this repository. I've been using the Skills workflow extensively on one of my projects, and it's probably the most structured approach to AI-assisted development that I've used so far.
As I completed my first full Wayfinder workflow, I realized I wasn't sure what the intended process is once the planning work is considered "finished."
After completing the Wayfinder, resolving every child decision, reviewing the generated artifacts, reconciling the planning documents, and preparing the handoff for the next phase, I performed one last manual review before moving into /to-spec.
During that review I noticed something interesting.
The planning itself was correct, but some higher-level artifacts (original discovery issues, parent specs, document status, etc.) no longer reflected the current state of the project. Nothing was actually broken—it was simply that the documentation had naturally drifted as the work evolved.
That made me wonder if I'm missing part of the intended workflow.
Do you normally have some kind of planning completion gate before moving from planning into specification and implementation?
For example, a final review that confirms things like:
every child decision or ticket has been completed;
parent artifacts have been reconciled;
planning documents have consistent status;
Git is in the expected state (commit created, maybe pushed);
the next handoff is ready.
I'm not necessarily suggesting that this should become another Skill. I'm mainly trying to understand whether this validation is expected to happen manually, whether another workflow already covers it, or whether each project is expected to define its own process.
I also have another question regarding the lifecycle of .scratch.
As a project grows, .scratch naturally accumulates Wayfinders, specs, discovery notes, resolved tickets, planning documents, and other artifacts.
Eventually it becomes difficult to distinguish active work from completed work.
How do you normally manage that?
Should completed initiatives remain in .scratch indefinitely?
Do you archive completed planning work somewhere else?
Is there a recommended structure for historical planning artifacts?
Or is .scratch intentionally expected to become the permanent planning history of the project?
I'd like to organize my project without working against the intended workflow, so I wanted to understand the recommended approach before creating my own conventions.
Finally, one last question.
Have you ever considered having a final project health or workflow audit Skill that validates planning artifacts before the project moves into the next phase? Or is that intentionally left to each project because every team's workflow is different?
I'd really appreciate your thoughts on how you envision the long-term lifecycle of planning artifacts.
Thanks again for all the work you've put into this project.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hi Matt,
First of all, thank you for building and maintaining this repository. I've been using the Skills workflow extensively on one of my projects, and it's probably the most structured approach to AI-assisted development that I've used so far.
As I completed my first full Wayfinder workflow, I realized I wasn't sure what the intended process is once the planning work is considered "finished."
After completing the Wayfinder, resolving every child decision, reviewing the generated artifacts, reconciling the planning documents, and preparing the handoff for the next phase, I performed one last manual review before moving into /to-spec.
During that review I noticed something interesting.
The planning itself was correct, but some higher-level artifacts (original discovery issues, parent specs, document status, etc.) no longer reflected the current state of the project. Nothing was actually broken—it was simply that the documentation had naturally drifted as the work evolved.
That made me wonder if I'm missing part of the intended workflow.
Do you normally have some kind of planning completion gate before moving from planning into specification and implementation?
For example, a final review that confirms things like:
every child decision or ticket has been completed;
parent artifacts have been reconciled;
planning documents have consistent status;
Git is in the expected state (commit created, maybe pushed);
the next handoff is ready.
I'm not necessarily suggesting that this should become another Skill. I'm mainly trying to understand whether this validation is expected to happen manually, whether another workflow already covers it, or whether each project is expected to define its own process.
I also have another question regarding the lifecycle of .scratch.
As a project grows, .scratch naturally accumulates Wayfinders, specs, discovery notes, resolved tickets, planning documents, and other artifacts.
Eventually it becomes difficult to distinguish active work from completed work.
How do you normally manage that?
Should completed initiatives remain in .scratch indefinitely?
Do you archive completed planning work somewhere else?
Is there a recommended structure for historical planning artifacts?
Or is .scratch intentionally expected to become the permanent planning history of the project?
I'd like to organize my project without working against the intended workflow, so I wanted to understand the recommended approach before creating my own conventions.
Finally, one last question.
Have you ever considered having a final project health or workflow audit Skill that validates planning artifacts before the project moves into the next phase? Or is that intentionally left to each project because every team's workflow is different?
I'd really appreciate your thoughts on how you envision the long-term lifecycle of planning artifacts.
Thanks again for all the work you've put into this project.
All reactions