claudex-setup：把关注的 AI 编程创作者变成 Claude Code 与 Codex 可用的经验库

Turn the agentic-coding creators you follow into a lessons library your agent actually uses, then audit your real projects against it, across Claude Code and Codex.

You watch the tutorials, read the threads, star the gists, and the best tips evaporate. claudex-setup is a config you run yourself: it mines those tips into source-cited lessons from the creators you pick, curates them, and audits your projects against them, alongside a battle-tested set of slash commands, subagents, and hooks.

Keep it as a standalone repo alongside your projects: you run it from here, and /optimise improves your other projects' agent setups in place. You don't install it into each repo. Point it at your favourite voices; make it yours.

Why "claudex"? Claude Code + Codex. /optimise audits whichever agent tools a project actually uses: Claude Code by default, Claude Design with --design, OpenAI Codex with --codex, keeping one tracker per tool. Working in this repo with Codex? Start at AGENTS.md, the Codex-side counterpart to CLAUDE.md.

Honest scope: the lessons library is Claude-Code-first (it also mines a Codex/OpenAI voice cluster, keeping what transfers to general agentic coding), and the commands, subagents, and hooks are Claude Code artifacts. Codex is first-class in what this repo audits and tracks, not a claim of tool parity.

Quickstart (60 seconds)

It's a hub you run from, not a config you install into each project:

Requirements: Claude Code, uv, Python >=3.14 (uv fetches it).

git clone https://github.com/runnithan/claudex-setup
cd claudex-setup && uv sync     # then open Claude Code here

/extract-lessons            # mine your tracked creators into a lessons library
/optimise <your-project>    # audit another project's setup against those lessons, apply fixes

→ Full walkthrough: USER_GUIDE.md. Prefer the commands available inside another repo? It's also a plugin: /plugin marketplace add runnithan/claudex-setup.

Learn from the creators you pick

Most configs "improve themselves" from your own sessions. This one learns from the practitioners you actually trust:

1. Pick your sources: drop creator video URLs in transcripts/urls.txt, or add voices to references/agentic-coding-voices.md.
2. Mine them: /extract-lessons (YouTube transcripts) or /extract-social-lessons (X/blog posts, via a research subagent team) distil them into one-file-per-lesson markdown, each citing its source.
3. Curate + apply: /consolidate-lessons keeps the library lean; /optimise <project> audits a project's setup against it and applies the fixes you approve.

Example: point it at Boris Cherny and Simon Willison and you get lessons like "pre-compute context with inline bash in slash commands" and "clone a reference repo to /tmp", each linked to the post it came from. Browse lessons/INDEX.md to see ~200 already mined.

About YouTube transcripts

YouTube has no official way to download captions for videos you don't own: its API's caption download requires permission to edit the video. So the fetcher uses the community youtube-transcript-api library, which reads the same captions the YouTube player shows. It's unofficial, and YouTube's Terms of Service restrict automated access, so treat the fetcher as a personal tool: use it for your own learning, keep runs small, and use it at your own discretion.

To keep that footprint small, the fetcher makes ordinary requests, waits a few seconds between videos, fetches at most 40 new transcripts a run, and stops after three blocked requests. Run it again later and it picks up where it stopped.

Transcripts are never published (the public repo ships without transcripts/). Only lessons ship, and those are short summaries that cite their source. To skip automated fetching entirely, open the video on YouTube, click Show transcript below the description, and paste the text into a .txt file under transcripts/<creator>/. Put # URL: https://www.youtube.com/watch?v=<id> on its first line, so lessons can cite it and the fetcher knows it's already done. Then run /extract-lessons.

Everything you can run

† /pr needs the gh CLI, and /ticket needs the Jira MCP server (see .mcp.json.example). Neither is bundled in the plugin, but both are available when you run the repo as a hub with those tools set up.

Plus subagents (code-reviewer, qa, backend-dev, frontend-dev, code-simplifier, pr-test-analyzer, read-only roles tool-restricted), lifecycle hooks (an advisory security reminder, a portable auto-formatter, GSD statusline/context-monitor), and skills (claude-md-improver, frontend-design).

Customising for your stack

The defaults lean toward a backend/ (Python + uv) + frontend/ (Node) layout, but the commands read your project's real commands from CLAUDE.md, so it adapts. Tune CLAUDE.md (your commands + conventions), settings.json (tool/secret rules), hooks/auto-format.sh (formatters), and agents/ (roles).

Using it inside another project (advanced)

If you do want the config in a specific repo (via the plugin, or by copying it into .claude/):

• The repo must become the .claude/ folder itself: settings.json references hooks as .claude/hooks/…, so copying it into a subfolder silently breaks them.
• settings.json does not cascade: each project needs its own copy.
• Verify with /hooks after copying. A single JSON typo in settings.json silently disables all hooks; the validate CI workflow catches malformed config.
• settings.local.json is gitignored (personal/machine overrides); shareable rules go in settings.json.

Contributing, layout & versioning

Contributions welcome, see CONTRIBUTING.md. Directory tree: references/project-structure.md. Changes are logged in CHANGELOG.md; releases are tagged vX.Y.Z.