feat: add claude code skills integration

[Jatin Mayekar (jatinmayekar)]

What

Adds openwiki integration claude [path], a command that scaffolds two Claude Code skills —
openwiki-init and openwiki-update — into .claude/skills/ in the target repo. The user then
runs /openwiki-init inside Claude Code, and Claude Code itself generates and maintains the
openwiki/ wiki using its own inference. No OpenWiki provider or API key is involved.

Scope is deliberately narrow: code mode only, one command, and the only files ever written
are under .claude/skills/. No new provider, no repository-file modification, no marketplace
metadata, no helper tooling.

Why

A large group of users already have Claude Code and just want repo docs generated without setting up
and paying for a second inference provider. This closes #156 (and overlaps #349).

It's also, as far as I can tell, the only shape Anthropic's terms permit here. A Claude-subscription
provider inside OpenWiki would have OpenWiki route requests through the user's Pro/Max credentials,
which Anthropic does not allow for
third-party developers. Scaffolding skills that run inside Claude Code, on the user's own
credentials, avoids that entirely — OpenWiki never sees a token. (This likely explains why #160,
#181 and #293 have stalled.) This is a smaller, single-concern alternative to the plugins approach in
#76 (thanks kylin0421) — happy to close in favor of that if you'd rather consolidate.

Design: rendered from prompt.ts, not vendored

The skill bodies are generated from the same prompt the OpenWiki agent already uses, so they
can't drift from the CLI. The shared methodology (documentation goals, OKF front-matter rules,
concept-graph modeling, section quality, coverage/backlog) is extracted from createSystemPrompt
into exported functions that both the live prompt and the skills renderer consume.

Two things are authored specifically for the keyless surface, because the CLI does them outside
the agent and a host coding agent can't invoke them:

• writing openwiki/.last-update.json,
• generating directory index.md deterministically, and
• getting OKF front matter right in place, since there's no post-run repair pass (an
  okfFrontMatterRules(..., { repairPass }) flag toggles that one bullet).

The Claude Code surface also uses real relative paths (openwiki/quickstart.md) instead of
OpenWiki's virtual /openwiki/... paths, and its own tool vocabulary.

Files

• src/agent/prompt.ts — extract 5 methodology blocks into exported functions (behavior-preserving;
  see test), add the repairPass flag and MethodologyContext type.
• src/integrations/claude-code.ts — the skills renderer (new).
• src/commands.ts — parse integration claude [path] + help.
• src/cli.tsx — one dispatch branch + handler.
• test/claude-code-integration.test.ts — command parsing + rendered-skill assertions (new).
• test/prompt.test.ts — regression test asserting createSystemPrompt still embeds each extracted
  block verbatim.

Most of the prompt.ts line count is methodology text relocated verbatim into the new functions,
not new logic.

Test plan

• pnpm run format:check, pnpm run lint:check, pnpm run typecheck — clean.
• pnpm test — 685 passing (13 new). The existing suite is unchanged.
• The extraction is byte-for-byte behavior-preserving: createSystemPrompt output is identical
  for every (surface × command) combination before and after, asserted by the new regression test
  and verified out-of-band by diffing all 12 combinations.
• pnpm dev integration claude <dir> scaffolds both SKILL.md files; rendered bodies contain
  real openwiki/... paths, zero virtual /openwiki/... paths, and no connector/CLI-only
  vocabulary.

---

🤖 Generated with Claude Code

[ethan (ethan-parkk)]

This looks like a good integration boundary for host-agent-native OpenWiki workflows.

Would the maintainers be open to a narrowly scoped follow-up for OpenCode using the same approach?

The proposed command would be:

openwiki integration opencode [path]
It would scaffold:

• .opencode/skills/openwiki-init/SKILL.md
• .opencode/skills/openwiki-update/SKILL.md

The generated skills would reuse the shared methodology functions introduced here, while adapting the invocation guidance, tool vocabulary, and
repository-relative paths for OpenCode.

The scope would remain intentionally small:

• code mode only,
• init and update skills,
• inference delegated to the model already configured in OpenCode,
• no additional OpenWiki provider or API key,
• no plugin hooks,
• no marketplace metadata,
• no helper tooling,
• and no OMOS-specific behavior.

Although OpenCode can discover Claude-compatible skill locations, a dedicated target would avoid Claude-specific invocation and tool guidance and would
use OpenCode’s native .opencode/skills/ location.

If this direction is welcome, I’d be happy to submit it as a separate follow-up PR after this one.