UNPKG

@crossplatformai/skills

Version:

Reusable Agent Skills for CrossPlatform.ai projects.

39 lines (23 loc) • 2.58 kB
# Staged Diff Ownership This is a Post.Build.Ship reference, not a standalone skill. Use this reference when `build` or `ship` is already active and the work involves staged diffs, mixed staged/unstaged files, patch staging, or commit ownership review. This reference supplements Post.Build.Ship. It preserves Authorizing User or direct-user authority, proportionate QA, commit coherence, and Ship safety. It adds no mandatory review or presentation fields. ## Terminology The canonical term is **hunk-level** ownership. A hunk is the contiguous block of changed lines Git stages as one unit under `git add -p`, bounded by `@@` diff headers. Developers may describe the same idea as **line-level** (the finer granularity of individual lines inside a hunk) or **patch-level** (after the `git add --patch` staging mode); informal usage includes **chunk-level**. Treat all of these as the hunk-level ownership rule defined here. ## Ownership Level Diff ownership is at the reviewed hunk and line level, not merely at the file path level. A single file can contain both approved staged hunks for the current unit and unrelated hunks from the user, another agent, generated output, or a later unit. Commit only hunks that were implemented by the current unit or explicitly reviewed and approved for the current unit. Do not treat every change in a path as owned just because the path is otherwise in scope. ## Mixed Status Entries In `git status --short`, the first column describes the index/staged state and the second column describes the worktree/unstaged state. Mixed states such as `MM` mean the file has staged modifications and also still has unstaged modifications. The second-column `M` means unstaged changes remain after the staged changes. When a file shows `MM`, inspect `git diff -- <file>` before staging or committing to understand the unstaged hunks that remain outside the staged diff. Also inspect `git diff --staged -- <file>` when needed to compare staged ownership against remaining unstaged work. ## Staging And Commit Safety Leave another agent's or user's unstaged hunks exactly as found. Do not stage, revert, fold in, rewrite, or treat them as reviewed unless the user explicitly approves that hunk-level action for the current unit. Do not blindly run `git add <file>` when the file may contain unrelated hunks. Use patch staging or leave unrelated hunks unstaged when mixed ownership exists. If staged and unstaged hunks overlap semantically or cannot be separated safely, stop and ask one targeted question before staging or committing.