docs: add Codex install symlink instructions

[sanogueralorenzo]

Adds the Codex equivalent install commands in the README install section, alongside Claude Code and Cursor instructions.

• Uses CODEX_HOME when set
• Falls back to $HOME/.codex/skills

[hamen]

@claude what do you think of this PR?

[claude]

Claude finished @hamen's task in 48s —— View job

---

PR review: docs: add Codex install symlink instructions

• Read PR diff and surrounding README context
• Compare PR description claims against the diff
• Post review feedback

---

Overall

Small, focused docs change. It cleanly mirrors the existing Claude Code / Cursor blocks, so it's stylistically consistent and easy to read. I'd merge it after one tweak below.

Mismatch between PR description and diff

The PR description states:

• Uses CODEX_HOME when set
• Falls back to $HOME/.codex/skills

…but the diff doesn't actually do that — it only hardcodes ~/.codex/skills:

# Codex (README.md:49-51)
mkdir -p ~/.codex/skills
ln -s "$(pwd)" ~/.codex/skills/jetpack-compose-audit

Either the description should be trimmed to match the diff, or the snippet should honor CODEX_HOME. Codex CLI does respect CODEX_HOME (defaulting to ~/.codex), so honoring it is the more correct option for users who relocate that directory:

# Codex
CODEX_SKILLS="${CODEX_HOME:-$HOME/.codex}/skills"
mkdir -p "$CODEX_SKILLS"
ln -s "$(pwd)" "$CODEX_SKILLS/jetpack-compose-audit"

Fix this →

Minor nits (optional)

• The Claude Code and Cursor blocks also hardcode ~/.claude and ~/.cursor — Claude Code likewise honors CLAUDE_CONFIG_DIR. If you go the env-aware route for Codex, consider doing the same for Claude Code in a follow-up so the three blocks stay symmetrical.
• ln -s "$(pwd)" … will fail silently-ish on a re-run because the symlink already exists. Not new to this PR (the existing blocks have the same shape), so not blocking — just worth a future ln -sfn pass.

Verdict

LGTM once the description/diff mismatch is reconciled. Preference: update the snippet to honor CODEX_HOME, since the description already promises it and it's a one-line change.
• docs/add-codex-install

[hamen]

@sanogueralorenzo would you mind giving it another polishing shot, please?

[alsd4git]

have you considered using skills.sh? https://skills.sh/hamen/compose_skill/jetpack-compose-audit

[hamen]

have you considered using skills.sh? https://skills.sh/hamen/compose_skill/jetpack-compose-audit

@claude what are the advantages of using https://skills.sh ?

[claude]

Claude finished @hamen's task in 1m 1s —— View job

---

Re: advantages of skills.sh

Quick disclosure: I couldn't fetch skills.sh from this job (WebFetch isn't authorized here), so I can't make verified claims about exactly what the service does. The URL shape — https://skills.sh/<owner>/<repo>/<skill> — looks like a curl-pipe-shell installer pattern (similar to rustup / nvm / oh-my-zsh), so the comparison below assumes that's roughly what it is. Treat as "general tradeoffs," not a product review.

Likely upsides over the symlink block in this PR

• One command across agents. A single installer can detect Claude Code / Codex / Cursor (and respect CLAUDE_CONFIG_DIR / CODEX_HOME) instead of three near-identical copy-paste blocks — which is exactly the asymmetry the previous review on this PR called out.
• Idempotent re-runs. A script can do the ln -sfn / "skill already installed, updating" handling that bare ln -s "$(pwd)" … doesn't.
• Versioning / updates. A registry-style installer can pin to a tag or run an update command, where the symlink approach implicitly tracks whatever branch you happen to be on.
• Discoverability. A central index makes the skill findable without users needing to know the GitHub URL.

Things to weigh before adopting it

• Trust surface. curl … | sh adds a third party between the user and this repo. The current symlink block is fully transparent — every command is visible in the README. For a skill that runs inside an agent context, some users will care about this.
• External dependency. If skills.sh goes away, changes its URL scheme, or rate-limits, the install instructions break. The symlink path only depends on git + the user's filesystem.
• Loss of "edit locally, git pull updates everywhere." That's the explicit selling point of the current README block (line 42). If skills.sh copies files instead of symlinking, contributors lose that workflow; if it symlinks, it's mostly a nicer wrapper around what's already documented.
• No behavior change for the actual skill. Either way the agent loads the same SKILL.md — this is purely an install-ergonomics question.

Suggestion for this PR specifically

I'd keep the scope of #1 narrow: land the Codex symlink block (with the CODEX_HOME fix already discussed) so the README is internally consistent, and evaluate skills.sh as a separate follow-up. Mixing "add Codex instructions" with "switch install mechanism" makes both harder to review and to revert.

If you do want to evaluate skills.sh, the things I'd want to confirm before recommending it:

1. Who runs it / what's the trust model (is it owned by someone in this org, or third-party)?
2. Does it symlink or copy? (Affects the git pull workflow.)
3. Does it honor CLAUDE_CONFIG_DIR / CODEX_HOME?
4. Is there a pinned-version install, or only "latest"?

• Investigate what skills.sh is (couldn't verify directly — answered from URL shape + general tradeoffs)
• Compare with the symlink approach used in this PR
• Post answer
  • docs/add-codex-install