feat: add Codex plugin marketplace

[Jonahxzhou]

Summary

• publish this repository as a Codex plugin marketplace
• add a Notebook Intelligence operational skill for environment selection, installation, provider configuration, and diagnostics
• document marketplace and plugin installation in the README

The Codex plugin intentionally does not claim direct notebook or Jupyter UI control. The existing PyPI/JupyterLab extension remains the runtime component.

Validation

• validate_plugin.py plugins/notebook-intelligence
• quick_validate.py plugins/notebook-intelligence/skills/notebook-intelligence
• Prettier 3.3.3 check for all changed Markdown and JSON files
• git diff --check
• added the fork branch as a Git-backed Codex marketplace
• installed notebook-intelligence@notebook-intelligence from that marketplace
• revalidated the installed Codex plugin cache

The repository has no Codex agent-integration harness, so model invocation behavior was reviewed manually; marketplace discovery, Git fetching, installation, and package validation were exercised end to end.

[pjdoland]

I verified this end to end against a real codex-cli install (0.144.6) before commenting, and the mechanics work: adding the marketplace, discovering the plugin, and installing it all succeed, and the skill lands with valid frontmatter.

$ codex plugin marketplace add <repo>
Added marketplace `notebook-intelligence`.
$ codex plugin add notebook-intelligence@notebook-intelligence
Added plugin `notebook-intelligence` ... 0.1.0
$ codex plugin list
notebook-intelligence@notebook-intelligence  installed, enabled  0.1.0

I also checked the skill's factual claims rather than assuming them, and they hold up: docs/troubleshooting.md and CONTRIBUTING.md both exist, NBI_CLAUDE_CLI_PATH is a real override (util.py:132), the labextension name @plmbr/notebook-intelligence matches package.json, requires-python = ">=3.10" matches the stated floor, license matches the repo's GPL-3.0, and the two verification commands the skill tells the agent to run (jupyter server extension list, jupyter labextension list) do report NBI as described. The provider list (Copilot, OpenAI-compatible/LiteLLM, Ollama, Claude Code mode) is accurate, and telling the model never to print or commit API keys is the right instinct for a skill that walks users through provider setup.

So no blocking defects in the code. My hesitation is about scope, and I think it's worth settling before this merges.

Is this the right thing for NBI to own?

This makes the repository a Codex plugin publisher. That's a different relationship than the one NBI has today. Right now NBI is a consumer of the plugin ecosystem: the Settings panel wraps claude plugin for install/uninstall/marketplace-add, with admin policies (NBI_CLAUDE_PLUGINS_MANAGEMENT_POLICY, NBI_ALLOW_GITHUB_PLUGIN_IMPORT) governing it. Publishing a marketplace from this repo adds a second, outward-facing surface that has to be maintained on someone else's release cadence.

Concretely, the costs I'd want priced in:

• The skill duplicates the docs. Install steps, provider setup, and troubleshooting all exist in the README and docs/. This is a fourth copy that can drift, and drift is the failure mode that matters: a stale skill confidently tells users the wrong thing inside their agent session, where they're least likely to cross-check. Nothing in CI validates it, so drift is silent.
• The version is independent. plugin.json pins 0.1.0 with no link to NBI's own version, and nothing bumps it. A user installing the plugin a year from now gets whatever main holds, described as 0.1.0.
• The format is young. codex plugin is a moving target; a schema change lands as a broken marketplace for anyone who added it, and the failure surfaces in Codex, not in NBI.

None of that is an argument that the idea is wrong. An operational skill for setup and troubleshooting is genuinely useful, and the marketplace format is the natural way to distribute one. It's an argument that the maintenance owner should be explicit before this becomes a published artifact people depend on.

Some questions worth answering first:

1. Is publishing to the Codex ecosystem something the project wants to commit to, or is Claude-mode integration the intended direction? Doing both is fine, but it doubles the surface.
2. Should the skill point at the docs rather than restate them? A thinner skill that orients the agent and links to docs/troubleshooting.md would capture most of the value with far less drift risk.
3. Should plugin.json's version track the package version, with a release-time check that they agree?

One small note if it does land: the README instructions (codex plugin marketplace add plmbr/notebook-intelligence --ref main) only work once this is on main, which is fine, just worth knowing they're inert until then.

Happy to be wrong on the scope question, and I'd defer to @mbektas on whether this is a direction the project wants. The implementation itself is clean and I found nothing that blocks on correctness.