ck is a Claude Code project memory skill for persistent context across sessions. It registers projects, auto-loads briefing data on start, and supports save, resume, info, list, forget, and migrate workflows through deterministic Node.js scripts. A strong fit for ck for Context Engineering.
This skill scores 82/100, which means it is a solid directory listing candidate for users who want persistent per-project memory in Claude Code. The repository gives agents clear command triggers, deterministic script execution, and enough command-level behavior to reduce guesswork versus a generic prompt, though install and setup expectations are still somewhat implicit.
- Strong triggerability: SKILL.md maps `/ck:*` commands to specific Node scripts and tells the agent to present stdout verbatim.
- Real operational substance: the repo includes working command scripts for init, save, resume, list, info, forget, and migrate rather than only descriptive prose.
- Useful workflow leverage: init auto-detects project metadata and save writes structured context plus native memory, making repeated project resumption more reliable.
- Install/setup clarity is incomplete: SKILL.md references `~/.claude/skills/ck/commands/` and data paths but does not provide an install command in the skill file.
- Some workflows still rely on agent judgment, such as confirmation/edit steps before `save.mjs --init` and manual caution before destructive `forget` behavior.
Overview of ck skill
What ck does
ck is a project memory skill for Claude Code that stores reusable context outside the current chat. It is built for people who work across multiple repositories and want session continuity without rewriting the same background every time. The core job-to-be-done is simple: register a project once, then save, resume, inspect, list, and forget context through deterministic Node.js commands.
Who should install the ck skill
The best fit for the ck skill is developers using Claude Code for ongoing repository work, especially when project goals, constraints, and decisions need to survive across sessions. It is also a strong fit for ck for Context Engineering because it separates durable project memory from ad hoc prompt history. If you mostly do one-off prompts or do not use Claude Code's local skill system, ck is less useful.
Why ck is different from a normal prompt
A normal prompt can summarize a repo once. ck adds persistent structure: a project registry in ~/.claude/ck/projects.json, a per-project context.json source of truth, a generated CONTEXT.md, and a session-start hook that can auto-load project context. The practical differentiator is consistency: commands call local scripts, so the workflow is less model-dependent than asking the assistant to "remember this" informally.
How to Use ck skill
Install context and files to read first
For ck install, use the Claude Code skills mechanism, then inspect skills/ck/SKILL.md first. After that, read:
commands/init.mjscommands/save.mjscommands/resume.mjscommands/info.mjshooks/session-start.mjs
That reading order matters. init.mjs shows what metadata ck tries to infer from the current repo, save.mjs defines the exact JSON schemas, and resume.mjs / info.mjs show what you will actually get back during daily use.
How ck is called in practice
The ck usage model is command-based. Main commands are:
/ck:initto register the current project/ck:saveto save session state/ck:resumeto load a full briefing/ck:infofor a quick snapshot/ck:listto view all registered projects/ck:forgetto remove a project/ck:migrateto convert older v1 data
A key implementation detail: ck expects the assistant to run Node scripts under ~/.claude/skills/ck/commands/ and present stdout cleanly. For init, it should not save immediately; it first drafts detected project details and waits for user confirmation before piping confirmed JSON into save.mjs --init.
What input produces better results
ck works best when you provide missing project facts that auto-detection cannot infer well. Strong inputs for /ck:init include:
- clear project name
- one-sentence description
- primary stack
- current goal
- explicit constraints or "do nots"
- repository URL if available
For /ck:save, stronger session input looks like:
summary: what changed this sessionleftOff: the exact stopping pointnextSteps: 2-5 concrete follow-upsdecisions: what was decided and whyblockers: unresolved issues
Weak input: "worked on auth."
Strong input: "Implemented refresh token rotation, left off at failing integration tests in apps/api/tests/auth.spec.ts, next step is fixing cookie domain handling, decision was to keep server-side revocation for now because mobile clients are not ready."
Suggested workflow for real projects
A practical ck guide is:
- In a repo root, run
/ck:init. - Review and correct the detected draft before confirming.
- At the end of meaningful work, run
/ck:save. - On the next session, use
/ck:resumefor full context or/ck:infofor a quick check. - Use
/ck:listwhen switching between projects.
If adopting ck for Context Engineering, treat it as your durable project briefing layer. Keep short-lived brainstorming in chat, but move stable facts, decisions, and next steps into ck so future sessions start from a cleaner state.
ck skill FAQ
Is ck beginner-friendly?
Mostly yes, if you are already comfortable with Claude Code and local command execution. The concept is straightforward, but the skill is more operational than conversational. Beginners may need to read SKILL.md carefully to understand the confirmation step, JSON handoff, and where data is stored.
When is ck better than ordinary prompting?
ck is better when the same project recurs over days or weeks. It is not just a smarter prompt template; it keeps structured project memory on disk and can reload it consistently. If your work is temporary or single-session, a regular prompt is usually enough and faster.
What are the main boundaries or risks?
The biggest boundary is that ck is only as good as what gets saved. If users skip /ck:save, the memory layer stays stale. Another constraint is fit: this is designed around Claude Code's local skills and filesystem conventions like ~/.claude/ck/. It is not a general cloud memory service. Also, CONTEXT.md is generated, so hand-editing it is the wrong place to maintain truth.
How to Improve ck skill
Give ck better project registration inputs
The highest-leverage improvement for ck is better initialization quality. Auto-detection from package.json, README content, or git metadata is helpful, but often incomplete. Correct the draft aggressively at /ck:init time. A precise goal and explicit constraints make later /ck:resume outputs much more useful than generic stack labels alone.
Avoid the most common failure modes
Common ck problems are predictable:
- registering from the wrong directory
- saving vague summaries
- forgetting to update next steps
- assuming generated markdown is the source of truth
- deleting context without confirming project identity first
If outputs feel weak, inspect whether the underlying context.json actually contains enough detail. Most quality issues come from sparse saved state, not from the command scripts themselves.
Iterate after the first output
To improve ck usage, do not treat the first saved context as final. After /ck:resume, ask: what is missing that I would need tomorrow with zero extra chat history? Then save again with sharper decisions, blockers, and stopping points. The best ck skill setups evolve into compact, high-value briefings rather than long diary entries.