Clarify what to do
Turn the requirement into "who does what action under what conditions, and what result should be observed." When there is an existing failure, screenshot, or reference implementation, read it; clarify the identity of the target project and the reference material to avoid modifying the reference repository.
Read the project conventions, README, and relevant scripts to confirm the scope of changes, then find the existing flow and reusable modules from the actual entry point; before reusing, check its real contract and do not infer from naming. When the requirement is unclear, first advance the investigation that does not depend on that information, then ask about the key differences that affect the result. There is no need to write a spec for every small change.
Implement one complete flow
Prioritize getting one complete user path working: input → state/business execution → actual output, rather than filling out all abstraction layers before doing a demo. Follow the existing stack and structure. Record necessary behavior and requirements not covered this time, and do not expand on your own into a platform rebuild.
When comparing with an available reference implementation, give the design premise, the parts worth reusing, and the existing capabilities that should be retained; if there is no source code, make judgments only about observable behavior. Reference code is evidence and does not mean automatically migrating its tech stack.
When changes involve configuration, events, providers, storage, or process boundaries, follow from the actual producer to the consumer, check sources, precedence, missing states, error propagation, and recovery behavior, and verify with the corresponding negative scenarios. When touching supported languages, themes, or platforms, cover the corresponding changes; capabilities not supported by the project do not become new requirements because of this flow.
Verify the user result
Execute the smallest user task from the project's real entry point, and check the actual output or persisted state. Add key failure or boundary scenarios according to the changes, and run the existing relevant checks. Checks that were already failing at the start should be recorded as a baseline, and must not be silently ignored or attributed to this code change.
When this change involves external services, verify the behavior among requests, responses, and actual consumers. When the service is inaccessible, complete the internal checks and note the external behavior that has not yet been verified. When the checks would not catch a wrong implementation, improve the assertions.
Problems newly introduced this time must be handled; unrelated old problems should be recorded for follow-up. For complex/high-impact changes or when the user requests an independent review, give the independent reviewer the task, acceptance criteria, target version, and original facts, without attaching preset conclusions; every finding must have a trigger condition and actual consequence, and should be verified one by one before fixing. Ordinary small changes can be delivered directly.
Completion and continuous iteration
After the feature is merged into the target branch, retest along the same user path to confirm that the final integrated state still meets acceptance.
When the next round or another session takes over, retain: the user result, current version, effective configuration, verified content, applicable conditions for excluded hypotheses, remaining issues, and allowed next steps.
When multiple rounds of iteration or handoff are needed, you can use feature development record to save the goal, implementation path, acceptance, and next steps.