Based on Chapters 3 and 14 of Ryan Singer's Shape Up, which has been read in full. Adapting the team method to Codex's scope card and verification approach is part of this project's design; when sources or boundaries are needed, readSources and reading scope. This package can be used independently.
Start: turn the feature name into a concrete problem
Extract from the existing context: who is in what scenario, at which step they get stuck, how they currently work around it, and what the user explicitly wants delivered. Do not define completion only as "optimize" or "refactor 2.0"; you may investigate existing code, interfaces, or failure records to narrow the problem.
Record the time/work boundary the user is willing to invest as the appetite (investment ceiling), not as an estimated work duration. If no budget is given, mark it as unspecified and first propose a scope commensurate with the existing requirements; only ask further if the trade-off truly depends on the budget. The team weeks in the book cannot be converted into model minutes, nor can unverified completion times be promised.
Enter the work with a short scope card:
- Current difficulty and goal: the specific use scenario, the current state, and what this round should improve.
- This round's boundaries: known investment constraints, explicit requirements, and immutable conditions.
- Must-haves and acceptance: what can be seen after each item is done, and how to confirm it.
- Nice-to-haves and unknowns: enhancements that can be deferred, and assumptions with no evidence yet.
The scope card is the basis for execution, not a default extra approval step. If the user only asks for a suggestion, deliver the card; if the user has already requested implementation, continue completing the authorized work.
During work: make a trade-off for every newly added item
Judge what happens if the newly added item is not done, who it affects, the likelihood of occurrence, and the actual consequences, then decide whether it is a must-have for this round. Do not exclude an item merely because it is old or rare.
Preserve the user's explicit requirements, the correctness necessary to achieve the goal, and existing verification requirements. When these conflict, explain the conflict and propose an adjustment plan; do not delete them without authorization. List optional enhancements separately from the current goal; when the user explicitly adds a goal, update the scope and acceptance criteria, and do not use an old card to reject a new instruction. For vague "make it more professional" requests, first translate them into concrete effects, and avoid automatically expanding them into a full system rewrite.
Wrap-up: judge by artifacts, not by the clock replacing completion
Against the user's original difficulty and the agreed acceptance criteria, provide evidence and gaps:
- All must-haves are complete and pass the relevant verification: ship; remaining nice-to-haves do not automatically prevent ending.
- Must-haves are incomplete, but the approach is clear and the remaining work has no unresolved questions: list the remaining items and the basis before considering an extension; do not automatically add budget or change commitments.
- Key unknowns remain: switch back to an investigation/plan revision with clear artifacts, and state the questions that need answering; do not use "a little more time" to hide unpredictability.
Report what was actually completed, what was only suggested, and what is still blocked. If the user requested implementation, the scope card alone does not count as completion; if acceptance fails, it also cannot be reclassified as passing by narrowing the wording.
Finally, leave a lightweight reading entry point: point out the chapter sections actually used this time, attach links to the original text, and give a question related to this trade-off. Users do not need to read the book first in order to use it.