Summary
Today flow init and flow skill install write SKILL.md only to ~/.claude/skills/flow/. The same SKILL.md format works as-is for Codex (~/.codex/skills/), Cursor (~/.cursor/skills/), and Gemini CLI (~/.gemini/skills/) — all of which already expose a Claude-Code-compatible skills loader. Filling those dirs at install time is the minimum change required for those agents to discover and load the flow skill.
Background — the gap on main
internal/app/skill.go::skillInstallPath() hardcodes ~/.claude/skills/flow/SKILL.md and is the only target everywhere (flow init, skill install, skill update, skill uninstall, maybeAutoUpgradeSkill).
- The embedded SKILL.md on
main makes no claims about other agents.
- The unmerged
facets/codex-support branch adds full flow do --agent codex runtime support but does NOT change the install layer.
- Result: even with the Codex branch merged,
~/.codex/skills/flow/ would still be empty unless the user copies SKILL.md by hand. Multi-agent install is missing for everyone.
Proposed behavior
skill.go exposes a skillTargets() function returning one entry per agent whose ~/.<agent>/ parent dir exists on disk:
| Agent |
Parent dir |
Skill path |
| Claude Code |
~/.claude/ |
~/.claude/skills/flow/SKILL.md |
| Codex CLI |
~/.codex/ |
~/.codex/skills/flow/SKILL.md |
| Cursor |
~/.cursor/ |
~/.cursor/skills/flow/SKILL.md |
| Gemini CLI |
~/.gemini/ |
~/.gemini/skills/flow/SKILL.md |
flow init, flow skill install, flow skill update, flow skill uninstall, and maybeAutoUpgradeSkill all loop over the discovered targets and operate on each — idempotently, with a per-agent VERSION sidecar so each agent can be upgraded independently.
Auto-discover only. If ~/.codex/ does not exist, the Codex target is silently skipped (the user does not have Codex installed). We do NOT eagerly create ~/.codex/ ourselves — that would litter the home dir for users who do not use that agent.
Hook installation is unchanged. The SessionStart hook in ~/.claude/settings.json is Claude-specific and stays Claude-only. Codex/Cursor/Gemini have their own hook mechanisms (or none) — out of scope here.
Why this is the right shape
- Smallest possible change. No new commands, no new flags, no
flow do changes, no DB schema work. Just a target list.
- Future-proof. Adding a new agent (e.g. opencode if it grows a standard skills dir) is a single entry in
skillTargets().
- Reversible.
flow skill uninstall cleans up across all agents the same way it cleans up Claude today.
- Compatible with the Codex branch. When
facets/codex-support is rebased and merged, the Codex install path will already be in place — the runtime work and the install work compose cleanly.
Out of scope (separate issues)
flow do --agent codex|opencode|... runtime dispatch (already partially built on facets/codex-support — separate review).
session_provider DB column.
- Agent-specific hook installation beyond Claude's SessionStart.
- Opencode support — its layout (
~/.opencode/ = node bin/) doesn't match the global-skills-dir pattern. Revisit if opencode adopts one.
Acceptance
Summary
Today
flow initandflow skill installwrite SKILL.md only to~/.claude/skills/flow/. The same SKILL.md format works as-is for Codex (~/.codex/skills/), Cursor (~/.cursor/skills/), and Gemini CLI (~/.gemini/skills/) — all of which already expose a Claude-Code-compatible skills loader. Filling those dirs at install time is the minimum change required for those agents to discover and load the flow skill.Background — the gap on main
internal/app/skill.go::skillInstallPath()hardcodes~/.claude/skills/flow/SKILL.mdand is the only target everywhere (flow init,skill install,skill update,skill uninstall,maybeAutoUpgradeSkill).mainmakes no claims about other agents.facets/codex-supportbranch adds fullflow do --agent codexruntime support but does NOT change the install layer.~/.codex/skills/flow/would still be empty unless the user copies SKILL.md by hand. Multi-agent install is missing for everyone.Proposed behavior
skill.goexposes askillTargets()function returning one entry per agent whose~/.<agent>/parent dir exists on disk:~/.claude/~/.claude/skills/flow/SKILL.md~/.codex/~/.codex/skills/flow/SKILL.md~/.cursor/~/.cursor/skills/flow/SKILL.md~/.gemini/~/.gemini/skills/flow/SKILL.mdflow init,flow skill install,flow skill update,flow skill uninstall, andmaybeAutoUpgradeSkillall loop over the discovered targets and operate on each — idempotently, with a per-agentVERSIONsidecar so each agent can be upgraded independently.Auto-discover only. If
~/.codex/does not exist, the Codex target is silently skipped (the user does not have Codex installed). We do NOT eagerly create~/.codex/ourselves — that would litter the home dir for users who do not use that agent.Hook installation is unchanged. The SessionStart hook in
~/.claude/settings.jsonis Claude-specific and stays Claude-only. Codex/Cursor/Gemini have their own hook mechanisms (or none) — out of scope here.Why this is the right shape
flow dochanges, no DB schema work. Just a target list.skillTargets().flow skill uninstallcleans up across all agents the same way it cleans up Claude today.facets/codex-supportis rebased and merged, the Codex install path will already be in place — the runtime work and the install work compose cleanly.Out of scope (separate issues)
flow do --agent codex|opencode|...runtime dispatch (already partially built onfacets/codex-support— separate review).session_providerDB column.~/.opencode/= node bin/) doesn't match the global-skills-dir pattern. Revisit if opencode adopts one.Acceptance
flow initon a machine with all four agent dirs writes SKILL.md into all fourskills/flow/paths.flow initon a machine with only~/.claude/writes only to Claude — no spurious dir creation.flow skill install,update,uninstalloperate over the full discovered set, idempotent on re-run.maybeAutoUpgradeSkillrefreshes every present agent's SKILL.md when the binary version changes.~/.<agent>/skills/flow/VERSION) track upgrades independently.skill_test.gocovers the multi-target case via$HOMEoverride.make testpasses.