Usage boundaries and preparation
This skill can be installed independently; the necessary methods are all in this file and do not depend on the author's local machine or other skills. First read the target project specifications, confirm the target repository/workspace, version, user results, and allowed changes; the reference repository is read-only. When there are no project rules, read the actual README, scripts, and source code to infer the entry point.
Execute with currently available and authorized tools: if an independent agent is lacking, use a new session/manual review or self-check from multiple perspectives, and note the actual review method; if a browser/real API is lacking, complete the executable parts and hand over the uncovered acceptance items, and do not pass them off as independent review, GUI, or real service success. The project's original runtime environment is still required; do not bind to a model vendor or specific plugin.
For complex tasks, you may use assets/task-record.md to save necessary facts; for simple tasks, record the results directly and do not mechanically add process.
Define observable results
Turn the requirement into "who does what action under what conditions, and what result should be observed." When existing failures, screenshots, or reference implementations are available, read them; clarify the identity of the target project and reference materials to prevent modifying the reference repository.
Find existing paths and reusable modules from the actual entry point; before reusing, check their real contracts 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 specification for every small rewrite.
Minimal vertical slice
Prioritize getting one complete user path working: input → state/business execution → actual output, rather than filling in all abstraction layers before doing a demo. Follow the existing stack and structure. Record the necessary behavior and the requirements not covered this time, and do not arbitrarily expand it into a platform rebuild.
When comparing with an available reference implementation, give the design premises, the parts worth reusing, and the existing capabilities that should be retained; if there is no source code, judge only 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, trace from the actual producer to the consumer, check the source, priority, 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 process.
Verify against results
Execute the minimal 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 the baseline and must not be silently ignored or attributed to this code change.
Real external service changes require real boundary evidence; when resources are unavailable, explain the unverified parts and complete the internal checks. When checks will not catch an incorrect implementation, improve the assertions rather than piling on quantity.
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 raw facts, not the author's conclusions; each finding must have trigger conditions and actual consequences, and should be verified one by one before fixing. Ordinary small changes can be delivered directly.
Completion and continuous iteration
When the user has authorized submission/integration, submit only the current scope, verify the latest objectives and semantic conflicts, and retest in the integrated state; when release has been authorized, verify the version and notes, observe CI, and validate the actual artifacts. When only implementation is requested, submission preparation and external release cannot replace the actual implementation.
When the next round or another session takes over, retain: user results, the current version, effective configuration, verified content, the applicable conditions of excluded assumptions, remaining issues, and permitted next steps. The record is the project's dynamic facts and is not elevated to permanent rules for all future tasks.