@laitszkin/apollo-toolkit 2.7.0 → 2.9.0

package/AGENTS.md

@@ -4,8 +4,8 @@
 
 - This repository is a skill catalog: each top-level skill lives in its own directory and is installable when that directory contains `SKILL.md`.
 - Typical skill layout is lightweight and consistent: `SKILL.md`, `README.md`, `LICENSE`, plus optional `agents/`, `references/`, and `scripts/`.
-- The npm package exposes an `apollo-toolkit` CLI that stages a managed copy under `~/.apollo-toolkit` and links each skill folder into selected target directories.
-- `scripts/install_skills.sh` and `scripts/install_skills.ps1` remain available for local/curl installs and mirror the managed-home linking behavior.
+- The npm package exposes an `apollo-toolkit` CLI that stages a managed copy under `~/.apollo-toolkit` and copies each skill folder into selected target directories.
+- `scripts/install_skills.sh` and `scripts/install_skills.ps1` remain available for local/curl installs and mirror the managed-home copy behavior.
 
 ## Core Business Flow
 
@@ -20,7 +20,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can research a topic deeply and produce evidence-based deliverables.
 - Users can research the latest completed market week and produce a PDF watchlist of tradeable instruments for the coming week.
 - Users can turn a marked weekly finance PDF into a concise evidence-based financial event report.
-- Users can install Apollo Toolkit through npm or npx and interactively choose one or more target skill directories to link.
+- Users can install Apollo Toolkit through npm or npx and interactively choose one or more target skill directories to populate with copied skills.
 - Users can design and implement new features through a spec-first workflow.
 - Users can generate shared feature spec, task, and checklist planning artifacts for approval-gated workflows.
 - Users can convert text or documents into audio files with subtitle timelines.
@@ -44,6 +44,7 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can process GitHub pull request review comments and resolve addressed threads.
 - Users can perform repository-wide code reviews and publish confirmed findings as GitHub issues.
 - Users can schedule a bounded project runtime window, stop it automatically, and analyze module health from captured logs.
+- Users can investigate gated or shadow LLM APIs by capturing real client request shapes, replaying verified traffic patterns, and attributing the likely underlying model through black-box fingerprinting.
 - Users can build and maintain Solana programs and Rust clients using official Solana development workflows.
 - Users can add focused observability to opaque workflows through targeted logs, metrics, traces, and tests.
 - Users can build against Jupiter's official Solana swap, token, price, lending, trigger, recurring, and portfolio APIs with an evidence-based development guide.

package/CHANGELOG.md

@@ -4,6 +4,19 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [v2.9.0] - 2026-03-21
+
+### Changed
+- Update `scheduled-runtime-health-check` to run requested commands in a background terminal immediately or within a requested time window, with optional pre-run safe updates and optional post-run log findings.
+- Update `open-github-issue` to require explicit BDD-style expected behavior, current behavior, and behavior-gap content for problem issues, and enforce that contract in the bundled publisher script and docs.
+
+## [v2.8.0] - 2026-03-21
+
+### Changed
+- Change the npm installer and local install scripts to copy managed skill directories into selected targets instead of creating symlinks.
+- Replace legacy Apollo Toolkit symlink installs with real copied skill directories during reinstall, while still removing stale skills that no longer ship in the current version.
+- Normalize every repository `LICENSE` file to the MIT template owned by `LaiTszKin`.
+
 ## [v2.7.0] - 2026-03-20
 
 ### Added

package/README.md

@@ -1,6 +1,6 @@
 # Apollo Toolkit Skills
 
-A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer that keeps the toolkit in `~/.apollo-toolkit` and links each skill into the targets you choose.
+A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer that keeps the toolkit in `~/.apollo-toolkit` and copies each skill into the targets you choose.
 
 ## Included skills
 
@@ -37,6 +37,7 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - review-change-set
 - review-codebases
 - scheduled-runtime-health-check
+- shadow-api-model-research
 - solana-development
 - systematic-debug
 - text-to-short-video
@@ -56,8 +57,9 @@ The interactive installer:
 - shows a branded `Apollo Toolkit` terminal welcome screen with a short staged reveal
 - installs a managed copy into `~/.apollo-toolkit`
 - lets you multi-select `codex`, `openclaw`, `trae`, or `all`
