patch-decomposition

Files (1)

• SKILL.md

SKILL.md (first lines)

# Patch Decomposition

## Bind The Inputs

1. Read the active Gate, accepted base and fork identities, plugin boundary, allowed paths, and prior ownership or dependency Decisions.
2. Record source tree hashes and preserve the dirty-worktree baseline.
3. Stop if the base is inferred from timestamps, either tree is unstable, or the Gate does not name one plugin claim.

## Isolate One Patch

1. Inventory changed files by content hash, then inspect each relevant diff hunk.
2. Classify every hunk as plugin-owned, accepted shared infrastructure, upstream drift, or `UNKNOWN`.
3. Exclude upstream drift. Leave ambiguous ownership `UNKNOWN` and request measurement or review rather than assigning it by proximity.
4. Map activation, inactive behavior, hook points, build effects, runtime effects, tests, and rollback ownership.
5. Record candidate dependencies separately from accepted dependency edges.
6. Generate the minimal patch from the accepted base without rewriting the source trees.
7. Check forward apply, reverse apply, path scope, and the smallest Gate-required build or tests in an isolated target.

## Return Contract

Return:

- base, fork, and generated patch identity tuples
- per-file and per-hunk ownership manifest
- included, excluded, shared, and `UNKNOWN` changes
- activation, inactive-path, hook-point, and dependency observations
- apply, verification, and rollback results
- unresolved blockers and one exact review action

## Forbidden Decisions

- Do not choose or revise the fork point, plugin boundary, or patch order.
- Do not assign ambiguous hunks or promote candidate dependencies to accepted edges.
- Do not combine unrelated plugins or silently include upstream drift.
- Do not rewrite either source tree to make extraction easier.
- Do not declare Gate or Phase PASS, update `CURRENT_PLAN`, or authorize rebasing.

From linjuhon/codex-personal-skills, MIT.

More from linjuhon/codex-personal-skills