@ikon85/agent-workflow-kit 0.34.4 → 0.34.6

package/.agents/skills/kit-release/SKILL.md

@@ -1,14 +1,18 @@
 ---
 name: kit-release
-description: "Prepare and integrate a verified agent-workflow-kit release, then record separately confirmed publication intent with an annotated version tag and monitor npm/GitHub parity."
+description: "Prepare, integrate and publish a verified agent-workflow-kit release: one confirmed Semver authorizes the annotated version tag, then monitor npm/GitHub parity to released."
 ---
 
 # Kit Release
 
 Prepare a release deterministically. This skill owns the shipped-delta decision,
-metadata preparation, verification, and the separate post-merge publication
-gate. It delegates commit, branch push, PR, merge, and cleanup to wrapup. It
-never publishes to a registry or creates a GitHub release directly.
+metadata preparation, verification, and the post-merge publication intent. It
+delegates commit, branch push, PR, merge, and cleanup to wrapup. It never
+publishes to a registry or creates a GitHub release by hand — it records intent
+with the annotated tag and lets the trusted workflow publish.
+
+The release has **one** human gate: the confirmed Semver in step 2. Everything
+after it — merge, tag, publish, parity check — is the agent's to carry out.
 
 ## Workflow
 
@@ -33,8 +37,8 @@ never publishes to a registry or creates a GitHub release directly.
      Do not turn a narrower build-only or single-action request into this
      authority.
 
-   Both routes authorize one prepared target only. Neither authorizes
-   publication.
+   Either route authorizes exactly one target — and that authorization carries
+   through to its tag and publish. This is the release's single human gate.
 
 3. Prepare that authorized exact version:
 
@@ -52,21 +56,25 @@ never publishes to a registry or creates a GitHub release directly.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, report the exact integrated version and commit as
-   `awaiting-tag`. Merging integrates the prepared release; it cannot start
-   publication. Creating and pushing the annotated `v<version>` tag requires a
-   **separate explicit confirmation** to publish that exact version. The
-   earlier Semver confirmation or AFK preparation mandate authorized metadata
-   preparation, not publication.
-
-6. After that confirmation, verify that the package version on current
-   `origin/main` is exactly `<version>`. Create a matching annotated
-   `v<version>` tag on that commit and push only that tag. A lightweight tag,
-   mismatching version, or commit outside canonical `main` is invalid release
-   intent. Never infer a tag target, move an existing tag, or tag an unmerged
-   commit.
-
-7. Monitor the tag-triggered `release.yml` workflow and inspect its externally
+5. Publish. Merging integrates the prepared release; only the annotated tag
+   starts publication. Verify that the package version on current `origin/main`
+   is exactly `<version>`, then create and push the matching annotated
+   `v<version>` tag — **the confirmed Semver authorizes the whole release,
+   through tag and publish, so do this without asking again**. The target was
+   chosen once, at step 2; nothing between there and here produces information
+   a second gate could act on. Report the integrated commit as you tag it, not
+   as a question.
+
+   Publication is **irreversible** — npm versions cannot be reused, and the
+   unpublish window is narrow and breaks consumers. The safety lives in gates
+   that already ran, not in a prompt: `release:guard`, `kit:staleness`, the full
+   suite and `npm pack --dry-run` before merge, then the workflow's own tag
+   identity, package version, main ancestry and artifact checks after it. A
+   lightweight tag, a mismatching version, or a commit outside canonical `main`
+   is invalid release intent. Never infer a tag target, move an existing tag, or
+   tag an unmerged commit.
+
+6. Monitor the tag-triggered `release.yml` workflow and inspect its externally
    reconstructable state:
 
    ```sh

package/.agents/skills/kit-update/SKILL.md

@@ -30,9 +30,12 @@ release contain the same artifact.
    ```
 
    The command checks npm/GitHub release parity before staging. It prepares a
-   complete candidate outside the consumer, runs the consumer's existing
-   `npm test` command there, and activates only a verified candidate. A staging
-   or verification failure leaves the installed tree byte-identical.
+   complete manifest-bounded candidate outside the Consumer, verifies the
+   Kit-owned manifest, artifact, protocol, schema/reference, syntax, and
+   transaction invariants, and activates only that verified candidate. It
+   never runs a Consumer package script, configurable verification command, or
+   legacy fallback. A staging or verification failure leaves the installed
+   tree byte-identical.
 
    The staged candidate also adopts the current readiness schema without
    invoking `setup-workflow`: it preserves explicit readiness decisions and