-- creates symlinks from `~/.apollo-toolkit/<skill>` into each selected target
-- in the same npm/npx install flow, removes stale linked skills that existed in the previous installed version but no longer exist in the current package skill list
+- copies `~/.apollo-toolkit/<skill>` into each selected target
+- removes stale previously installed skill directories that existed in the previous installed version but no longer exist in the current package skill list
+- replaces legacy symlink-based installs created by older Apollo Toolkit installers with real copied directories
 
 ### Global install
 

package/analyse-app-logs/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/archive-specs/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/commit-and-push/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/develop-new-features/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/docs-to-voice/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 tszkinlai
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/enhance-existing-features/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/feature-propose/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 tszkinlai
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/generate-spec/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/learn-skill-from-conversations/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Yamiyorunoshura
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
@@ -19,4 +19,3 @@ 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/lib/cli.js

@@ -67,8 +67,8 @@ function buildWelcomeScreen({ version, colorEnabled, stage = 4 }) {
       '',
       'This setup will configure:',
       `  ${color('*', '1;33', colorEnabled)} A managed Apollo Toolkit home in ${color('~/.apollo-toolkit', '1', colorEnabled)}`,
-      `  ${color('*', '1;33', colorEnabled)} Symlinked skill folders for your selected targets`,
-      `  ${color('*', '1;33', colorEnabled)} A clean install flow with target-aware linking`,
+      `  ${color('*', '1;33', colorEnabled)} Copied skill folders for your selected targets`,
+      `  ${color('*', '1;33', colorEnabled)} A clean install flow with target-aware replacement`,
     );
   }
 
