@laitszkin/apollo-toolkit 2.6.0 → 2.8.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.
@@ -38,11 +38,13 @@ This repository enables users to install and run a curated set of reusable agent
 - Users can publish structured GitHub issues or feature proposals with auth fallbacks.
 - Users can prepare and open open-source pull requests from existing changes.
 - Users can generate storyboard image sets from chapters, novels, articles, or scripts.
+- Users can configure OpenClaw from official documentation, including `~/.openclaw/openclaw.json`, skills loading, SecretRefs, CLI edits, and validation or repair workflows.
 - Users can record multi-account spending and balance changes in monthly Excel ledgers with summary analytics and charts.
 - Users can review the current git change set from an unbiased reviewer perspective to find abstraction opportunities and simplification candidates.
 - 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,24 @@ All notable changes to this repository are documented in this file.
 
 ## [Unreleased]
 
+## [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
+- Add `openclaw-configuration` for explaining, editing, validating, and troubleshooting OpenClaw configuration from the current official docs, including `~/.openclaw/openclaw.json`, skills config, secrets, and CLI workflows.
+- Add bundled OpenClaw configuration references covering the official doc map, config option guide, and operational best practices.
+
+### Changed
+- Update `fix-github-issues` to require temporary worktree and local branch cleanup as part of direct-push or PR completion, with explicit cleanup verification before finishing.
+- Update `learn-skill-from-conversations` to treat post-completion cleanup or finalization follow-ups as evidence that the owning workflow's done criteria need tightening.
+- Update the repository skill inventory and project capability docs to include OpenClaw configuration support.
+
 ## [v2.6.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
 
@@ -31,11 +31,13 @@ A curated skill catalog for Codex, OpenClaw, and Trae with a managed installer t
 - open-github-issue
 - open-source-pr-workflow
 - openai-text-to-image-storyboard
+- openclaw-configuration
 - record-spending
 - resolve-review-comments
 - review-change-set
 - review-codebases
 - scheduled-runtime-health-check
+- shadow-api-model-research
 - solana-development
 - systematic-debug
 - text-to-short-video
@@ -55,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/fix-github-issues/SKILL.md

