@xenonbyte/xsk 0.1.0

package/skills/check/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: xsk-check
+description: Review a code change before it ships. Check scope drift, enforce hard stops, gate findings on evidence, then verify and sign off. Distilled from Waza /check.
+---
+
+# xsk-check
+
+Review a code change against its goal and the available evidence before it merges or ships. Read the diff, find the real problems, fix what is safe to fix, surface the rest, and verify before calling anything done. Distilled from the default-review discipline of Waza `/check`.
+
+It reviews code diffs and changes, not prose. A clean review is a valid result: do not invent findings to look thorough, and do not approve a risky change just to seem agreeable.
+
+## When to use
+
+Match the intent, not the exact words. Common cues:
+
+- "看看代码", "检查一下", "有没有问题", "是否需要优化", "合并前"
+- "review my code", "check this change", "before merge", "code review"
+- any request to review a diff, a pull request, or a pending change for correctness and quality before it ships
+
+## How it works
+
+**1. Read the worktree and the diff first.** Start from `git status` and the full diff against the base branch. Treat modified, staged, and untracked files as the user's work: read them, and never discard, stash, or overwrite them without explicit approval. If the base or the review range is unclear, ask before guessing.
+
+**2. Did the change build what was asked? Check scope drift.** Every changed file and every new surface must trace back to the stated goal in one sentence. A pure refactor folded into a bug fix, a new dependency the goal never mentioned, or a new abstraction nothing requires is drift until justified. Label the change on target, drift, or incomplete.
+
+**3. Classify depth, then state it.** Quick for a small, low-risk change. Standard for a medium one. Deep when the diff is large or touches auth, payments, data mutation, or destructive operations. A deeper change earns a wider read of its callers and consumers, not just the changed lines.
+
+**4. Apply the hard stops. Fix or flag before merge.**
+
+- No unverified claims. Never write "tests pass", "I verified", or "this fixes it" unless the command output is in front of you this session. If the judgment comes from reading the code, say that instead.
+- Re-read before citing a fact. Line numbers, file state, branch position, and fallback behavior go stale. Re-check them in this pass rather than trusting memory.
+- Secrets and injection. No credential hardcoded, logged, or committed. Watch for SQL, shell, and path injection at every entry point.
+- Unexpected dependencies. Flag any added or version-bumped dependency the goal does not obviously require.
+- Unknown identifiers. Grep before approving any symbol the diff introduces. No match outside the diff means it does not exist.
+- Dead-code deletion needs proof. A "zero callers" claim must be checked across the whole repo, including tests, scripts, and dynamic lookups, before anything is removed.
+- Safety sinks. Destructive file operations, path or symlink traversal, and approval-boundary changes need explicit validation, rollback, and confirmation review.
+- Generated-artifact drift. If sources change, the generated or bundled output must be regenerated and included.
+- String-matching on captured output. A subprocess run with inherited stdio streams its diagnostics to the terminal, not into the error message, which then holds only the command line. A matcher on that string silently matches the command, not the output. Probe the real value, or branch on a structured fact such as the exit code.
+- Audit before restore. When the diff re-adds a symbol, string, or field that history removed, grep first to confirm anything still uses it. A rule or test that merely names it is not proof of life.
+- Migration code for unshipped features. Reject "carry the old key forward" logic when the key never shipped. Check the last release tag: if it is absent there, no migration is needed, so ship the default.
+- Install and runtime proof. For a skill, plugin, package, or installer, metadata and source tests are not enough. Build or install through the real user path, or mark that layer unverified.
+- Verifier failure layer. When a check fails before its assertions run, from setup, a missing optional dependency, or the environment, classify setup failure versus product failure. Do not call the code broken until the real test body actually ran.
+
+**5. Sweep the pattern, not just the instance.** When the change fixes one case of a bug class, grep the repo for siblings of the same shape and confirm they were handled too. List any that were missed.
+
+**6. Gate every finding on evidence.** A HIGH or CRITICAL finding needs three things: the exact file and line, the concrete trigger that produces the bad outcome, and why existing guards do not already prevent it. Missing any one, downgrade it or drop it. Do not pad the report with low-confidence noise that trains the reader to ignore the real findings.
+
+**7. Route the fixes.** Apply safe, risk-free fixes (typos, missing imports, obvious style) right away. Batch behavior-changing fixes (added null checks, new error handling) into one confirmation block instead of asking one at a time. Leave architecture and security tradeoffs for the user to decide, and mark informational notes as advisory.
+
+**8. Verify before claiming done.** Run the project's own verification (its tests, lint, type check, build, or syntax check) and read the output. For a bug fix, a regression test that fails on the old code must exist before the fix counts as done. If no verification command is available, say so plainly and call it a gap. Never present unverified work as passing.
+
+## Output
+
+Lead with the findings, most severe first, each with its file and line, the trigger, and the fix or the open question. When there are none, say so plainly: a clean review with a stated review surface is a complete result.
+
+Then a short sign-off block:
+
+- files changed, and the size of the diff
+- scope: on target, or the specific drift
+- review depth: quick, standard, or deep
+- hard stops: how many found, fixed, and deferred
+- new tests, if the change needed them
+- doc debt: any invariant the change introduced that the project docs do not yet capture
+- verification: the command that ran, and whether it passed
+
+Then stop. Do not merge, push, tag, or publish unless the user asks for it.
+
+## Conventions shared across xsk skills
+
+- Triggers are matched by intent, not by exact wording. The phrases listed under "When to use" are cues, not a required incantation.
+- Write in natural, direct prose. No formulaic openers, no filler conclusions, no restating the request before you answer it.
+- When a decision would change the implementation, surface it as a short question and let the user decide. Do not pick silently.
+- These are instruction skills. They shape how work is approached, not what the agent is technically capable of.

