Usage boundaries and preparation
This skill can be installed on its own; the necessary methods are all in this file, and it does not depend on the author's machine or other skills. First read the target project's conventions and 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 points.
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 off the uncovered acceptance, and do not pass yourself 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.
Pin down the source and target
Read the project's Git conventions, and inspect status, the current branch/HEAD, staged and unstaged diffs, the target branch, and the worktree list. Distinguish this change from existing user changes; do not automatically reset, clean, stash, or overwrite unrelated work.
When there is no Git, deliver file diffs and verification; do not force initialization just to complete this process. When the user requests only a local commit, do not extend to push/PR.
Individually reviewable commits
Stage only the verified task files; when the same file contains unrelated modifications, first separate the attributable changes, and clearly explain substantive ambiguities that cannot be safely separated. Separate independent root causes into separate commits where possible, to facilitate review and rollback. Commit messages should state behavior and reasons, following project style; include an issue number only when a real issue exists.
Verification should correspond to the content being committed. A single pass on an already dirty workspace does not prove it will also pass when unrelated files are absent; when needed, verify in an isolated copy.
Integrate into the latest target
Update target information according to current authorization; handle fetching remote refs and integrating the local workspace separately. Check whether the target is checked out by another worktree and whether there are uncommitted changes. Maintain consistency between HEAD and the workspace through normal Git operations; do not bypass restrictions by hard-updating a ref for an already checked-out target.
Use the repository's established merge strategy. If "merge only this commit" is required, first confirm the commit scope and its dependencies; when fast-forward is possible, use ff-only, otherwise cherry-pick only the confirmed current commits. Do not impose this strategy on all repositories.
For conflicts, first look at the business semantics on both sides and the original acceptance criteria; do not pick the side that looks like it compiles just to get it done. Conflicts that can be determined with evidence may be resolved within the authorized scope; when the tradeoff cannot be judged from the available information, leave the specific conflict and options and wait for the necessary input.
After integration, inspect the target diff and verify the original task affected by the merge/conflict and adjacent paths. The absence of a textual Git conflict does not mean there is no behavioral conflict. patch-id only helps identify a patch; it does not mean the full target tree and runtime environment are the same.
External delivery
push, creating a PR, deleting branches/worktrees, or publishing are all performed according to the current request and authorization. A successful local commit, a successful remote upload, and CI passing are different states. When a PR is authorized, deliver the real URL; if it was not created, do not fabricate one.
PR descriptions should state the actual problem, the final behavior, necessary verification, and uncovered items, omitting discussion history and unimplemented approaches. When a CI failure is received, confirm whether it is related to the current changes, fix the relevant cause, and observe the new result. Output the commit/target identity and the delivery layer actually completed.