@@ -16,8 +16,8 @@ description: Resolve issues from remote GitHub repositories via GitHub CLI (`gh`
 
 - Evidence: Verify repository context, fetch remote issue details, and derive expected behavior from issue text before coding.
 - Execution: Select the issue, open an isolated worktree by default, fix it through `systematic-debug`, validate locally, then hand off to the delivery workflow that matches the user's request.
-- Quality: Keep scope limited to the selected issue, capture exact validation commands, and preserve issue linkage in the final PR or commit message.
-- Output: Finish with either a linked PR or a direct pushed commit, then clean up the temporary worktree when the work is complete.
+- Quality: Keep scope limited to the selected issue, capture exact validation commands, preserve issue linkage in the final PR or commit message, and treat temporary worktree cleanup as part of completion rather than an optional follow-up.
+- Output: Finish with either a linked PR or a direct pushed commit, then clean up the temporary worktree plus any matching local branch before reporting completion.
 
 ## Overview
 
@@ -89,10 +89,12 @@ python3 scripts/list_issues.py --limit 50 --state open
   - executed test commands and results
 - Include issue-closing reference (for example, `Closes #<issue-number>`) whenever a PR is opened.
 
-### 8) Clean up the temporary worktree after PR creation
+### 8) Clean up the temporary worktree after PR creation or direct push
 
 - Once the PR is opened or the direct push is complete and no more work is needed in that isolated tree, remove the worktree you created for the fix.
 - Also clean up the matching local branch reference if it is no longer needed locally.
+- Verify the cleanup with `git worktree list` and confirm the temporary path no longer appears before finishing.
+- If the worktree cannot be removed because of uncommitted changes or a still-checked-out branch, resolve that state immediately instead of leaving cleanup for a later user request.
 
 ## Included Script
 

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/learn-skill-from-conversations/SKILL.md

@@ -15,7 +15,7 @@ description: Learn and evolve the local skill library from recent Codex conversa
 ## Standards
 
 - Evidence: Extract recent Codex session history first and derive reusable lessons only from actual conversation patterns.
-- Execution: Inventory the current skill catalog before editing, prioritize repeated requests, user corrections, and reported errors, then prefer a focused update to the strongest related skill or create a new skill only when the overlap is weak.
+- Execution: Inventory the current skill catalog before editing, prioritize repeated requests, user corrections, reported errors, and post-completion follow-up asks that reveal missing closure, then prefer a focused update to the strongest related skill or create a new skill only when the overlap is weak.
 - Quality: Take no action when there are no recent sessions, avoid unrelated broad refactors, and validate every changed skill.
 - Output: Report the analyzed sessions, extracted lessons, created or updated skills, and the reasoning behind each decision.
 
@@ -48,6 +48,8 @@ python3 ~/.codex/skills/learn-skill-from-conversations/scripts/extract_recent_co
 - Identify repeated user needs, recurring friction, and repeated manual workflows.
 - Give extra weight to moments where the user corrected the agent, rejected an earlier interpretation, or pointed out a missing preference or requirement.
 - Give extra weight to user-reported errors, regressions, or avoidable mistakes, then ask how a skill can prevent repeating that failure mode.
+- Treat a user follow-up that asks for cleanup or an omitted finalization step immediately after the assistant reported completion as evidence that the workflow's done criteria were incomplete.
+- When that kind of follow-up recurs, tighten the owning skill's completion checklist before considering any new-skill extraction.
 - Ignore one-off issues that do not provide reusable value.
 - Distinguish between:
   - repeated trigger intent that deserves a new skill

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-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

@@ -0,0 +1,126 @@
+---
+name: openclaw-configuration
+description: Build, audit, and explain OpenClaw configuration from official documentation. Use when configuring `~/.openclaw/openclaw.json`, mapping config options, adjusting skills or secrets, generating validated snippets, or diagnosing config errors with `openclaw config`, `openclaw configure`, and `openclaw doctor`.
+---
+
+# OpenClaw Configuration
+
+## Dependencies
+
+- 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.
+
+## Standards
+
+- Evidence: Verify the active config file, current values, and CLI diagnostics before editing.
+- Execution: Prefer the smallest safe change; use `openclaw config` for narrow edits and direct JSON edits for broad restructures.
+- Quality: Keep the file schema-valid, avoid plaintext secrets when a SecretRef or env var fits, and preserve unrelated valid settings.
+- Output: Return exact file paths, touched keys, validation commands, and any restart or hot-reload caveats.
+
+## Goal
+
+Help another agent configure OpenClaw safely, quickly, and with citations back to the official docs.
+
+## Workflow
+
+### 1. Classify the request
+
+Decide whether the user needs:
+
+- a config explanation
+- 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
+
+Assume the canonical config file is `~/.openclaw/openclaw.json` unless the environment proves otherwise.
+
+### 2. Choose the safest edit surface
+
+- Use `openclaw onboard` or `openclaw configure` for guided setup.
+- Use `openclaw config get/set/unset/validate` for precise path-based edits.
+- Use direct JSON edits only when changing several related branches at once.
+- If the local gateway is running, the Control UI config tab at `http://127.0.0.1:18789` can help inspect or edit the same schema-backed config.
+
+### 3. Load only the references you need
+
+- Read `references/official-docs.md` first for the canonical doc map.
+- Read `references/config-reference-map.md` when you need option names, CLI behavior, hot reload, skills config, env handling, or secrets rules.
+- Read `references/best-practices.md` before producing a new config, touching credentials, or fixing a broken setup.
+
+### 4. Apply minimal, schema-safe changes
+
+- Prefer `openclaw config set` for one-path edits.
+- Prefer SecretRefs or env substitution over plaintext credentials.
+- 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
+
+- Run `openclaw config validate` after edits.
+- If the gateway refuses to boot, run `openclaw doctor`.
+- Use `openclaw doctor --repair` only after reviewing what it will change; the tool can back up the config and remove unknown keys.
+- Call out whether the change should hot-apply or may still need a restart.
+
+### 6. Return a concise handoff
+
+Always include:
+
+- the file or keys changed
+- the command or JSON snippet used
+- the validation command
+- any secret or env prereqs
+- the official doc pages that justify the change
+
+## Common Tasks
+
+### Generate a starter config
+
+Start from the official minimal or starter shape, then add only the channels, models, or skills the user actually needs.
+
+### Explain config options
+
+Summarize the relevant branch and point back to the matching official page rather than dumping the entire reference.
+
+### Configure skills
+
+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
+
+Prefer SecretRefs (`env`, `file`, or `exec`) for supported credential fields. Use plaintext only when the user explicitly wants a local-only quick setup and understands the tradeoff.
+
+### Repair a broken config
+
+Run `openclaw config validate`, then `openclaw doctor`, and only then make the smallest correction that restores schema validity.

package/openclaw-configuration/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "OpenClaw Configuration"
+  short_description: "Configure and troubleshoot OpenClaw settings"
+  default_prompt: "Use $openclaw-configuration to explain, edit, validate, or troubleshoot OpenClaw configuration, including `~/.openclaw/openclaw.json`, `skills` settings, env vars, SecretRefs, and official OpenClaw CLI/config workflows."

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

@@ -0,0 +1,70 @@
+# OpenClaw Configuration Best Practices
+
+These rules are distilled from the official OpenClaw docs and adapted into a practical workflow.
+
+## Authoring rules
+
+- Treat `~/.openclaw/openclaw.json` as the source of truth unless the environment proves otherwise.
+- Prefer the smallest possible edit surface:
+  - one key: `openclaw config set`
+  - one subtree removal: `openclaw config unset`
+  - several coordinated edits: direct JSON edit plus validation
+- Keep JSON structure conservative; OpenClaw rejects unknown keys.
+- Use the configuration examples page as a baseline instead of inventing a new root layout.
+
+## Safety rules
+
+- Never store production credentials in plaintext if a SecretRef or env var can be used.
+- Avoid mixing plaintext and SecretRefs for the same credential path; the ref wins on supported fields and makes ownership clearer.
+- Validate immediately after editing:
+  - `openclaw config validate`
+  - `openclaw doctor` when the gateway still behaves unexpectedly
+- Use `openclaw doctor --repair` only when you are comfortable with automatic cleanup and backup behavior.
+
+## Environment rules
+
+- Prefer `${VAR_NAME}` substitution for portable config shared across machines.
+- Keep env var names uppercase to match the documented substitution pattern.
+- Use `env.shellEnv.enabled` only when the missing-key import behavior is intentional and understood.
+- Avoid scattering the same secret across the parent shell, local `.env`, and `~/.openclaw/.env`; keep precedence simple.
+
+## 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.
+- Use `skills.entries.<skillKey>.apiKey` only when the skill expects a primary env-backed API key convenience field.
+- 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.
+- When troubleshooting a credentialed path, inspect both the config branch and the SecretRef provider branch.
+- When a user asks for "why did this stop working," capture the exact key path and the command used to validate it.
+- For broken skill loading, check both `skills.load.extraDirs` and the effective `skillKey` mapping.
+
+## Recommended delivery format
+
+When answering a user or editing a machine, return:
+
+1. the exact file or key path
+2. the change made
+3. the validation command
+4. the secret or env prerequisites
+5. the official docs used

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

@@ -0,0 +1,211 @@
+# OpenClaw Config Reference Map
+
+This file condenses the official OpenClaw configuration docs into a quick operator map.
+
+## Main file and edit surfaces
+
+- Canonical file: `~/.openclaw/openclaw.json`
+- Guided setup:
+  - `openclaw onboard`
+  - `openclaw configure`
+- Precise edits:
+  - `openclaw config get <path>`
+  - `openclaw config set <path> <value>`
+  - `openclaw config unset <path>`
+  - `openclaw config validate`
+- UI editing:
+  - Config tab in the local Control UI at `http://127.0.0.1:18789`
+- Direct editing:
+  - safe for broader restructures, but validate immediately afterward
+
+## Validation and reload behavior
+
+- OpenClaw enforces a strict schema.
+- Unknown keys, bad types, or invalid values can prevent the gateway from starting.
+- The root `$schema` string is the documented exception for editor schema metadata.
+- When validation fails, the docs point to diagnostic commands such as:
+  - `openclaw doctor`
+  - `openclaw logs`
+  - `openclaw health`
+  - `openclaw status`
+- The gateway watches `~/.openclaw/openclaw.json` and hot-applies many changes automatically.
+
+## CLI behavior worth remembering
+
+### Paths
+
+- Dot notation works: `agents.defaults.workspace`
+- Bracket notation works: `agents.list[0].tools.exec.node`
+
+### Value parsing
+
+- `openclaw config set` parses JSON5 when possible.
+- Use `--strict-json` when you want parsing to be required.
+- Use strings intentionally for values such as heartbeat durations.
+
+### Assignment modes
+
+- Value mode: plain path/value edit
+- SecretRef builder mode: build a supported ref without hand-writing JSON
+- Provider builder mode: build `secrets.providers.<alias>` entries
+- Batch mode: apply several edits from a JSON payload or file
+
+## Official namespace map
+
+The full reference documents these major sections:
+
+- `channels`
+- `agents`
+- `session`
+- `messages`
+- `talk`
+- `tools`
+- custom providers and base URLs
+- `skills`
+- `plugins`
+- `browser`
+- `ui`
+- `gateway`
+- `hooks`
+- canvas host
+- discovery
+- `environment`
+- `secrets`
+- auth storage
+- logging
+- CLI
+- wizard
+- identity
+- `cron`
+- media model template variables
+- config includes via `$include`
+
+Use the official full reference when you need the exact nested shape under one of these branches.
+
+## Environment variables
+
+The gateway docs describe three non-inline sources:
+
+- env vars from the parent process
+- `.env` in the current working directory
+- `~/.openclaw/.env` as a global fallback
+
+Neither `.env` file overrides variables that are already present in the parent process.
+
+The docs also describe config-side helpers:
+
+- inline `env` sections
+- optional shell env import via `env.shellEnv.enabled`
+- config string substitution with `${VAR_NAME}`
+
+Key rules called out by the docs:
+
+- substitution targets uppercase variable names
+- missing or empty values fail at load time
+- use `$${VAR}` to escape a literal placeholder
+
+## Secrets and credential references
+
+OpenClaw documents a common SecretRef shape:
+
+```json
+{
+  "source": "env",
+  "provider": "default",
+  "id": "OPENAI_API_KEY"
+}
+```
+
+Supported ref sources in the docs:
+
+- `env`
+- `file`
+- `exec`
+
+Operational rules confirmed by the secrets docs:
+
+- if a supported field has both plaintext and a ref, the ref takes precedence
+- `openclaw secrets audit --check` is the default preflight
+- `openclaw secrets configure` helps wire providers
+- a final `openclaw secrets audit --check` confirms the setup
+
+## Skills configuration
+
+The official skills config page documents these fields:
+
+- `skills.allowBundled`
+- `skills.load.extraDirs`
+- `skills.load.watch`
+- `skills.load.watchDebounceMs`
+- `skills.install.preferBrew`
+- `skills.install.nodeManager`
+- `skills.entries.<skillKey>.enabled`
+- `skills.entries.<skillKey>.env`
+- `skills.entries.<skillKey>.apiKey`
+
+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
+
+### Minimal starter
+
+```json
+{
+  "agents": {
+    "defaults": {
+      "workspace": "~/.openclaw/workspace"
+    }
+  },
+  "channels": {
+    "whatsapp": {
+      "allowFrom": ["+15555550123"]
+    }
+  }
+}
+```
+
+### Custom skill directory plus per-skill env
+
+```json
+{
+  "skills": {
+    "load": {
+      "extraDirs": ["~/skills", "~/.apollo-toolkit"]
+    },
+    "entries": {
+      "openclaw-configuration": {
+        "enabled": true,
+        "env": {
+          "OPENCLAW_CONFIG_PATH": "~/.openclaw/openclaw.json"
+        }
+      }
+    }
+  }
+}
+```

package/openclaw-configuration/references/official-docs.md

@@ -0,0 +1,40 @@
+# OpenClaw Official Config Docs
+
+Last verified: 2026-03-20
+
+Use this file as the entry map into the official OpenClaw documentation on `docs.openclaw.ai`.
+
+## Canonical pages
+
+- Gateway configuration overview: `https://docs.openclaw.ai/gateway/configuration`
+  - Covers the main config file path, edit surfaces, strict validation, hot reload, env vars, and links to the full reference.
+- Full configuration reference: `https://docs.openclaw.ai/gateway/configuration-reference`
+  - Covers the major top-level namespaces such as `channels`, `agents`, `tools`, `skills`, `plugins`, `gateway`, `secrets`, `cron`, and `$include`.
+- Configuration examples: `https://docs.openclaw.ai/gateway/configuration-examples`
+  - Provides minimal and starter-shaped configs plus common deployment patterns.
+- Skills config: `https://docs.openclaw.ai/tools/skills-config`
+  - Covers `skills.allowBundled`, `skills.load.*`, `skills.install.*`, and `skills.entries.<skillKey>`.
+- Secrets management: `https://docs.openclaw.ai/gateway/secrets`
+  - Covers SecretRef structure, providers, precedence, audit flow, and secure credential handling.
+- CLI config command: `https://docs.openclaw.ai/cli/config`
+  - Covers `openclaw config get/set/unset/validate`, path syntax, parsing rules, and SecretRef builder modes.
+- CLI configure command: `https://docs.openclaw.ai/cli/configure`
+  - Covers the guided configuration wizard.
+- CLI doctor command: `https://docs.openclaw.ai/cli/doctor`
+  - Covers diagnostics, repair behavior, backups, and environment checks.
+
+## Core facts confirmed from the official docs
+
+- The canonical config file is `~/.openclaw/openclaw.json`.
+- OpenClaw supports guided edits, CLI path edits, Control UI editing, and direct file editing.
+- The gateway validates the config strictly against schema; unknown keys are rejected except for the root `$schema` metadata key.
+- The gateway watches the config file and hot-applies many changes automatically.
+- Secrets can be supplied through env vars, files, or exec-backed SecretRefs, depending on the field.
+
+## When to open which doc
+
+- Need the exact field name or namespace: open the full reference.
+- Need a starting snippet or pattern: open configuration examples.
+- Need to load custom skills or set per-skill env: open skills config.
+- Need to wire API keys safely: open secrets management plus CLI config.
+- Need to repair a broken config: open gateway configuration plus CLI doctor.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@laitszkin/apollo-toolkit",
-  "version": "2.6.0",
-  "description": "Apollo Toolkit npm installer for managed skill linking across Codex, OpenClaw, and Trae.",
+  "version": "2.8.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

package/scripts/install_skills.ps1

@@ -12,9 +12,9 @@ Usage:
   ./scripts/install_skills.ps1 [codex|openclaw|trae|all]...
 
 Modes:
-  codex     Install links into ~/.codex/skills
-  openclaw  Install links into ~/.openclaw/workspace*/skills
-  trae      Install links into ~/.trae/skills
+  codex     Copy skills into ~/.codex/skills
+  openclaw  Copy skills into ~/.openclaw/workspace*/skills
+  trae      Copy skills into ~/.trae/skills
   all       Install all supported targets
 
 Optional environment overrides:
@@ -33,7 +33,7 @@ function Show-Banner {
   @"
 +------------------------------------------+
 |              Apollo Toolkit              |
-|      npm installer and skill linker      |
+|      npm installer and skill copier      |
 +------------------------------------------+
 "@
 }
@@ -180,7 +180,7 @@ function Remove-PathForce {
   }
 }
 