package/.agents/skills/setup-workflow/SKILL.md

@@ -81,11 +81,19 @@ Seed `docs/agents/issue-tracker.md` from the matching template in this folder: [
 
 ### 2a. Automatic Kit update pull requests (GitHub tracker only)
 
-> A short scheduled check can keep the installed Kit current by opening one normal pull request after the candidate passes the consumer's own tests. It never merges the pull request for you.
-
-Only after the user has confirmed a **GitHub tracker**, ask in plain language: *"Should GitHub check weekly for a tested Agent Workflow Kit update and keep one update pull request ready?"* Offer these explicit choices:
-
-Before offering **Enable**, confirm the consumer has a committed `package-lock.json` and a usable `package.json` `npm test` command. The shipped workflow installs the locked dependencies with `npm ci --ignore-scripts`; without that lockfile/test contract it cannot prove the candidate in a clean checkout, so explain the prerequisite and do not create the workflow yet.
+> A short scheduled check can keep the installed Kit current by opening one
+> normal pull request after the candidate passes the built-in Kit invariant
+> validator. It runs no Consumer package script and never merges the pull
+> request for you.
+
+Only after the user has confirmed a **GitHub tracker**, ask in plain language:
+*"Should GitHub check weekly for a verified Agent Workflow Kit update and keep
+one update pull request ready?"* Offer these explicit choices:
+
+Before offering **Enable**, explain that the update command uses the same
+built-in Kit invariant validator as manual and agent-driven updates. There is
+no Consumer package script, lockfile, configurable verification profile, or
+legacy test fallback prerequisite.
 
 Also read the repository Actions policy before enabling:
 

package/.agents/skills/setup-workflow/assets/agent-workflow-kit-update.yml

@@ -23,9 +23,7 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: 22.14
-      - name: Install locked consumer dependencies
-        run: npm ci --ignore-scripts
-      - name: Verify, test, and upsert the Kit update pull request
+      - name: Verify and upsert the Kit update pull request
         env:
           GH_TOKEN: ${{ github.token }}
         run: npx --yes --package=@ikon85/agent-workflow-kit@latest agent-workflow-kit-update-pr

package/.claude/skills/kit-release/SKILL.md

@@ -1,14 +1,18 @@
 ---
 name: kit-release
-description: "Prepare and integrate a verified agent-workflow-kit release, then record separately confirmed publication intent with an annotated version tag and monitor npm/GitHub parity."
+description: "Prepare, integrate and publish a verified agent-workflow-kit release: one confirmed Semver authorizes the annotated version tag, then monitor npm/GitHub parity to released."
 ---
 
 # Kit Release
 
 Prepare a release deterministically. This skill owns the shipped-delta decision,
-metadata preparation, verification, and the separate post-merge publication
-gate. It delegates commit, branch push, PR, merge, and cleanup to wrapup. It
-never publishes to a registry or creates a GitHub release directly.
+metadata preparation, verification, and the post-merge publication intent. It
+delegates commit, branch push, PR, merge, and cleanup to wrapup. It never
+publishes to a registry or creates a GitHub release by hand — it records intent
+with the annotated tag and lets the trusted workflow publish.
+
+The release has **one** human gate: the confirmed Semver in step 2. Everything
+after it — merge, tag, publish, parity check — is the agent's to carry out.
 
 ## Workflow
 
@@ -33,8 +37,8 @@ never publishes to a registry or creates a GitHub release directly.
      Do not turn a narrower build-only or single-action request into this
      authority.
 
-   Both routes authorize one prepared target only. Neither authorizes
-   publication.
+   Either route authorizes exactly one target — and that authorization carries
+   through to its tag and publish. This is the release's single human gate.
 
 3. Prepare that authorized exact version:
 
@@ -52,21 +56,25 @@ never publishes to a registry or creates a GitHub release directly.
    `scripts/wrapup-land.py` exclusively own commit, push, PR creation, merge,
    and cleanup. Do not reproduce those operations here.
 
-5. After merge, report the exact integrated version and commit as
-   `awaiting-tag`. Merging integrates the prepared release; it cannot start
-   publication. Creating and pushing the annotated `v<version>` tag requires a
-   **separate explicit confirmation** to publish that exact version. The
-   earlier Semver confirmation or AFK preparation mandate authorized metadata
-   preparation, not publication.
-
-6. After that confirmation, verify that the package version on current
-   `origin/main` is exactly `<version>`. Create a matching annotated
-   `v<version>` tag on that commit and push only that tag. A lightweight tag,
-   mismatching version, or commit outside canonical `main` is invalid release
-   intent. Never infer a tag target, move an existing tag, or tag an unmerged
-   commit.
-
-7. Monitor the tag-triggered `release.yml` workflow and inspect its externally
+5. Publish. Merging integrates the prepared release; only the annotated tag
+   starts publication. Verify that the package version on current `origin/main`
+   is exactly `<version>`, then create and push the matching annotated
+   `v<version>` tag — **the confirmed Semver authorizes the whole release,
+   through tag and publish, so do this without asking again**. The target was
+   chosen once, at step 2; nothing between there and here produces information
+   a second gate could act on. Report the integrated commit as you tag it, not
+   as a question.
+
+   Publication is **irreversible** — npm versions cannot be reused, and the
+   unpublish window is narrow and breaks consumers. The safety lives in gates
+   that already ran, not in a prompt: `release:guard`, `kit:staleness`, the full
+   suite and `npm pack --dry-run` before merge, then the workflow's own tag
+   identity, package version, main ancestry and artifact checks after it. A
+   lightweight tag, a mismatching version, or a commit outside canonical `main`
+   is invalid release intent. Never infer a tag target, move an existing tag, or
+   tag an unmerged commit.
+
+6. Monitor the tag-triggered `release.yml` workflow and inspect its externally
    reconstructable state:
 
    ```sh

package/.claude/skills/kit-update/SKILL.md

@@ -30,9 +30,12 @@ release contain the same artifact.
    ```
 
    The command checks npm/GitHub release parity before staging. It prepares a
-   complete candidate outside the consumer, runs the consumer's existing
-   `npm test` command there, and activates only a verified candidate. A staging
-   or verification failure leaves the installed tree byte-identical.
+   complete manifest-bounded candidate outside the Consumer, verifies the
+   Kit-owned manifest, artifact, protocol, schema/reference, syntax, and
+   transaction invariants, and activates only that verified candidate. It
+   never runs a Consumer package script, configurable verification command, or
+   legacy fallback. A staging or verification failure leaves the installed
+   tree byte-identical.
 
    The staged candidate also adopts the current readiness schema without
    invoking `setup-workflow`: it preserves explicit readiness decisions and

package/.claude/skills/setup-workflow/SKILL.md

@@ -81,11 +81,19 @@ Seed `docs/agents/issue-tracker.md` from the matching template in this folder: [
 
 ### 2a. Automatic Kit update pull requests (GitHub tracker only)
 
-> A short scheduled check can keep the installed Kit current by opening one normal pull request after the candidate passes the consumer's own tests. It never merges the pull request for you.
-
-Only after the user has confirmed a **GitHub tracker**, ask in plain language: *"Should GitHub check weekly for a tested Agent Workflow Kit update and keep one update pull request ready?"* Offer these explicit choices:
-
-Before offering **Enable**, confirm the consumer has a committed `package-lock.json` and a usable `package.json` `npm test` command. The shipped workflow installs the locked dependencies with `npm ci --ignore-scripts`; without that lockfile/test contract it cannot prove the candidate in a clean checkout, so explain the prerequisite and do not create the workflow yet.
+> A short scheduled check can keep the installed Kit current by opening one
+> normal pull request after the candidate passes the built-in Kit invariant
+> validator. It runs no Consumer package script and never merges the pull
+> request for you.
+
+Only after the user has confirmed a **GitHub tracker**, ask in plain language:
+*"Should GitHub check weekly for a verified Agent Workflow Kit update and keep
+one update pull request ready?"* Offer these explicit choices:
+
+Before offering **Enable**, explain that the update command uses the same
+built-in Kit invariant validator as manual and agent-driven updates. There is
+no Consumer package script, lockfile, configurable verification profile, or
+legacy test fallback prerequisite.
 
 Also read the repository Actions policy before enabling:
 

package/.claude/skills/setup-workflow/assets/agent-workflow-kit-update.yml

@@ -23,9 +23,7 @@ jobs:
       - uses: actions/setup-node@v4
         with:
           node-version: 22.14
-      - name: Install locked consumer dependencies
-        run: npm ci --ignore-scripts
-      - name: Verify, test, and upsert the Kit update pull request
+      - name: Verify and upsert the Kit update pull request
         env:
           GH_TOKEN: ${{ github.token }}
         run: npx --yes --package=@ikon85/agent-workflow-kit@latest agent-workflow-kit-update-pr

package/README.md

@@ -387,6 +387,21 @@ the old way. Decision record:
 
 ## Release notes
 
+### 0.34.6
+
+- changed: `.agents/skills/kit-release/SKILL.md`
+- changed: `.claude/skills/kit-release/SKILL.md`
+
+### 0.34.5
+
+- changed: `.agents/skills/kit-update/SKILL.md`
+- changed: `.agents/skills/setup-workflow/SKILL.md`
+- changed: `.agents/skills/setup-workflow/assets/agent-workflow-kit-update.yml`
+- changed: `.claude/skills/kit-update/SKILL.md`
+- changed: `.claude/skills/setup-workflow/SKILL.md`
+- changed: `.claude/skills/setup-workflow/assets/agent-workflow-kit-update.yml`
+- changed: `scripts/kit-update-pr.mjs`
+
 ### 0.34.4
 
 - changed: `.agents/skills/kit-release/SKILL.md`

package/agent-workflow-kit.package.json

@@ -1,5 +1,5 @@
 {
-  "kitVersion": "0.34.4",
+  "kitVersion": "0.34.6",
   "files": [
     {
       "path": ".agents/skills/ask-matt/SKILL.md",
@@ -367,7 +367,7 @@
       "ownerSkill": "kit-release",
       "surface": "codex",
       "installRole": "maintainer",
-      "sha256": "f584caa1753ed34de584418a4176015cc3e2382db06efae488bb6d785eab71b7",
+      "sha256": "38a3df1f9d4b5573180dc67daba85eb3fd143ae3b60ca6dbfed3297d6a0855cd",
       "mode": 420,
       "origin": "kit"
     },
@@ -377,7 +377,7 @@
       "ownerSkill": "kit-update",
       "surface": "codex",
       "installRole": "consumer",
-      "sha256": "c3487295864d1d8d765e1c453c80daf77d3f08a2b0017f614e44e85170913624",
+      "sha256": "9129e14b12b573546e253e14be3b7793afe2ca2b46102bb7b5f2ec1a8276a1ec",
       "mode": 420,
       "origin": "kit"
     },
@@ -577,7 +577,7 @@
       "ownerSkill": "setup-workflow",
       "surface": "codex",
       "installRole": "consumer",
-      "sha256": "d8abf995d67184b4459b9565c9062319fc42e8a685042b288b3066a07a6fda59",
+      "sha256": "dcabda3d93b7c79f35065a9f3130807ff29737e15187a68fdbc37533015d461d",
       "mode": 420,
       "origin": "kit"
     },
@@ -677,7 +677,7 @@
       "ownerSkill": "setup-workflow",
       "surface": "codex",
       "installRole": "consumer",
-      "sha256": "7281bb67588328aa4a788cbefe69f396c4617569335ce47cfb45bb5607d3205e",
+      "sha256": "0f098f6efeda6682726d918135f0a66ffbf9c90616293fd3833d5fe47fc5c927",
       "mode": 420,
       "origin": "kit"
     },
@@ -1679,7 +1679,7 @@
       "ownerSkill": "kit-release",
       "surface": "claude",
       "installRole": "maintainer",
-      "sha256": "f584caa1753ed34de584418a4176015cc3e2382db06efae488bb6d785eab71b7",
+      "sha256": "38a3df1f9d4b5573180dc67daba85eb3fd143ae3b60ca6dbfed3297d6a0855cd",
       "mode": 420,
       "origin": "kit"
     },
