docs(takt): note that Takt does not inherit Codex skills by default

docs/reference/file-formats.md

@@ -878,6 +878,8 @@ When `claudecode.scheduled-task: true` is set, that skill is emitted only as a C
 
 > **Note:** Codex CLI reads UI metadata, invocation policy, and tool dependencies from an `agents/openai.yaml` sidecar next to `SKILL.md` (Codex's `SKILL.md` frontmatter only carries `name` and `description`). When `codexcli.interface`, `codexcli.policy`, or `codexcli.dependencies` is present, Rulesync emits `.agents/skills/<name>/agents/openai.yaml` and reads it back on import. If the sidecar is emitted and `interface.short_description` is absent, the legacy `codexcli.short-description` is routed there. See the [Codex skills docs](https://developers.openai.com/codex/skills.md).
 
+> **Takt-driven Codex note:** Rulesync's `codexcli` skills land in `.agents/skills/` (project) and `~/.agents/skills/` (global), but a Takt workflow driving Codex does **not** inherit repository or user skills from there by default — upstream's wording is "TAKT workflows do not inherit repository or user Codex Skills by default" — so skills you generated will not reach a Takt-driven Codex run unless you turn inheritance on. (`takt exec` is the documented exception: each scope defaults to inheritance when it is not explicitly configured.) The setting is `provider_options.codex.skills.repo` for the project tree and `.user` for the global one, added in Takt 0.53.0. **Where it goes depends on your Takt version.** Up to 0.55.x, and on any later version whenever `runtime.yaml` is inactive (a file carrying only `version: 1` counts as inactive and leaves the legacy resolution in place), it belongs in `provider_options` in `.takt/config.yaml` — which is also where a `takt` block in `.rulesync/permissions.*` writes it. From 0.56.0, `runtime.yaml` owns provider configuration, and while it is active **any** legacy provider setting in `config.yaml` — `provider_options` included — stops Takt with `Mixed provider configuration detected` before it runs an agent. Takt generates `~/.takt/runtime.yaml` active on first launch in a fresh environment, so a new install is in runtime mode by default; there, set the flag in `runtime.yaml` under the `options` of a profile whose provider is Codex, and keep `provider_options` out of `config.yaml`. Mind the shape when you move it: a profile's `options` is a **flat bag applying to that profile's own provider**, so the `codex` segment is dropped — `options: { skills: { repo: true } }`, not `options: { codex: { skills: { repo: true } } }`. The nested spelling is not a schema error; it is simply never read, so inheritance stays off while the config looks right. Takt 0.57.0 adds a workflow-side alternative to writing `provider_options` inline: a workflow, step, or parallel sub-step can declare `capabilities: enable-skills`, a bundled preset covering the Codex repo and user skills. Takt 0.55.0 made the same default change for Claude providers (`provider_options.claude.skills.enabled`, plus `--disable-slash-commands` on CLI-backed ones), so Rulesync-generated Claude Code skills and slash commands are off in Takt-driven sessions unless re-enabled the same way. See the [Takt configuration docs](https://github.com/nrslib/takt/blob/main/docs/configuration.md) and [CHANGELOG](https://github.com/nrslib/takt/blob/main/CHANGELOG.md).
+
 > **Reasonix note:** Reasonix discovers Anthropic-style directory-layout skills (`<name>/SKILL.md`) under `.reasonix/skills/` (project) / `~/.reasonix/skills/` (global, via `--global`). Rulesync emits the portable `name`/`description` frontmatter (Reasonix supports additional optional keys, but only that pair is modeled); the schema is loose, so any extra keys on an imported `SKILL.md` survive the round-trip. See the [Reasonix GUIDE](https://github.com/esengine/DeepSeek-Reasonix/blob/main-v2/docs/GUIDE.md).
 
 > **Meta Muse Code note:** Muse Code discovers Agent Skills (`<skill-id>/SKILL.md`) under `.agents/skills/` (project) and under `$XDG_CONFIG_HOME/muse/skills` plus `~/.agents/skills` (user). Rulesync emits the shared `.agents/skills/` directory in project mode and only the XDG-default `~/.config/muse/skills` in global mode (via `--global`), so a skill is written exactly once. Muse Code's compatibility scans of repo-local `.codex/skills` and `.claude/skills` belong to other tools and are not emitted for `musecode`. Only the portable `name`/`description` frontmatter pair is modeled; the schema is loose, so extra keys on an imported `SKILL.md` survive the round-trip. See the [Muse Code extending docs](https://dev.meta.ai/docs/muse-code/extending.md).

src/features/skills/codexcli-skill.ts

@@ -150,7 +150,8 @@ export type CodexCliSkillParams = {
 /**
  * Represents a Codex CLI skill directory.
  * Codex CLI supports skills in both project mode (under $CWD/.agents/skills)
- * and global mode (under $CODEX_HOME/skills, typically ~/.agents/skills).
+ * and global mode (under ~/.agents/skills — Rulesync resolves the home
+ * directory rather than $CODEX_HOME).
  */
 export class CodexCliSkill extends ToolSkill {
   constructor({
@@ -190,7 +191,7 @@ export class CodexCliSkill extends ToolSkill {
     // Codex CLI skills use the same relative path for both project and global modes
     // The actual location differs based on outputRoot:
     // - Project mode: {process.cwd()}/.agents/skills/
-    // - Global mode: {$CODEX_HOME}/skills/ (typically ~/.agents/skills/)
+    // - Global mode: {home}/.agents/skills/
     return {
       relativeDirPath: CODEXCLI_SKILLS_DIR_PATH,
     };