-function Link-Skill {
+function Copy-Skill {
   param(
     [string]$Source,
     [string]$TargetRoot
@@ -192,15 +192,8 @@ function Link-Skill {
   New-Item -ItemType Directory -Path $TargetRoot -Force | Out-Null
   Remove-PathForce -Target $target
 
-  try {
-    New-Item -Path $target -ItemType SymbolicLink -Target $Source -Force | Out-Null
-    Write-Host "[linked] $target -> $Source"
-  }
-  catch {
-    # Fallback for environments where symlink permission is restricted.
-    New-Item -Path $target -ItemType Junction -Target $Source -Force | Out-Null
-    Write-Host "[linked-junction] $target -> $Source"
-  }
+  Copy-Item -LiteralPath $Source -Destination $target -Recurse -Force
+  Write-Host "[copied] $Source -> $target"
 }
 
 function Install-Codex {
@@ -215,7 +208,7 @@ function Install-Codex {
 
   Write-Host "Installing to codex: $target"
   foreach ($src in $SkillPaths) {
-    Link-Skill -Source $src -TargetRoot $target
+    Copy-Skill -Source $src -TargetRoot $target
   }
 }
 
@@ -242,7 +235,7 @@ function Install-OpenClaw {
     $skillsDir = Join-Path $workspace.FullName "skills"
     Write-Host "Installing to openclaw workspace: $skillsDir"
     foreach ($src in $SkillPaths) {
-      Link-Skill -Source $src -TargetRoot $skillsDir
+      Copy-Skill -Source $src -TargetRoot $skillsDir
     }
   }
 }
@@ -259,7 +252,7 @@ function Install-Trae {
 
   Write-Host "Installing to trae: $target"
   foreach ($src in $SkillPaths) {
-    Link-Skill -Source $src -TargetRoot $target
+    Copy-Skill -Source $src -TargetRoot $target
   }
 }
 

package/scripts/install_skills.sh

@@ -7,9 +7,9 @@ Usage:
   ./scripts/install_skills.sh [codex|openclaw|trae|all]...
 
 Modes:
-  codex     Install symlinks into ~/.codex/skills
-  openclaw  Install symlinks into ~/.openclaw/workspace*/skills
-  trae      Install symlinks into ~/.trae/skills
+  codex     Copy skills into ~/.codex/skills
+  openclaw  Copy skills into ~/.openclaw/workspace*/skills
+  trae      Copy skills into ~/.trae/skills
   all       Install all supported targets
 
 Optional environment overrides:
@@ -29,7 +29,7 @@ show_banner() {
   cat <<'BANNER'
 +------------------------------------------+
 |              Apollo Toolkit              |
-|      npm installer and skill linker      |
+|      npm installer and skill copier      |
 +------------------------------------------+
 BANNER
 }
@@ -74,7 +74,7 @@ collect_skills() {
   fi
 }
 
-replace_with_symlink() {
+replace_with_copy() {
   local src="$1"
   local target_root="$2"
   local name target
@@ -86,8 +86,8 @@ replace_with_symlink() {
   if [[ -e "$target" || -L "$target" ]]; then
     rm -rf "$target"
   fi
-  ln -s "$src" "$target"
-  echo "[linked] $target -> $src"
+  cp -R "$src" "$target"
+  echo "[copied] $src -> $target"
 }
 
 install_codex() {
@@ -96,7 +96,7 @@ install_codex() {
 
   echo "Installing to codex: $codex_skills_dir"
   for src in "${SKILL_PATHS[@]}"; do
-    replace_with_symlink "$src" "$codex_skills_dir"
+    replace_with_copy "$src" "$codex_skills_dir"
   done
 }
 
@@ -120,7 +120,7 @@ install_openclaw() {
     skills_dir="$workspace/skills"
     echo "Installing to openclaw workspace: $skills_dir"
     for src in "${SKILL_PATHS[@]}"; do
-      replace_with_symlink "$src" "$skills_dir"
+      replace_with_copy "$src" "$skills_dir"
     done
   done
 }
@@ -131,7 +131,7 @@ install_trae() {
 
   echo "Installing to trae: $trae_skills_dir"
   for src in "${SKILL_PATHS[@]}"; do
-    replace_with_symlink "$src" "$trae_skills_dir"
+    replace_with_copy "$src" "$trae_skills_dir"
   done
 }
 

package/shadow-api-model-research/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: shadow-api-model-research
+description: Investigate gated or shadow LLM APIs by capturing real client request shapes, separating request-shape gating from auth/entitlement checks, replaying verified traffic patterns, and attributing the likely underlying model with black-box fingerprinting. Use when users ask how Codex/OpenClaw/custom-provider traffic works, want a capture proxy or replay harness, need LLMMAP-style model comparison, or want a research report on which model a restricted endpoint likely wraps.
+---
+
+# Shadow API Model Research
+
+## Dependencies
+
+- Required: `answering-questions-with-research` for primary-source web verification and code-backed explanations.
+- Conditional: `openclaw-configuration` when the capture path uses OpenClaw custom providers or workspace config edits; `deep-research-topics` when the user wants a formal report, especially PDF output.
+- Optional: none.
+- Fallback: If you cannot inspect either the real client code path or authorized live traffic, stop and report the missing evidence instead of guessing from headers or marketing copy.
+
+## Standards
+
+- Evidence: Base conclusions on actual client code, captured traffic, official docs, and controlled replay results; do not infer protocol details from memory alone.
+- Execution: Split the job into request-shape capture, replay validation, and model-attribution analysis; treat each as a separate hypothesis gate.
+- Quality: Distinguish request-shape compatibility, auth or entitlement requirements, system-prompt wrapping, and underlying-model behavior; never collapse them into one claim.
+- Output: Return the tested providers, exact capture or replay setup, prompt set or scoring rubric, observed differences, and an explicit confidence statement plus caveats.
+
+## Goal
+
+Help another agent run lawful, evidence-based shadow-API research without drifting into guesswork about what a gated endpoint checks or which model it wraps.
+
+## Workflow
+
+### 1. Classify the research ask
+
+Decide which of these the user actually needs:
+
+- capture the true request shape from a known client
+- configure OpenClaw or another client to hit a controlled endpoint
+- build a replay harness from observed traffic
+- compare the endpoint against known providers with black-box prompts
+- package findings into a concise report
+
+If the user is mixing all of them, still execute in that order: capture first, replay second, attribution third.
+
+### 2. Verify the real client path before writing any script
+
+- Inspect the local client code and active config first.
+- For OpenClaw, load the relevant official docs or local source through `answering-questions-with-research`, and use `openclaw-configuration` if you need to rewire a custom provider for capture.
+- When Codex or another official client is involved, verify current behavior from primary sources and the local installed code when available.
+- Do not claim that a request shape is "Codex-compatible" or "OpenClaw-compatible" until you have either:
+  - captured it from the client, or
+  - confirmed it from the current implementation and docs.
+
+### 3. Capture the true request shape
+
+- Read `references/request-shape-checklist.md` before touching the network path.
+- Prefer routing the real client to a capture proxy or controlled upstream you own.
+- Record, at minimum:
+  - method
+  - path
+  - query parameters
+  - headers
+  - body schema
+  - streaming or SSE frame shape
+  - retries, timeouts, and backoff behavior
+  - any client-added metadata that changes between providers or models
+- Treat aborted turns or partially applied config edits as tainted state; re-check the active config before trusting a capture.
+
+### 4. Separate request gating from auth or entitlement
+
+- Build explicit hypotheses for what the endpoint may be checking:
+  - plain OpenAI-compatible schema only
+  - static headers or user-agent shape
+  - transport details such as SSE formatting
+  - token claims, workspace identity, or other entitlement state
+- Do not tell the user that replaying the request shape is sufficient unless the replay actually works.
+- If the evidence shows the endpoint still rejects cloned traffic, report that the barrier is likely beyond the visible request shape.
+
+### 5. Build the replay harness only from observed facts
+
+- Read `references/fingerprinting-playbook.md` before implementing the replay phase.
+- Use `.env` or equivalent env-backed config for base URLs, API keys, and provider labels.
+- Mirror only the fields that were actually observed from the client.
+- Keep capture and replay scripts separate unless there is a strong reason to combine them.
+- Preserve the observed stream mode; do not silently downgrade SSE to non-streaming or vice versa.
+
+### 6. Run black-box fingerprinting
+
+- Compare the target endpoint against one or more control providers with known or documented models.
+- Use a prompt matrix that spans:
+  - coding or tool-use style
+  - factual knowledge questions with externally verified answers
+  - refusal and policy behavior
+  - instruction-following edge cases
+  - long-context or truncation behavior when relevant
+- When building factual question sets, verify the answer key from primary sources or fresh web research instead of relying on memory.
+- If the user wants LLMMAP-style comparison, keep the benchmark inputs fixed across providers and score each response on the same rubric.
+
+### 7. Report with confidence and caveats
+
+- Summarize:
+  - what was captured
+  - what replayed successfully
+  - which differences were protocol-level versus model-level
+  - the most likely underlying model family
+  - the confidence level and why
+- If system prompts or provider-side wrappers likely distort the output, say so explicitly and lower confidence accordingly.
+- If the user wants a report artifact, hand off to `deep-research-topics` after the evidence has been collected.
+
+## References
+
+- `references/request-shape-checklist.md` for the capture and replay evidence checklist.
+- `references/fingerprinting-playbook.md` for comparison design, scoring dimensions, and report structure.
+
+## Guardrails
+
+- Keep the work on systems the user is authorized to inspect or test.
+- Do not present speculation about hidden auth checks as established fact.
+- Do not over-index on one response; model attribution needs repeated prompts and multiple signal types.

package/shadow-api-model-research/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Shadow API Model Research"
+  short_description: "Capture gated client traffic and attribute likely model families"
+  default_prompt: "Use $shadow-api-model-research when the task is to inspect Codex/OpenClaw/custom-provider request shapes, build a capture or replay workflow, compare a restricted endpoint against control providers, or estimate the likely underlying model with black-box fingerprinting."

package/shadow-api-model-research/references/fingerprinting-playbook.md

@@ -0,0 +1,69 @@
+# Fingerprinting Playbook
+
+Use this playbook after you have trustworthy captured traffic or a validated replay harness.
+
+## Comparison design
+
+- Keep prompts, temperature-like settings, and stream mode fixed across providers.
+- Prefer at least one documented control provider with a known model family.
+- Run multiple prompt categories; one category is not enough for attribution.
+
+## Recommended prompt categories
+
+### 1. Factual knowledge
+
+- Use questions with fresh, externally verifiable answers.
+- Build the answer key from current primary sources or credible web verification.
+- Score for correctness, completeness, and unsupported claims.
+
+### 2. Coding style
+
+- Use short implementation tasks and bug-fix prompts.
+- Compare code structure, caution level, and explanation style.
+
+### 3. Instruction following
+
+- Use prompts with explicit formatting or ranking constraints.
+- Compare compliance, stability, and unnecessary extra content.
+
+### 4. Refusal and policy behavior
+
+- Use borderline prompts that should trigger a recognizable refusal or safe alternative.
+- Compare refusal style, redirect wording, and partial compliance behavior.
+
+### 5. Long-context behavior
+
+- Only run this when the target is expected to support larger contexts.
+- Compare truncation, summarization drift, and consistency across later references.
+
+## Scoring dimensions
+
+Score each response on a fixed rubric, for example:
+
+- factual accuracy
+- completeness
+- instruction compliance
+- reasoning clarity
+- code quality
+- refusal consistency
+- verbosity control
+- latency or throughput when that matters
+
+Use the same rubric for every provider and every prompt.
+
+## Confidence discipline
+
+- High confidence needs multiple converging signals across categories.
+- Medium confidence fits cases where the target tracks one family strongly but wrappers may distort style.
+- Low confidence fits cases where the protocol was captured but output signals remain mixed.
+
+## Suggested report structure
+
+1. Research objective
+2. Capture setup
+3. Replay validation status
+4. Prompt matrix and controls
+5. Scoring rubric
+6. Comparative findings
+7. Most likely model family
+8. Caveats, including wrappers and system prompts

package/shadow-api-model-research/references/request-shape-checklist.md

@@ -0,0 +1,44 @@
+# Request Shape Checklist
+
+Use this checklist before claiming you understand how a gated endpoint is called.
+
+## 1. Capture setup
+
+- Confirm which client will generate the traffic.
+- Confirm the exact provider or model config that client is using.
+- Route the client to a capture proxy, reverse proxy, or controlled upstream you can inspect.
+- Freeze other moving parts when possible: same model, same prompt, same stream mode, same tool settings.
+
+## 2. What to record
+
+- HTTP method
+- URL path
+- query string
+- request headers
+- body payload shape
+- stream or SSE response framing
+- request or response ids
+- retries, reconnects, timeout handling, rebroadcast logic
+- any provider-specific or model-specific metadata fields
+
+## 3. Environment and config evidence
+
+- Save the effective client config that produced the capture.
+- Save the exact env vars used for base URL, API key, and provider selection.
+- When OpenClaw is involved, note the relevant `openclaw.json` keys and whether validation passed.
+
+## 4. Replay readiness gate
+
+Do not write the replay script until you can answer all of these:
+
+- Which fields are constant across repeated requests?
+- Which fields change per request?
+- Which fields come from auth or session state?
+- Is the target using streaming?
+- Is the target expecting OpenAI-compatible JSON or a client-specific variant?
+
+## 5. Replay result interpretation
+
+- Success with cloned shape does not prove the model identity.
+- Failure with cloned shape does not prove the headers are wrong; it may indicate entitlement or hidden session checks.
+- If only some requests replay, compare stream mode, auth tokens, and subtle metadata differences before drawing conclusions.

package/systematic-debug/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/text-to-short-video/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/version-release/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/video-production/LICENSE

@@ -1,18 +1,21 @@
 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 in the Software without restriction, including
-without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
-following conditions:
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
 
-The above copyright notice and this permission notice shall be included in all copies or substantial
-portions of the Software.
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
 
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
-LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
-EVENT SHALL THE 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.
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+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.