القائمة
Guru Team Trellis fallback orientation entry. Use when automatic startup context is unavailable, hooks did not run, or the user explicitly asks to reload full Trellis context.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Guru Team Trellis continue entry. Use to advance the current task through planning, implementation, commit, and Branch Review Gate before finish-work.
Guru Team Trellis finish entry. Use after task work is committed and Branch Review Gate passed; archives task, records journal, then publishes a non-draft PR.
Discovers and injects project-specific coding guidelines from .trellis/spec/ before implementation begins. Reads spec indexes, pre-development checklists, and shared thinking guides for the target package. Use when starting a new coding task, before writing any code, switching to a different package, or needing to refresh project conventions and standards.
Guides collaborative requirements discovery before implementation. Creates task directory, seeds PRD, asks high-value questions one at a time, researches technical choices, and converges on MVP scope. Use when requirements are unclear, there are multiple valid approaches, or the user describes a new feature or complex task.
Comprehensive quality verification: spec compliance, lint, type-check, tests, cross-layer data flow, code reuse, and consistency checks. Use when code is written and needs quality verification, before committing changes, or to catch context drift during long sessions.
Understand and customize the local Trellis architecture inside a user project. Use when modifying .trellis plus platform hooks, settings, agents, skills, commands, prompts, workflows, the channel runtime (trellis channel), bundled runtime agents under .trellis/agents/, selectable workflow templates, registry-backed spec refresh, cross-session memory (trellis mem) generated by trellis init, or AI-facing bundled skills (trellis-channel, trellis-session-insight, trellis-spec-bootstrap) and bundled-skill auto-dispatch flow.
| name | trellis-start |
| description | Guru Team Trellis fallback orientation entry. Use when automatic startup context is unavailable, hooks did not run, or the user explicitly asks to reload full Trellis context. |
Use this entry as fallback / explicit orientation. In normal auto-bootstrap platforms, users can describe the task, paste an issue URL, or say "handle issue #123"; the AI should classify that request from injected Trellis context, workflow-state, startup context, hook breadcrumbs, or skill matching.
Run this start entry when the platform has no automatic session/startup injection, hooks are disabled or unapproved, bootstrap appears not to have run, or the user asks for a full context report / reload.
python3 ./.trellis/scripts/get_context.py
python3 ./.trellis/scripts/get_context.py --mode phase
task.py create in the current checkout. Do not silently edit the current checkout. Run:.trellis/guru-team/scripts/bash/check-env.sh --json
.trellis/guru-team/scripts/bash/prepare-task.sh --json "<user request, issue number, or issue URL>"
Treat default prepare-task as intake/preflight planning only. Show duplicate candidates, proposed title/body when present, naming quality result, base branch, branch name, workspace path, and the confirmed command. If naming_quality.ok=false or requires_semantic_name=true, read the issue and choose a semantic English short-name, then pass it explicitly with --short-name, --workspace-slug, --task-slug, and --branch; do not rely on Chinese transliteration or low-information names such as issue-52. If prepare returns proposed_issue / requires_confirmation, stop until the user approves GitHub issue creation. Only then rerun with --create-issue-confirmed --issue-title "<reviewed title>" --issue-body-file <reviewed-body-file>.
After reading the request or issue body/comments, perform the .trellis/workflow.md intake clarity check. If scope, acceptance criteria, close/ref semantics, or implementation target is ambiguous, enter trellis-brainstorm before task start; inspect repository evidence before asking user questions. Clarification results must be reflected in a reviewed proposed issue body, an issue comment, or a deliberate issue body update when appropriate.
Ask for consent before creating a GitHub issue, worktree, branch, or Trellis task unless the user explicitly requested that side effect. --create-worktree and --create-task are executor flags for after intake plan review, not default intake commands, and they fail closed when naming quality requires semantic overrides. In workspace_mode: worktree, use prepare-task --create-worktree --create-task or an equivalent controlled Guru Team executor to create the execution worktree and task; do not run bare python3 ./.trellis/scripts/task.py create ... in the source checkout.
After an executor path writes .trellis/tasks/<task-slug>/task-start-context.json, treat its portable workspace_slug, task_workspace_id, and task_artifact_dir as identifiers only; resolve the machine-local task worktree from the current checkout, .trellis/.runtime/guru-team/**, and git worktree list, then use that resolved checkout as the write boundary for all task artifact writes. Before writing or validating planning-approval.json, phase2-check.json, agent-assignment.json, reviews/*.md, review.md, or review-gate.json, run .trellis/guru-team/scripts/bash/check-workspace-boundary.sh --json --task <task-path> from the target worktree. If an edit tool cannot receive an explicit workdir, use an absolute path under the task worktree, never a source-checkout relative task path.
Task creation consent is not current-checkout direct-edit consent. A current-checkout direct-edit override is allowed only after explicit user approval. The approval must state that the user wants to skip creating or reusing a GitHub issue, Trellis task, worktree, and branch for this turn. Before editing, summarize the skipped artifacts, current checkout, current branch, dirty state, expected side effects, changed-file scope, and that commit/push/PR still require separate approval.
In target business repositories, keep human-readable documentation in Chinese by default: .trellis/spec/**, .trellis/tasks/**, docs/**, docs SSOT created or completed by 00-bootstrap-guidelines, and workflow artifact fields such as summaries, evidence, findings, observations, follow-up candidates, PR titles, and PR bodies. Literal commands, paths, config keys, GitHub keywords, external API names, and code symbols may stay in English.
During planning, follow .trellis/workflow.md for Middle-platform Knowledge Gate and Repo Docs SSOT discovery. MCP availability is checked from current AI tools/capabilities, not shell scripts.
Treat .trellis/tasks/<task-slug>/task-start-context.json as intake provenance only. Final close/ref/followup scope belongs in the task-level issue-scope-ledger.json; sub-agent assignment and reuse evidence belongs in task-local agent-assignment.json.
Full contract lives in .trellis/workflow.md.