AGENTS.md requires functions under 50 lines; planOperations was 54 and mixed
source filtering, destination mapping, and operation construction. Extract the
per-path mapping into planSourcePathOperations and share the prefix test with
supportsCopilotSourcePath. planOperations is now 18 lines. No behaviour change.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
GitHub Copilot CLI discovers SKILL.md skills from .github/skills/ and custom
agents from .github/agents/, so ECC's catalog can be installed there without a
conversion step. This adds a managed-project install target that places both.
Scope is deliberately limited to agents and skills. ECC hooks are written
against Claude Code's event model, and commands rely on slash-command argument
substitution Copilot does not provide, so neither is installed.
Agent frontmatter goes through an allowlist transform rather than a passthrough:
Copilot resolves the session model from user configuration, so a Claude model id
makes it warn and fall back on every invocation; Claude tool names are not
Copilot tool names, and Copilot governs tool access per session via
--allow-tool/--deny-tool. Unknown keys added to ECC agents later therefore
cannot leak into the Copilot copy.
Target selection stays permissive in supportsModule so dependency-anchor modules
still resolve; planOperations is what narrows the install, matching the
convention used by the other adapters.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Reviewers without the CLI on PATH can reproduce the plain-clone count with the
npm-distributed build. The 39 + 3 split is reported by 1.0.82 from npm and by
1.0.83 installed locally, so it is not specific to one build or install method.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot CLI 1.0.83 lists all 42 plain-clone entries under Project skills with
source project and enabled true. Record that the three from .claude/commands/
are Claude command files surfaced as skills, and that their reported path is
the .claude/commands directory rather than a per-skill subdirectory.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The jq snippet filtered on source == "project", which returns 290 rather
than 286: the full catalog under .github/skills/ plus the .claude/commands/
entries and the one .agents/skills/ skill whose name does not collide with a
full-catalog entry. Filter on the path instead and explain the de-duplication.
Also document that Copilot registers a skill under its SKILL.md frontmatter
name rather than its directory name, so catalog folders whose directory and
frontmatter names differ still load.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot CLI discovers SKILL.md skills from .github/skills/, .agents/skills/, .claude/skills/, ~/.copilot/skills/ and ~/.agents/skills/, and custom agents from .github/agents/. ECC's existing skill and agent frontmatter is already compatible, so the README's 'no native skill discovery' and 'no subagent API' statements are out of date.
Because ECC ships a Codex skill subset in .agents/skills/, a plain clone already loads 42 ECC skills into Copilot CLI with no configuration. Placing skills/ at .github/skills/ loads all 286, all enabled.
Documentation only. No installer target, no hook porting, no new execution surface. Verified against Copilot CLI 1.0.83.
Keep npm and Yarn resolution policy aligned so both lockfile paths stay on the patched release.\n\nCo-authored-by: Svector-anu <svector-anu@users.noreply.github.com>
* docs(ito-compute): document ito accept and ito_accept MCP workflow
Updates the canonical ECC skill to cover the new quote acceptance path:
- CLI: ecc ito accept <ticket-id>
- MCP: ito_accept tool
- Explicit buyer-authority guard before accepting
- Clear statement that accept routes to desk, does not purchase
* test(ito-compute): assert the four-tool MCP boundary including ito_accept
The exact-boundary test pinned the three-tool description. Runtime
ito-compute-cli now exposes ito_accept (Ito-Markets/ito-cloud-runtime#1453),
so the template boundary assertion moves to four tools.
* docs(ito-compute): drop the firm-quote gate from the accept workflow
Desk quotes are indicative_paper in production (a firm quote requires the
separate human-held signing path and cannot reach the client), so gating
accept on 'a firm quote is ready' described an unfireable condition. Align
with the runtime contract: accept routes the current desk quote to human
review and the result carries quote_class (ito-cloud-runtime#1453).
The uninstall cases run two full CLI passes (install, then uninstall)
over several hundred files under a flat 30s timeout, which is tight
enough on Windows CI to fail intermittently with spawnSync ETIMEDOUT.
install-apply.test.js already scales its timeout by platform for the
same reason; match that precedent rather than re-running past the flake.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The guided installer asks how ECC hooks should run, but that consent
lived only in the wizard path. Running install-apply directly with a
profile that includes hooks-runtime still materialized the hook runtime
with no disclosure and no decision.
Gate the apply layer instead, so every entry point is covered:
- disclose the six hook capability groups when a plan would materialize
the hook runtime, and refuse to apply until the caller decides
- --enable-hooks confirms the hook runtime; --no-hooks installs the rest
of the selection without it and records the reduced module closure in
install-state
- surface the pending decision as a dry-run warning
- show the same capability disclosure in the guided installer's plan
preview, so the wizard's hook question states what it is asking about
Plans that never materialize hooks (Kimi, --profile minimal,
--without baseline:hooks) are unaffected and need no flag. Repair and
uninstall operate on already-recorded state and stay unchanged.
The capability taxonomy and the held-materialization behavior come from
Samarjeet Singh Tomar's PR #2634, reworked to fit the single-decision
consent model that shipped with the guided installer in #2649.
Co-Authored-By: Samarjeet Singh Tomar <samar_tomar@hotmail.com>
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