package/skills/skill-scaffold/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: xsk-skill-scaffold
+description: Bring an agent-skill project up to the xsk standard, or refuse if the target is not an agent-skill project.
+---
+
+# xsk-skill-scaffold
+
+Bring an agent-skill project up to the `xsk` standard, or refuse if the target is not an agent-skill project. The standard is self-owned and canonical: it lives in this skill, not in an external file that can drift.
+
+## When to use
+
+Match the intent, not the exact words. Common cues:
+
+- "scaffold skill project", "make this a skill installer", "conform to skill standard"
+- "项目规范化", "agent 技能项目脚手架"
+- any request to bring a project up to a multi-platform agent-skill installer standard
+
+## How it works
+
+**1. Gate first.** Before mutating anything, decide whether the current directory is an agent-skill project: one that has, or is intended to have, a CLI that generates and installs skill files into agent config dirs. Heuristics: a `bin/` plus `skills/` or `shared/` or `templates/`, or a `package.json` whose purpose is skill installation. If it is clearly **not** an agent-skill project (an application, a library with no install surface), **error out** with a one-sentence reason and stop. Do not mutate a non-agent-skill project.
+
+**2. Audit** the project against the canonical checklist below. Record each item as met or missing, with the concrete file or gap.
+
+**3. Propose** the gap-closing changes as a concrete, reviewable patch plan: which files to add or edit, with targets. Patch what is missing or non-conforming; do not rewrite the project wholesale.
+
+**4. Apply on approval.** Wait for explicit approval, then make the changes: add the missing `lib/` modules, wire the CLI commands, add templates, add README parity tests, add `LICENSE`. Do not apply before approval.
+
+### Canonical checklist (the standard this skill enforces)
+
+- CLI surface: `version` / `--version` / `-v`, `help` / `--help` / `-h`, `install [--platform <list>]`, `uninstall [--platform <list>]`, `status` (read-only), optional `doctor`.
+- `--platform` is optional, comma-separated, defaults to all platforms; unknown and duplicate values are rejected.
+- Unknown options fail loud.
+- `status` validates manifest **shape**, not just parse success.
+- Removed or renamed commands leave no stale references (grep-clean across CLI, help, README, generated text, `AGENTS.md`, `CLAUDE.md`).
+- Four platforms, all full: Claude Code, Codex, opencode, Gemini.
+- Manifest-backed install safety: owned-only removal, ownership markers, atomic writes, symlink refusal.
+- `install` is uninstall-first: a reinstall resets the previously-owned files (pruning skills no longer installed) before regenerating, so no manual `uninstall` is needed. It still refuses to overwrite a user-edited owned file and rolls back instead of destroying it.
+- A golden snapshot of the generated skill shell, masking embedded `shared/` body.
+- A bilingual README (`README.md` plus `README.zh-CN.md`) with identical headings, English literals preserved, and content-pinning tests.
+
+### Self-conformance
+
+A project that ships this standard must conform to it itself. The machine-checkable part is an executable self-conformance test (the five core commands resolve, EN/CN README headings match, the manifest module and `LICENSE` exist, `package.json` carries the required fields). The remainder is this skill's judgment when applied to its own source.
+
+## Output
+
+For a non-agent-skill project: a one-sentence refusal and stop, with nothing mutated.
+
+For an agent-skill project: the audit result (each checklist item, met or missing), followed by the proposed patch plan. On approval, the applied changes. Then stop.
+
+## Conventions shared across xsk skills
+
+- Triggers are matched by intent, not by exact wording. The phrases listed under "When to use" are cues, not a required incantation.
+- Write in natural, direct prose. No formulaic openers, no filler conclusions, no restating the request before you answer it.
+- When a decision would change the implementation, surface it as a short question and let the user decide. Do not pick silently.
+- These are instruction skills. They shape how work is approached, not what the agent is technically capable of.

