Installing the skills

One command writes the instructions for every coding agent your repository uses, plus the permission table that decides which commands need approval.

For the full sequence after installing the CLI, follow From sign-in to a published flow.

ff agent install

It detects the coding agents already present in the repository and writes for all of them, not one. A project holding both .claude/ and .cursor/ has two people on two tools working the same flows, and they should be under the same rules.

On a new workspace, name the host

Detection works by looking for a host's own directory — .claude/, .cursor/, .github/. A workspace where you have never yet run that tool does not have one, so there is nothing to find and the command writes only AGENTS.md:

Installed 9 skill(s) for: agents-md

That is the command working correctly and detecting nothing, which looks identical to the command failing to install what you wanted. Name the host and detection is skipped:

ff agent install --host claude-code

Once .claude/ exists it is detected like any other host, so later runs pick it up with no flag.

--host replaces detection rather than narrowing it. ff agent install --host claude-code writes for Claude Code only — including skipping AGENTS.md, which every unflagged run writes. Run the command once without the flag afterwards if you want both.

What lands where

.fixtureframe/skills/            canonical, host-neutral, committed
  ff.md  ff-context.md  ff-suggest.md  ff-script.md  ff-record.md
  ff-deck.md  ff-adapter.md  ff-diagnose.md  ff-cli.md

.claude/skills/<name>/SKILL.md   the full guides
.claude/commands/<name>.md       /ff, /ff-script, …
.claude/settings.json            the permission table (merged, not replaced)

AGENTS.md                        a ~20-line pointer
.cursor/rules/fixtureframe.mdc   the same pointer
.github/copilot-instructions.md  the same pointer

The canonical copies under .fixtureframe/skills/ are written on every run whatever the host, because every pointer below refers to them.

Where Claude Code looks

All of this is written relative to the workspace directory, so the skills belong to that project: Claude Code finds them when it starts there and not when it starts somewhere else. Start it in the workspace and /ff appears among the slash commands — that is the check that this worked.

Skill discovery is not the only thing that depends on where you start, and the other one is quieter. See Working in a session for what the CLI reads from where.

To get the skills in every project, copy them to the user-level directory once:

cp -r .claude/skills/ff* ~/.claude/skills/

The permission table deliberately does not travel with them. .claude/settings.json is written per project because whether ff publish prompts is a decision about a repository rather than about a person, so a globally installed skill still takes its gates from wherever it is run.

Two shapes, not four dialects

Hosts differ more than a file path. Claude Code loads a skill when it is needed. Cursor, Copilot, Windsurf and the rest read their instructions on every turn, where eight guides would be paid for continuously.

So one host receives the skills themselves; the rest receive a short pointer at the canonical copy — which every one of those agents can open when it decides to. The condensed form is an index, not a précis.

Host	Detected by	Receives
Claude Code	`.claude/`	Skills, slash commands, permissions
Cursor	`.cursor/`	Pointer
GitHub Copilot	`.github/`	Pointer
`AGENTS.md`	—	Pointer, on any run without `--host`

AGENTS.md is written whenever no --host is named, because several tools read it and a project that adopts one later finds the rules already there rather than a gap nobody remembered to fill.

Files your project owns — AGENTS.md, Copilot instructions — are edited between markers rather than overwritten, and .claude/settings.json is merged. Whatever else your team told its agents survives.

The permission table

ff agent install writes the gate policy as configuration rather than as advice, because a rule in a skill is something a model may or may not follow.

Free — allowed without asking	Spends — prompts first
`doctor` `lint` `brief` `validate` `status` `diagnose` `suggest` `survey` `pull`	`script` `record` `run` `publish` `push` `profile`

survey is in the free column deliberately. It signs in and takes minutes, but it never acts on what it finds, cannot reach further than a run could, and is what ff lint needs to work at all — prompting for it would put a dialog in front of the cheapest gate in the design. A well-behaved agent narrates it rather than running it silently.

profile is on the asking side for the opposite reason. It opens no browser and bills nobody, but profile create saves a record to your organisation — and the column is "changes what others see" rather than "costs money". Its --local-only form writes a file and nothing else.

Commit the result

The canonical copy and the permission table are meant to be checked in. What an agent was told to do belongs in the pull request beside what it did — including the fact that publish requires a prompt, which a reviewer can then see rather than take on trust.

Options

Flag
`--host <id>`	Write for one host instead of detecting: `claude-code`, `cursor`, `copilot`, `agents-md`.
`--directory <path>`	Workspace directory holding `.fixtureframe`. Defaults to `FIXTUREFRAME_PROJECT_DIR`, then the current directory.

Versioning

Skills ship inside the CLI package rather than being fetched. They describe the CLI's own command surface, so a skill naming a flag your installed CLI does not have would be a failure neither side could explain. Upgrade the CLI and re-run ff agent install to update them.

On this page