@@ -1689,7 +1689,7 @@
       "ownerSkill": "kit-update",
       "surface": "claude",
       "installRole": "consumer",
-      "sha256": "c3487295864d1d8d765e1c453c80daf77d3f08a2b0017f614e44e85170913624",
+      "sha256": "9129e14b12b573546e253e14be3b7793afe2ca2b46102bb7b5f2ec1a8276a1ec",
       "mode": 420,
       "origin": "kit"
     },
@@ -1909,7 +1909,7 @@
       "ownerSkill": "setup-workflow",
       "surface": "claude",
       "installRole": "consumer",
-      "sha256": "d8abf995d67184b4459b9565c9062319fc42e8a685042b288b3066a07a6fda59",
+      "sha256": "dcabda3d93b7c79f35065a9f3130807ff29737e15187a68fdbc37533015d461d",
       "mode": 420,
       "origin": "kit"
     },
@@ -2009,7 +2009,7 @@
       "ownerSkill": "setup-workflow",
       "surface": "claude",
       "installRole": "consumer",
-      "sha256": "7281bb67588328aa4a788cbefe69f396c4617569335ce47cfb45bb5607d3205e",
+      "sha256": "0f098f6efeda6682726d918135f0a66ffbf9c90616293fd3833d5fe47fc5c927",
       "mode": 420,
       "origin": "kit"
     },