package/skills/think/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: xsk-think
+description: Plan before coding. Weigh options, surface ambiguities, and produce a decision-complete design, then stop for approval.
+---
+
+# xsk-think
+
+Turn a rough idea into a decision-complete plan before any code is written. xsk-think does the weighing, the option-trimming, and the ambiguity-surfacing up front, so that once you approve, the implementation is mostly mechanical.
+
+It is planning-only. It writes no code, no scaffolding, and no pseudo-code.
+
+## When to use
+
+Match the intent, not the exact words. Common cues:
+
+- "出方案", "给方案", "怎么设计", "用什么方案"
+- "判断一下", "有没有必要", "值不值得"
+- "plan this", "how should I", "should we keep this"
+- any request to design something, choose between approaches, or judge whether a piece of work is worth doing
+
+## How it works
+
+**1. Preflight on durable context.** Before designing, scan `AGENTS.md`, `CLAUDE.md`, and any repo rules or config for hard constraints that would forbid or force a choice: lint rules, test conventions, locked decisions, "never do X" rules. If a hard rule conflicts with the likely plan, name it before going further.
+
+**2. Check for an existing solution first.** If a library, framework, CLI, or the codebase already solves the problem, prefer that over inventing something. Only design custom when no adequate existing solution exists.
+
+**3. Match the depth to the problem.**
+
+- **Lightweight.** Small, reversible, low-stakes. One paragraph, one recommendation, done.
+- **Evaluation.** A genuine choice between approaches. Lay out the realistic options, weigh the tradeoffs that actually matter, and recommend one with rationale. Mention a second option only if the tradeoff is genuinely close. Do not manufacture alternatives just to look thorough.
+- **Triage.** Unclear or multi-part problem. Decompose first: separate the parts, order them, and identify which part actually needs design versus which is mechanical. Then design only the part that needs it.
+
+**4. Declare premise collapse explicitly.** If the whole plan rests on one assumption that, if wrong, invalidates everything, say so as a single sentence up front: "This assumes X; if X is false, the rest does not hold."
+
+**5. No placeholders in an approved plan.** A plan is not done until every decision is concrete. No "TBD", no "figure out later", no "we'll decide". If a decision is genuinely open, it goes into Open Questions for the user to resolve, not into the plan body.
+
+**6. Stop at the design.** Output the plan, surface blocking ambiguities as one-sentence questions, then stop. Implementation starts only on explicit approval.
+
+## Output
+
+A **Proposed Design Summary** with these parts:
+
+- The recommended approach, with rationale.
+- The premise-collapse assumption, if there is one.
+- The concrete steps, structured so an executor can act without re-deciding (the handoff is execution-shaped, not exploration-shaped).
+- A short **Gotchas** table of the traps to avoid.
+- **Open Questions**, if any, that only the user can resolve.
+
+Then stop and wait for approval. Do not begin implementation.
+
+## Conventions shared across xsk skills
+
+- Triggers are matched by intent, not by exact wording. The phrases listed under "When to use" are cues, not a required incantation.
+- Write in natural, direct prose. No formulaic openers, no filler conclusions, no restating the request before you answer it.
+- When a decision would change the implementation, surface it as a short question and let the user decide. Do not pick silently.
+- These are instruction skills. They shape how work is approached, not what the agent is technically capable of.

