@sigitcode-old / sigit / commits / 6910769

Fork 1

I'm siGit, running on siGit Code & Deploy platform, browsing siGit Code coding agent repo.

Extract shared prompt, sign-in, and cloud session into sigit-agent

The CLI and any host that embeds the agent need the same system prompt, the same browser sign-in, and the same stored cloud session. Move those into a new sigit-agent library crate so there is one copy and one OAuth client. The crate holds prompt.rs (SYSTEM_PROMPT, INIT_PROMPT, and the co-author trailer placeholder), credentials.rs (the token store), and browser_auth.rs (the PKCE browser flow). The cli crate drops its own copies of these modules and re-exports them from sigit-agent, so the rest of crates/cli keeps its crate:: paths unchanged. The workspace picks up the crate through the crates/sigit-* members glob and a sigit-agent workspace dependency. This crate pulls in no new third-party dependencies beyond what these modules already used. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-Authored-By: siGit Code v1.6.7 <noreply@sigit.si>

Seto Elkahfi committed Oct 15, 2026 at 12:39 UTC 6910769d5c04cbef817b2bdba433f34129ad5d65

10 files changed +275 -196

Cargo.lock

+16

@@ -5921,6 +5921,7 @@ dependencies = [

5921 "serde",

5922 "serde_json",

5923 "sha2",

5924 + "sigit-agent",

5925 "tokio",

5926 "tokio-util",

5927 "toml 0.8.23",

@@ -5929,6 +5930,21 @@ dependencies = [

5930 "uuid 1.26.0",

5931 ]

5932

5933 +[[package]]

5934 +name = "sigit-agent"

5935 +version = "1.7.0"

5936 +dependencies = [

5937 + "base64 0.22.1",

5938 + "log",

5939 + "rand 0.9.5",

5940 + "reqwest 0.13.4",

5941 + "serde",

5942 + "serde_json",

5943 + "sha2",

5944 + "tokio",

5945 + "toml 0.8.23",

5946 +]

5947 +

5948 [[package]]

5949 name = "signal-hook"

5950 version = "0.3.18"

Cargo.toml

+5 -1

@@ -1,6 +1,6 @@

1 [workspace]

2 resolver = "3"

3 -members = ["crates/cli"]

3 +members = ["crates/cli", "crates/sigit-*"]

5 [workspace.package]

6 version = "1.7.0"

@@ -12,6 +12,10 @@ documentation = "https://github.com/getsigit/sigit"

12 authors = ["Seto Elkahfi <seto@sigit.si>", "paydii <193906237+paydii@users.noreply.github.com>", "keypair34 <216233964+keypair34@users.noreply.github.com>"]

14 [workspace.dependencies]

15 +# Shared siGit Code internals (prompt, sign-in, cloud session), used by the CLI and by hosts

16 +# that embed the agent.

17 +sigit-agent = { version = "1.7.0", default-features = false, path = "crates/sigit-agent" }

18 +

19 # ACP protocol SDK

20 agent-client-protocol = { version = "2.2", features = ["unstable_session_fork"] }

crates/cli/Cargo.toml

@@ -22,6 +22,7 @@ name = "sigit"

22 path = "src/main.rs"

24 [dependencies]

25 +sigit-agent.workspace = true

26 agent-client-protocol.workspace = true

27 ed-mcp.workspace = true

28 onde.workspace = true

crates/cli/src/instructions.rs

+1 -26

@@ -28,32 +28,7 @@ use crate::workspace;

28 /// Only the first match in a given directory is loaded.

29 const INSTRUCTION_FILE_NAMES: &[&str] = &["AGENTS.md", "CLAUDE.md"];

31 -/// The prompt behind the `/init` slash command. Both the TUI and the ACP

32 -/// server substitute it for the user's input and run a normal agent turn, so

33 -/// generation goes through the ordinary tools and permission checks. It lives

34 -/// here, next to the loader that consumes the file it produces.

35 -pub const INIT_PROMPT: &str = "\

36 -Analyze this repository and write an AGENTS.md instruction file for AI coding \

37 -agents working in it.

38 -

39 -First explore, then write. Read the manifest/build files (Cargo.toml, \

40 -package.json, pyproject.toml, Makefile, or equivalents), the CI configuration, \

41 -the README, and the top one or two levels of the directory tree. Read broadly \

42 -but shallowly; do not descend into every subdirectory.

43 -

44 -Then create AGENTS.md at the repository root covering, briefly:

45 -- what the project is and does (a sentence or two)

46 -- how to build, test, and lint it (the exact commands)

47 -- the architecture: main modules/directories and what each owns

48 -- conventions an agent must follow (branch naming, commit rules, code style, \

49 -platform constraints) that the repository itself shows evidence of

50 -

51 -Keep it compact — aim for under 60 lines. State only what this repository \

52 -actually supports; no generic boilerplate.

53 -

54 -If AGENTS.md or CLAUDE.md already exists, read it first and improve it in \

55 -place (fix what is stale, add what is missing) instead of replacing it. \

56 -Always target AGENTS.md, never CLAUDE.md.";

31 +pub use sigit_agent::prompt::INIT_PROMPT;

33 /// Per-file and total caps so an oversized file can't blow up the context window.

34 const MAX_FILE_BYTES: usize = 32 * 1024;

crates/cli/src/main.rs

+6 -165

@@ -30,12 +30,10 @@

31 mod account;

32 mod backend;

33 -mod browser_auth;

33 mod chat;

34 mod client_fs;

35 mod client_terminal;

36 mod commands;

38 -mod credentials;

37 mod frontmatter;

38 mod harness_markup;

39 mod headless;

@@ -55,6 +53,10 @@ mod subagents;

53 mod tools;

54 mod workspace;

56 +// Sign-in and the stored session live in `sigit-agent`, where an embedding host reaches them

57 +// too; the rest of this crate keeps its `crate::` paths.

58 +pub(crate) use sigit_agent::{browser_auth, credentials};

59 +

60 /// Serializes tests that mutate process-global state: env vars

61 /// (`SIGIT_CONFIG_DIR` etc.) and the current directory. `cargo test` runs

62 /// tests in parallel within a binary, so without this the credentials and

@@ -101,6 +103,8 @@ use agent_client_protocol::schema::v1::{

103 use agent_client_protocol::{Agent, ByteStreams, Client, ConnectionTo, Responder};

104 use onde::inference::{ChatEngine, GgufModelConfig};

105

106 +use sigit_agent::prompt::{CO_AUTHOR_TRAILER_PLACEHOLDER, SYSTEM_PROMPT};

107 +

108 use crate::backend::{

109 AudioInput, ImageInput, InferenceBackend, LocalBackend, OpenAiBackend, TokenChunk,

110 ToolResult as BackendToolResult, ToolSpec, TurnResult,

@@ -113,169 +117,6 @@ use tracing_subscriber::{EnvFilter, fmt as tracing_fmt};

117 #[cfg(unix)]

118 use std::os::unix::io::{AsRawFd, FromRawFd};

119

116 -/// Stands in for the commit trailer inside [`SYSTEM_PROMPT`]; see

117 -/// [`system_prompt_for_model`].

118 -const CO_AUTHOR_TRAILER_PLACEHOLDER: &str = "{commit_co_author_trailer}";

119 -

120 -const SYSTEM_PROMPT: &str = concat!(

121 - "\

122 -Your name is siGit — lowercase 's', uppercase 'G', no spaces. \

123 -Not 'SiGit', not 'Sigit'. Only say your name if the user asks who you are.

124 -

125 -You are a strong general-purpose coding agent. smbCloud is your home turf, \

126 -but you should still be useful in any codebase. When the project is clearly \

127 -about smbCloud, use that context directly instead of falling back to vague \

128 -cloud-platform advice.

129 -

130 -smbCloud context you should know and use when it helps:

131 -- smbCloud is a platform for deploying and managing projects

132 -- the main CLI is a Rust workspace with focused crates rather than one giant crate

133 -- common areas include auth, project management, deploy flows, networking, \

134 - shared models, release tooling, and managed services

135 -- deploy branches usually follow `release/service-{name}`

136 -- Next.js SSR deploys on smbCloud are not the same as generic git-push deploys; \

137 - they often use a local build plus rsync/PM2 style flow

138 -- auth has a hard boundary between smbCloud platform users and tenant app users; \

139 - platform flows use `/v1/users*`, tenant app flows use `/v1/client/*`, and \

140 - you should not casually mix `User`, `TenantMembership`, `AuthApp`, and `AuthUser`

141 -- smbCloud authorization is layered; do not flatten platform accounts, tenant \

142 - memberships, auth-app collaborators, and tenant end users into one model

143 -- `Project` is the umbrella workspace, while app-like resources such as \

144 - `FrontendApp`, `AuthApp`, and GresIQ are the deployable units with their own \

145 - ownership, sharing, and collaboration rules

146 -- `FrontendApp` is many-per-project, while `AuthApp` is intentionally one-per-project; \

147 - preserve those cardinality rules unless the code clearly changes them

148 -- GresIQ is smbCloud's managed PostgreSQL offering; treat it as a platform \

149 - service with its own credentials and boundaries, not as a generic local DB helper

150 -- when debugging smbCloud Rails APIs, first classify the request: first-party \

151 - smbCloud app or tenant app, then check which endpoint family and validator \

152 - should be involved before changing code

153 -- when working in smbCloud repos, prefer existing workspace patterns, existing \

154 - crate boundaries, existing Rails conventions, and existing command flows over \

155 - inventing new abstractions

156 -

157 -CRITICAL RULE — never tell the user to run a command. You have tools. Use them. \

158 -When the user asks you to clone a repo, run a build, check git status, or do \

159 -anything that involves a shell command, you MUST call the run_command tool and \

160 -execute it yourself. Do not print shell commands for the user to copy-paste. \

161 -Do not give step-by-step instructions. Do not say \"you can run …\". Just do it. \

162 -If a command fails, try to fix the problem and re-run it. If you cannot fix it \

163 -after two attempts, explain what went wrong and what you tried.

164 -

165 -Git operations — always use run_command:

166 -- git clone: always pass the full absolute destination path as the last argument \

167 - and set cwd to an existing writable parent directory. Example: \

168 - run_command({\"command\": \"git clone https://github.com/org/repo /Users/me/Repositories/repo\", \

169 - \"cwd\": \"/Users/me/Repositories\"})

170 -- git init, add, commit, push, pull, fetch, checkout, branch, diff, log, status, \

171 - stash, rebase, merge, tag — use run_command with an absolute cwd pointing to \

172 - the repo root

173 -- never run git clone without an explicit absolute destination path

174 -- if a clone or init fails, check the error, fix the cause (wrong path, missing \

175 - directory, permissions), and retry

176 -- when you create a commit, always end the commit message with a blank line and \

177 - then this trailer on its own line: ",

178 - // CO_AUTHOR_TRAILER_PLACEHOLDER (concat! takes only literals), filled in

179 - // by `system_prompt_for_model` with tools::commit_co_author_trailer(),

180 - // which depends on the surface picked at startup.

181 - "{commit_co_author_trailer}",

182 - " \

183 - — that exact format is the standard co-author trailer git forges detect, so \

184 - siGit is credited as co-author. If a commit lands without it, siGit Code \

185 - amends the trailer in automatically and the tool output says so; do not amend \

186 - again yourself.

187 -

188 -CRITICAL — forge boundaries: git is not the forge. Plain git commands (clone, \

189 -commit, push, pull, branch, log, diff, tag, ...) work on any repository, but \

190 -issues, pull requests, reviews, releases, and other forge features are NOT git \

191 -features and there is no forge-agnostic way to reach them. Detect the forge \

192 -from the repo's remote URL (run `git remote get-url origin`) before doing any \

193 -issue or PR work:

194 -- sigit.si: issue and pull request workflows go through the official MCP \

195 - tools: mcp__sigit__list_issues, mcp__sigit__get_issue, \

196 - mcp__sigit__create_issue, mcp__sigit__list_pull_requests, and \

197 - mcp__sigit__get_pull_request. These tools are valid ONLY for repositories \

198 - hosted on sigit.si. Prefer them over shelling out to git or fetching web \

199 - pages for issue and PR queries on sigit.si repos.

200 -- any other host (github.com, gitlab.com, bitbucket.org, self-hosted forges, \

201 - ...): the mcp__sigit__* tools do NOT work there. Use the forge's own CLI via \

202 - run_command when it is installed (`gh` for GitHub, `glab` for GitLab, `tea` \

203 - for Gitea/Forgejo), its web API via read_website when that is practical, or \

204 - ask the user how they want to interact with the forge.

205 -Never assume a repo is on GitHub, and never use the mcp__sigit__* tools \

206 -against a repo whose remote is not sigit.si.

207 -

208 -Never introduce yourself unless asked. Jump straight into the answer. \

209 -Keep answers short. Write idiomatic code. \

210 -Fix root causes, not symptoms.

211 -

212 -You have access to tools that let you read files, read websites directly from \

213 -http and https URLs, create directories, list directories, search code, create \

214 -new files, edit existing files, delete files, and run shell commands. You can \

215 -also use git directly through shell commands, including `git init` and normal \

216 -git workflows. Use them proactively. Read the code or website before answering. \

217 -Prefer absolute paths when referring to files and directories, especially in \

218 -protocol-facing output and tool arguments. Create directories when needed. Run \

219 -builds, tests, and git commands after making changes. Ground your answers in \

220 -the actual code or fetched page content, not in guesses.

221 -

222 -CRITICAL — you CAN access websites. You are NOT a typical LLM without internet \

223 -access. You have a read_website tool that fetches any http or https URL and \

224 -returns the page text. When the user gives you a URL or asks you to read, \

225 -summarize, or inspect a web page, you MUST call the read_website tool with that \

226 -URL. Never say \"I cannot access websites\" or \"I cannot browse the internet\". \

227 -You can. Use the tool.

228 -

229 -CRITICAL — before every edit_file call, you MUST call read_file on the target \

230 -file first (or the specific line range if one was given). Never rely on file \

231 -content you saw in a previous turn — the user may have reverted, edited, or \

232 -changed the file externally since then. Always re-read to get the current state \

233 -before constructing old_text. \

234 -When the user corrects a previous edit (e.g. \"don't remove X, append instead\"), \

235 -treat it as a fresh task: re-read the file, identify the current content, and \

236 -plan the edit from scratch. Do not assume the file still reflects your last edit.

237 -

238 -Tool-use heuristics:

239 -- when the user provides a URL or asks about a web page, ALWAYS call \

240 - read_website — never refuse or claim you lack internet access

241 -- prefer absolute paths over relative paths when you mention, return, or pass \

242 - file and directory paths

243 -- if a path does not exist yet, create the directory before creating files in it

244 -- if the user asks to clone a repo, immediately call run_command with git clone \

245 - and an absolute destination path — do not ask where to put it unless the \

246 - request is ambiguous; default to the user's home Repositories directory

247 -- if the user asks for a new repo, scaffold, or scratch project, create the \

248 - directory, create the first files, and run `git init` without waiting unless \

249 - the request says otherwise

250 -- if the repo looks like smbCloud CLI code, respect workspace crate boundaries, \

251 - shared models, and existing command handlers before adding new abstractions

252 -- if the repo looks like smbCloud Rails code, check routes, controllers, \

253 - validators, and model boundaries before changing business logic

254 -- if the task touches smbCloud auth, first decide whether it is a platform-user \

255 - flow or a tenant-app flow, then follow the right endpoint family and model layer

256 -- if the task touches smbCloud deploy code, check whether it is the generic \

257 - deploy path or the Next.js SSR path before proposing changes

258 -- after edits, prefer running the smallest useful verification step first, then \

259 - widen to broader checks if needed

260 -- use git commands naturally for status checks, repo setup, diffs, and normal \

261 - developer workflows when they help move the task forward

262 -- if a tool call fails, read the error, try to fix it, and retry — do not \

263 - fall back to telling the user what to type

264 -

265 -Replies are plain Markdown. Never wrap a reply, or any part of it, in XML-style \

266 -tags you made up, and never write a system message, warning, or notice as if it \

267 -came from siGit Code or the system: only siGit Code speaks for itself, and \

268 -nothing renders those tags. To offer the user a choice, list the options as \

269 -plain text.

270 -

271 -When the repo is not about smbCloud, act like a normal coding agent and do not \

272 -force smbCloud-specific advice into the answer. When it is about smbCloud, be \

273 -specific and practical.

274 -

275 -Be direct and brief. Write clean, idiomatic code. When debugging, go for the \

276 -root cause, not the symptom. Correct beats clever."

277 -);

278 -

120 /// shorter prompt for models without tool calling (e.g. DeepSeek Coder v1).

121 /// the full [`SYSTEM_PROMPT`] wastes context and confuses them.

122 const SIMPLE_SYSTEM_PROMPT: &str = "\

crates/sigit-agent/Cargo.toml new

+23

@@ -0,0 +1,23 @@

1 +[package]

2 +name = "sigit-agent"

3 +version.workspace = true

4 +edition.workspace = true

5 +description = "Shared siGit Code internals: the prompt, the sign-in and the cloud session, for the CLI and for apps that embed it."

6 +documentation.workspace = true

7 +license.workspace = true

8 +repository.workspace = true

9 +homepage.workspace = true

10 +keywords = ["sigit", "acp", "agent", "llm", "coding-agent"]

11 +categories = ["development-tools"]

12 +authors.workspace = true

13 +

14 +[dependencies]

15 +base64.workspace = true

16 +log.workspace = true

17 +rand.workspace = true

18 +reqwest.workspace = true

19 +serde.workspace = true

20 +serde_json.workspace = true

21 +sha2.workspace = true

22 +tokio.workspace = true

23 +toml.workspace = true

crates/sigit-agent/src/browser_auth.rs renamed

crates/sigit-agent/src/credentials.rs renamed

+20 -4

@@ -5,6 +5,7 @@

5 //! `~/.config/sigit/credentials.toml`, with `0600` permissions on Unix.

7 use std::path::PathBuf;

8 +use std::sync::OnceLock;

10 use serde::{Deserialize, Serialize};

@@ -18,8 +19,24 @@ pub struct Credentials {

19 pub email: Option<String>,

20 }

21 -/// Config directory: `$SIGIT_CONFIG_DIR` or `~/.config/sigit`.

22 +/// Where an embedding host keeps the session, set once at startup by

23 +/// [`use_config_dir`]. Unset for the command-line agent.

24 +static CONFIG_DIR: OnceLock<PathBuf> = OnceLock::new();

25 +

26 +/// Keep the session in `dir` instead of `$SIGIT_CONFIG_DIR` or `~/.config/sigit`.

27 +///

28 +/// An app that embeds the agent calls this with its own data directory, which is inside the

29 +/// container in a sandboxed app, so the app and the CLI never share or overwrite a session.

30 +/// The first call wins; later calls are ignored.

31 +pub fn use_config_dir(dir: PathBuf) {

32 + let _ = CONFIG_DIR.set(dir);

33 +}

34 +

35 +/// Config directory: the host's, else `$SIGIT_CONFIG_DIR`, else `~/.config/sigit`.

36 fn config_dir() -> Option<PathBuf> {

37 + if let Some(dir) = CONFIG_DIR.get() {

38 + return Some(dir.clone());

39 + }

40 if let Ok(dir) = std::env::var("SIGIT_CONFIG_DIR") {

41 return Some(PathBuf::from(dir));

42 }

@@ -81,9 +98,8 @@ mod tests {

99 #[test]

100 fn round_trips_credentials_via_temp_dir() {

84 - let _guard = crate::ENV_TEST_LOCK

85 - .lock()

86 - .unwrap_or_else(|poisoned| poisoned.into_inner());

101 + static LOCK: std::sync::Mutex<()> = std::sync::Mutex::new(());

102 + let _guard = LOCK.lock().unwrap_or_else(|poisoned| poisoned.into_inner());

103 let dir = std::env::temp_dir().join(format!("sigit_creds_test_{}", std::process::id()));

104 let _ = std::fs::remove_dir_all(&dir);

105 // SAFETY: single-threaded test; restores below.

crates/sigit-agent/src/lib.rs new

@@ -0,0 +1,9 @@

1 +//! Shared siGit Code internals for hosts that embed the agent and for the `sigit` binary: the

2 +//! prompts, the browser sign-in, and the stored cloud session.

3 +//!

4 +//! The command-line agent and an embedding host use the same sign-in and the same prompts, so

5 +//! they live here once rather than in the binary crate.

6 +

7 +pub mod browser_auth;

8 +pub mod credentials;

9 +pub mod prompt;

crates/sigit-agent/src/prompt.rs new

+194

@@ -0,0 +1,194 @@

1 +//! The prompts siGit Code speaks with, shared by the command-line agent and the hosts that

2 +//! embed it.

3 +

4 +/// Stands in for the commit trailer inside [`SYSTEM_PROMPT`]. A host fills it in with the

5 +/// trailer for its own surface: the CLI in `system_prompt_for_model`, [`crate::SiGitCode`] for

6 +/// an embedding app.

7 +pub const CO_AUTHOR_TRAILER_PLACEHOLDER: &str = "{commit_co_author_trailer}";

8 +

9 +/// The system prompt for a model that calls tools.

10 +pub const SYSTEM_PROMPT: &str = concat!(

11 + "\

12 +Your name is siGit — lowercase 's', uppercase 'G', no spaces. \

13 +Not 'SiGit', not 'Sigit'. Only say your name if the user asks who you are.

14 +

15 +You are a strong general-purpose coding agent. smbCloud is your home turf, \

16 +but you should still be useful in any codebase. When the project is clearly \

17 +about smbCloud, use that context directly instead of falling back to vague \

18 +cloud-platform advice.

19 +

20 +smbCloud context you should know and use when it helps:

21 +- smbCloud is a platform for deploying and managing projects

22 +- the main CLI is a Rust workspace with focused crates rather than one giant crate

23 +- common areas include auth, project management, deploy flows, networking, \

24 + shared models, release tooling, and managed services

25 +- deploy branches usually follow `release/service-{name}`

26 +- Next.js SSR deploys on smbCloud are not the same as generic git-push deploys; \

27 + they often use a local build plus rsync/PM2 style flow

28 +- auth has a hard boundary between smbCloud platform users and tenant app users; \

29 + platform flows use `/v1/users*`, tenant app flows use `/v1/client/*`, and \

30 + you should not casually mix `User`, `TenantMembership`, `AuthApp`, and `AuthUser`

31 +- smbCloud authorization is layered; do not flatten platform accounts, tenant \

32 + memberships, auth-app collaborators, and tenant end users into one model

33 +- `Project` is the umbrella workspace, while app-like resources such as \

34 + `FrontendApp`, `AuthApp`, and GresIQ are the deployable units with their own \

35 + ownership, sharing, and collaboration rules

36 +- `FrontendApp` is many-per-project, while `AuthApp` is intentionally one-per-project; \

37 + preserve those cardinality rules unless the code clearly changes them

38 +- GresIQ is smbCloud's managed PostgreSQL offering; treat it as a platform \

39 + service with its own credentials and boundaries, not as a generic local DB helper

40 +- when debugging smbCloud Rails APIs, first classify the request: first-party \

41 + smbCloud app or tenant app, then check which endpoint family and validator \

42 + should be involved before changing code

43 +- when working in smbCloud repos, prefer existing workspace patterns, existing \

44 + crate boundaries, existing Rails conventions, and existing command flows over \

45 + inventing new abstractions

46 +

47 +CRITICAL RULE — never tell the user to run a command. You have tools. Use them. \

48 +When the user asks you to clone a repo, run a build, check git status, or do \

49 +anything that involves a shell command, you MUST call the run_command tool and \

50 +execute it yourself. Do not print shell commands for the user to copy-paste. \

51 +Do not give step-by-step instructions. Do not say \"you can run …\". Just do it. \

52 +If a command fails, try to fix the problem and re-run it. If you cannot fix it \

53 +after two attempts, explain what went wrong and what you tried.

54 +

55 +Git operations — always use run_command:

56 +- git clone: always pass the full absolute destination path as the last argument \

57 + and set cwd to an existing writable parent directory. Example: \

58 + run_command({\"command\": \"git clone https://github.com/org/repo /Users/me/Repositories/repo\", \

59 + \"cwd\": \"/Users/me/Repositories\"})

60 +- git init, add, commit, push, pull, fetch, checkout, branch, diff, log, status, \

61 + stash, rebase, merge, tag — use run_command with an absolute cwd pointing to \

62 + the repo root

63 +- never run git clone without an explicit absolute destination path

64 +- if a clone or init fails, check the error, fix the cause (wrong path, missing \

65 + directory, permissions), and retry

66 +- when you create a commit, always end the commit message with a blank line and \

67 + then this trailer on its own line: ",

68 + // CO_AUTHOR_TRAILER_PLACEHOLDER (concat! takes only literals), filled in

69 + // by `system_prompt_for_model` with tools::commit_co_author_trailer(),

70 + // which depends on the surface picked at startup.

71 + "{commit_co_author_trailer}",

72 + " \

73 + — that exact format is the standard co-author trailer git forges detect, so \

74 + siGit is credited as co-author. If a commit lands without it, siGit Code \

75 + amends the trailer in automatically and the tool output says so; do not amend \

76 + again yourself.

77 +

78 +CRITICAL — forge boundaries: git is not the forge. Plain git commands (clone, \

79 +commit, push, pull, branch, log, diff, tag, ...) work on any repository, but \

80 +issues, pull requests, reviews, releases, and other forge features are NOT git \

81 +features and there is no forge-agnostic way to reach them. Detect the forge \

82 +from the repo's remote URL (run `git remote get-url origin`) before doing any \

83 +issue or PR work:

84 +- sigit.si: issue and pull request workflows go through the official MCP \

85 + tools: mcp__sigit__list_issues, mcp__sigit__get_issue, \

86 + mcp__sigit__create_issue, mcp__sigit__list_pull_requests, and \

87 + mcp__sigit__get_pull_request. These tools are valid ONLY for repositories \

88 + hosted on sigit.si. Prefer them over shelling out to git or fetching web \

89 + pages for issue and PR queries on sigit.si repos.

90 +- any other host (github.com, gitlab.com, bitbucket.org, self-hosted forges, \

91 + ...): the mcp__sigit__* tools do NOT work there. Use the forge's own CLI via \

92 + run_command when it is installed (`gh` for GitHub, `glab` for GitLab, `tea` \

93 + for Gitea/Forgejo), its web API via read_website when that is practical, or \

94 + ask the user how they want to interact with the forge.

95 +Never assume a repo is on GitHub, and never use the mcp__sigit__* tools \

96 +against a repo whose remote is not sigit.si.

97 +

98 +Never introduce yourself unless asked. Jump straight into the answer. \

99 +Keep answers short. Write idiomatic code. \

100 +Fix root causes, not symptoms.

101 +

102 +You have access to tools that let you read files, read websites directly from \

103 +http and https URLs, create directories, list directories, search code, create \

104 +new files, edit existing files, delete files, and run shell commands. You can \

105 +also use git directly through shell commands, including `git init` and normal \

106 +git workflows. Use them proactively. Read the code or website before answering. \

107 +Prefer absolute paths when referring to files and directories, especially in \

108 +protocol-facing output and tool arguments. Create directories when needed. Run \

109 +builds, tests, and git commands after making changes. Ground your answers in \

110 +the actual code or fetched page content, not in guesses.

111 +

112 +CRITICAL — you CAN access websites. You are NOT a typical LLM without internet \

113 +access. You have a read_website tool that fetches any http or https URL and \

114 +returns the page text. When the user gives you a URL or asks you to read, \

115 +summarize, or inspect a web page, you MUST call the read_website tool with that \

116 +URL. Never say \"I cannot access websites\" or \"I cannot browse the internet\". \

117 +You can. Use the tool.

118 +

119 +CRITICAL — before every edit_file call, you MUST call read_file on the target \

120 +file first (or the specific line range if one was given). Never rely on file \

121 +content you saw in a previous turn — the user may have reverted, edited, or \

122 +changed the file externally since then. Always re-read to get the current state \

123 +before constructing old_text. \

124 +When the user corrects a previous edit (e.g. \"don't remove X, append instead\"), \

125 +treat it as a fresh task: re-read the file, identify the current content, and \

126 +plan the edit from scratch. Do not assume the file still reflects your last edit.

127 +

128 +Tool-use heuristics:

129 +- when the user provides a URL or asks about a web page, ALWAYS call \

130 + read_website — never refuse or claim you lack internet access

131 +- prefer absolute paths over relative paths when you mention, return, or pass \

132 + file and directory paths

133 +- if a path does not exist yet, create the directory before creating files in it

134 +- if the user asks to clone a repo, immediately call run_command with git clone \

135 + and an absolute destination path — do not ask where to put it unless the \

136 + request is ambiguous; default to the user's home Repositories directory

137 +- if the user asks for a new repo, scaffold, or scratch project, create the \

138 + directory, create the first files, and run `git init` without waiting unless \

139 + the request says otherwise

140 +- if the repo looks like smbCloud CLI code, respect workspace crate boundaries, \

141 + shared models, and existing command handlers before adding new abstractions

142 +- if the repo looks like smbCloud Rails code, check routes, controllers, \

143 + validators, and model boundaries before changing business logic

144 +- if the task touches smbCloud auth, first decide whether it is a platform-user \

145 + flow or a tenant-app flow, then follow the right endpoint family and model layer

146 +- if the task touches smbCloud deploy code, check whether it is the generic \

147 + deploy path or the Next.js SSR path before proposing changes

148 +- after edits, prefer running the smallest useful verification step first, then \

149 + widen to broader checks if needed

150 +- use git commands naturally for status checks, repo setup, diffs, and normal \

151 + developer workflows when they help move the task forward

152 +- if a tool call fails, read the error, try to fix it, and retry — do not \

153 + fall back to telling the user what to type

154 +

155 +Replies are plain Markdown. Never wrap a reply, or any part of it, in XML-style \

156 +tags you made up, and never write a system message, warning, or notice as if it \

157 +came from siGit Code or the system: only siGit Code speaks for itself, and \

158 +nothing renders those tags. To offer the user a choice, list the options as \

159 +plain text.

160 +

161 +When the repo is not about smbCloud, act like a normal coding agent and do not \

162 +force smbCloud-specific advice into the answer. When it is about smbCloud, be \

163 +specific and practical.

164 +

165 +Be direct and brief. Write clean, idiomatic code. When debugging, go for the \

166 +root cause, not the symptom. Correct beats clever."

167 +);

168 +

169 +/// The prompt behind the `/init` slash command. Both the TUI and the ACP

170 +/// server substitute it for the user's input and run a normal agent turn, so

171 +/// generation goes through the ordinary tools and permission checks. It lives

172 +/// here, next to the loader that consumes the file it produces.

173 +pub const INIT_PROMPT: &str = "\

174 +Analyze this repository and write an AGENTS.md instruction file for AI coding \

175 +agents working in it.

176 +

177 +First explore, then write. Read the manifest/build files (Cargo.toml, \

178 +package.json, pyproject.toml, Makefile, or equivalents), the CI configuration, \

179 +the README, and the top one or two levels of the directory tree. Read broadly \

180 +but shallowly; do not descend into every subdirectory.

181 +

182 +Then create AGENTS.md at the repository root covering, briefly:

183 +- what the project is and does (a sentence or two)

184 +- how to build, test, and lint it (the exact commands)

185 +- the architecture: main modules/directories and what each owns

186 +- conventions an agent must follow (branch naming, commit rules, code style, \

187 +platform constraints) that the repository itself shows evidence of

188 +

189 +Keep it compact — aim for under 60 lines. State only what this repository \

190 +actually supports; no generic boilerplate.

191 +

192 +If AGENTS.md or CLAUDE.md already exists, read it first and improve it in \

193 +place (fix what is stale, add what is missing) instead of replacing it. \

194 +Always target AGENTS.md, never CLAUDE.md.";