Coordinate a development task from planning through implementation and review. Choose whether to proceed after seeing the plan, then receive a report covering commits, verification results, review findings, and any work left unfinished.
中文简介正在准备中。当前显示英语简介。
Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: "/gitnexus-lfg Add retry support to the ingestion pipeline", "run the gitnexus pipeline on this", "plan, build and review this feature".
安装前可以查看交给 AI 代理的指令内容。
Thin orchestrator over three existing skills. It adds no engineering logic of
its own — it sequences gitnexus-plan, gitnexus-work, and
gitnexus-review, with the user deciding at the plan gate. Run every lane
by actually invoking the named skill (read its SKILL.md and follow it);
never inline a summary of what the skill would have done.
/gitnexus-lfg <task description>
/gitnexus-lfg docs/plans/<existing-plan>.md # skip lane 1, start at the gate
Boundary triage first. If the task is plainly below the planning
boundary — trivial or small-bounded work an agent finishes in well under ~35
turns (the measured regime where a planning pass costs more than it returns;
measured in the GitNexus repository's eval/workflow_bench/) — say so and
offer gitnexus-work direct mode as an alternative to the full pipeline
before spending the plan lane. Honor the user's choice.
The threshold is a promoted benchmark policy measured offline, not a timeless heuristic — never self-edit it from a live task. Its re-evaluation governance lives in this skill's README.
Otherwise invoke gitnexus-plan with the task (knob overrides pass through
verbatim; gitnexus-plan owns the up-front depth question — never ask it
again here). If the input is already a plan file path, skip to Lane 2. The
plan lands in docs/plans/ — record its path; every later lane consumes it.
Present the plan's chat summary (objective, proposed changes, sequence, top
risks, open questions, plan path), then ask the user — as a blocking
question (AskUserQuestion in Claude Code; a numbered list in chat on CLIs
without a blocking tool):
Depth was the user's up-front choice in Lane 1, so deepening is not offered
by default — but honor an explicit request for it at the gate: run
gitnexus-plan Deepen mode on the plan file and return here with the
strengthened plan, as many times as the user asks. Do not proceed past the
gate without an explicit choice — the gate is the pipeline's only checkpoint
and exists precisely because execution is expensive to unwind.
Headless / non-interactive runs: no one can answer the gate, so end the pipeline after Lane 1 — the plan file is the deliverable (gate option 2) — and say so in the final report. Never auto-proceed to execution.
Invoke gitnexus-work with the plan path. It re-anchors the plan at HEAD,
executes the Implementation Sequence as verified atomic commits, refreshes
the knowledge graph when done (its Phase 4), and reports deviations. If it routes back for re-planning (structural drift), run the
Deepen pass and return to the Lane 2 gate rather than pushing through.
Invoke gitnexus-review on the completed work. Pass an open PR URL/number
when one exists; otherwise pass the current branch. The review skill owns
target resolution, exact-SHA checkout/index alignment, and merge-base
selection. Do not duplicate that logic here. If work left local changes,
pass local as a second, separately labeled review surface.
Surface the review verdict and findings to the user. Findings the user
wants fixed: those within gitnexus-work's direct-mode bounds (1–2 files,
no architectural decisions) → hand to gitnexus-work direct mode; anything
larger → offer the plan gate instead (Deepen the plan with the findings, or
stop). Then re-run this lane's review once. On that re-run, do not start
another fix cycle even if findings remain — report them and point the user
at /gitnexus-work (or the plan gate) to continue deliberately.
One message: plan path, deepen cycles run, commits produced, verification status, review verdict with unresolved findings, and what (if anything) was explicitly left undone. The pipeline does not push or open a PR on its own — offer both as next steps.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Build and maintain a GitNexus code index, a searchable map of code relationships. Use CLI commands to refresh or remove indexes, check their status, list indexed projects, and generate repository documentation with an LLM.
中文简介正在准备中。当前显示英语简介。
Investigate errors and unexpected behavior by finding related code, following function calls, and checking source files. GitNexus helps trace execution paths, while the diagnosis identifies the repository and reports how current its code index is.
中文简介正在准备中。当前显示英语简介。
Explore unfamiliar code with GitNexus to understand project structure and execution flows. Find related functions, inspect their callers and callees, and read implementation files to explain how a feature works, with repository and index freshness information.
中文简介正在准备中。当前显示英语简介。
Find the right GitNexus tools and workflows for exploring code relationships. This reference explains available commands, graph queries, and resources, including how to check which branch an answer describes and whether its index is current.
中文简介正在准备中。当前显示英语简介。
Assess the impact of code changes with GitNexus by tracing callers, dependencies, and affected execution flows. Check existing changes and report their scope, risk, and uncertainty before editing or committing.
中文简介正在准备中。当前显示英语简介。
Use GitNexus to inspect which conditions control a statement and how variable values flow within a function. Understand early exits, investigate empty query results, and guide changes to the tool’s control and data dependency queries.
中文简介正在准备中。当前显示英语简介。