code-task

name	code-task
description	PREFERRED way to change code in a REAL repository: fix a GitHub issue, fix a bug, add/implement a function or feature, or make any edit to a project the user names by a filesystem path (e.g. /tmp/foo, ~/code/bar) or a git URL. Clones the repo, runs an OpenSquilla agent on the host to make the change on a task branch, then independently VERIFIES it with a red→green→regression test loop and reports a structured result. STRONGLY prefer this over hand-editing the user's files yourself in this session: editing files directly skips the isolation and the runner-verified red→green proof, so it is not equivalent. Use it whenever the request names a real on-disk repo/path or a repo URL and asks to fix/add/implement/change code. Examples: 'fix issue 412 in github.com/acme/widgets', '给 /tmp/calc 加个 average 函数', '帮我改一下 ~/proj 里的 X', 'implement CSV export in my project'. Docker-free host execution; treat the target repo as TRUSTED. GitHub issue mode needs the `gh` CLI. For self-contained, TESTABLE code from scratch when NO repo is named (e.g. 'write a function that maps A-Z to pitches'), use `--verification-mode scratch` with no --repo: it scaffolds a throwaway project, writes the code plus a test, and verifies it green. Only truly trivial one-liners or conceptual/non-testable questions are answered inline.
description_zh	在真实代码仓库中修改代码的首选方式：修复GitHub issue、修复bug、添加/实现函数或功能，或对用户以文件路径或git URL指定的项目做任何改动。它克隆仓库、在任务分支上运行OpenSquilla代理进行修改，再通过红→绿→回归测试循环独立验证并返回结构化结果，优于在本会话中手动改文件。当请求指定了真实的本地仓库/路径或仓库URL并要求修复/添加/实现/更改代码时使用；若未指定仓库、需从零编写可测试代码，则用 --verification-mode scratch。仅极简单的一行改动或概念性/不可测试的问题才直接内联回答。
triggers	["code-task","fix the issue","fix issue","fix the bug","implement this feature","add a function","add a feature","change the code","解决 issue","给项目加功能","给项目加","加个函数","加一个函数","改一下代码","修复仓库","修复 bug"]
provenance	{"origin":"openstarry-original","license":"Apache-2.0","maintained_by":"OpenStarry Code"}
metadata	{"opensquilla":{"requires_tools":["background_process","exec_command","process"]},"platform":{"emoji":"🛠️","requires":{"bins":"[Truncated]","env":"[Truncated]"},"install":[]}}

code-task

Solve a real-repository coding task end to end: clone the repo to a disposable working directory, run an OpenStarry Code agent to make the change on a task branch, then independently verify it with a red→green→regression loop. Host mode (no Docker) in v1.

Use this — do not hand-edit the repo yourself

When the user asks to fix/add/implement/change code in a repository they name by path or URL, route it through openstarry-code code-task solve — even if the change looks small enough to do by hand. Editing the files yourself in this session is not equivalent: it skips the disposable clone, the task branch, and (most importantly) the runner-verified red→green→regression proof, so neither you nor the user gets evidence the change actually works. Answer inline (no code-task) ONLY for truly trivial one-liners, pseudocode, or conceptual / non-deterministic questions. For self-contained TESTABLE code from scratch with no repo named, use code-task solve --task "..." --verification-mode scratch (no --repo): it writes the code plus a test and verifies it green-only (no red/regression -- there is nothing pre-existing to regress). When a real repo is named, prefer code-task red-green.

Translating the user's request

The user speaks naturally ("fix issue 412 in github.com/acme/widgets", "add CSV BOM support to my project at ~/code/foo"). Map that to the command:

openstarry-code code-task solve --repo <url-or-path> ( --issue N | --task "<text>" | --task-file <path> ) [--yes]

Invocation: do NOT assume a bare openstarry-code (or bare python) is on PATH — the gateway commonly runs from an absolute interpreter path. When coding mode is active it injects the EXACT, resolved, PATH-independent command: use ONLY that. Otherwise invoke via an ABSOLUTE interpreter, e.g. /abs/path/python -P -m openstarry_code.cli.main code-task solve .... Never install a second OpenStarry Code runtime or run an installer to "get" the command; if it cannot be run, stop and report the environment is broken.

• A GitHub issue → --issue N (needs gh; see below).
• A short request in the message → --task "<their request>".
• A long spec, or pasted from Jira/GitLab/内网 → save it to a file and use --task-file <path>.
• Pass --repo for changes to an EXISTING repo. Omit it for --verification-mode scratch (from-scratch code) and for a from-scratch --verification-mode build (a brand-new app) — both scaffold their own repo. If the user is already in a local checkout, use that path; otherwise the URL.