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>
_parse_stream_json() persisted raw tool_input/tool_response content into
ObservationEvents that grade() scores and generate_report() writes to
results/<skill>.md -- a report meant to be shared and reviewed.
--add-dir restricts the agent's additional accessible directory to the
sandbox (SANDBOX_BASE = /tmp/skill-comply-sandbox), but that doesn't stop
the agent's own tool calls (a Bash command using ~ expansion, a scenario
setup_commands entry referencing a dotfile) from emitting the operator's
home directory into tool_input/tool_response -- which then lands
verbatim, truncated but not sanitized, in the written report.
Adds _redact_home_path(), pure stdlib (Path.home()), applied to both
input_str and output_str before they're stored on the ObservationEvent.
Scoped deliberately to the home directory only -- grade() needs real
tool-call semantics for LLM-based compliance classification, so
truncating/stripping content the way a pure logging hook could isn't an
option here; only the operator-identifying path component needs to go.
New TestParseStreamJsonRedactsHomePath class in
skills/skill-comply/tests/test_runner.py (3 tests) -- full file now
10/10 passing, up from 7/7. Confirmed tests/test_invariant_runner.py (the
sandbox-execution security tests from #2149) still passes clean, 4/4.
Fixes#2730
