Add siGit Code vs Copilot CLI parity doc and next three specs
Companion to the Claude Code roadmap. Compares siGit Code against GitHub Copilot CLI as of July 2026 (GA since February, redesigned terminal since June) and specifies the next three features: permission rule patterns, a headless programmatic mode, and git-host workflows through the official sigit.si MCP server. The in-flight PRs from the first roadmap (sigit #22, #23, #24) are counted as closed gaps, and the doc notes where siGit is ahead: in-process on-device inference and ACP as the native protocol.
Seto Elkahfi committed
Jul 4, 2026 at 22:46 UTC
1bf1c83051e4e3b8956b5b0a0af98b38ce8292ed
1 file changed
+170
docs/product/sigit-code-copilot-cli-parity.md
new
+170
@@ -0,0 +1,170 @@
1
+# siGit Code vs GitHub Copilot CLI: parity and the three biggest wins
2
+
3
+Status: draft v1 (2026-07-04). Owner: product/eng. Audience: internal (private repo).
4
+Scope: **siGit Code**, the Rust CLI / ACP agent. Companion to
5
+[sigit-code-parity-roadmap.md](sigit-code-parity-roadmap.md), which compares
6
+against Claude Code; this document compares against **GitHub Copilot CLI** and
7
+specifies the next three features. Each spec is implementable on its own branch
8
+off `development` in the `sigit` repo, independent of the others.
9
+
10
+Source basis: GitHub's Copilot CLI docs and changelog as of July 2026. Copilot
11
+CLI went GA in February 2026 and shipped a redesigned terminal interface in June
12
+2026, so this comparison is against a fast-moving GA product, not a preview.
13
+
14
+---
15
+
16
+## 1. Where we stand
17
+
18
+Copilot CLI is the closest competitor in spirit: a terminal agent that also
19
+speaks ACP and also ships skills, plan mode, MCP, and custom instructions. The
20
+open PRs from the Claude Code roadmap (sigit #22 background commands, #23
21
+subagent tool, #24 durable sessions and compaction) already close three gaps
22
+that used to be Copilot advantages. What remains:
23
+
24
+| Capability | Copilot CLI | siGit Code today |
25
+|---|---|---|
26
+| Plan mode | yes (Shift+Tab, agent picker) | yes (/plan) |
27
+| Skills / custom instructions | yes | yes (Agent Skills + AGENTS.md/CLAUDE.md) |
28
+| MCP | built-in GitHub server + custom, stdio | official sigit.si server + custom, HTTP only |
29
+| ACP | yes | yes (it is our native protocol) |
30
+| On-device inference | no (BYO endpoint only) | yes, in-process via onde |
31
+| Model picker | Anthropic/OpenAI/Google + reasoning effort | local models + cloud tiers + BYO |
32
+| Context compaction | auto at 95% + /compact + /context | in PR #24 |
33
+| Session resume | yes, across machines + /remote | in PR #24 (local only) |
34
+| Background commands | not first-class | in PR #22 |
35
+| Subagents / custom agents | yes, with automatic delegation | task tool in PR #23 |
36
+| Permission rules | allow/deny patterns like `shell(git push)` | mode + per-tool only |
37
+| Headless / programmatic mode | yes (`copilot -p`, approval flags) | no |
38
+| Git-host workflows in the terminal | Issues/PRs/Actions tabs, create/review/merge | none |
39
+| Sandboxing | local `/sandbox` + cloud `--cloud` | no |
40
+| Hooks | yes | no |
41
+| Persistent memory | Copilot Memory | `remember` tool, no recall layer |
42
+
43
+siGit's edge is real: in-process on-device inference, and ACP as the native
44
+protocol rather than an add-on. The three specs below are where Copilot CLI is
45
+ahead in ways that matter most, ordered smallest to largest.
46
+
47
+---
48
+
49
+## 2. Spec: permission rule patterns
50
+
51
+**Branch:** `feature/permission-rules` · **Touches:** `src/permissions.rs`, `src/settings.rs`
52
+
53
+### Problem
54
+
55
+The permission system (merged PR #20) knows three modes and per-tool overrides.
56
+That makes autonomy all-or-nothing per tool: `run_command = "allow"` waves
57
+through `rm -rf` along with `cargo test`. Copilot CLI's `--allow-tool
58
+"shell(git push)"` granularity is what makes long unattended runs safe, and our
59
+own longer-running sessions (PR #24 raises the round cap) make this urgent.
60
+
61
+### Design
62
+
63
+- `[permissions.rules]` in settings.toml: ordered lists `allow = [...]` and
64
+ `deny = [...]` of rule strings. A rule is `tool_name` or
65
+ `tool_name(argument_prefix)`, e.g. `run_command(git status)`,
66
+ `run_command(cargo *)`, `edit_file(src/*)`. Matching for `run_command` is
67
+ against the command string; for file tools against the path argument. `*`
68
+ is a glob-style wildcard (reuse the `glob_to_regex` helper in tools.rs).
69
+- Evaluation order inside `decision_for`, after plan mode and session grants:
70
+ deny rules, then allow rules, then the existing per-tool override, then the
71
+ default mode. First match wins; deny always beats allow.
72
+- Session grants gain the same granularity: the approval prompt's "always
73
+ allow" records `tool(prefix)` for `run_command` (the first token pair of the
74
+ command, e.g. `git push`) instead of the bare tool name, so one approval
75
+ covers the command family without opening the whole shell.
76
+- `/permissions` prints the active rule lists.
77
+
78
+### Acceptance
79
+
80
+- With `deny = ["run_command(git push*)"]` and `allow = ["run_command(git *)"]`,
81
+ `git status` runs, `git push` is denied, everything else asks.
82
+- Rules survive settings reload; unit tests cover ordering, wildcard matching,
83
+ and the deny-beats-allow invariant.
84
+
85
+---
86
+
87
+## 3. Spec: headless programmatic mode
88
+
89
+**Branch:** `feature/headless-mode` · **Touches:** `src/main.rs` (arg parsing, new run mode)
90
+
91
+### Problem
92
+
93
+Copilot CLI's `copilot -p "prompt"` runs one task and exits, which is what CI,
94
+scripts, and cron want. siGit has no equivalent: ACP needs a client and the TUI
95
+needs a TTY. Our own [Cloud Agent plan](sigit-code-cloud-agent-plan.md) needs
96
+exactly this entry point for its sandbox runner, so this spec is on the Cloud
97
+Agent critical path.
98
+
99
+### Design
100
+
101
+- `sigit -p "<prompt>"` (long form `--prompt`): resolve the backend exactly like
102
+ the ACP path (provider override, cloud when signed in, on-device), run one
103
+ agent turn loop against the prompt with the full toolset, stream assistant
104
+ text to stdout, exit 0 on completion. Logs stay on stderr. `--quiet` prints
105
+ only the final message.
106
+- Permissions in headless mode: default deny for anything that would ask (there
107
+ is nobody to ask). `--allow-tool <rule>` / `--deny-tool <rule>` flags feed the
108
+ rule engine from spec 2 for the run; `SIGIT_PERMISSIONS=allow` keeps working
109
+ as the blunt instrument. If spec 2 lands second, the flags start as bare tool
110
+ names and gain patterns when it lands.
111
+- `--cwd <dir>` sets the working directory; instruction files load from there
112
+ like every other entry point.
113
+- Exit codes: 0 success, 1 inference or tool-loop error, 2 bad invocation.
114
+
115
+### Acceptance
116
+
117
+- `sigit -p "list the rust files here and count the tests" --allow-tool
118
+ run_command` works in CI (no TTY) against a configured provider and exits 0.
119
+- A prompt that needs a denied tool finishes with the denial surfaced in the
120
+ output rather than hanging.
121
+- Integration test drives the built binary with `-p` against the scripted
122
+ OpenAI-compatible endpoint harness from `tests/acp_permissions.rs`.
123
+
124
+---
125
+
126
+## 4. Spec: git-host workflows in the terminal
127
+
128
+**Branch:** `feature/githost-tools` · **Touches:** `src/tools.rs`, official MCP server (sigit-si side)
129
+
130
+### Problem
131
+
132
+Copilot CLI ships a built-in GitHub MCP server plus Issues and Pull requests
133
+tabs: the agent reads issues, opens PRs, reviews and merges without leaving the
134
+terminal. siGit Code has the official sigit.si MCP server baked in but exposes
135
+no repository workflows through it, and sigit.si is literally our own git host.
136
+Our agent should be the best terminal client sigit.si has.
137
+
138
+### Design
139
+
140
+- sigit-si side: extend the official MCP server (`/api/v1/mcp`) with repo
141
+ workflow tools for the authenticated user: `list_issues`, `get_issue`,
142
+ `create_issue`, `list_pull_requests`, `get_pull_request` (diff included),
143
+ `create_pull_request`, `comment_on_pull_request`. Repo defaults to the origin
144
+ remote of the session cwd when it points at sigit.si; the tools take an
145
+ explicit `repo` argument otherwise.
146
+- siGit Code side: nothing structural, the MCP plumbing already namespaces and
147
+ routes these (`mcp__sigit__*`); the work is prompt-level. Teach the system
148
+ prompt that issue and PR workflows on sigit.si repos go through those tools,
149
+ and classify the read-only ones (`list_*`, `get_*`) as read-only in
150
+ `permissions.rs` so browsing issues never prompts.
151
+- GitHub repos: not in scope here. The Git-host adapter direction from the
152
+ Cloud Agent plan covers it later; users can already add GitHub's own MCP
153
+ server in mcp.toml today, which becomes the documented recipe.
154
+
155
+### Acceptance
156
+
157
+- In a repo cloned from sigit.si, "what open issues mention auth, and open a PR
158
+ for this branch that references the right one" works end to end with only
159
+ the create/comment steps prompting for permission.
160
+- Server-side request specs cover the new MCP tools; client-side unit tests
161
+ cover the read-only classification.
162
+
163
+---
164
+
165
+## 5. Sequencing
166
+
167
+Permission rules first (smallest, and headless mode wants its flags), then
168
+headless mode (Cloud Agent critical path), then git-host workflows (spans both
169
+repos). Fast follows from the table: stdio MCP transport, hooks, local
170
+sandboxing, and a recall layer over `remember`.