Support GitHub Copilot CLI as an agent: `spektacular init copilot`

[Danathar]

Status: nothing here is implemented. I checked Spektacular 0.24.0 and main at f424611, and GitHub Copilot CLI 1.0.91, on 2026-10-04. Everything under "What I tested" was run against the real tools. Where something comes only from reading Copilot's help or Spektacular's source, I say so. The requirements, constraints and acceptance criteria below are a spek I wrote with Spektacular itself.

Summary

I'd like spektacular init copilot to set a project up for GitHub Copilot CLI, the way init claude, init bob and init codex do for those agents.

Spektacular sets a project up for one of three coding agents, and GitHub Copilot CLI is not among them: asking for it is refused. People who use Copilot CLI get by today by setting the project up for a different agent, which works because Copilot also reads those agents' files, but it records the wrong agent on the project, is not documented anywhere, and in the Claude Code case hands Copilot every standing rule twice. The standing rules are the instructions Spektacular gives the agent in every project, such as where the code lives and that Spektacular's own files are changed only through its commands. This feature adds Copilot CLI as a supported agent, so that someone working in Copilot can set a project up with one command, start every Spektacular workflow by name, and find in the documentation what they get, whether they use Copilot alone or next to another supported agent on the same project.

My own case: I use Copilot CLI myself, and I want to run Spektacular's workflows from it, on its own or next to Claude Code on the same project.

What happens today

spektacular init copilot is refused, on 0.24.0 and on main, and nothing is written to the project:

$ spektacular init copilot
{
  "error": true,
  "code": "internal_error",
  "message": "unknown agent \"copilot\": must be one of bob, claude, codex",
  "next_action": ""
}

