patch.md-intent 0.1.0

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Elliot Drel
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,95 @@
+# PatchMD
+
+PatchMD is a proposed convention for keeping customized software updatable.
+
+A root `PATCH.md` records the **intent** behind deliberate changes made to a
+fork. The code and Git commits remain the implementation. The document gives a
+future developer or AI agent enough context to preserve, adapt, or retire those
+changes when upstream moves on.
+
+```text
+customize -> record intent -> update upstream -> repair if needed -> review
+```
+
+PatchMD is a draft proposal, not an established standard or finished product.
+It is inspired by [Theo's "A letter to tech CEOs" talk](https://www.youtube.com/watch?v=G1xqTjoihfo),
+the predictable-file approach of [AGENTS.md](https://agents.md/), and a working
+fork-maintenance workflow first developed in
+[gbrain](https://github.com/ElliotDrel/gbrain/commit/2e3053fa000c6e01fc8dc28f0eb4acaa11381c37). An early project-specific
+experiment also exists in [T3 Code PR #3146](https://github.com/pingdotgg/t3code/pull/3146).
+
+## The idea
+
+When you customize a fork:
+
+1. Change the application normally and commit the work normally.
+2. Add or update a `PATCH.md` entry describing the outcome you intended.
+3. Later, update from upstream using normal Git mechanics first.
+4. If a patch conflicts or has become obsolete, use its recorded intent to
+   repair or retire it.
+5. Verify and review the result before pushing or deploying it.
+
+`PATCH.md` is not a diff, lockfile, or substitute for version control. It
+explains *why the fork differs* so the implementation can change safely.
+
+## Quick start
+
+From the root of your fork, give your agent either of these prompts.
+
+### Run the installer directly
+
+```text
+Read and follow this skill in the current repository:
+https://raw.githubusercontent.com/ElliotDrel/PATCH-md/main/skills/install-patch-md/SKILL.md
+
+Use it to install PatchMD in this fork.
+```
+
+### Install it as a skill
+
+Install the
+[install-patch-md skill](skills/install-patch-md/)
+in your agent's skills directory, then run:
+
+```text
+Use the install-patch-md skill to add PatchMD to this fork.
+```
+
+The installer creates `PATCH.md`, inventories existing customizations, and
+adapts the other two repository skills to the fork's upstream and verification
+commands:
+
+- `install-patch-md` sets up an existing or new fork.
+- `modify-with-patch-md` records intent while making custom changes.
+- `update-with-patch-md` safely rebases, repairs, verifies, and reports.
+
+## What belongs in PATCH.md
+
+Record intentional changes to upstream-owned behavior that the fork needs to
+keep. Do not record formatting-only edits, generated files, lockfile churn,
+environment files, ordinary dependency updates, or unrelated local additions.
+
+Keep entries about outcomes, not old code. One entry may cover several files or
+commits when they implement one customization.
+
+## Specification
+
+[SPEC.md](SPEC.md) defines Draft 0.1. The format is intentionally small:
+
+- one root `PATCH.md`;
+- one stable ID per customization;
+- plain-English intent, rationale, behavior, scope, and reconstruction guidance;
+- `active` and `retired` lifecycle states;
+- normal Git commits as the implementation record.
+
+See [examples/](examples/) for complete files.
+
+## Status
+
+Draft 0.1 is open for practical feedback from maintainers of private and
+downstream forks. Keep proposals simple and grounded in a real maintenance
+problem.
+
+## License
+
+MIT

package/SPEC.md

@@ -0,0 +1,93 @@
+# PatchMD Draft 0.1
+
+PatchMD is an AI-readable record of the intent behind deliberate customizations
+to a downstream software fork.
+
+The key words **MUST**, **MUST NOT**, **SHOULD**, and **MAY** describe this draft's
+requirements.
+
+## File
+
+- The file MUST be named `PATCH.md` and live at the repository root.
+- The file MUST be readable as ordinary Markdown without special tooling.
+- A repository MUST have at most one authoritative `PATCH.md`.
+- The file SHOULD identify the upstream repository and branch.
+
+## Scope
+
+An entry belongs in `PATCH.md` when it describes an intentional change to
+upstream-owned behavior that the downstream fork expects to preserve.
+
+The file SHOULD NOT track:
+
+- formatting-only or incidental refactors;
+- generated files or dependency lockfiles;
+- local environment configuration or secrets;
+- ordinary dependency updates;
+- additions that upstream cannot overwrite and that need no upgrade handling.
+
+## Entries
+
+Each customization MUST have a stable, human-readable ID. A kebab-case ID such
+as `compact-navigation` is recommended. IDs MUST NOT depend on commit hashes or
+list positions.
+
+Each entry MUST contain:
+
+- **Status:** `active` or `retired`.
+- **Intent:** the user or product outcome being preserved.
+- **Why:** why the downstream fork needs the change.
+- **Behavior:** observable requirements that should remain true.
+- **Scope:** affected files, packages, or subsystems.
+- **Reconstruction:** guidance and constraints for implementing the intent on
+  newer upstream code.
+
+An entry MAY include implementation notes and links to commits, issues, or
+upstream pull requests. It SHOULD NOT contain a full source patch. One entry MAY
+cover multiple files or commits when they serve one intent.
+
+## Lifecycle
+
+### Record
+
+Downstream code MUST remain in ordinary Git commits. The matching `PATCH.md`
+entry SHOULD be added or refreshed in the same logical change.
+
+### Update
+
+An update process MUST:
+
+1. refuse to discard uncommitted work;
+2. create a recoverable reference before rewriting history;
+3. try normal Git integration before reconstructing code;
+4. preserve displaced downstream content before resolving a conflict;
+5. prefer the new upstream version when a conflict cannot be resolved safely;
+6. verify the resulting repository with its own checks;
+7. make no push or deployment without user approval.
+
+### Resolve
+
+When mechanical integration is insufficient, a developer or agent SHOULD
+compare the new upstream implementation, the previous downstream
+implementation, and the matching `PATCH.md` intent.
+
+It MUST reconstruct intent rather than blindly restore old text. Ambiguous work
+MUST be shown to the user instead of guessed.
+
+### Retire
+
+When upstream satisfies an intent or the customization is abandoned, its entry
+MUST be marked `retired` rather than deleted. The reason and relevant upstream
+reference SHOULD be recorded.
+
+## Review
+
+The user MUST be told which customizations were preserved, changed, retired, or
+left unresolved. The result MUST be reviewed before it is pushed, deployed, or
+otherwise adopted.
+
+## Compatibility
+
+PatchMD does not require a specific agent, package manager, programming
+language, or upgrade program. Tools MAY automate this lifecycle if they preserve
+the guarantees above.

package/examples/customization.PATCH.md

@@ -0,0 +1,27 @@
+# PATCH.md
+
+This file records the intent behind deliberate customizations to this fork.
+
+## Upstream
+
+- Repository: `https://github.com/example/notes-app`
+- Branch: `main`
+
+## Active customizations
+
+### compact-navigation
+
+- **Status:** active
+- **Intent:** Let keyboard-heavy users switch sections without opening the
+  navigation drawer.
+- **Why:** Upstream requires pointer interaction for every section change.
+- **Behavior:** `Ctrl+1` through `Ctrl+4` switch the four primary sections;
+  shortcuts do nothing while a text field is active.
+- **Scope:** Desktop keyboard handling and primary navigation state.
+- **Reconstruction:** Use upstream's current command and navigation APIs. Keep
+  the text-input guard and avoid a second navigation state store.
+- **References:** Downstream issue `#12`.
+
+## Retired customizations
+
+No retired customizations.

package/examples/minimal.PATCH.md

@@ -0,0 +1,16 @@
+# PATCH.md
+
+This file records the intent behind deliberate customizations to this fork.
+
+## Upstream
+
+- Repository: `https://github.com/example/notes-app`
+- Branch: `main`
+
+## Active customizations
+
+No active customizations.
+
+## Retired customizations
+
+No retired customizations.

package/examples/retired-fix.PATCH.md

@@ -0,0 +1,25 @@
+# PATCH.md
+
+This file records the intent behind deliberate customizations to this fork.
+
+## Upstream
+
+- Repository: `https://github.com/example/notes-app`
+- Branch: `main`
+
+## Active customizations
+
+No active customizations.
+
+## Retired customizations
+
+### preserve-drafts-on-refresh
+
+- **Status:** retired
+- **Intent:** Prevent unsaved drafts from disappearing after a browser refresh.
+- **Why:** Older upstream releases stored drafts only in component memory.
+- **Behavior:** A refresh restores the latest unsaved draft for the open note.
+- **Scope:** Draft persistence and note editor initialization.
+- **Reconstruction:** No longer required. Upstream now persists draft state and
+  restores it before rendering the editor.
+- **References:** Retired after upstream PR `#456`.

package/package.json

@@ -0,0 +1,26 @@
+{
+  "name": "patch.md-intent",
+  "version": "0.1.0",
+  "description": "A convention for keeping customized software forks updatable. Add a PATCH.md to record the intent behind your fork's deliberate changes.",
+  "keywords": [
+    "patch",
+    "fork",
+    "upstream",
+    "convention",
+    "ai",
+    "agent"
+  ],
+  "homepage": "https://github.com/ElliotDrel/PATCH-md",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/ElliotDrel/PATCH-md.git"
+  },
+  "license": "MIT",
+  "author": "Elliot Drel",
+  "files": [
+    "README.md",
+    "SPEC.md",
+    "template/",
+    "examples/"
+  ]
+}

package/template/PATCH.md

@@ -0,0 +1,30 @@
+# PATCH.md
+
+This file records the intent behind deliberate customizations to this fork.
+Code and Git commits are the implementation; this file explains what must
+survive an upstream update.
+
+## Upstream
+
+- Repository: `https://github.com/OWNER/REPOSITORY`
+- Branch: `main`
+
+## Active customizations
+
+<!-- Copy this section for each customization. Use a stable kebab-case ID. -->
+
+### customization-id
+
+- **Status:** active
+- **Intent:** What outcome should this customization provide?
+- **Why:** Why does this fork need behavior that upstream does not provide?
+- **Behavior:** What observable requirements must remain true?
+- **Scope:** Which files, packages, or subsystems are involved?
+- **Reconstruction:** How should a future developer or agent rebuild the intent
+  on newer upstream code? Include constraints, not a full code patch.
+- **References:** Optional commits, issues, or upstream pull requests.
+
+## Retired customizations
+
+Move or copy retired entries here, set `Status` to `retired`, and explain why
+the customization is no longer needed. Do not delete its history.