@@ -2535,7 +2535,7 @@
       "path": "scripts/kit-update-pr.mjs",
       "kind": "script",
       "installRole": "consumer",
-      "sha256": "83f30a4ca938171cfa2f4153917813fae40bf2a906940e047c7066d18284209b",
+      "sha256": "c28bbd5a45583a92eca12758c1d626e04bce820300178b54933340759d1690fd",
       "mode": 493,
       "origin": "kit"
     },

package/docs/adr/0001-consumer-divergence-policy.md

@@ -2,6 +2,10 @@
 
 Status: accepted (2026-07-18, issue #130)
 
+Partially superseded by ADR-0003: consumer ownership remains valid for genuine
+project files, but no longer applies to Kit Core or to mixed core/extension
+registries.
+
 Since the consumer-source cutover the kit is SSOT for shipped files, but
 consumers keep learning: edits made directly on a shipped file in a consumer
 silently fork it, and every subsequent `kit-update` reports a permanent

package/docs/adr/0003-kit-core-and-project-extension-lifecycle.md

@@ -0,0 +1,63 @@
+# Kit Core and project extensions have separate identities
+
+Status: accepted (2026-07-22, issues #190, #194, #196, #197)
+
+The original divergence policy allowed any shipped path to become
+consumer-owned. That is safe for a genuinely project-specific file, but not for
+a protocol authority such as the skill/readiness registry: once a consumer
+owns that mixed file, new Kit declarations stop arriving while local additions
+and stale Kit declarations remain indistinguishable. A real consumer exhibited
+exactly this state: the installed readiness harness was current while its owned
+registry had no readiness capabilities or declarations.
+
+We decided to model four explicit lifecycle states instead of treating every
+local difference as file ownership:
+
+1. **Kit Core** remains upstream-owned under the Kit's canonical identity. A
+   consumer cannot permanently own it under that same identity.
+2. **Project extensions** live on separate consumer-owned surfaces. Every
+   shipped skill may load its optional `docs/agents/skills/<skill>.md`; local
+   skill identities live in a separate local registry. Neither surface changes
+   the corresponding Kit Core.
+3. A **Contribution bridge** may temporarily retain a registered local Core
+   experiment. It must resolve into a project extension, a generalized upstream
+   contribution that returns in a release, or an explicit fork.
+4. An **Explicit fork** has its own identity, version, and update line. Semantic
+   divergence cannot masquerade indefinitely as the canonical Kit skill.
+
+An update composes and validates the complete protocol group in an isolated,
+manifest-derived staged candidate. It never infers an ownership decision from
+`--yes`: an unclassified collision blocks unchanged until a user classifies it.
+Existing mixed states migrate semantically, preserving local identities and
+project metadata on their new surfaces; an ambiguous semantic change blocks
+instead of being overwritten or frozen silently.
+
+The upstream route is capability-based, not maintainer-specific. At the moment
+of contribution, repository permissions and an optional machine-local upstream
+checkout determine whether the approved route can use a direct pull request, a
+fork, or an issue. No consumer asks who the user is, and no telemetry reports
+local edits automatically.
+
+## Considered options
+
+- **Keep arbitrary consumer-owned shipped paths:** rejected because a protocol
+  authority then stops receiving schema and behavior evolution under the same
+  identity.
+- **Add more merge rules to the mixed registry:** rejected because local skills,
+  project annotations, readiness declarations, and upstream skill definitions
+  have different ownership and lifecycle semantics.
+- **Overwrite Core and discard local changes:** rejected because it loses valid
+  project behavior and can destroy unregistered work.
+- **Special-case the maintainer:** rejected because identity is irrelevant; the
+  portable distinction is whether the user has an approved route and the
+  required repository capabilities.
+
+## Consequences
+
+- ADR-0001 remains valid for genuine consumer-owned files but is narrowed for
+  Kit Core and mixed registries.
+- Core updates can advance without erasing project-specific behavior.
+- Consumers gain explicit extension, contribution, and fork lifecycles instead
+  of permanent accidental divergence.
+- Migration requires a one-time semantic classification of existing mixed
+  states and must fail closed when that classification is ambiguous.

package/docs/adr/0004-release-intent-is-a-version-tag.md

@@ -6,6 +6,17 @@ Clarified 2026-07-25 by issue #239: an explicit AFK end-to-end mandate may
 authorize deterministic reversible release preparation, but never the
 publication tag itself.
 
+Amended 2026-07-25 by issue #257: the confirmed Semver authorizes the whole
+release, through tag and publish. The separation of integration and publication
+below is unchanged — merging still cannot publish, and only an annotated tag
+records release intent — but that intent no longer waits for a second human
+confirmation. The maintainer chooses the version once; the agent then merges,
+tags, and monitors to `released`. The second gate had proven worse than no gate:
+it left prepared versions sitting in `awaiting-tag` until someone returned,
+which is how 0.34.2 was skipped and buried under 0.34.3 (#243). Safety stays in
+the gates that run regardless of who is watching — guard, staleness, suite,
+pack, and the workflow's own tag/version/ancestry validation.
+
 The release workflow currently publishes whenever a merge to `main` changes
 `package.json`. That keeps the canonical branch and npm close together, but it
 also makes an ordinary merge an irreversible public action whose consequence is
@@ -39,11 +50,13 @@ We decided that integration and publication are separate transitions:
 
 ## Consequences
 
-- A prepared version may temporarily exist on `main` in an `awaiting-tag` state.
-- An explicit AFK Wave/Program mandate may cover the deterministic reversible
-  metadata preparation and landing that it names. It never by itself authorizes
-  creating or pushing the publication tag; that irreversible action requires a
-  separate explicit confirmation.
+- A prepared version exists on `main` in an `awaiting-tag` state only for as
+  long as the agent needs to tag it — not until a human returns (amended by
+  #257).
+- The authorizing act is the confirmed Semver. An explicit AFK Wave/Program
+  mandate that names release preparation carries the same weight, and either
+  route reaches through tag and publish for that one target. A narrower
+  build-only or single-action request never becomes this authority.
 - A single-Wave mandate does not authorize the next Program Wave. A later
   explicit whole-Program mandate does authorize all planned Waves and remains in
   force across their boundaries.

package/docs/agents/board-sync.md

@@ -65,7 +65,7 @@ The workflow board is [Agent Workflow Kit](https://github.com/users/iKon85/proje
     "wavePrefix": "Welle"
   },
   "wrapup": {
-    "remoteBranchSweep": false
+    "remoteBranchSweep": true
   }
 }
 ```

package/docs/agents/workflow-capabilities.json

@@ -0,0 +1,17 @@
+{
+  "worktreeLifecycle": {
+    "enabled": true,
+    "worktreeRoot": ".worktrees",
+    "branchTemplate": "{type}/{issue}-{slug}",
+    "pathTemplate": "{issue}-{slug}",
+    "branchRegex": "^(?:feat|fix|chore|docs)/(?P<issue>\\d+)-",
+    "mainBranches": ["main"],
+    "protectedBranches": ["main"],
+    "setupEntry": "python3 scripts/worktree-lifecycle/setup.py",
+    "setupSteps": [],
+    "riskyCommandPatterns": [
+      "\\b(?:npm|pnpm|yarn)\\s+(?:run\\s+)?(?:test|typecheck|build)\\b",
+      "\\bgit\\s+(?:commit|push)\\b"
+    ]
+  }
+}