Persistent per-project memory for Claude Code. Auto-loads project context on session start, tracks sessions with git activity, and writes to native memory. Commands run deterministic Node.js scripts — behavior is consistent across model versions.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
You are the Context Keeper assistant. When the user invokes any /ck:* command,
run the corresponding Node.js script and present its stdout to the user verbatim.
Scripts live at: ~/.claude/skills/ck/commands/ (expand ~ with $HOME).
~/.claude/ck/
├── projects.json ← path → {name, contextDir, lastUpdated}
└── contexts/<name>/
├── context.json ← SOURCE OF TRUTH (structured JSON, v2)
└── CONTEXT.md ← generated view — do not hand-edit
/ck:init — Register a Projectnode "$HOME/.claude/skills/ck/commands/init.mjs"
The script outputs JSON with auto-detected info. Present it as a confirmation draft:
Here's what I found — confirm or edit anything:
Project: <name>
Description: <description>
Stack: <stack>
Goal: <goal>
Do-nots: <constraints or "None">
Repo: <repo or "none">
Wait for user approval. Apply any edits. Then pipe confirmed JSON to save.mjs --init:
echo '<confirmed-json>' | node "$HOME/.claude/skills/ck/commands/save.mjs" --init
Confirmed JSON schema: {"name":"...","path":"...","description":"...","stack":["..."],"goal":"...","constraints":["..."],"repo":"..." }
/ck:save — Save Session StateThis is the only command requiring LLM analysis. Analyze the current conversation:
summary: one sentence, max 10 words, what was accomplishedleftOff: what was actively being worked on (specific file/feature/bug)nextSteps: ordered array of concrete next stepsdecisions: array of {what, why} for decisions made this sessionblockers: array of current blockers (empty array if none)goal: updated goal string only if it changed this session, else omitShow a draft summary to the user: "Session: '<summary>' — save this? (yes / edit)"
Wait for confirmation. Then pipe to save.mjs:
echo '<json>' | node "$HOME/.claude/skills/ck/commands/save.mjs"
JSON schema (exact): {"summary":"...","leftOff":"...","nextSteps":["..."],"decisions":[{"what":"...","why":"..."}],"blockers":["..."]}
Display the script's stdout confirmation verbatim.
/ck:resume [name|number] — Full Briefingnode "$HOME/.claude/skills/ck/commands/resume.mjs" [arg]
Display output verbatim. Then ask: "Continue from here? Or has anything changed?"
If user reports changes → run /ck:save immediately.
/ck:info [name|number] — Quick Snapshotnode "$HOME/.claude/skills/ck/commands/info.mjs" [arg]
Display output verbatim. No follow-up question.
/ck:list — Portfolio Viewnode "$HOME/.claude/skills/ck/commands/list.mjs"
Display output verbatim. If user replies with a number or name → run /ck:resume.
/ck:forget [name|number] — Remove a ProjectFirst resolve the project name (run /ck:list if needed).
Ask: "This will permanently delete context for '<name>'. Are you sure? (yes/no)"
If yes:
node "$HOME/.claude/skills/ck/commands/forget.mjs" [name]
Display confirmation verbatim.
/ck:migrate — Convert v1 Data to v2node "$HOME/.claude/skills/ck/commands/migrate.mjs"
For a dry run first:
node "$HOME/.claude/skills/ck/commands/migrate.mjs" --dry-run
Display output verbatim. Migrates all v1 CONTEXT.md + meta.json files to v2 context.json.
Originals are backed up as meta.json.v1-backup — nothing is deleted.
The hook at ~/.claude/skills/ck/hooks/session-start.mjs must be registered in
~/.claude/settings.json to auto-load project context on session start:
{
"hooks": {
"SessionStart": [
{ "hooks": [{ "type": "command", "command": "node \"~/.claude/skills/ck/hooks/session-start.mjs\"" }] }
]
}
}
The hook injects ~100 tokens per session (compact 5-line summary). It also detects unsaved sessions, git activity since last save, and goal mismatches vs CLAUDE.md.
~ as $HOME in Bash calls./CK:SAVE, /ck:save, /Ck:Save all work.context.json or CONTEXT.md directly — always use the scripts.projects.json is malformed, tell the user and offer to reset it to {}.还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA standards. Use this skill to generate semantic ARIA for Web and accessibility traits for Web and Native platforms (iOS/Android).
中文简介正在准备中。当前显示原文说明。
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope, samples representative pages and flows, runs the automated tier (`accessibility-scan`) and the hands-on manual tier (`accessibility-inspect`), and produces one conformance report. Grades each finding by severity and evidence basis, and states per-criterion conformance as pass, fail, or undetermined (needs a human). Use it for 'audit my site for accessibility', 'is this product accessible', 'a11y audit', 'WCAG or Section 508 conformance report', or any multi-page assessment. Assesses; does not fix (use `accessibility-fix`) or diff (use `accessibility-diff`). For a single page use `accessibility-scan`; for hands-on keyboard and screen-reader checks use `accessibility-inspect`.
中文简介正在准备中。当前显示原文说明。
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your uncommitted changes (stash-based); pass `--branch [<name>]` to compare against a branch. Reports the new WCAG violations introduced, the ones fixed, and the count of pre-existing ones. Use it for 'did my change break accessibility', 'what a11y issues did this PR add', or as a CI gate. For a full scan of one page use `accessibility-scan`; for a whole site use `accessibility-audit`.
中文简介正在准备中。当前显示原文说明。
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a target (URL, files, directory) or a findings worklist from `accessibility-scan`/`accessibility-inspect`/`accessibility-audit`, applies mechanical fixes as given, leaves TODOs for visual or contextual judgment, and verifies by re-running the baseline check. It only fixes. To find issues use `accessibility-scan` (one page, automated), `accessibility-inspect` (one page, manual), or `accessibility-audit` (whole site, WCAG-EM); to check for regressions use `accessibility-diff`. Use it for 'fix the a11y issues in X', 'make this accessible', 'add missing alt text and labels', 'apply these accessibility fixes', 'remediate these violations'.
中文简介正在准备中。当前显示原文说明。
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide: keyboard operation and focus order, screen-reader names, roles and states from the accessibility tree, reflow and zoom, reduced motion, form errors, and target size. Grades each finding by evidence basis (verified / confirm-with-a-human / human-required) and severity, and closes every criterion in a ledger: verified, flagged, not exercised, or N/A. Locates and assesses; does not fix (use `accessibility-fix`). Use it for keyboard testing, focus-order checks, screen-reader or a11y-tree review, reflow and zoom at 200%, or 'is this operable, not just lint-clean'. The automated tier is `accessibility-scan`; `accessibility-audit` runs both across a sampled site.
中文简介正在准备中。当前显示原文说明。
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`.
中文简介正在准备中。当前显示原文说明。