Local-Cursor/internal/skills/builtin/fd-engineering/references/workflow.md

# Protocol stages and authorization

Use on entry, stage changes, approval changes, and resumption. FD stages are responsibilities managed by this skill; they do not request or activate a host application's modes.

## Select and advance

Use the explicit FD command or natural-language intent and the single clear current task. Otherwise infer the stage from the effective task state; use research when facts or goals are still unclear. Do not require every stage, exact switching phrases, or a fixed report. Use the exact marker below once as the first line of each substantive reply or question body, followed by one blank line before the body so Markdown renderers preserve the line break; do not repeat it in progress-only messages. It describes the FD protocol, never a host-mode transition.

| Command / stage | Required body-first marker | Work and boundary |
|---|---|---|
| /FD-research / RESEARCH | [FD:已进入研究模式] | Investigate evidence and reuse; clarify intent; no business or engineering edits |
| /FD-grill / GRILL | [FD:已进入质询模式] | Resolve consequential decisions one question per round; conclusions do not approve implementation |
| /FD-plan / PLAN | [FD:已进入计划模式] | Produce a reviewable protocol plan and hierarchical TODO; await implementation approval |
| /FD-uiux / UIUX | [FD:已进入界面设计模式] | Discover → confirm brief → generate prototypes → select → refine → hand off; confirmed brief/count authorize isolated artifacts only |
| /FD-execute / EXECUTE | [FD:已进入执行模式] | Reconcile an approved plan or eligible explicit quick-path request; implement, validate, and self-review continuously |
| /FD-review / REVIEW | [FD:已进入审查模式] | Review actual implementation; no automatic source fixes or Git actions |
| /FD-devops / DEVOPS | [FD:已进入工程交付模式] | Investigate and plan first; implement applicable capabilities when authorized |
| /FD-commit / COMMIT | [FD:已进入提交说明模式] | Inspect actual changes and draft a message; no automatic index or repository mutations |

Choose the marker for the work actually underway: an execute request lacking a usable approved plan uses PLAN first, unless it qualifies for the quick path. Merely loading an auxiliary reference does not change the marker; actually entering a separate Grill conversation uses GRILL, then returns to the calling stage when settled. Execution self-review remains EXECUTE. UIUX sub-stages can be stated briefly after its marker without inventing new marker formats. Never prefix raw deliverable contents with the marker.

A stage may load another reference for necessary investigation or Grill without expanding authorization. At handoff, name the relevant next FD command when useful. If the user agrees, continue by its reference; do not require typing a command or simulating a slash-menu invocation.

## Approval and revision

Record the effective plan version/content and the actual approval basis. An explicit request to implement a complete user-supplied plan, agreement to a clearly identified plan, or /FD-execute directed at the single clear unblocked current plan can approve that plan. Reuse valid approvals across turns and recovery; do not wait for an IDE button, card, or particular wording.

Accept approval conveyed by the host only when its context actually identifies the user's approval and the relevant plan. The skill does not require or inspect a particular host UI. Missing tools, a stage declaration, silence, a default selection, accepting an observation, or agreeing to one recommendation do not establish approval.

After approval, choose ordinary in-scope details and continue implementation, checks, and self-review without per-step permission questions. Substantive changes to requirements, public interfaces, selected dependencies, or scope need reasons, impact, a recorded revision, and confirmation of affected parts. Unaffected decisions and approval remain reusable. Self-review stays part of execution; a separate requested review uses REVIEW.

UI/UX brief approval covers only the confirmed prototype scope. Selection, design approval, and production implementation approval are separate. Actual commits, pushes, merges, publication, deployment, and other external mutations need explicit intent already present or newly given.

## Explicit small-change quick path

A direct implementation request can itself supply the short plan and authorization when its target, desired result, and verification are clear, the inspected change is small, local, and easily reversible, and no consequential choice remains. State the intended change/check briefly, enter EXECUTE, perform it, verify proportionately, and report. A separate task file or approval round is unnecessary. Examples include changing a specified button label or correcting a known local reference.

Do not use this path for persistent-data/schema/format changes, dependency changes, public-interface changes, security/permission changes, external mutations, broad refactors/redesigns, or unclear scope. Do not infer safety from a small line count. Research, Grill, planning, review, and commit-drafting requests alone do not authorize edits; the UIUX reference/brief/count gates remain intact. If inspection reveals excluded impact, preserve state and establish/confirm the affected plan instead of stretching the quick path.

## Real capabilities and evidence

Use actual available file, search, diff, execution, browser, and process capabilities. Do not discover or request host-specific mode, plan, task-board, or question-card tools as protocol prerequisites. Missing such conveniences is not a workflow blocker; plans, TODOs, and questions are valid protocol artifacts.

Respect the host's actual instructions, permissions, and available capabilities. A protocol transition cannot unlock writes or override read-only restrictions. Keep conclusions in Chinese conversation when persistence is unavailable, mark it pending, and sync when writes are permitted. Preserve approval when a real required capability is blocked; state the affected action rather than asking to approve the same plan again.

Never simulate tool results. Checks require actual results, rendering requires actual inspection, and preview cleanup requires verified closure/exit. If an essential capability is absent, report the real gap and a usable manual artifact or independent next step where possible.

For persistent state use [task-record.md](task-record.md); for steps, completion, failure, and recovery use [todo.md](todo.md).