菜单
Gest Issue. Create or update durable Gest outline tasks with user story, context, acceptance criteria, tags, metadata, and child-of links.
用 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 | gis |
| description | Gest Issue. Create or update durable Gest outline tasks with user story, context, acceptance criteria, tags, metadata, and child-of links. |
Use to create or update durable internal Gest tasks. These are Gest issues, not necessarily GitHub issues.
## User Story
As a <role>, I want <capability> so that <benefit>.
## Context
Why this matters and any constraints.
## Acceptance Criteria
- [ ] <measurable outcome>
## Out of Scope
- <non-goal>
Use tags and metadata deliberately:
gest task create "<title>" \
-d "<issue body>" \
-l child-of:<parent-id> \
--tag outline \
--tag issue \
--tag <area> \
--metadata workflow.kind=session \
--metadata depth=1 \
--quiet
Use subissue for lower-level children. Subissues should always have a parent.
For tasks that will write files, include VCS metadata when the branch/execution shape is known:
--metadata vcs.tool=git-butler \
--metadata vcs.branch_mode=stacked-development \
--metadata vcs.execution=gitbutler-workspace \
--metadata vcs.parallel_allowed=false
Use vcs.execution=git-worktrees and a distinct vcs.workspace_path per task
when parallel agents will write concurrently. Do not model GitButler parallel
lanes as agent parallelism.
When creating or updating durable tasks, run the classification pass in references/tag_dependency_workflow.md: collect existing tags, select matching tags, reject near misses explicitly when useful, and add new dynamic tags only when no existing tag covers the concept. Use metadata such as classification.tags.reviewed=true, classification.tags.new=<comma-separated-new-tags>, and impact.ast_grep.required=true|false for code-facing work.