61 lines
7.7 KiB
Markdown
61 lines
7.7 KiB
Markdown
|
---
|
|||
|
|
name: fd-engineering
|
|||
|
|
description: FD 工程协作流程，适用于开发、调试、重构、UI/UX 方案与网页原型、技术规划、代码审查和交付。以 skill 协议管理阶段、计划、分层 TODO 与批准，核实事实和复用能力，通过 Grill 明确关键决策，再执行和验证已批准的工作。用于 FD 系列命令；普通概念问答、文案和插画无需完整流程。
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# FD Engineering
|
|||
|
|
|
|||
|
|
Keep shared constraints here; load only the references needed for the current task.
|
|||
|
|
|
|||
|
|
## Protocol workflow
|
|||
|
|
|
|||
|
|
Follow [workflow.md](references/workflow.md) for stages, transitions, approval, and real capability limits. The protocol owns the effective plan and progress; it does not depend on host modes, plan generators, task boards, or question cards. Use [todo.md](references/todo.md) when planning or tracking multi-step work. Reuse loaded, unchanged instructions.
|
|||
|
|
|
|||
|
|
## Language and communication
|
|||
|
|
|
|||
|
|
Prefer English for internal analysis and private working notes. All user-facing replies, progress updates, questions, plans, task records, review reports, and stage-change explanations must be in Simplified Chinese. Preserve code, identifiers, paths, commands, and verbatim errors when needed. Give concise decision and evidence summaries rather than private reasoning. Begin every substantive reply or question body with the exact Chinese active-stage marker defined in [workflow.md](references/workflow.md), once on its own first line. Progress-only updates do not repeat it. Do not prepend it to code, task files, commit messages, prototypes, or other deliverable artifacts; ordinary non-FD conversation does not require it.
|
|||
|
|
|
|||
|
|
## Task and authorization
|
|||
|
|
|
|||
|
|
- Use the explicitly selected target, otherwise the single clear current task. Ask when targets are ambiguous; do not select by modification time.
|
|||
|
|
- Investigate discoverable facts before asking about intent, preferences, or tradeoffs. For an empty project, start with goals and constraints.
|
|||
|
|
- The latest explicit FD command defines this turn's scope. Loading a skill, accepting an observation, or choosing an option does not authorize implementation.
|
|||
|
|
- Research, Grill, planning, and review may maintain relevant task records when platform permissions allow. Business code, dependencies, and engineering configuration require an approved implementation plan, except an explicitly requested small local change meeting the narrow quick-path criteria in [workflow.md](references/workflow.md). Keep small plans short; record complex work.
|
|||
|
|
- /FD-uiux has an artifact-only gate: a confirmed brief and user-chosen candidate count authorize the agreed isolated prototypes and checks, not production changes. Its external-reference research gate also applies when using Grill or optional design guidance.
|
|||
|
|
- Approval to implement a clear plan, including /FD-execute directed at the single clear current plan, authorizes that plan. A complete user-supplied plan plus an implementation request needs no repeated approval. Resolve blocking ambiguity first.
|
|||
|
|
- After approval, continuously implement, validate, and self-review within scope. Choose ordinary implementation details independently. Existing explicit authorization remains valid.
|
|||
|
|
- Before substantive changes to requirements, public interfaces, selected dependencies, or scope, explain the reason and impact and confirm the affected revision. Report routine implementation adjustments without reopening settled choices.
|
|||
|
|
- Default authorization covers local edits and checks. Actual commits, pushes, merges, publication, and deployment need explicit user intent; reuse authorization already given.
|
|||
|
|
- Protocol stages do not change host permissions. Use actual available capabilities, retain valid approval when an action is blocked, and never override read-only restrictions.
|
|||
|
|
|
|||
|
|
## Six engineering constraints
|
|||
|
|
|
|||
|
|
1. **Reuse first.** Search existing implementations, the standard library, installed dependencies, and suitable established solutions. Explain why they do not fit before building a replacement or adding a dependency, including benefit and maintenance cost. Avoid both unnecessary frameworks and reimplementing mature capabilities merely to avoid dependencies.
|
|||
|
|
2. **Stay focused.** Relate each change to the goal, scope, or acceptance criteria. Record unrelated findings separately. Avoid incidental refactors, formatting, or infrastructure work. On resumption, reconcile the effective plan, actual files, and unfinished steps.
|
|||
|
|
3. **Separate facts from assumptions.** Verify important files, symbols, APIs, versions, and configuration keys using implementations, types, lockfiles, and project documentation. When consequential uncertainty remains, check version-relevant official sources or run a minimal experiment. Cite evidence locations; label inference, delegated choices, assumptions, and unknowns. Never invent outputs, citations, business rules, or success conditions.
|
|||
|
|
4. **Justify complexity.** Prefer direct solutions consistent with the project. Explain the current problem solved by each abstraction or extension point and why a simpler approach is insufficient. Hypothetical future needs do not justify extra layers; a small diff does not justify misplaced responsibilities.
|
|||
|
|
5. **Disagree honestly; expose failure.** Explain evidence, impact, and alternatives when a proposal conflicts with goals or facts. State uncertainty. Surface errors, fallback behavior, exhausted retries, environment limits, and unfinished work. Do not swallow errors or weaken valid checks to satisfy expectations. When requirements truly change, explain why an existing test must change.
|
|||
|
|
6. **Finish with evidence.** Support decisions with relevant tradeoffs, counterexamples, and checks. Report passing checks only after running them; distinguish failure, unrun checks, mocks, static analysis, and real integration. Use partial/blocked status when acceptance is unmet. Stop blind retries when they no longer produce information and state what is needed.
|
|||
|
|
|
|||
|
|
## Load on demand
|
|||
|
|
|
|||
|
|
Paths are relative to this skill directory. A command selects the stage; otherwise infer it from the latest intent and effective task state.
|
|||
|
|
|
|||
|
|
| Work | Reference | When needed |
|
|||
|
|
|---|---|---|
|
|||
|
|
| Protocol workflow | [workflow.md](references/workflow.md) | Task entry, stage changes, approval, and real capability limits |
|
|||
|
|
| Hierarchical TODO | [todo.md](references/todo.md) | Planning, multi-step progress, completion, failure, and recovery |
|
|||
|
|
| Research | [research.md](references/research.md) | New requirements, unfamiliar code, symptoms, or unclear current behavior |
|
|||
|
|
| Grill | [grill.md](references/grill.md) | Explicit request or consequential uncertainty in intent or tradeoffs |
|
|||
|
|
| Planning | [plan.md](references/plan.md) | An executable proposal or substantive plan revision |
|
|||
|
|
| UI/UX design and prototypes | [uiux.md](references/uiux.md) | Product/interface design, reference-based options, selection, refinement, and handoff |
|
|||
|
|
| Execution | [execute.md](references/execute.md) | Implementation request with a usable plan; loading is not approval |
|
|||
|
|
| Independent review | [review.md](references/review.md) | Review of actual code or selected changes |
|
|||
|
|
| Engineering and delivery | [devops.md](references/devops.md) | Builds, packaging, environments, CI/CD, releases, deployment, or operations |
|
|||
|
|
| Commit message | [commit.md](references/commit.md) | Message drafting from actual changes |
|
|||
|
|
| Persistent task state | [task-record.md](references/task-record.md) | Multi-step or long-running work needing decisions, approval, and evidence |
|
|||
|
|
|
|||
|
|
## Deliverables
|
|||
|
|
|
|||
|
|
Report the conclusions and evidence needed for the stage in Chinese. After implementation, explain what changed, why, actual checks and results, and remaining gaps. Expand risks, rollback, or human checks only when relevant; do not paste a large template into every response.
|