@codyswann/lisa 2.13.0 → 2.15.0

package/package.json

@@ -79,7 +79,7 @@
     "lodash": ">=4.18.1"
   },
   "name": "@codyswann/lisa",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "Claude Code governance framework that applies guardrails, guidance, and automated enforcement to projects",
   "main": "dist/index.js",
   "exports": {

package/plugins/lisa/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "Universal governance — agents, skills, commands, hooks, and rules for all projects",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa/rules/base-rules.md

@@ -56,6 +56,7 @@ Git Discipline:
 - When opening a PR, watch the PR. If any status checks fail, fix them. For all bot code reviews, if the feedback is valid, implement it and push the change to the PR. Then resolve the feedback. If the feedback is not valid, reply to the feedback explaining why it's not valid and then resolve the feedback. Do this in a loop until the PR is able to be merged and then merge it.
 - When merging a PR into an environment branch (dev, staging, main), watch the resultant deploy until it fully succeeds. If it fails for any reason, fix the failure and then open a new PR with the fix.
 - When referencing a PR in a response, always include the url
+- **Promotion PRs (environment branch → environment branch — e.g., `dev` → `staging`, `staging` → `main`) MUST be merged with a regular merge commit (`gh pr merge --merge`), NEVER squash-merged.** Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into a single commit titled with the PR title, which (a) strips the `[skip ci]` markers so the release workflow re-runs and double-bumps the version on the destination branch, and (b) breaks the release workflow's promotion-detection regex (which inspects the merge-commit subject for `Merge branch 'X' into Y` or `Merge pull request #N from .../<env-branch>`). The merge commit produced by `--merge` keeps the subject clean and the per-commit `[skip ci]` markers attached where they belong. Feature PRs (anything → `dev`) use `--squash` as usual.
 
 Testing Discipline:
 - Never skip or disable any tests or quality checks.

package/plugins/lisa/skills/git-submit-pr/SKILL.md

@@ -24,7 +24,9 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
    - Check for existing PR on this branch
    - If exists: Update description with latest changes
    - If not: Create PR with comprehensive description (not a draft)
-5. **Auto-merge**: Enable auto-merge on the PR using `gh pr merge --auto --merge`
+5. **Auto-merge**: Choose merge strategy by PR type:
+   - **Promotion PRs** (env → env, e.g. `dev` → `staging`): use `gh pr merge --auto --merge` (never squash). Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into one commit titled with the PR title, stripping the `[skip ci]` markers and breaking the release workflow's promotion-detection regex — the destination branch then double-bumps its version. `--merge` keeps each `chore(release)` commit (and its `[skip ci]` marker) intact under a clean merge commit subject the workflow can recognize.
+   - **Feature PRs** (anything → `dev`): use `gh pr merge --auto --squash`.
 
 ### PR Description Format
 

package/plugins/lisa-cdk/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-cdk",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "AWS CDK-specific plugin",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-expo/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-expo",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "Expo/React Native-specific skills, agents, rules, and MCP servers",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-nestjs/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-nestjs",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "NestJS-specific skills (GraphQL, TypeORM) and hooks (migration write-protection)",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-rails/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-rails",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "Ruby on Rails-specific hooks — RuboCop linting/formatting and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/lisa-typescript/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "lisa-typescript",
-  "version": "2.13.0",
+  "version": "2.15.0",
   "description": "TypeScript-specific hooks — Prettier formatting, ESLint linting, and ast-grep scanning on edit",
   "author": {
     "name": "Cody Swann"

package/plugins/src/base/rules/base-rules.md

@@ -56,6 +56,7 @@ Git Discipline:
 - When opening a PR, watch the PR. If any status checks fail, fix them. For all bot code reviews, if the feedback is valid, implement it and push the change to the PR. Then resolve the feedback. If the feedback is not valid, reply to the feedback explaining why it's not valid and then resolve the feedback. Do this in a loop until the PR is able to be merged and then merge it.
 - When merging a PR into an environment branch (dev, staging, main), watch the resultant deploy until it fully succeeds. If it fails for any reason, fix the failure and then open a new PR with the fix.
 - When referencing a PR in a response, always include the url
+- **Promotion PRs (environment branch → environment branch — e.g., `dev` → `staging`, `staging` → `main`) MUST be merged with a regular merge commit (`gh pr merge --merge`), NEVER squash-merged.** Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into a single commit titled with the PR title, which (a) strips the `[skip ci]` markers so the release workflow re-runs and double-bumps the version on the destination branch, and (b) breaks the release workflow's promotion-detection regex (which inspects the merge-commit subject for `Merge branch 'X' into Y` or `Merge pull request #N from .../<env-branch>`). The merge commit produced by `--merge` keeps the subject clean and the per-commit `[skip ci]` markers attached where they belong. Feature PRs (anything → `dev`) use `--squash` as usual.
 
 Testing Discipline:
 - Never skip or disable any tests or quality checks.

package/plugins/src/base/skills/git-submit-pr/SKILL.md

@@ -24,7 +24,9 @@ Push current branch and create or update a pull request. Optional hint: $ARGUMEN
    - Check for existing PR on this branch
    - If exists: Update description with latest changes
    - If not: Create PR with comprehensive description (not a draft)
-5. **Auto-merge**: Enable auto-merge on the PR using `gh pr merge --auto --merge`
+5. **Auto-merge**: Choose merge strategy by PR type:
+   - **Promotion PRs** (env → env, e.g. `dev` → `staging`): use `gh pr merge --auto --merge` (never squash). Squashing flattens the constituent `chore(release): X.Y.Z [skip ci]` commits into one commit titled with the PR title, stripping the `[skip ci]` markers and breaking the release workflow's promotion-detection regex — the destination branch then double-bumps its version. `--merge` keeps each `chore(release)` commit (and its `[skip ci]` marker) intact under a clean merge commit subject the workflow can recognize.
+   - **Feature PRs** (anything → `dev`): use `gh pr merge --auto --squash`.
 
 ### PR Description Format
 

package/rails/create-only/.github/workflows/claude-sync-down-branches.yml

@@ -0,0 +1,37 @@
+# This file was created by Lisa on first setup.
+# You can customize this file — Lisa will not overwrite it.
+#
+# Back-syncs merges down the env chain so hotfixes propagate.
+# Example: PR merged to main -> opens a sync PR to staging.
+#          PR merged to staging -> opens a sync PR to dev.
+#
+# Customize for your project:
+#   - `branches`: list each branch that should *trigger* a back-sync
+#     (typically the keys of `chain` below).
+#   - `chain`: JSON map of source -> target. Examples:
+#       3-env: '{"main":"staging","staging":"dev"}'
+#       2-env main/staging: '{"main":"staging"}'
+#       2-env master/preprod: '{"master":"preprod"}'
+
+name: Claude Sync Down Branches
+
+on:
+  pull_request:
+    types: [closed]
+    branches: [main, staging]
+
+permissions:
+  contents: write
+  pull-requests: write
+  issues: write
+  actions: read
+  id-token: write
+
+jobs:
+  sync:
+    if: github.event.pull_request.merged == true
+    uses: CodySwannGT/lisa/.github/workflows/reusable-claude-sync-down-branches.yml@main
+    with:
+      chain: '{"main":"staging","staging":"dev"}'
+    secrets:
+      CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}

package/typescript/create-only/.github/workflows/claude-sync-down-branches.yml

@@ -0,0 +1,37 @@
+# This file was created by Lisa on first setup.
+# You can customize this file — Lisa will not overwrite it.
+#
+# Back-syncs merges down the env chain so hotfixes propagate.
+# Example: PR merged to main -> opens a sync PR to staging.
+#          PR merged to staging -> opens a sync PR to dev.
+#
+# Customize for your project:
+#   - `branches`: list each branch that should *trigger* a back-sync
+#     (typically the keys of `chain` below).
+#   - `chain`: JSON map of source -> target. Examples:
+#       3-env: '{"main":"staging","staging":"dev"}'
+#       2-env main/staging: '{"main":"staging"}'
+#       2-env master/preprod: '{"master":"preprod"}'
+
+name: Claude Sync Down Branches
+
+on:
+  pull_request:
+    types: [closed]
+    branches: [main, staging]
+
+permissions:
+  contents: write
+  pull-requests: write
+  issues: write
+  actions: read
+  id-token: write
+
+jobs:
+  sync:
+    if: github.event.pull_request.merged == true
+    uses: CodySwannGT/lisa/.github/workflows/reusable-claude-sync-down-branches.yml@main
+    with:
+      chain: '{"main":"staging","staging":"dev"}'
+    secrets:
+      CLAUDE_CODE_OAUTH_TOKEN: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}