There is a workaround, and for Copilot it goes further than it did for omp (#73). Copilot reads other tools' project folders as well as its own. So after spektacular init codex or spektacular init claude, Copilot lists all six workflow skills, offers each one as a plain command (/spek-new and so on), and loads AGENTS.md. After spektacular init bob it lists none.

What the workaround does not give you:

• The project records the wrong agent. Spektacular's settings say codex or claude for a project that is worked on in Copilot.
• Set up as Claude Code, Copilot gets every standing rule twice. init claude adds a CLAUDE.md that imports AGENTS.md. Copilot loads AGENTS.md and also follows that import. The instructions it assembles came to 65,969 characters, against 44,211 when the project was set up as Codex, and that is sent with every request.
• It leaves files for a tool that may not be in use: a CLAUDE.md, or skills in a folder named for another agent.
• It depends on Copilot continuing to read other tools' folders.
• None of it is documented.

What I tested

All of this used Copilot CLI 1.0.91 in throwaway projects, with Copilot pointed at an empty user-settings folder so that nothing from my own Copilot setup took part. No model was called and nothing went over the network. Copilot can list the skills and instruction files it finds without either; the method is below the table.

In the table, "rules" means Spektacular's eight sections from AGENTS.md. "Hand-built Copilot layout" is my stand-in for what init copilot might install: the six skills copied to .github/skills/, and the root AGENTS.md exactly as init writes it.

#	Project	Skills Copilot lists	Rules in Copilot's instructions	Other instruction file loaded
1	spektacular init claude	6	twice	CLAUDE.md
2	spektacular init codex	6	once	n/a
3	spektacular init bob	none	once	n/a
4	Hand-built Copilot layout	6	once	n/a
5	4 + .github/copilot-instructions.md	6	once	yes
6	4 + a path file, .github/instructions/style.instructions.md	6	once	yes
7	4 + GEMINI.md at the top of the project	6	once	yes
8	4 + CLAUDE.md at the top of the project, with no import in it	6	once	yes
9	4 + .claude/CLAUDE.md	6	once	no, Copilot does not read it
10	4 + .gemini/GEMINI.md	6	once	no, Copilot does not read it
11	4, with Copilot started in a subfolder	6	once	n/a
12	1 + the same six skills in .github/skills/	6, each once	twice	CLAUDE.md
13	12, with one of the two copies of spek-new changed	6, the .github/skills/ copy	twice	CLAUDE.md
14	2 + the same six skills in .github/skills/	6, each once	once	n/a
15	14, with the .agents/skills/ copy of spek-new changed	6, the .github/skills/ copy	once	n/a
16	init claude, then init codex	6, the .agents/skills/ copies	twice	CLAUDE.md
17	3 + the six skills in .github/skills/	6	once	n/a

Other things I saw:

• Plain commands come for free. A Copilot session offered /spek-new, /spek-plan, /spek-implement, /spek-knowledge, /spek-manage-repos and /spek-design in cases 1, 2, 4, 11, 12 and 13, each once, and none of them in case 3. No command files were involved. I did not check the command list in the other cases.

• Text after the command is delivered. Typing /spek-new add user auth to the admin pages in a session reached the model as the skill's own text with this at the end, once:

  ARGUMENTS: add user auth to the admin pages
  

• Outside a session the command is not expanded. Given on the command line, as copilot -p "/spek-new add user auth to the admin pages", the text went to the model exactly as typed, the same as an unknown command did.

• On a shared project Copilot runs its own copy. In cases 13 and 15, and in case 12 with Claude Code's copy of spek-new changed instead, typing /spek-new in a session handed the model the text of the .github/skills/ copy.

• Copilot's help names the folders. copilot skill --help says project skills are found in .github/skills/, .agents/skills/, or .claude/skills/. The order in which it prefers them (cases 13, 15 and 16) is what I saw, not something the help states.

• The doubling comes from the import. In case 1 the CLAUDE.md is the one init claude writes, which contains @AGENTS.md. In case 8 the CLAUDE.md has no import, and the rules appear once.

• A subfolder is fine for Copilot, not for Spektacular. Started two folders down (case 11), Copilot still found the skills, the commands and AGENTS.md. Spektacular's own commands refuse to run there ("code": "no_project"), which is why everything below is scoped to the project's top folder.

• I found no Copilot setting that stops it reading other tools' folders. copilot help config lists none.

Not tested: a whole workflow run in Copilot with a model; Copilot's terminal screen itself, since I read the command list from a session opened over its Agent Client Protocol mode; Copilot in an editor; any Copilot CLI version other than 1.0.91.

Method. copilot skill list --json and copilot instruction list --json print what Copilot finds in the folder it is run in. Setting COPILOT_HOME to an empty folder keeps user settings out, and COPILOT_OFFLINE=true stops all network access. To see the instructions Copilot assembles and what a typed command hands to the model, I pointed COPILOT_PROVIDER_BASE_URL at a small program on my own machine that records each request and answers "ok", then ran copilot -p hello in each project and counted how often the heading "## Where the Code Lives" appeared in the recorded instructions. For the command list and for a command typed in a session, I started copilot --acp, opened a session in the project, and read the commands it announced.

A short script for the first two columns

#!/usr/bin/env python3
"""Ask Copilot CLI what it found in a project, without calling a model or using the network.
usage: minimal_check.py <project folder> <empty folder for Copilot's user settings>"""
import json, os, subprocess, sys

project = os.path.abspath(sys.argv[1])
env = dict(os.environ, COPILOT_HOME=os.path.abspath(sys.argv[2]), COPILOT_OFFLINE="true")

def ask(*what):
    done = subprocess.run(["copilot", *what, "--json"], cwd=project, env=env,
                          capture_output=True, text=True, check=True)
    return json.loads(done.stdout)

skills = [s for s in ask("skill", "list") if s["name"].startswith("spek-")]
print("skills:", sorted(s["name"] for s in skills))
print("read from:", sorted({os.path.relpath(os.path.dirname(s["path"]), project) for s in skills}))
print("instruction files:", [i["sourcePath"] for i in ask("instruction", "list")])

Requirements

Setting a project up

• Copilot is an accepted agent
  spektacular init copilot must set the project up for GitHub Copilot CLI and finish without error, and the project must record copilot as its agent.

• Copilot is listed in the setup help and the unknown-agent message
  The help for spektacular init, and the message shown when an agent name is not recognised, must name copilot alongside the other supported agents.

• Running setup again is safe
  Running spektacular init copilot on a project already set up for Copilot must leave exactly one copy of everything it installs.

• Upgrades refresh what was installed for Copilot
  On a project that records copilot as its agent, running spektacular migrate after Spektacular has been upgraded must bring everything Spektacular installed for Copilot to the current version.

• Skill files with Spektacular's names are replaced
  When the project already holds a file at a place where Spektacular installs a workflow skill for Copilot, such as a hand-made copy of the spek-new skill, setup and upgrade must replace it, as setup does for the other agents. An existing AGENTS.md is never replaced: only Spektacular's sections inside it are written.

• Setup creates only the skills and AGENTS.md
  In an empty project, the only things setup for Copilot may create outside Spektacular's own project folder are the six workflow skills, in the place it installs them for Copilot, and AGENTS.md.

Running workflows from Copilot

• Copilot finds the workflow skills
  In a project set up for Copilot and for no other agent, Copilot started in the project's top folder must list all six Spektacular workflow skills.

• Each workflow starts with a plain command
  In a Copilot session started in the project's top folder, the user can start each workflow with a plain command, meaning a short command named after the workflow: /spek-new, /spek-plan, /spek-implement, /spek-knowledge, /spek-manage-repos or /spek-design.

• Text after the command reaches the workflow
  Whatever the user types after a plain command, such as the description in /spek-new add user auth to the admin pages, must be handed to the workflow it starts, whole and unchanged.

Standing rules

• The standing rules reach the agent
  The standing rules are the sections Spektacular writes for a project. In every Copilot session started in the project's top folder, the agent's instructions must contain all of them. This must hold when the project also has instruction files of its own for Copilot, or top-level instruction files written for other coding tools.

• Nothing else is taken away from Copilot
  Setting a project up for Copilot must not stop Copilot loading any instruction file it would load without Spektacular, whether the file was there before setup or is added later.

• One version of the rules
  On a project that records copilot as its agent, the standing rules Copilot receives must be the same sections, in the same words, that Spektacular installs for any supported agent, and must still match them after setup is run again and after an upgrade.

• Each rule appears once
  In a project set up for Copilot and for no other agent, the agent's instructions must contain the full text of each standing-rule section one time, not more. The exception is a project whose top-level CLAUDE.md imports AGENTS.md, whoever wrote that file. It is covered under Non-Goals.

Sharing a project with another agent

• No skill or command is doubled on a shared project
  In a project set up for Copilot and for another supported agent, Copilot must list each workflow skill once and offer each plain command once, whether or not the two agents' copies of the skills are the same version.

• Copilot runs the copies installed for Copilot
  On a shared project where another agent's copy of a workflow skill differs from the one installed for Copilot, the skill Copilot runs must be the one installed for Copilot.

• Rules are not doubled next to Bob or Codex
  In a project set up for Copilot and for Bob or Codex, Copilot's instructions must contain the full text of each standing-rule section one time. The exception, covered under Non-Goals, is a project whose top-level CLAUDE.md imports AGENTS.md, which is what Claude Code's setup writes.

Documentation

• README covers Copilot
  The README must name Copilot CLI as a supported agent, say what setup installs for it, and show how to start a workflow from Copilot.

• Website pages cover Copilot
  Every website page that names the supported agents must name Copilot CLI. When this was written those were the home, plugins, configuration and how-it-works pages, and the getting-started tutorial.

• The tutorial has a Copilot path
  The getting-started tutorial must offer Copilot CLI as one of its agent choices, with Copilot's install steps, the setup command, and a screenshot for each step that has one for the other agents.

• The documentation states Copilot's limits
  The README and the website must each say three things. First, that Copilot has to be started in the project's top folder, because Spektacular's commands only work there. Second, that where a project has a top-level CLAUDE.md that imports AGENTS.md, as every project set up for Claude Code does, Copilot receives the standing rules twice, and why. Third, that a command name given with the prompt on the command line, without opening a session, is not expanded by Copilot, so workflows are started from inside a session.

• The documentation covers shared projects
  The README and the website must each say three things about a project shared with another agent: that setting it up for Copilot makes copilot the project's recorded agent; that an upgrade refreshes only the recorded agent's files, so the other agent's fall behind; and that running spektacular init once for each agent after upgrading brings everything up to date. If the separate issue named under Non-Goals has been resolved when this feature is released, the documentation describes the behaviour as it then is.

• The documentation covers projects set up the old way
  The README and the website must each tell someone who set a project up for Claude Code or Codex only so that Copilot could find the skills four things: to run spektacular init copilot; that the earlier agent's files stay, and can be removed by hand if that agent is not used; that AGENTS.md is shared and must stay; and that on a project first set up for Claude Code the standing rules stay doubled for as long as its CLAUDE.md remains.

Constraints

• The agent's name on the command line must be copilot, the name of the program.
• This request covers GitHub Copilot CLI only. Copilot in an editor and the Copilot cloud agent are outside it.
• Must work with Copilot CLI as released, with no change to Copilot itself. The release to test against is the latest Copilot CLI release on the day the change is submitted for review, and that version is recorded with the test results. Earlier releases are not required.
• Must work on Copilot's default settings, without the user changing any.
• The workflows must be delivered to Copilot as skills, and the skill files installed for Copilot must be identical to the ones the same Spektacular version installs for the other agents.
• Setup for Copilot must write Spektacular's standing-rule sections into the AGENTS.md file at the top of the project, identified by their headings, as setup does for every other agent.
• Setup and upgrade must write only inside the project folder. Nothing may be written to the user's home folder or to Copilot's user-level settings.
• Must not change what spektacular init and spektacular migrate produce for Claude Code, Bob or Codex, or for any agent added before this one.
• Must not change or remove anything in the project that is not Spektacular's. Ownership goes by name. Spektacular's are its own project folder, every file at a place where it installs a workflow skill for Copilot, whoever made that file, and its own sections of AGENTS.md, which any setup or upgrade may bring up to date. Everything else stays as it is, including the project's own Copilot skills, instruction files and settings under other names, and the files installed for another agent.
• The website and its tutorial live in a separate repository, hivecommons/spektacular-website. Their changes must be made there, and they are part of this feature.

Acceptance criteria

• Setup succeeds for Copilot
  In an empty project, spektacular init copilot exits with success, and Spektacular's settings for the project afterwards name copilot as its agent. On a project that records Claude Code, Bob or Codex as its agent, spektacular init copilot also exits with success, and the settings afterwards name copilot.

• Copilot appears in help and in the unknown-agent message
  spektacular init --help lists copilot, and the message printed by spektacular init nosuchagent names copilot among the accepted agents.

• Running setup twice changes nothing
  After spektacular init copilot has been run twice in a project, the project holds the same files with the same content as after one run.

• An upgrade refreshes Copilot's files
  On a project set up for Copilot whose installed skill files and standing-rule sections have then been altered to differ from the current version, as an older Spektacular would have left them, running spektacular migrate leaves everything installed for Copilot identical to what a fresh spektacular init copilot produces.

• Same-named skill files are replaced, and AGENTS.md is not
  In a project that already holds a hand-made file at the place of a workflow skill Spektacular installs for Copilot, spektacular init copilot leaves it with the content Spektacular installs. On a project that records copilot, spektacular migrate does the same. In a project that already holds an AGENTS.md of its own, spektacular init copilot leaves the existing content in place and adds Spektacular's sections to it.

• Setup creates only the skills and AGENTS.md
  After spektacular init copilot in an empty project, a listing of the project shows, outside Spektacular's own project folder, only the six workflow skills in the place they are installed for Copilot, and AGENTS.md. In particular there is no CLAUDE.md.

• All six skills are found
  After spektacular init copilot in an empty project, Copilot started in the top folder lists spek-new, spek-plan, spek-implement, spek-knowledge, spek-manage-repos and spek-design among its project skills.

• Plain commands are offered
  After spektacular init copilot in an empty project, a Copilot session started in the top folder offers /spek-new, /spek-plan, /spek-implement, /spek-knowledge, /spek-manage-repos and /spek-design among its commands.

• Text after a plain command is delivered
  After spektacular init copilot in an empty project, when /spek-new add user auth to the admin pages is entered in a Copilot session started in the top folder, what Copilot hands to the model contains the spek-new skill's instructions and the text add user auth to the admin pages exactly as typed. The same holds for each of the other five plain commands.

• Rules are present in a plain project
  After spektacular init copilot in an empty project, the instructions Copilot assembles for a session started in the top folder contain the full text of every standing-rule section Spektacular installs, each one time.

• Rules and the project's other instruction files are both present
  Take four projects, each holding one of these: a Copilot instructions file for the repository; a Copilot instructions file that applies to a path; a GEMINI.md at the top of the project; or a CLAUDE.md at the top of the project that does not import AGENTS.md. After spektacular init copilot in each, the instructions Copilot assembles for a session started in the top folder contain the full text of every standing-rule section, each one time, and the other file's content appears in them exactly as it does in the same project before spektacular init copilot. The result is the same whether the file was in the project before setup or is added after it.

• Rules match AGENTS.md
  On a project that records copilot as its agent: after spektacular init copilot, after running it a second time, and after spektacular migrate on a project whose standing-rule sections had been altered to differ from the current version, the standing rules in the instructions Copilot assembles for a session started in the top folder are word for word Spektacular's sections of the project's AGENTS.md.

• Same rules and skills as another agent
  With the same Spektacular version, spektacular init copilot in one empty project produces the same standing-rule sections in AGENTS.md, and the same files for each of the six skills, as spektacular init claude, spektacular init bob and spektacular init codex each produce in an empty project of their own.

• The project's own Copilot files survive
  A project that already holds its own Copilot skill, instructions file, path instructions file and repository-level Copilot settings file, under names Spektacular does not use, has each of them unchanged, byte for byte, after spektacular init copilot and after spektacular migrate run on a project whose installed skill files and standing-rule sections had first been altered to differ from the current version. On a project whose AGENTS.md already holds sections of the project's own, everything in AGENTS.md outside Spektacular's sections is likewise unchanged. This checks the constraint on what Spektacular may change.

• Another agent's files survive
  On a project set up with spektacular init claude, spektacular init bob or spektacular init codex, running spektacular init copilot with the same Spektacular version leaves every skill, command and instruction file the first setup installed unchanged. This checks the same constraint.

• No skill or command is doubled on a shared project
  For each of Claude Code, Bob and Codex: on a project set up for that agent and for Copilot, in either order, Copilot started in the top folder lists each of the six skills once and offers each of the six plain commands once.

• Copilot's own copy is the one that runs
  For each of Claude Code and Codex, the two agents whose skill folders Copilot also reads: on a project set up for that agent and for Copilot, after the other agent's copy of spek-new has been changed, entering /spek-new in a Copilot session hands the model the text of the copy installed for Copilot and not the changed text, and Copilot still lists each of the six skills once and offers each of the six plain commands once.

• Rules appear once next to Bob and Codex
  For each of Bob and Codex: on a project set up for that agent and for Copilot, in either order, the instructions Copilot assembles for a session started in the top folder contain the full text of each standing-rule section one time.

• Running setup for each agent brings a shared project up to date
  On a project set up for Copilot and for another agent whose installed files have then been altered to differ from the current version, as an older Spektacular would have left them, running spektacular init once for each of the two agents leaves each agent's installed files identical to what a fresh setup produces, and Copilot lists each skill once.

• Other agents' output is unchanged
  spektacular init for Claude Code, Bob, Codex and any other agent supported when this change is made, in an empty project, and spektacular migrate run on a project that records one of them and whose installed skill files and standing-rule sections had first been altered to differ from the current version, produce the same files with the same content as the same Spektacular source without this change. This checks the constraint on the other agents.

• Nothing is written outside the project
  After spektacular init copilot, and after spektacular migrate run on a project whose installed skill files and standing-rule sections had first been altered to differ from the current version, no file outside the project folder has been created or changed.

• README shows Copilot
  The README's list of supported agents includes Copilot CLI, says what setup installs for it, and shows how to start a workflow from Copilot.

• Website pages show Copilot
  Each website page that lists the supported agents includes Copilot CLI.

• Tutorial has a Copilot path
  The getting-started tutorial's agent choice includes Copilot CLI. Choosing it shows Copilot's install steps and its setup command, and a screenshot at every step that has one for the other agents.

• Copilot's limits are documented
  The README and the website each state that Copilot has to be started in the project's top folder, with the reason; that where a top-level CLAUDE.md imports AGENTS.md, as on every project set up for Claude Code, Copilot receives the standing rules twice, with the reason; and that a command name given with the prompt on the command line is not expanded.

• Shared projects are documented
  The README and the website each state that setting a shared project up for Copilot makes copilot its recorded agent, that an upgrade refreshes only the recorded agent's files, and that running spektacular init once for each agent after upgrading brings everything up to date. If the separate issue named under Non-Goals has been resolved when this feature is released, they describe the behaviour as it then is.

• Projects set up the old way are documented
  The README and the website each tell someone with a project that was set up for Claude Code or Codex only so that Copilot could find the skills: to run spektacular init copilot; that the earlier agent's files stay and can be removed by hand; that AGENTS.md must stay; and that the rules stay doubled while a CLAUDE.md that imports AGENTS.md remains.

Technical approach (direction, not binding)

• Add Copilot the way Codex is added, within the constraints on skills and AGENTS.md. No command files are needed. In a Copilot session every skill it finds is offered as a plain command, and the text typed after the command arrives with the skill as ARGUMENTS: ….
• Prefer installing the skills in Copilot's own project folder, .github/skills/. Copilot also reads .agents/skills/ and .claude/skills/. When the same skill is in more than one of them it is listed once, and Copilot takes .github/skills/ first, then .agents/skills/, then .claude/skills/. That order held when the copies differed, both in what Copilot listed and in the skill text a session handed to the model, so on a shared project Copilot would run its own copy.
• AGENTS.md alone carries the standing rules. Copilot loaded it together with every other instruction file tried: .github/copilot-instructions.md, a path file under .github/instructions/, a top-level GEMINI.md, and a top-level CLAUDE.md. It did not read .claude/CLAUDE.md or .gemini/GEMINI.md. Nothing tried kept AGENTS.md out.
• The rules are doubled next to Claude Code because of how init claude wires its file. That setup writes a top-level CLAUDE.md containing @AGENTS.md. Copilot loads AGENTS.md and also follows the import, so the rules arrive twice: 65,969 characters of instructions against 44,211. A top-level CLAUDE.md without the import did not double them. Stopping it would mean changing what Claude Code's setup writes, which the constraints rule out.
• Copilot can report what it found without calling a model or reaching the network. copilot skill list --json and copilot instruction list --json list the skills and instruction files, COPILOT_HOME pointed at an empty folder keeps user settings out, and COPILOT_OFFLINE=true stops all network access. A session opened with copilot --acp reports the commands it offers. Pointing COPILOT_PROVIDER_BASE_URL at a local stand-in shows the instructions Copilot assembles and what a typed command hands to the model. Together these allow an automated check of the acceptance criteria with no credentials.
• The workaround people rely on today is to set the project up for Codex or Claude Code. Hive does it too: on its v6 line, spekInitAgent runs spektacular init codex for every backend other than Claude and Bob, Copilot included.
• The acceptance criteria check what Copilot finds and what it hands to the model. A whole workflow run with a model is left to the first success metric, and to an end-to-end run if the harness can drive Copilot.
• If omp support (Support oh-my-pi (omp) as an agent: spektacular init omp #73, pull request feat: support oh-my-pi as a project agent #74) lands first, Copilot can follow the same pattern and its tests.
• The agent names are written out by hand in a number of existing tests. Copilot would be added wherever they are.
• End-to-end runs exist for Claude Code and Codex only. Add one for Copilot if the end-to-end harness can drive it. Whether it can is not known.
• Risk: Copilot's behaviour was checked on release 1.0.91 only. Copilot CLI updates itself by default and changes quickly, and the order in which it prefers skill folders is not something its help promises.
• Where this touches the code, from reading main at f424611, by name because line numbers drift. internal/agent holds the Agent interface (Name, Install) and its registry; codex.go there is the nearest model, calling installWorkflowSkills with its folder and then the eight install…Section functions that write AGENTS.md. cmd/init.go builds its help from agent.Supported(), and Lookup builds the unknown-agent message the same way, so both pick up a new agent once it is registered. installerFor in cmd/migrate.go reinstalls through the same Install. Tests that list the agents by hand: cmd/init_test.go, the []string{"claude", "codex", "bob"} loops under internal/agent, and the agent-to-folder map in uncommitted_changes_test.go. The Makefile has harbor-test-spec-claude and harbor-test-spec-codex. Documentation: the README's "Supported agents" and quick start, and in spektacular-website the pages src/pages/index.mdx, plugins.mdx, configuration.mdx, how-it-works.mdx and the AgentBlock sections of src/content/tutorials/getting-started.mdx.

How we will know it works

• A Copilot CLI user gets from an empty project to a finished spec using only the documented steps, with no files copied or renamed by hand. This is confirmed by walking through the tutorial's Copilot path at release.
• In the three months after release, no report is filed of a Copilot session missing Spektacular's skills or standing rules in a project set up for Copilot.
• In the same three months, no report is filed that setting a project up for Copilot changed how Claude Code, Bob or Codex behave on it.

Non-goals

• Keeping more than one agent's installed files current in one project. An upgrade still refreshes only the agent the project records. Tracked in Projects set up for more than one agent: migrate upgrades only one agent's files #72.
• Removing the doubled standing rules where a top-level CLAUDE.md imports AGENTS.md. Every project set up for Claude Code has such a file, and a project's owner can write one too. Copilot reads that file as well as AGENTS.md, and follows the import.
• Sessions started in a subfolder of the project. Copilot finds the skills and AGENTS.md from a subfolder, but Spektacular's own commands only work from the project's top folder, for every agent.
• Starting a workflow by command name without opening a session. Copilot passes a command name given with the prompt on the command line to the model as plain text.
• Cleaning up after the workaround. A project that was set up for Claude Code or Codex only so that Copilot could find the skills is treated as a project shared with that agent, and that agent's files stay until the user removes them.
• Changing Hive, which today sets projects up as Codex when its backend is Copilot.
• Publishing the Spektacular skills as a Copilot plugin, or to a skill registry.

Open questions

• Can the Harbor harness drive Copilot CLI, so that the spec workflow gets an end-to-end run like the ones Claude Code and Codex have?
• Is there a way to stop the standing rules being doubled on a project shared with Claude Code without changing what Claude Code's setup writes? I did not find one. If there is, that non-goal could become a requirement.

Related

• Support oh-my-pi (omp) as an agent: spektacular init omp #73 asks for the same thing for oh-my-pi (omp), and feat: support oh-my-pi as a project agent #74 is a pull request for it. Copilot needs less than omp did: no command files, and nothing extra to keep the standing rules in place.
• Projects set up for more than one agent: migrate upgrades only one agent's files #72 covers keeping every installed agent's files current, which is the other half of using Copilot next to another agent.
• Publish the spek skills to skill registries so users can install them without Hive #57 and feat: publish Spek skills to registry #67 publish the skills to a registry. As far as I can tell from the pull request description, that route installs the skill files only, so it would not cover init and migrate for Copilot or the project's recorded agent.
• Hive sets a project up as Codex when its backend is Copilot (spekInitAgent in src/pkg/dashboard/spek_hub_executor.go on the v6 line of hivecommons/hive). Once init copilot exists, Hive could use it. That is not part of this request.