@jaybeeuu/agent-cortex 2.2.0 → 2.3.0

package/CHANGELOG.md

@@ -1,5 +1,29 @@
 # Changelog
 
+## 2.3.0
+
+### Minor Changes
+
+- 3dd1e20: Sync a behind branch by rebasing it onto its base branch, not by merging the base in. The
+  `git-workflow` skill previously told agents to merge the base in, which dragged every intervening
+  commit into the review diff and left a merge commit behind; rule 6 now says fetch, rebase onto
+  `origin/main` (or `epic/<id>` for a feature branch inside an epic), and force-push with
+  `--force-with-lease`. Rewritten commits are re-signed automatically by `commit.gpgsign`, so no
+  `--gpg-sign` and no `rebase.gpgSign` is needed. The rule is scoped to your own unmerged branch —
+  never `main`, never a branch someone else is working on — with one stated exception: a shared
+  integration branch that other branches are based on is synced by merging the base in, because
+  rewriting it would rewrite history under every branch based on it. Landing is unchanged:
+  squash-merge still governs how a branch reaches `main`, so the two decisions can no longer be read
+  as one rule. `AGENTS.md` splits its collapsed "Landing method" bullet into those two decisions
+  accordingly.
+
+### Patch Changes
+
+- 9944bca: Retire `docs/ideas/` now that ideas are `kind:idea` beads. The four remaining idea files that had
+  never been migrated were recorded as beads, and the directory was deleted, so ideas have a single
+  home. Live references to the deleted paths now cite the originating bead instead; `agent-cortex
+migrate` step v2 still reads `docs/ideas/` as a migration source, which is unchanged.
+
 ## 2.2.0
 
 ### Minor Changes

package/extensions/output-style/README.md

@@ -2,7 +2,7 @@
 
 Appends the always-on reply shape to the PI system prompt once per user prompt.
 
-This is the second slice of `docs/ideas/improve-pi-system-prompt.md`: the first
+This is the second slice of the "Improve PI System Prompt" idea (bead `agnt-ctx-s5hn`): the first
 (`agent-guardrails`) stops wasted work; this one stops the answer getting buried in
 it. The extension injects a stable block via the `before_agent_start` hook — which
 fires once per user prompt, before the agent loop — so the rules apply to every

package/extensions/output-style/index.ts

@@ -3,8 +3,8 @@
  *
  * Appends the always-on reply shape to the PI system prompt on every turn: lead
  * with the action, write in Simplified Technical English (ASD-STE100), restate the
- * context the reader cannot remember (the second slice of
- * docs/ideas/improve-pi-system-prompt.md).
+ * context the reader cannot remember (the second slice of the "Improve PI
+ * System Prompt" idea, bead `agnt-ctx-s5hn`).
  *
  * The block is stable text appended after any chained system-prompt changes, so it
  * keeps the prompt-cache prefix intact while remaining authoritative for the model.

package/extensions/output-style/output-style.ts

@@ -1,8 +1,8 @@
 /**
  * Output style for the PI system prompt.
  *
- * The second slice of docs/ideas/improve-pi-system-prompt.md: the reply shape, not
- * the task discipline. Three concerns, in order — lead with the action, write in
+ * The second slice of the "Improve PI System Prompt" idea (bead `agnt-ctx-s5hn`): the reply
+ * shape, not the task discipline. Three concerns, in order — lead with the action, write in
  * Simplified Technical English, restate the context the reader cannot remember.
  *
  * The prose lives in output-style.md so one file feeds both harnesses: this

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jaybeeuu/agent-cortex",
-  "version": "2.2.0",
+  "version": "2.3.0",
   "description": "Personal PI package with custom agents, skills, and extensions",
   "keywords": [
     "pi-package"

package/skills/workflow/git-workflow/SKILL.md

@@ -90,39 +90,41 @@ git pull
 
 This avoids avoidable merge conflicts.
 
-### 6. Bring a behind branch up to date — merge, don't rebase
+### 6. Bring a behind branch up to date — rebase, don't merge
 
-When the base branch moves and the PR reports `BEHIND` or `CONFLICTING`, update
-the branch before anything else:
+When the base branch moves and the PR reports `BEHIND` or `CONFLICTING`, rebase
+your branch onto its base branch before anything else — never merge the base in:
 
 ```bash
 git fetch origin
-git merge origin/main
+git rebase origin/main        # or epic/<id> for a feature branch inside an epic
+git push --force-with-lease
 ```
 
-**Never rebase a branch that contains a merge commit.** `git rebase` drops merge
-commits and the patches they carry, so rebasing a branch that already merged the
-base silently reverts what that merge resolved — the conflict resolutions, and
-any fix from the base the merge brought in. The result usually looks like a
-regression in your own change. `--rebase-merges` preserves the structure, but
-it re-opens the same conflicts; only worth it when the branch's history is
-itself the deliverable.
-
-Rebase only a **linear branch that has not been reviewed yet**. Rewriting
-commits under review discards the review context and invalidates approvals, and
-it requires `git push --force-with-lease` — never `--force`, which overwrites
-work you have not seen.
-
-Which one you owe the repository depends on its landing method, not on taste:
-
-- **Squash merge**: the branch is collapsed on landing, so its shape never
-  reaches the base branch. Merge the base in and move on — rebasing here is
-  cosmetic, and the risky kind of cosmetic.
-- **Rebase-and-merge**: a linear branch is mandatory, so rebase *before* the
-  first review. Once a merge has landed on the branch, that option is gone.
-
-After any update, re-run the checks. A merge that resolved conflicts by hand is
-not verified by the base branch's green CI.
+A merge from the base drags every intervening commit into the review diff and,
+under a squash-merge landing method, contributes nothing that reaches the base
+branch. Landing is still a squash merge; rebasing only reshapes *your* branch
+before it lands, so these are separate decisions, not rivals. Keeping the branch
+linear is what makes the rebase safe: `git rebase` drops merge commits and the
+patches they resolved, so never rebase a branch that already merged the base.
+
+One exception: an **integration branch** that other branches are based on
+(`main`, or an `epic/<id>` branch) is not yours to rewrite. Sync it by merging
+the base in — under squash-merge that merge never reaches the landing diff, and
+the branches based on it stay linear by rebasing onto it.
+
+Rewritten commits are re-signed automatically when `commit.gpgsign` is set. Pass
+no `--gpg-sign`, and do not set `rebase.gpgSign` — both are redundant.
+
+Scope: rebase only your **own unmerged feature branch**. Never rebase `main` or an
+`epic/<id>` branch others are based on, and never rebase a branch another person
+or agent is working on — it discards their context and invalidates review.
+Force-push with `--force-with-lease`, never `--force`, which overwrites work you
+have not seen. Rewriting a reviewed branch discards the review context and
+invalidates approvals, so re-request review after a sync.
+
+After any update, re-run the checks: a conflict resolved by hand is not verified
+by the base branch's green CI.
 
 ### 7. Worktree lifecycle