一键导入
gor
Gest Orchestrate. Execute a phased Gest iteration, deciding per phase whether work should run sequentially or in parallel physical worktrees/subagents.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Gest Orchestrate. Execute a phased Gest iteration, deciding per phase whether work should run sequentially or in parallel physical worktrees/subagents.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Gest Format. Run formatting, linting, typechecking, compile/static checks, and mechanical diff hygiene; fix mechanical issues. Use gte for tests and gdo for documentation.
Gest Implement. Implement one concrete Gest task end to end by reading, claiming, splitting if too broad, editing, verifying, reviewing, formatting as appropriate, and completing it.
Gest Setup. Bootstrap or refresh a Gest-tracked repository workflow surface across tool checks, project command contracts, Justfile targets, AGENTS.md mappings, docs, tests, and setup follow-ups.
Gest Test. Run unit, API regression, smoke, regression, and integration tests appropriate to the changed code; add missing tests when the task changes callable behavior.
Gest Track Work. Use for substantial coding, debugging, implementation, refactoring, documentation, verification, GitHub issue planning, or project work. GTW is the router that classifies requests, chooses/creates Gest outline parents, creates session or development tasks, decides whether a spec or parallel work is needed, and routes to the g* stage skills.
Gest Brainstorm. Explore rough ideas or ambiguous requests, inspect existing code/docs/Gest context, ask clarifying questions when needed, and decide whether to create a spec, outline issue, plan, or session task.
| name | gor |
| description | Gest Orchestrate. Execute a phased Gest iteration, deciding per phase whether work should run sequentially or in parallel physical worktrees/subagents. |
Use for a phased iteration. Works for both session and development iterations.
gest iteration show <id> --json
gest iteration status <id> --json
gest iteration graph <id>
gest project --json
gest search "<area/topic>" --all --json --limit 20 hits,
especially unresolved follow-ups and previous verification notes.gim locallygest iteration next <id> --claim --agent <agent-name> --json
Exit code 75 means no task is currently available.
vcs.workspace_path metadata for each writable task when practical.Do not parallelize just because there are multiple tasks. Parallelize only when task independence and file ownership make it useful.
Distinguish sub-agent roles before dispatch:
Gest mutations, task completion, commit/push decisions, and PR decisions should remain centralized unless a role is explicitly assigned those responsibilities. Writable sub-agents must have disjoint write scopes. In Git/GitButler repos, concurrent writable work uses physical git worktrees, not GitButler parallel lanes.
Agentic Just targets add a mandatory delegation case: an emitted AGENT_TASK v1
block is a subagent handoff packet. The current agent validates the packet and
delegates the parsed task rather than running it inline. Nested agentic Just
calls, agentic dependencies, hook-triggered packets, and agentic verification
targets inherit the same recursive subagent boundary.
GitButler parallel branches and stacked branches share one managed workspace. They are useful for sequential branch curation, but they are not the execution primitive for multiple write agents.
Before dispatching more than one writable task, inspect task/iteration metadata for:
vcs.tool=git-butler
vcs.execution=gitbutler-workspace
vcs.parallel_allowed=false
If those values apply, do not launch parallel write agents. Run the phase
sequentially, using but status, explicit branch targets, and current but
commands. If the phase truly needs parallelism, create physical git worktrees
first and update metadata to vcs.execution=git-worktrees with a distinct
vcs.workspace_path per task. After worktree tasks finish, integrate the
results back into the intended branch or stack in a separate sequential step.
Before dispatching phase work, make sure each child task has gone through the tag classification pass from references/tag_dependency_workflow.md. For code-facing tasks, workers should know which semantic contracts and ast-grep patterns must be checked. Dependent surfaces found by tags or ast-grep should be in the same task, a linked child task, or an explicit follow-up before completion.