Menü
Break work into atomic tasks. Sequence by risk. Add stakeholder touchpoints every 2-3 tasks.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
The operating system for Forward Deployed Engineers. 34 skills across 6 domains — from first meeting to final handoff. Tell it your situation, it routes to the right skill, does the work, and the engagement memory writes itself.
Taking over mid-engagement. Reads what exists, separates what works from what was assumed.
Safe implementation in any codebase. Characterisation tests first, Strangler Fig for fragile code.
End of engagement. Retrospective, pattern extraction, clean handoff so the team can sustain it.
Generate a status dashboard across all active engagements from .fde/ data.
Systematic debugging. Reproduce first, isolate second, fix third. Never guess.
| name | fde-plan |
| description | Break work into atomic tasks. Sequence by risk. Add stakeholder touchpoints every 2-3 tasks. |
An FDE plan is not a sprint backlog. The technical sequence is the easy part. The hard part is knowing when to stop and show someone progress, who needs to see what before they will approve the next phase, and where the trust is thin enough that silence for two weeks will be read as failure.
A technically correct plan that ignores engagement politics will fail on schedule.
Load reality.md, success.md, terrain.md, stakeholders.md only. Load business-case.md if it exists -- it contains the scored use case from @fde-sketch that this plan should be built around. Load decisions.md only if re-planning an existing phase. Not the full .fde/ directory.
Clarify scope in conversation — feature vs phase vs whole delivery. One natural question, e.g. "Are we planning this slice or the whole engagement?" — then listen before structuring anything.
Before planning begins, confirm scope is locked. Read success.md. If out-of-scope is not defined, define it now. A plan built on undefined scope will accumulate scope creep silently. Every task added later without a scope conversation is a commitment made without the customer's awareness.
Step 1: Start from success, work backwards
Read success.md. What's the final state? Now walk backwards, what's the last thing that has to be true before that? And before that? This gives you the dependency chain, not a wish list.
Step 2: Identify the fragile zones
Check terrain.md. Which parts of the codebase are high-risk? Those tasks go earlier, fail fast, not at the end. Never leave the riskiest work for last.
Step 3: Slice vertically, not horizontally Each task delivers something visible and testable, not "build the database layer" but "user can submit a form and see it saved." A working thin slice is always better than a complete horizontal layer that can't be demonstrated.
Step 4: Size tasks to 30-90 minutes Anything longer is two tasks. Anything shorter is probably setup, not a task. This keeps each task small enough for a fresh context window and verifiable in one sitting.
Each task should be PR-sized: one reviewable unit an agent can implement, test, and pass @fde-review without a thousand-line diff. Name the verification step per task (test command, demo script, or stakeholder check).
For solo FDE delivery, sequence so every 2–3 tasks produces something visible to the customer — not a month of invisible backend work.
For AI components, name the evaluation tasks explicitly: "Model output validated on 50 real examples from production data" is a task. "Fallback path tested under model unavailability" is a task. "Observability confirmed: inputs and outputs logging to [destination]" is a task. These are not afterthoughts. They are pre-conditions for shipping and must appear in the plan before building starts.
Step 5: Add the human touchpoints After every 2-3 technical tasks, add: "Show progress to [stakeholder from stakeholders.md]." These are not optional. They are not ceremony. An FDE who goes quiet for two weeks while building is not being efficient -- they are letting the customer fill that silence with doubt. A stakeholder who sees consistent small wins stays bought in. A stakeholder who goes three weeks without visible progress starts asking questions that derail the build.
No task moves to implementation without written acceptance criteria. Not "build the auth module" -- "a user can log in with valid credentials and receives a session token; a user with invalid credentials receives a 401 and no token is issued; a user with an expired token is redirected to login."
If you cannot write the acceptance criteria, the task is not ready. This is not a process requirement. It is a signal about your own understanding. Vague acceptance criteria means you do not know what done looks like. That ambiguity will surface during build as scope creep, as disagreements about whether something is finished, as rework.
The discipline: write the acceptance criteria before writing any code. If writing them reveals you do not know the answer to a question, that question goes to the customer before the task starts -- not during.
Happy path and unhappy path -- both required: Every task needs both. Happy path: what happens when everything works. Unhappy path: what happens when it does not. An acceptance criterion that only covers the happy path is half a criterion. The failure modes are what you are actually shipping.
Each task:
Task [N]: [One-line description of the outcome, not the activity]
Delivers: [What someone can see or test when this is done]
Accepts: [Happy path criteria] / [Unhappy path criteria]
Touches: [Files or systems affected, blast radius declared upfront]
Risk: [What could go wrong, and the fallback]
Verify: [Specific check that confirms it's done]
A sequenced task list written to decisions.md. Always decisions.md. fde-build reads from decisions.md to find the plan. If the plan is anywhere else, the build starts without one and will not warn about it.
Not a project management document. A clear sequence any FDE could pick up, execute, and verify, even if they have never seen the engagement before.
Scope resets happen. The brief was wrong. Discovery revealed something larger. A stakeholder has changed what done means.
When this happens: do not quietly update the tasks. Name the reset explicitly. Update reality.md and success.md to reflect the new shared understanding. Write a single paragraph in decisions.md explaining what changed, why, and what the new sequence is. Then continue.
An undocumented scope reset looks like the FDE drifted. A documented one looks like the FDE caught something important and adapted. The distinction matters when the project is reviewed by someone who was not in the room.
decisions.md: the plan itself, all subsequent updates, and the rationale for every sequence change.
reality.md, success.md, terrain.md, stakeholders.md. Not the full .fde/ directory.