persistent-python

Persistent Python

ALWAYS use the clikernel MCP server for ALL Python work: writing code, editing code or notebooks, running or debugging anything, inspecting objects or packages, probing APIs, and transforming data. It is the workbench for every task in this environment. If the work could go through Python, it goes through clikernel. Do not fall back to python -c, shell heredocs, or ad hoc scripts.

The server's execute tool runs code in one persistent IPython session, so imports, variables, monkeypatches, and cached objects carry across calls. Check the clikernel MCP server instructions already in your context before the first call. Normally the startup script has run, and its output says what is imported and which cells to run next. Follow it. If the instructions report that project imports were skipped, or contain no startup output, report that to the user before other work. Then run the guarded import block from $XDG_CONFIG_HOME/clikernel/startup.py (default ~/.config/clikernel/startup.py) as one execute call. That file is the single source of truth for bootstrap imports; never retype them from memory.

Complete every practice task named in the server instructions (the llmdojo round started by dojo_start()) before any other work. This gate applies in every session, including tasks that only read files or search directories.

The server instructions and startup docs cover the tools, notebook magics, output shape, interaction rules, reload gotchas, and pyskills workflow, so this skill does not repeat them. list_pyskills() shows the available tooling. Prefer a relevant pyskill over ad hoc code.

Environment specifics

The following apply specifically to this environment:

• Doc-state persists on disk per conversation and is managed mechanically (the compaction hook resets it when your context is rewritten), so there is nothing to run by hand: doc notes fire exactly for the functions whose docs you don't hold. After a kernel restart or compaction, just read doc(f) again whenever a note fires.
• Use exhash for ALL edits -- code, tests, config, prose, notebook cells -- never the host's built-in file-edit tools, and read with lnhashview_* (not the host's file reader) the moment an edit is plausible. llmsurgery.dlgskill covers the structural cell/message operations exhash doesn't; fastcore.tools file editors are the rare fallback where exhash can't express a text edit.
• Claude Code settings are plain JSON: ~/.claude/settings.json (user-global), .claude/settings.json (project, committed), .claude/settings.local.json (project, personal); later files override earlier. Edit them with the normal kernel tooling (lnhashview_file + %%exhash), merging into existing keys rather than replacing, then verify with json.load. Useful facts: a BARE tool name in permissions.deny removes that tool from the system prompt entirely, while a scoped rule (Bash(rm *)) only blocks matching calls; hooks live under "hooks" keyed by event (PreToolUse, SessionStart, UserPromptSubmit, ...); skillOverrides hides bundled skills ("off", or "user-invocable-only" to keep the slash command usable by the user). Settings load at startup, so changes take effect from the next session.
• Narration between consecutive tool calls must ride inside a tool call, since mid-run assistant text is neither shown nor saved (anthropics/claude-code#75900). For clikernel work that means a separate execute call containing only a Python comment: one or two prose lines starting #, saying what the last result showed and what comes next. It runs as a no-op, renders in the transcript, and persists across resume. Retire this practice when the issue is fixed.