plugins/src/base/skills/lisa-wiki-install/SKILL.md
Bootstrap the LLM Wiki kernel (lisa-wiki plugin) in a host project. Solves the chicken-and-egg gap: the base lisa plugin can install the wiki plugin so its setup skill becomes discoverable. Edits .claude/settings.json to enable lisa-wiki@lisa and confirm the CodySwannGT/lisa marketplace, then for Codex verifies whether the .codex/skills/lisa overlay already carries lisa-wiki-* skills (printed by Lisa's apply) and nudges the user to refresh the overlay if missing. Idempotent. Never auto-runs `lisa apply`. After this skill, reload the runtime and run /setup:wiki (Claude) or $lisa-wiki-setup (Codex) to scaffold the wiki itself.
npx skillsauth add codyswanngt/lisa lisa-wiki-installInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill makes the lisa-wiki plugin visible in the current project so its scaffolder (/setup:wiki / $lisa-wiki-setup) can run. It does not scaffold the wiki itself — that is the wiki plugin's job. This skill only flips the install bit and verifies the Codex overlay carries the kernel.
lisa-wiki is published as AVAILABLE (not INSTALLED_BY_DEFAULT) in Lisa's marketplace. A downstream project that never enabled it has no way to discover the wiki's setup command — a chicken-and-egg bootstrap gap. Because the base lisa plugin is auto-enabled everywhere, putting the bootstrap here is what makes the wiki reachable.
The two runtimes work differently:
.claude/settings.json enabledPlugins. The wiki skills are invisible until lisa-wiki@lisa is enabled there. This skill makes that edit.src/codex/skills-installer.ts runs from Lisa.apply() and copies every built plugins/<p>/skills/<n>/ into .codex/skills/lisa/). Wiki skills land in that overlay automatically every time the project re-applies Lisa. This skill does not mutate Codex config — it only checks whether the overlay carries lisa-wiki-setup and tells the user how to refresh if missing.cwd="$(pwd)"
if [ -f "$cwd/.lisa-source" ] || { [ -d "$cwd/plugins/src/base" ] && [ -f "$cwd/.claude-plugin/marketplace.json" ]; }; then
echo "This is the Lisa monorepo itself — the base plugin's wiki kernel already lives here."
echo "Run /setup:wiki to scaffold a wiki, or invoke this skill from inside a downstream project."
exit 0
fi
Read <cwd>/.claude/settings.json (create with {} if absent). Then, using the Edit or Write tool with valid JSON (not jq one-liners that risk corrupting comments / formatting):
Ensure enabledPlugins is an object.
Set enabledPlugins["lisa-wiki@lisa"] = true.
Ensure extraKnownMarketplaces is an object containing the entry below if it is not already present (do not overwrite an existing entry):
"CodySwannGT/lisa": {
"source": {
"source": "github",
"repo": "CodySwannGT/lisa"
}
}
Pretty-print the file with 2-space indentation and a trailing newline.
If enabledPlugins["lisa-wiki@lisa"] was already true, log "Claude: lisa-wiki@lisa already enabled — no change." If not, log "Claude: enabled lisa-wiki@lisa in .claude/settings.json."
Do not edit .claude/settings.local.json — that file is per-user and is not the right surface for a project-level enablement.
codex_wiki_setup=".codex/skills/lisa/lisa-wiki-setup/SKILL.md"
if [ -f "$codex_wiki_setup" ]; then
echo "Codex: lisa-wiki overlay already present (found $codex_wiki_setup). Nothing to do for Codex."
else
echo "Codex: lisa-wiki skills not found in .codex/skills/lisa/."
if [ -d ".agents" ] || [ -d ".codex" ]; then
echo " → This project appears Codex-wired but its overlay is stale or predates lisa-wiki."
echo " → Refresh it by running your project's Lisa apply command, e.g.:"
echo " npx lisa --harness=codex ."
echo " (or whatever shape your project uses to apply Lisa for Codex)."
else
echo " → This project does not have a Codex installation yet (no .agents/ or .codex/). Skip if Codex parity is not needed."
fi
fi
Do not invoke lisa apply automatically. lisa apply rewrites more than the wiki overlay; it must remain the user's explicit choice.
Print:
Wiki kernel install complete.
Next steps:
• Reload your runtime so it picks up the newly-enabled plugin (Claude: /reload or restart the session; Codex: restart `codex`).
• Then run /setup:wiki (Claude) or $lisa-wiki-setup (Codex) to scaffold wiki/ in this project.
~/.codex/config.toml or any user-global config.lisa apply on the user's behalf..claude/settings.local.json — it is user-scoped overrides.lisa-wiki-setup (the actual scaffolder, lives in the lisa-wiki plugin once enabled), lisa-wiki-doctor, lisa-wiki-usage.
development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.