package/skills/write-req/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: xsk-write-req
+description: Turn plain-language needs into a grounded requirement document in requirements/, with a self-audit gate before it is finalized.
+---
+
+# xsk-write-req
+
+Convert plain-language ("白话") needs into a compliant requirement document in `requirements/`, grounded in the current project's actual code. The output is a doc an implementer can act on without guessing, not a transcript of the request.
+
+## When to use
+
+Match the intent, not the exact words. Common cues:
+
+- "写需求", "需求文档", "把这个需求写清楚", "需求整理"
+- "write a requirement", "turn this into a spec"
+- any request to capture a fuzzy need as a structured, grounded requirement doc
+
+## How it works
+
+**1. Read the project first.** `grep` and `read` the current project structure, config files (`package.json` and the like), and relevant code to ground the requirement in reality. Never quote defaults from memory.
+
+**2. Locate or create the active requirement doc.** Scan `requirements/*.md` for frontmatter `status: active`. There is **at most one** active doc at a time. If more than one exists, stop, list the offending paths, and report the broken invariant for the user to resolve. If one exists, lock onto it and append or refine. If none exists, create `requirements/<slug>.md` with `status: active` and a slug generated from the need.
+
+**3. Ensure the directory convention.** Auto-create `requirements/.gitignore` containing `archive/` if it is absent (creating `requirements/` and `requirements/archive/` as needed). Never overwrite an existing `.gitignore`; append `archive/` only if the line is missing.
+
+**4. Convert fuzzy into concrete.** Match the document structure to the input richness:
+
+- A minimal one-liner becomes a concise requirement: Goal, Scope, Acceptance. Do not force a Background section that would be filler.
+- Richer input becomes Background, Goal, Scope (in and out), Requirements, Open Questions, Checkpoints.
+
+**5. Decision points go to the user.** When a genuine technical or scoping choice would change the implementation, stop and ask the user to decide. Surface the options and the tradeoffs; let them pick. Do not pick silently.
+
+**6. Brainstorm the genuinely open-ended.** Where the need is open-ended, run a short exploration with the user before writing.
+
+**7. Wording.** Natural, fluent English (or match the project's language). No em-dash (U+2014) or en-dash (U+2013). No formulaic phrasing, no filler conclusions. The author's voice wins; most editing is subtraction.
+
+**8. Self-audit checkpoint.** Before finalizing, audit the requirement against itself. A document that fails this gate is not ready.
+
+- **Conflict check:** verify no internal contradictions (Goal versus Scope, in-scope versus out-of-scope, Requirements versus Open Questions, any two statements that cannot both hold). Resolve every conflict, or surface it to the user. A finalized doc contains zero conflicts.
+- **Ambiguity check:** verify no undefined terms, unstated assumptions, or vague qualifiers ("fast", "supported", "as needed") that would force the implementer to guess. Tighten each to a concrete, testable statement. A finalized doc leaves no ambiguity that blocks implementation.
+- **Checkpoint gates:** ensure the requirement defines the verification points where downstream implementation must pause and confirm against the requirement (acceptance criteria, integration gates, review gates). If it lacks them, add them before finalizing.
+- If the audit surfaces issues only the user can resolve, stop, list them, and ask. Do not write a contradictory or under-specified doc.
+
+The document frontmatter:
+
+```markdown
+---
+status: active
+slug: <slug>
+created_at: <ISO date>
+---
+```
+
+## Output
+
+The path of the requirement file, with confirmation that it is now the single active doc.
+
+## Conventions shared across xsk skills
+
+- Triggers are matched by intent, not by exact wording. The phrases listed under "When to use" are cues, not a required incantation.
+- Write in natural, direct prose. No formulaic openers, no filler conclusions, no restating the request before you answer it.
+- When a decision would change the implementation, surface it as a short question and let the user decide. Do not pick silently.
+- These are instruction skills. They shape how work is approached, not what the agent is technically capable of.

package/templates/fragments/archive-req.behavior.md

@@ -0,0 +1,7 @@
+1. Scan `requirements/*.md` (excluding `requirements/archive/`) for the single document whose frontmatter has `status: active`. If more than one exists, stop, list the offending paths, and report the broken invariant for the user to resolve.
+2. If there is no active document, refuse with a one-line reason and stop. Do not archive anything.
+3. Read the active doc slug and validate it against `^[a-z0-9]+(-[a-z0-9]+)*$`. If the slug is missing/invalid, stop with the reason before any write.
+4. Check the archive target `requirements/archive/<slug>.md`. If it already exists, stop, ask the user how to proceed, and leave it unchanged, writing nothing.
+5. Write the fully-updated archived content to `requirements/archive/<slug>.md`: set `status: archived`, add `archived_at: <ISO date>`, and preserve every other frontmatter field and the entire body unchanged.
+6. Confirm it landed as written, then remove the source active doc.
+7. After archiving, confirm zero active documents remain.

package/templates/fragments/archive-req.output.md

@@ -0,0 +1 @@
+Either a one-line refusal that names the missing/invalid slug, a stop-and-ask response when `requirements/archive/<slug>.md` already exists and it was left unchanged, writing nothing, or the archived path (`requirements/archive/<slug>.md`) plus confirmation that it landed before the source active doc was removed and that no active requirement docs remain.

package/templates/fragments/archive-req.purpose.md

@@ -0,0 +1 @@
+Archive the active requirement document into `requirements/archive/`. After it runs, zero active requirement docs remain.

package/templates/fragments/archive-req.triggers.md

@@ -0,0 +1,5 @@
+Match the intent, not the exact words. Common cues:
+
+- "归档需求", "需求归档", "把这个需求存档"
+- "archive requirement"
+- any request to file away the current active requirement doc

package/templates/fragments/bypass-claude.behavior.md

@@ -0,0 +1,23 @@
+Operate on the **current project directory** only. The target is always `.claude/settings.local.json`.
+
+1. If the current agent is not Claude Code, refuse the request, state that this is a Claude Code-only skill, write nothing, and stop.
+
+2. Never write or modify `.claude/settings.json`.
+
+3. If `.claude/settings.local.json` does not exist, create the `.claude/` directory and write exactly:
+
+   ```json
+   {
+     "permissions": {
+       "defaultMode": "bypassPermissions"
+     }
+   }
+   ```
+
+4. If `.claude/settings.local.json` already exists, read it. If the file is invalid JSON or is not a JSON object, report that `.claude/settings.local.json` is malformed, write nothing, and stop.
+
+5. Otherwise, set only `permissions.defaultMode` to `"bypassPermissions"` in `.claude/settings.local.json`, preserve every other field and its value, and write back with 2-space indentation and a trailing newline. Do not reorder, reformat, or drop existing keys.
+
+6. If `permissions.defaultMode` is already `"bypassPermissions"`, make no change (idempotent no-op).
+
+`permissions.defaultMode = "bypassPermissions"` is the verified Claude Code setting for auto-approving tools.

package/templates/fragments/bypass-claude.output.md

@@ -0,0 +1 @@
+Report only the path written (`.claude/settings.local.json`) and that `permissions.defaultMode` is `bypassPermissions`. Do not include preserved setting values. Take no further action.

package/templates/fragments/bypass-claude.purpose.md

@@ -0,0 +1 @@
+Set the current project to Claude Code bypass-permissions mode (auto-approve tools) by writing `.claude/settings.local.json`. This is a Claude Code-only skill; it has no effect on Codex, opencode, or Gemini.

package/templates/fragments/bypass-claude.triggers.md

@@ -0,0 +1,5 @@
+Match the intent, not the exact words. Common cues:
+
+- "bypass permissions", "auto approve", "set bypassPermissions"
+- "跳过权限", "免确认", "设置 bypassPermissions"
+- any request to make Claude Code stop asking for tool approval in the current project

package/templates/fragments/check.behavior.md

@@ -0,0 +1,29 @@
+**1. Read the worktree and the diff first.** Start from `git status` and the full diff against the base branch. Treat modified, staged, and untracked files as the user's work: read them, and never discard, stash, or overwrite them without explicit approval. If the base or the review range is unclear, ask before guessing.
+
+**2. Did the change build what was asked? Check scope drift.** Every changed file and every new surface must trace back to the stated goal in one sentence. A pure refactor folded into a bug fix, a new dependency the goal never mentioned, or a new abstraction nothing requires is drift until justified. Label the change on target, drift, or incomplete.
+
+**3. Classify depth, then state it.** Quick for a small, low-risk change. Standard for a medium one. Deep when the diff is large or touches auth, payments, data mutation, or destructive operations. A deeper change earns a wider read of its callers and consumers, not just the changed lines.
+
+**4. Apply the hard stops. Fix or flag before merge.**
+
+- No unverified claims. Never write "tests pass", "I verified", or "this fixes it" unless the command output is in front of you this session. If the judgment comes from reading the code, say that instead.
+- Re-read before citing a fact. Line numbers, file state, branch position, and fallback behavior go stale. Re-check them in this pass rather than trusting memory.
+- Secrets and injection. No credential hardcoded, logged, or committed. Watch for SQL, shell, and path injection at every entry point.
+- Unexpected dependencies. Flag any added or version-bumped dependency the goal does not obviously require.
+- Unknown identifiers. Grep before approving any symbol the diff introduces. No match outside the diff means it does not exist.
+- Dead-code deletion needs proof. A "zero callers" claim must be checked across the whole repo, including tests, scripts, and dynamic lookups, before anything is removed.
+- Safety sinks. Destructive file operations, path or symlink traversal, and approval-boundary changes need explicit validation, rollback, and confirmation review.
+- Generated-artifact drift. If sources change, the generated or bundled output must be regenerated and included.
+- String-matching on captured output. A subprocess run with inherited stdio streams its diagnostics to the terminal, not into the error message, which then holds only the command line. A matcher on that string silently matches the command, not the output. Probe the real value, or branch on a structured fact such as the exit code.
+- Audit before restore. When the diff re-adds a symbol, string, or field that history removed, grep first to confirm anything still uses it. A rule or test that merely names it is not proof of life.
+- Migration code for unshipped features. Reject "carry the old key forward" logic when the key never shipped. Check the last release tag: if it is absent there, no migration is needed, so ship the default.
+- Install and runtime proof. For a skill, plugin, package, or installer, metadata and source tests are not enough. Build or install through the real user path, or mark that layer unverified.
+- Verifier failure layer. When a check fails before its assertions run, from setup, a missing optional dependency, or the environment, classify setup failure versus product failure. Do not call the code broken until the real test body actually ran.
+
+**5. Sweep the pattern, not just the instance.** When the change fixes one case of a bug class, grep the repo for siblings of the same shape and confirm they were handled too. List any that were missed.
+
+**6. Gate every finding on evidence.** A HIGH or CRITICAL finding needs three things: the exact file and line, the concrete trigger that produces the bad outcome, and why existing guards do not already prevent it. Missing any one, downgrade it or drop it. Do not pad the report with low-confidence noise that trains the reader to ignore the real findings.
+
+**7. Route the fixes.** Apply safe, risk-free fixes (typos, missing imports, obvious style) right away. Batch behavior-changing fixes (added null checks, new error handling) into one confirmation block instead of asking one at a time. Leave architecture and security tradeoffs for the user to decide, and mark informational notes as advisory.
+
+**8. Verify before claiming done.** Run the project's own verification (its tests, lint, type check, build, or syntax check) and read the output. For a bug fix, a regression test that fails on the old code must exist before the fix counts as done. If no verification command is available, say so plainly and call it a gap. Never present unverified work as passing.

package/templates/fragments/check.output.md

@@ -0,0 +1,13 @@
+Lead with the findings, most severe first, each with its file and line, the trigger, and the fix or the open question. When there are none, say so plainly: a clean review with a stated review surface is a complete result.
+
+Then a short sign-off block:
+
+- files changed, and the size of the diff
+- scope: on target, or the specific drift
+- review depth: quick, standard, or deep
+- hard stops: how many found, fixed, and deferred
+- new tests, if the change needed them
+- doc debt: any invariant the change introduced that the project docs do not yet capture
+- verification: the command that ran, and whether it passed
+
+Then stop. Do not merge, push, tag, or publish unless the user asks for it.

package/templates/fragments/check.purpose.md

@@ -0,0 +1,3 @@
+Review a code change against its goal and the available evidence before it merges or ships. Read the diff, find the real problems, fix what is safe to fix, surface the rest, and verify before calling anything done. Distilled from the default-review discipline of Waza `/check`.
+
+It reviews code diffs and changes, not prose. A clean review is a valid result: do not invent findings to look thorough, and do not approve a risky change just to seem agreeable.

package/templates/fragments/check.triggers.md

@@ -0,0 +1,5 @@
+Match the intent, not the exact words. Common cues:
+
+- "看看代码", "检查一下", "有没有问题", "是否需要优化", "合并前"
+- "review my code", "check this change", "before merge", "code review"
+- any request to review a diff, a pull request, or a pending change for correctness and quality before it ships

package/templates/fragments/skill-scaffold.behavior.md

@@ -0,0 +1,24 @@
+**1. Gate first.** Before mutating anything, decide whether the current directory is an agent-skill project: one that has, or is intended to have, a CLI that generates and installs skill files into agent config dirs. Heuristics: a `bin/` plus `skills/` or `shared/` or `templates/`, or a `package.json` whose purpose is skill installation. If it is clearly **not** an agent-skill project (an application, a library with no install surface), **error out** with a one-sentence reason and stop. Do not mutate a non-agent-skill project.
+
+**2. Audit** the project against the canonical checklist below. Record each item as met or missing, with the concrete file or gap.
+
+**3. Propose** the gap-closing changes as a concrete, reviewable patch plan: which files to add or edit, with targets. Patch what is missing or non-conforming; do not rewrite the project wholesale.
+
+**4. Apply on approval.** Wait for explicit approval, then make the changes: add the missing `lib/` modules, wire the CLI commands, add templates, add README parity tests, add `LICENSE`. Do not apply before approval.
+
+### Canonical checklist (the standard this skill enforces)
+
+- CLI surface: `version` / `--version` / `-v`, `help` / `--help` / `-h`, `install [--platform <list>]`, `uninstall [--platform <list>]`, `status` (read-only), optional `doctor`.
+- `--platform` is optional, comma-separated, defaults to all platforms; unknown and duplicate values are rejected.
+- Unknown options fail loud.
+- `status` validates manifest **shape**, not just parse success.
+- Removed or renamed commands leave no stale references (grep-clean across CLI, help, README, generated text, `AGENTS.md`, `CLAUDE.md`).
+- Four platforms, all full: Claude Code, Codex, opencode, Gemini.
+- Manifest-backed install safety: owned-only removal, ownership markers, atomic writes, symlink refusal.
+- `install` is uninstall-first: a reinstall resets the previously-owned files (pruning skills no longer installed) before regenerating, so no manual `uninstall` is needed. It still refuses to overwrite a user-edited owned file and rolls back instead of destroying it.
+- A golden snapshot of the generated skill shell, masking embedded `shared/` body.
+- A bilingual README (`README.md` plus `README.zh-CN.md`) with identical headings, English literals preserved, and content-pinning tests.
+
+### Self-conformance
+
+A project that ships this standard must conform to it itself. The machine-checkable part is an executable self-conformance test (the five core commands resolve, EN/CN README headings match, the manifest module and `LICENSE` exist, `package.json` carries the required fields). The remainder is this skill's judgment when applied to its own source.

package/templates/fragments/skill-scaffold.output.md

@@ -0,0 +1,3 @@
+For a non-agent-skill project: a one-sentence refusal and stop, with nothing mutated.
+
+For an agent-skill project: the audit result (each checklist item, met or missing), followed by the proposed patch plan. On approval, the applied changes. Then stop.

package/templates/fragments/skill-scaffold.purpose.md

@@ -0,0 +1 @@
+Bring an agent-skill project up to the `xsk` standard, or refuse if the target is not an agent-skill project. The standard is self-owned and canonical: it lives in this skill, not in an external file that can drift.

package/templates/fragments/skill-scaffold.triggers.md

@@ -0,0 +1,5 @@
+Match the intent, not the exact words. Common cues:
+
+- "scaffold skill project", "make this a skill installer", "conform to skill standard"
+- "项目规范化", "agent 技能项目脚手架"
+- any request to bring a project up to a multi-platform agent-skill installer standard

package/templates/fragments/think.behavior.md

@@ -0,0 +1,15 @@
+**1. Preflight on durable context.** Before designing, scan `AGENTS.md`, `CLAUDE.md`, and any repo rules or config for hard constraints that would forbid or force a choice: lint rules, test conventions, locked decisions, "never do X" rules. If a hard rule conflicts with the likely plan, name it before going further.
+
+**2. Check for an existing solution first.** If a library, framework, CLI, or the codebase already solves the problem, prefer that over inventing something. Only design custom when no adequate existing solution exists.
+
+**3. Match the depth to the problem.**
+
+- **Lightweight.** Small, reversible, low-stakes. One paragraph, one recommendation, done.
+- **Evaluation.** A genuine choice between approaches. Lay out the realistic options, weigh the tradeoffs that actually matter, and recommend one with rationale. Mention a second option only if the tradeoff is genuinely close. Do not manufacture alternatives just to look thorough.
+- **Triage.** Unclear or multi-part problem. Decompose first: separate the parts, order them, and identify which part actually needs design versus which is mechanical. Then design only the part that needs it.
+
+**4. Declare premise collapse explicitly.** If the whole plan rests on one assumption that, if wrong, invalidates everything, say so as a single sentence up front: "This assumes X; if X is false, the rest does not hold."
+
+**5. No placeholders in an approved plan.** A plan is not done until every decision is concrete. No "TBD", no "figure out later", no "we'll decide". If a decision is genuinely open, it goes into Open Questions for the user to resolve, not into the plan body.
+
+**6. Stop at the design.** Output the plan, surface blocking ambiguities as one-sentence questions, then stop. Implementation starts only on explicit approval.

package/templates/fragments/think.output.md

@@ -0,0 +1,9 @@
+A **Proposed Design Summary** with these parts:
+
+- The recommended approach, with rationale.
+- The premise-collapse assumption, if there is one.
+- The concrete steps, structured so an executor can act without re-deciding (the handoff is execution-shaped, not exploration-shaped).
+- A short **Gotchas** table of the traps to avoid.
+- **Open Questions**, if any, that only the user can resolve.
+
+Then stop and wait for approval. Do not begin implementation.

package/templates/fragments/think.purpose.md

@@ -0,0 +1,3 @@
+Turn a rough idea into a decision-complete plan before any code is written. xsk-think does the weighing, the option-trimming, and the ambiguity-surfacing up front, so that once you approve, the implementation is mostly mechanical.
+
+It is planning-only. It writes no code, no scaffolding, and no pseudo-code.

package/templates/fragments/think.triggers.md

@@ -0,0 +1,6 @@
+Match the intent, not the exact words. Common cues:
+
+- "出方案", "给方案", "怎么设计", "用什么方案"
+- "判断一下", "有没有必要", "值不值得"
+- "plan this", "how should I", "should we keep this"
+- any request to design something, choose between approaches, or judge whether a piece of work is worth doing

package/templates/fragments/write-req.behavior.md

@@ -0,0 +1,33 @@
+**1. Read the project first.** `grep` and `read` the current project structure, config files (`package.json` and the like), and relevant code to ground the requirement in reality. Never quote defaults from memory.
+
+**2. Locate or create the active requirement doc.** Scan `requirements/*.md` for frontmatter `status: active`. There is **at most one** active doc at a time. If more than one exists, stop, list the offending paths, and report the broken invariant for the user to resolve. If one exists, lock onto it and append or refine. If none exists, create `requirements/<slug>.md` with `status: active` and a slug generated from the need.
+
+**3. Ensure the directory convention.** Auto-create `requirements/.gitignore` containing `archive/` if it is absent (creating `requirements/` and `requirements/archive/` as needed). Never overwrite an existing `.gitignore`; append `archive/` only if the line is missing.
+
+**4. Convert fuzzy into concrete.** Match the document structure to the input richness:
+
+- A minimal one-liner becomes a concise requirement: Goal, Scope, Acceptance. Do not force a Background section that would be filler.
+- Richer input becomes Background, Goal, Scope (in and out), Requirements, Open Questions, Checkpoints.
+
+**5. Decision points go to the user.** When a genuine technical or scoping choice would change the implementation, stop and ask the user to decide. Surface the options and the tradeoffs; let them pick. Do not pick silently.
+
+**6. Brainstorm the genuinely open-ended.** Where the need is open-ended, run a short exploration with the user before writing.
+
+**7. Wording.** Natural, fluent English (or match the project's language). No em-dash (U+2014) or en-dash (U+2013). No formulaic phrasing, no filler conclusions. The author's voice wins; most editing is subtraction.
+
+**8. Self-audit checkpoint.** Before finalizing, audit the requirement against itself. A document that fails this gate is not ready.
+
+- **Conflict check:** verify no internal contradictions (Goal versus Scope, in-scope versus out-of-scope, Requirements versus Open Questions, any two statements that cannot both hold). Resolve every conflict, or surface it to the user. A finalized doc contains zero conflicts.
+- **Ambiguity check:** verify no undefined terms, unstated assumptions, or vague qualifiers ("fast", "supported", "as needed") that would force the implementer to guess. Tighten each to a concrete, testable statement. A finalized doc leaves no ambiguity that blocks implementation.
+- **Checkpoint gates:** ensure the requirement defines the verification points where downstream implementation must pause and confirm against the requirement (acceptance criteria, integration gates, review gates). If it lacks them, add them before finalizing.
+- If the audit surfaces issues only the user can resolve, stop, list them, and ask. Do not write a contradictory or under-specified doc.
+
+The document frontmatter:
+
+```markdown
+---
+status: active
+slug: <slug>
+created_at: <ISO date>
+---
+```

package/templates/fragments/write-req.output.md

@@ -0,0 +1 @@
+The path of the requirement file, with confirmation that it is now the single active doc.

package/templates/fragments/write-req.purpose.md

@@ -0,0 +1 @@
+Convert plain-language ("白话") needs into a compliant requirement document in `requirements/`, grounded in the current project's actual code. The output is a doc an implementer can act on without guessing, not a transcript of the request.

package/templates/fragments/write-req.triggers.md

@@ -0,0 +1,5 @@
+Match the intent, not the exact words. Common cues:
+
+- "写需求", "需求文档", "把这个需求写清楚", "需求整理"
+- "write a requirement", "turn this into a spec"
+- any request to capture a fuzzy need as a structured, grounded requirement doc

package/templates/skill.md.tmpl

@@ -0,0 +1,22 @@
+---
+name: {{NAME}}
+description: {{DESCRIPTION}}
+---
+
+# {{NAME}}
+
+{{PURPOSE}}
+
+## When to use
+
+{{TRIGGERS}}
+
+## How it works
+
+{{BEHAVIOR}}
+
+## Output
+
+{{OUTPUT}}
+
+{{SHARED}}