docs(takt): note that Takt does not inherit Codex skills by default - #2645
Merged
Conversation
Rulesync's codexcli skills adapter writes to .agents/skills, and a Takt workflow driving Codex does not inherit repo or user skills from there - so generated skills silently never reach the run. The flag's home depends on the Takt version: up to 0.55.x it is provider_options in config.yaml, but from 0.56.0 runtime.yaml owns provider configuration and a config.yaml provider_options stops Takt with a mixed-configuration error. Record both, since a fresh install is in runtime mode by default.
…shape Review fact-check turned up two wrong claims in the new note. Rulesync never resolves CODEX_HOME - global skills go to ~/.agents/skills via getHomeDirectory - and a runtime.yaml profile's options is a flat bag for that profile's own provider, so the codex segment must be dropped. The nested spelling is not a schema error, it is just never read, which is the worst kind of wrong for a setting you enable once and forget. Also record the takt exec inheritance exception and 0.57.0's capabilities: enable-skills preset, and correct the same CODEX_HOME confusion where the note's author found it, in codexcli-skill.ts.
…ilities line Upstream sets no upper bound on the legacy path: whenever runtime.yaml is inactive - a file carrying only version: 1 counts - config.yaml provider resolution still applies, so naming 0.56.0 specifically dropped 0.57.0 on the floor. Also say plainly that capabilities is a workflow-side preset reference rather than a third configuration file.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Part of #2421 (documentation slice from the 2026-07-30 comment). The issue stays open — gap 2 (
assistant.init_files) and the runtime.yaml follow-up recorded on 2026-08-08 are untouched here.The problem
Rulesync's
codexcliskills adapter writes to.agents/skills/(project) and$CODEX_HOME/skills(global). A Takt workflow driving Codex does not inherit repository or user skills from there by default, so skills a user generated silently never reach a Takt-driven Codex run. Nothing in the docs said so.What the note says, and why it is not the note the issue proposed
The 2026-07-30 comment suggested one line telling users to enable
provider_options.codex.skills.repoin their Takt workflow config. Taken literally today, that advice breaks people: the 2026-08-08 re-check on the same issue found that Takt 0.56.0'sruntime.yamlmakesprovider_optionsinconfig.yamla legacy signal — while runtime mode is active, its presence stops Takt withMixed provider configuration detectedbefore it runs an agent. Takt generates~/.takt/runtime.yamlactive on first launch in a fresh environment, so a new install is in runtime mode by default.So the note carries the version split rather than the bare recommendation:
runtime.yamlinactive —provider_optionsin.takt/config.yaml, which is also where ataktblock in.rulesync/permissions.*writes it.runtime.yamlactive —provider.profiles.<name>.optionsinruntime.yaml, keepingprovider_optionsout ofconfig.yaml.It also picks up the 0.55.0 status change the same comment recorded: Claude providers no longer inherit filesystem skills either (
provider_options.claude.skills.enabled), and CLI-backed ones launch with--disable-slash-commands, so Rulesync-generated Claude Code skills and slash commands are off in Takt-driven sessions unless re-enabled the same way.Placed beside the Codex CLI skills note in
docs/reference/file-formats.md, since that is where the.agents/skills/output is described. Docs-only;docs-contentregenerated andsync-skill-docsclean.pnpm cicheckgreen.Deliberately out of scope
The 2026-08-08 comment's proposed follow-up for the Takt permissions adapter — reading
runtime.yamlfor active-provider resolution, routing an authoredprovider_optionstoruntime.yamlor refusing the write, and the import round-trip that reintroduces the legacy key and breaks a migrated install — is a code change on a different owner and is not attempted here.🤖 Generated with Claude Code