@@ -178,7 +178,7 @@ function renderSelectionScreen({ output, version, cursor, selected, message, env
 
   clearScreen(output);
   output.write(`${buildBanner({ version, colorEnabled })}\n\n`);
-  output.write('Choose where Apollo Toolkit should create symlinked skills.\n');
+  output.write('Choose where Apollo Toolkit should copy managed skills.\n');
   output.write(`${color('Use Up/Down', '1;33', colorEnabled)} (or ${color('j/k', '1;33', colorEnabled)}) to move, ${color('Space', '1;33', colorEnabled)} to toggle, ${color('Enter', '1;33', colorEnabled)} to continue.\n`);
   output.write(`Press ${color('a', '1;33', colorEnabled)} to toggle all, ${color('q', '1;33', colorEnabled)} to cancel.\n\n`);
 
@@ -329,7 +329,7 @@ function printSummary({ stdout, version, toolkitHome, modes, installResult, env
   stdout.write(color('Installation complete.', '1;32', colorEnabled));
   stdout.write('\n');
   stdout.write(`Apollo Toolkit home: ${toolkitHome}\n`);
-  stdout.write(`Linked skills: ${installResult.skillNames.length}\n`);
+  stdout.write(`Installed skills: ${installResult.skillNames.length}\n`);
   stdout.write(`Targets: ${modes.join(', ')}\n\n`);
 
   for (const target of installResult.targets) {

package/lib/installer.js

@@ -185,18 +185,16 @@ async function ensureDirectory(dirPath) {
   await fsp.mkdir(dirPath, { recursive: true });
 }
 
-async function replaceWithSymlink(sourcePath, targetPath) {
+async function replaceWithCopy(sourcePath, targetPath) {
   await fsp.rm(targetPath, { recursive: true, force: true });
   await ensureDirectory(path.dirname(targetPath));
-
-  const type = process.platform === 'win32' ? 'junction' : 'dir';
-  await fsp.symlink(sourcePath, targetPath, type);
+  await fsp.cp(sourcePath, targetPath, { recursive: true, force: true });
 }
 
 async function installLinks({ toolkitHome, modes, env = process.env, previousSkillNames = [] }) {
   const skillNames = await listSkillNames(toolkitHome);
   const targets = await getTargetRoots(modes, env);
-  const linkedPaths = [];
+  const copiedPaths = [];
   const staleSkillNames = previousSkillNames.filter((skillName) => !skillNames.includes(skillName));
 
   for (const target of targets) {
@@ -207,15 +205,15 @@ async function installLinks({ toolkitHome, modes, env = process.env, previousSki
     for (const skillName of skillNames) {
       const sourcePath = path.join(toolkitHome, skillName);
       const targetPath = path.join(target.root, skillName);
-      await replaceWithSymlink(sourcePath, targetPath);
-      linkedPaths.push({ target: target.label, path: targetPath, skillName });
+      await replaceWithCopy(sourcePath, targetPath);
+      copiedPaths.push({ target: target.label, path: targetPath, skillName });
     }
   }
 
   return {
     skillNames,
     targets,
-    linkedPaths,
+    copiedPaths,
   };
 }
 

package/novel-to-short-video/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Yamiyorunoshura
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/open-github-issue/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Tsz Kin Lai
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/open-github-issue/README.md

@@ -42,7 +42,7 @@ The bundled script can also be called directly:
 python scripts/open_github_issue.py \
   --issue-type problem \
   --title "[Log] Payment timeout spike" \
-  --problem-description "Repeated timeout warnings escalated into request failures during the incident window." \
+  --problem-description $'Expected Behavior (BDD)\nGiven the payment service sees transient upstream latency\nWhen the retry path runs\nThen requests should recover without user-visible failures\n\nCurrent Behavior (BDD)\nGiven the payment service sees transient upstream latency\nWhen the retry path runs\nThen repeated timeout warnings still escalate into request failures\n\nBehavior Gap\n- Expected: retries absorb transient upstream slowness.\n- Actual: retries still end in request failures.\n- Difference/Impact: customers receive failed payment attempts during the incident window.\n\nEvidence\n- symptom: repeated timeout warnings escalated into request failures.\n- impact: payment attempts failed for end users.\n- key evidence: logs from the incident window show retries without successful recovery.' \
   --suspected-cause "payment-api/handler.py:84 retries immediately against a slow upstream with no jitter; confidence high." \
   --reproduction "Not yet reliably reproducible; more runtime evidence is required." \
   --repo owner/repo
@@ -72,6 +72,12 @@ Problem issues always include exactly three sections:
 - `Suspected Cause`
 - `Reproduction Conditions (if available)`
 
+Within `Problem Description`, include:
+
+- `Expected Behavior (BDD)`
+- `Current Behavior (BDD)`
+- `Behavior Gap`
+
 For Chinese-language repositories, use translated section titles with the same meaning.
 
 Feature proposal issues always include:

package/open-github-issue/SKILL.md

@@ -14,9 +14,9 @@ description: Publish structured GitHub issues and feature proposals with determi
 
 ## Standards
 
-- Evidence: Require structured issue inputs and detect repository language from the target README instead of guessing.
+- Evidence: Require structured issue inputs, detect repository language from the target README instead of guessing, and for `problem` issues capture BDD-style expected vs current behavior with an explicit delta.
 - Execution: Resolve the repo, normalize the issue body, publish with strict auth order, then return the publication result.
-- Quality: Preserve upstream evidence, localize only the structural parts, and keep publication deterministic and reproducible.
+- Quality: Preserve upstream evidence, localize only the structural parts, keep publication deterministic and reproducible, and make behavioral mismatches easy for maintainers to verify.
 - Output: Return publication mode, issue URL when created, rendered body, and any publish error in the standardized JSON contract.
 
 ## Overview
@@ -37,6 +37,7 @@ It is designed to be reusable by other skills that already know the issue title
 - Detect repository issue language from the target remote README instead of guessing.
 - Preserve upstream evidence content; only localize section headers and default fallback text.
 - Make the issue type explicit: `problem` for defects/incidents, `feature` for proposals.
+- For `problem` issues, describe the expected behavior and current behavior with BDD-style `Given / When / Then`, then state the behavioral difference explicitly.
 
 ## Workflow
 
@@ -49,6 +50,11 @@ It is designed to be reusable by other skills that already know the issue title
      - `problem-description`
      - `suspected-cause`
      - `reproduction` (optional)
+   - Within `problem-description`, require a precise behavior diff:
+     - `Expected Behavior (BDD)`: `Given / When / Then` for what the program should do.
+     - `Current Behavior (BDD)`: `Given / When / Then` for what the program does now.
+     - `Behavior Gap`: a short explicit comparison of the observable difference and impact.
+     - Include the symptom, impact, and key evidence alongside the behavior diff; do not leave the mismatch implicit.
    - For `feature` issues, require these structured sections:
      - `proposal` (optional; defaults to title when omitted)
      - `reason`
@@ -74,7 +80,7 @@ Problem issue:
 python scripts/open_github_issue.py \
   --issue-type problem \
   --title "[Log] <short symptom>" \
-  --problem-description "<symptom + impact + key evidence>" \
+  --problem-description $'Expected Behavior (BDD)\nGiven ...\nWhen ...\nThen ...\n\nCurrent Behavior (BDD)\nGiven ...\nWhen ...\nThen ...\n\nBehavior Gap\n- Expected: ...\n- Actual: ...\n- Difference/Impact: ...\n\nEvidence\n- symptom: ...\n- impact: ...\n- key evidence: ...' \
   --suspected-cause "<path:line + causal chain + confidence>" \
   --reproduction "<steps/conditions or leave empty>" \
   --repo <owner/repo>
@@ -111,6 +117,7 @@ When another skill depends on `open-github-issue`:
 
 - Pass exactly one confirmed problem or one accepted feature proposal per invocation.
 - Prepare evidence or proposal details before calling this skill; do not ask this skill to infer root cause or architecture.
+- For `problem` issues, pass a `problem-description` that contains `Expected Behavior (BDD)`, `Current Behavior (BDD)`, and `Behavior Gap`; the difference must be explicit, not implied.
 - Reuse the returned `mode`, `issue_url`, and `publish_error` in the parent skill response.
 - For accepted feature proposals, pass `--issue-type feature` plus `--proposal`, `--reason`, and `--suggested-architecture`.
 

package/open-github-issue/scripts/open_github_issue.py

@@ -19,6 +19,18 @@ DEFAULT_REPRO_ZH = "尚未穩定重現；需補充更多執行期資料。"
 DEFAULT_REPRO_EN = "Not yet reliably reproducible; more runtime evidence is required."
 ISSUE_TYPE_PROBLEM = "problem"
 ISSUE_TYPE_FEATURE = "feature"
+PROBLEM_BDD_MARKER_GROUPS = (
+    (
+        r"Expected Behavior\s*\(BDD\)",
+        r"Current Behavior\s*\(BDD\)",
+        r"Behavior Gap",
+    ),
+    (
+        r"預期行為\s*[（(]BDD[）)]",
+        r"(?:目前|當前)行為\s*[（(]BDD[）)]",
+        r"行為(?:落差|差異)",
+    ),
+)
 
 
 def parse_args() -> argparse.Namespace:
@@ -83,6 +95,19 @@ def validate_issue_content_args(args: argparse.Namespace) -> None:
         raise SystemExit("Problem issues require --problem-description.")
     if not (args.suspected_cause or "").strip():
         raise SystemExit("Problem issues require --suspected-cause.")
+    if not has_required_problem_bdd_sections(args.problem_description or ""):
+        raise SystemExit(
+            "Problem issues require --problem-description to include "
+            "Expected Behavior (BDD), Current Behavior (BDD), and Behavior Gap sections."
+        )
+
+
+def has_required_problem_bdd_sections(problem_description: str) -> bool:
+    normalized = problem_description.strip()
+    return any(
+        all(re.search(pattern, normalized, flags=re.IGNORECASE) for pattern in marker_group)
+        for marker_group in PROBLEM_BDD_MARKER_GROUPS
+    )
 
 
 def run_command(args: list[str]) -> subprocess.CompletedProcess[str]:

package/open-github-issue/tests/test_open_github_issue.py

@@ -121,11 +121,59 @@ class OpenGitHubIssueTests(unittest.TestCase):
             )
         )
 
+    def test_validate_issue_content_args_requires_problem_bdd_sections(self) -> None:
+        with self.assertRaises(SystemExit):
+            MODULE.validate_issue_content_args(
+                Namespace(
+                    issue_type=MODULE.ISSUE_TYPE_PROBLEM,
+                    reason=None,
+                    suggested_architecture=None,
+                    problem_description="Repeated timeout warnings escalated into request failures.",
+                    suspected_cause="handler.py:12",
+                )
+            )
+
+        MODULE.validate_issue_content_args(
+            Namespace(
+                issue_type=MODULE.ISSUE_TYPE_PROBLEM,
+                reason=None,
+                suggested_architecture=None,
+                problem_description=(
+                    "Expected Behavior (BDD)\n"
+                    "Given requests arrive during transient upstream latency\n"
+                    "When the retry path runs\n"
+                    "Then the request should recover without user-visible failure\n\n"
+                    "Current Behavior (BDD)\n"
+                    "Given requests arrive during transient upstream latency\n"
+                    "When the retry path runs\n"
+                    "Then the request still fails after immediate retries\n\n"
+                    "Behavior Gap\n"
+                    "- Expected: retries absorb transient slowness.\n"
+                    "- Actual: retries amplify failures.\n"
+                    "- Difference/Impact: users still receive errors.\n"
+                ),
+                suspected_cause="handler.py:12",
+            )
+        )
+
     def test_main_dry_run_returns_structured_json_without_publish_attempt(self) -> None:
         args = Namespace(
             title="[Log] sample",
             issue_type=MODULE.ISSUE_TYPE_PROBLEM,
-            problem_description="problem",
+            problem_description=(
+                "Expected Behavior (BDD)\n"
+                "Given the issue is confirmed\n"
+                "When the issue body is rendered\n"
+                "Then the expected path should be explicit\n\n"
+                "Current Behavior (BDD)\n"
+                "Given the issue is confirmed\n"
+                "When the issue body is rendered\n"
+                "Then the current path should be explicit\n\n"
+                "Behavior Gap\n"
+                "- Expected: clear behavior diff.\n"
+                "- Actual: sample payload for dry run.\n"
+                "- Difference/Impact: contract stays structured.\n"
+            ),
             suspected_cause="handler.py:12",
             reproduction=None,
             proposal=None,

package/open-source-pr-workflow/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 LTKSunny
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/openai-text-to-image-storyboard/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 tszkinlai
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/openclaw-configuration/SKILL.md

@@ -9,6 +9,7 @@ description: Build, audit, and explain OpenClaw configuration from official docu
 
 - Required: none.
 - Conditional: `answering-questions-with-research` when a request depends on newer OpenClaw docs than the bundled references cover.
+- Conditional: `commit-and-push` when the user explicitly wants OpenClaw workspace changes committed and pushed after validation.
 - Optional: none.
 - Fallback: If the local CLI is unavailable, work from the bundled references and clearly mark any runtime behavior that was not verified on the machine.
 
@@ -33,6 +34,8 @@ Decide whether the user needs:
 - a new starter config
 - a targeted key update
 - skills loading or per-skill env setup
+- workspace persona or memory customization under `~/.openclaw/workspace`
+- browser, exec, or sandbox permission changes
 - secrets or provider wiring
 - validation or repair of a broken config
 
@@ -55,7 +58,9 @@ Assume the canonical config file is `~/.openclaw/openclaw.json` unless the envir
 
 - Prefer `openclaw config set` for one-path edits.
 - Prefer SecretRefs or env substitution over plaintext credentials.
-- For skill-specific setup, use `skills.load.extraDirs`, `skills.entries.<skillKey>`, and per-skill `env` or `apiKey`.
+- For skill-specific setup, prefer the workspace convention `~/.openclaw/workspace/skills`, then wire it through `skills.load.extraDirs`, `skills.entries.<skillKey>`, and per-skill `env` or `apiKey`.
+- When the user is customizing the assistant persona or standing instructions, inspect and edit the matching workspace files such as `AGENTS.md`, `TOOLS.md`, `SOUL.md`, `USER.md`, and `memory/*.md` instead of stuffing everything into `openclaw.json`.
+- When enabling automation or browser workflows, verify the actual permission path for `browser`, `exec`, and sandbox behavior rather than assuming the profile already grants them.
 - Do not invent unknown root keys; OpenClaw rejects schema-invalid config.
 
 ### 5. Validate before finishing
@@ -87,7 +92,30 @@ Summarize the relevant branch and point back to the matching official page rathe
 
 ### Configure skills
 
-Use `skills.load.extraDirs` for additional skill folders and `skills.entries.<skillKey>` for per-skill enablement, env vars, or `apiKey`.
+Use `skills.load.extraDirs` for additional skill folders and `skills.entries.<skillKey>` for per-skill enablement, env vars, or `apiKey`. When the user asks for OpenClaw workspace-local skills, default to `~/.openclaw/workspace/skills` unless the environment proves another convention.
+
+### Customize workspace instructions and persona
+
+When the request is about how the assistant should behave inside OpenClaw, inspect the workspace instruction files first and keep each edit in the narrowest home:
+
+- `AGENTS.md` for workflow rules, completion criteria, and memory discipline
+- `TOOLS.md` for tool usage instructions
+- `SOUL.md` for persona or relationship framing
+- `USER.md` for the user's profile and durable identity details
+- `memory/*.md` for durable corrections, failures, and learned preferences
+
+If the workspace is a git repo and the user explicitly asks to persist those changes remotely, validate first and then hand off to `commit-and-push`.
+
+### Verify tool permissions
+
+When the user says "make sure OpenClaw can use this tool," confirm the exact config path and runtime status for:
+
+- `tools.*` policy entries
+- sandbox mode and workspace access
+- `browser.enabled` and any browser profile settings
+- any profile-level defaults that may still block the tool
+
+Report both the config edit and the runtime verification command; do not assume that a schema-valid config means the tool is actually usable.
 
 ### Wire secrets
 

package/openclaw-configuration/references/best-practices.md

@@ -30,6 +30,7 @@ These rules are distilled from the official OpenClaw docs and adapted into a pra
 
 ## Skills rules
 
+- For OpenClaw workspace-local skills, prefer `~/.openclaw/workspace/skills` as the first extra skill root unless the machine already uses a different proven convention.
 - Put extra skill roots in `skills.load.extraDirs` instead of hard-coding ad hoc discovery logic elsewhere.
 - Use `skills.entries.<skillKey>.enabled` for explicit enable or disable state.
 - Use `skills.entries.<skillKey>.env` for skill-local environment variables.
@@ -37,6 +38,20 @@ These rules are distilled from the official OpenClaw docs and adapted into a pra
 - Leave `skills.load.watch` enabled while iterating on local skills unless file-watch churn becomes a confirmed problem.
 - If you set `skills.install.nodeManager`, remember the official docs still recommend Node as the runtime for the gateway itself.
 
+## Workspace customization rules
+
+- Do not force persona, memory, and workflow instructions into `openclaw.json` when the workspace already has dedicated files.
+- Use `AGENTS.md` for task-completion and memory-management instructions.
+- Use `TOOLS.md` for browser, Playwright, or wrapper command guidance.
+- Use `SOUL.md` for persona framing and `USER.md` for durable user profile facts.
+- When the user asks OpenClaw to remember valuable failures or corrections, store them in the workspace memory files that the current workspace already uses rather than inventing a second memory system.
+
+## Tool permission rules
+
+- Treat browser and sandbox enablement as a two-part check: config policy plus runtime verification.
+- After changing tool policy, verify the effective runtime state with the relevant OpenClaw command instead of trusting config shape alone.
+- If a tool still fails after config edits, inspect whether profile defaults or sandbox policy override the leaf setting.
+
 ## Troubleshooting rules
 
 - If the gateway stops booting after a config change, assume schema breakage first and validate before changing unrelated systems.

package/openclaw-configuration/references/config-reference-map.md

@@ -148,6 +148,28 @@ Notes confirmed by the docs:
 - `skills.entries` keys default to the skill name
 - if a skill defines `metadata.openclaw.skillKey`, use that key instead
 - watcher-driven skill changes are picked up on the next agent turn when watching is enabled
+- for workspace-scoped customization, `~/.openclaw/workspace/skills` is a practical local skill root to wire through `skills.load.extraDirs`
+
+## Workspace files often edited alongside config
+
+These are not all part of the OpenClaw JSON schema, but they are common neighboring files when users ask to customize behavior:
+
+- `~/.openclaw/workspace/AGENTS.md`
+- `~/.openclaw/workspace/TOOLS.md`
+- `~/.openclaw/workspace/SOUL.md`
+- `~/.openclaw/workspace/USER.md`
+- `~/.openclaw/workspace/memory/*.md`
+
+Use them for persona, tool instructions, durable user profile details, and memory-management rules instead of overloading `openclaw.json`.
+
+## Tool and sandbox checks worth remembering
+
+- A valid config does not prove the tool is usable at runtime.
+- When enabling browser automation or sandboxed command execution, verify the effective state after editing:
+  - tool policy
+  - sandbox mode and workspace access
+  - browser enablement and profile selection
+- Profile defaults can still block a tool even when a nearby leaf branch looks permissive, so check the effective runtime path, not only the edited key.
 
 ## Example snippets to adapt
 

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "2.7.0",
-  "description": "Apollo Toolkit npm installer for managed skill linking across Codex, OpenClaw, and Trae.",
+  "version": "2.9.0",
+  "description": "Apollo Toolkit npm installer for managed skill copying across Codex, OpenClaw, and Trae.",
   "license": "MIT",
   "author": "LaiTszKin",
   "homepage": "https://github.com/LaiTszKin/apollo-toolkit#readme",

package/review-change-set/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Lai Tsz Kin
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

package/review-codebases/LICENSE

@@ -1,6 +1,6 @@
 MIT License
 
-Copyright (c) 2026 Yamiyorunoshura
+Copyright (c) 2026 LaiTszKin
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal