spigell
diff --git a/‎.agents/skills/gemini-cli-fork-resyncer/SKILL.md‎
Lines changed: 118 additions & 0 deletions b/‎.agents/skills/gemini-cli-fork-resyncer/SKILL.md‎
Lines changed: 118 additions & 0 deletions
diff --git a/‎.gemini/settings.json‎
Lines changed: 1 addition & 1 deletion b/‎.gemini/settings.json‎
Lines changed: 1 addition & 1 deletion
diff --git a/‎.gemini/skills/docs-changelog/SKILL.md‎
Lines changed: 3 additions & 1 deletion b/‎.gemini/skills/docs-changelog/SKILL.md‎
Lines changed: 3 additions & 1 deletion
diff --git a/‎.gemini/skills/docs-writer/SKILL.md‎
Lines changed: 18 additions & 15 deletions b/‎.gemini/skills/docs-writer/SKILL.md‎
Lines changed: 18 additions & 15 deletions
@@ -0,0 +1,118 @@
+---
+name: gemini-cli-fork-resyncer
+description: >-
+  Updates this fork to a newly released upstream gemini-cli version while
+  preserving fork-specific patches, versioning, and validation gates.
+---
+
+# Procedure: Resync Fork to New Upstream Release
+
+## Objective
+
+Upgrade this fork to a target upstream release tag (for example `v0.40.0`) and
+carry forward fork-specific behavior safely and repeatably.
+
+## Inputs
+
+- `target_tag`: Upstream release tag to sync to (required), for example
+  `v0.39.0`.
+- `fork_version_suffix`: Fork version strategy (required), for example
+  `spigell.YYYYMMDD.<shortsha>`.
+- `fork_patch_source`: Where fork-only patches come from (required):
+  `existing-fork-commits` or `patch-branch`.
+- `validation_level` (optional): `targeted` or `full`.
+
+## Required Safety Rules
+
+- Use `git-mcp` for all git operations.
+- Always run git with full path: `git -C /project/my-shared-infra/my-gemini-cli ...`
+- Do not rewrite remotes.
+- Do not use destructive git commands unless explicitly requested.
+- Preserve unrelated existing work; do not revert user changes.
+
+## Step 1: Baseline and Branch Setup
+
+1. Verify working tree and branch state.
+2. Fetch upstream tag.
+3. Create a branch named:
+   `spigell/chore/update-to-<target_tag_without_v>`
+4. Confirm the tag exists locally and points to the expected upstream commit.
+
+## Step 2: Isolate Fork-Only Delta
+
+1. Compute fork-only diff against the previous synced upstream baseline.
+2. Split fork delta into:
+   - Functional patches (code behavior).
+   - Release/version metadata updates.
+   - Temporary or accidental files (must not be carried).
+3. Build a replay list with commit SHAs or file-scoped patch groups.
+
+## Step 3: Replay Patches onto Target Release
+
+1. Start from the target upstream tag.
+2. Replay only functional fork patches first.
+3. Resolve conflicts with this policy:
+   - Prefer upstream for broad refactors and generated files.
+   - Re-apply fork intent at behavior level, not raw hunk copying.
+   - Keep conflict resolution minimal and auditable.
+4. Ensure no temporary artifacts are introduced (for example `.COMMIT_MSG.txt`).
+
+## Step 4: Normalize Fork Versioning
+
+1. Set versions in root and workspace `package.json` files to:
+   `X.Y.Z-<fork_version_suffix>`.
+2. Update `sandboxImageUri` tags to the same fork version in root and CLI
+   package config where present.
+3. Regenerate lockfile with `npm install --ignore-scripts` if prepare/bundle
+   scripts are unstable during merge state.
+4. Stage all resolved manifest and lockfile changes.
+
+## Step 5: Validate
+
+Minimum validation:
+
+- `npm run build`
+- Targeted tests for fork-modified logic (for example fallback and MCP retry
+  paths).
+
+If `validation_level=full`:
+
+- `npm run test`
+- Optional `npm run preflight` at the end only when needed.
+
+When failures occur:
+
+1. Fix only regressions introduced by replay/conflict resolution.
+2. Re-run the smallest failing scope first.
+3. Re-run full requested validation after targeted fixes pass.
+
+## Step 6: Finalize Merge/Commits
+
+1. Confirm no unresolved conflicts remain.
+2. Create clean commit(s):
+   - Commit A: functional replay/conflict resolutions.
+   - Commit B: fork version/lockfile metadata.
+3. Commit message format:
+   - Line 1: concise summary.
+   - Line 2: blank.
+   - Line 3: why this update was needed and what it preserves.
+
+## Step 7: Push and PR
+
+1. Push branch to origin.
+2. Open/update PR with:
+   - Target upstream tag.
+   - Fork patches carried forward.
+   - Validation commands run and results.
+   - Known residual risks, if any.
+3. If requested, request developer review.
+
+## Output Contract
+
+Always report:
+
+- Target tag synced.
+- Fork patch set applied (list of commits or behavioral groups).
+- Files materially changed by fork logic.
+- Validation status with pass/fail and key errors.
+- Final branch name and push status.
@@ -2,7 +2,7 @@
   "experimental": {
     "extensionReloading": true,
     "modelSteering": true,
-    "memoryManager": false,
+    "memoryManager": true,
     "topicUpdateNarration": true
   },
   "general": {
 
@@ -162,5 +162,7 @@ instructions for the other section.
 
 ## Finalize
 
-- After making changes, run `npm run format` ONLY to ensure consistency.
+- After making changes, if `npm run format` fails, it may be necessary to run
+  `npm install` first to ensure all formatting dependencies are available.
+  Then, run `npm run format` to ensure consistency.
 - Delete any temporary files created during the process.
@@ -1,7 +1,7 @@
 ---
 name: docs-writer
 description:
-  Always use this skill when the task involves writing, reviewing, or editing 
+  Always use this skill when the task involves writing, reviewing, or editing
   files in the `/docs` directory or any `.md` files in the repository.
 ---
 
@@ -24,7 +24,7 @@ approach.
 
 - **Perspective and tense:** Address the reader as "you." Use active voice and
   present tense (e.g., "The API returns...").
-- **Tone:** Professional, friendly, and direct. 
+- **Tone:** Professional, friendly, and direct.
 - **Clarity:** Use simple vocabulary. Avoid jargon, slang, and marketing hype.
 - **Global Audience:** Write in standard US English. Avoid idioms and cultural
   references.
@@ -47,8 +47,8 @@ Write precisely to ensure your instructions are unambiguous.
   "foo" or "bar."
 - **Quota and limit terminology:** For any content involving resource capacity
   or using the word "quota" or "limit", strictly adhere to the guidelines in
-  the `quota-limit-style-guide.md` resource file. Generally, Use "quota" for the
-  administrative bucket and "limit" for the numerical ceiling.
+  the `quota-limit-style-guide.md` resource file. Generally, Use "quota" for
+  the administrative bucket and "limit" for the numerical ceiling.
 
 ### Formatting and syntax
 Apply consistent formatting to make documentation visually organized and
@@ -120,7 +120,7 @@ accessible.
 > This is an experimental feature currently under active development.
 
 - **Headings:** Use hierarchical headings to support the user journey.
-- **Procedures:** 
+- **Procedures:**
   - Introduce lists of steps with a complete sentence.
   - Start each step with an imperative verb.
   - Number sequential steps; use bullets for non-sequential lists.
@@ -134,7 +134,7 @@ accessible.
 
 ## Phase 2: Preparation
 Before modifying any documentation, thoroughly investigate the request and the
-surrounding context. 
+surrounding context.
 
 1.  **Clarify:** Understand the core request. Differentiate between writing new
     content and editing existing content. If the request is ambiguous (e.g.,
@@ -145,6 +145,8 @@ surrounding context.
 4.  **Connect:** Identify all referencing pages if changing behavior. Check if
     `docs/sidebar.json` needs updates.
 5.  **Plan:** Create a step-by-step plan before making changes.
+6.  **Audit Docset:** If asked to audit the documentation, follow the procedural
+    guide in [docs-auditing.md](./references/docs-auditing.md).
 
 ## Phase 3: Execution
 Implement your plan by either updating existing files or creating new ones
@@ -157,7 +159,7 @@ documentation.
 
 - **Gaps:** Identify areas where the documentation is incomplete or no longer
   reflects existing code.
-- **Structure:** Apply "Structure (New Docs)" rules (BLUF, headings, etc.) when 
+- **Structure:** Apply "Structure (New Docs)" rules (BLUF, headings, etc.) when
   adding new sections to existing pages.
 - **Headers**: If you change a header, you must check for links that lead to
   that header and update them.
@@ -168,15 +170,16 @@ documentation.
   documents.
 
 ## Phase 4: Verification and finalization
-Perform a final quality check to ensure that all changes are correctly formatted
-and that all links are functional.
+Perform a final quality check to ensure that all changes are correctly
+formatted and that all links are functional.
 
 1.  **Accuracy:** Ensure content accurately reflects the implementation and
   technical behavior.
 2.  **Self-review:** Re-read changes for formatting, correctness, and flow.
-3.  **Link check:** Verify all new and existing links leading to or from modified
-    pages. If you changed a header, ensure that any links that lead to it are
-    updated.
-4.  **Format:** Once all changes are complete, ask to execute `npm run format`
-    to ensure consistent formatting across the project. If the user confirms,
-    execute the command.
+3.  **Link check:** Verify all new and existing links leading to or from
+    modified pages. If you changed a header, ensure that any links that lead to
+    it are updated.
+4.  **Format:** If `npm run format` fails, it may be necessary to run `npm
+    install` first to ensure all formatting dependencies are available. Once all
+    changes are complete, ask to execute `npm run format` to ensure consistent
+    formatting across the project. If the user confirms, execute the command.