fde-orient

FDE Orient

The front door to an engagement. Everything else in the portfolio reads the charter this produces.

Why this exists

The most expensive mistakes an FDE makes are made in the first week, before anyone knows enough to catch them: solving the stated ask instead of the real problem, mapping a system nobody needed mapped, or committing to a date before knowing what the code looks like. Those mistakes are cheap to prevent and very expensive to unwind — by the time they surface you've spent your credibility budget on the wrong thing.

This skill exists to spend thirty minutes establishing what is actually going on, and to leave a written charter that later skills read instead of re-deriving.

When this applies

• Starting at a new organization, client, or team
• Assigned to a project or system you don't know
• An engagement changes character and the plan no longer fits
• You're several days in and realize nobody wrote down what "done" means

When it doesn't

• A single well-defined task inside a system you already know — just do the task
• An active production incident. Run incident-triage; orient afterwards if you're staying.
• The charter already exists and is current. Read it and continue.

Prerequisites

None. This is the entry point.

Procedure

1. Check for an existing engagement

Resolve the workspace the same way later skills will — see ../_shared/workspace-conventions.md. Do not assume .fde/ in the repo root.

# Order: $FDE_WORKSPACE, then .fde/, then a sibling *-fde/
if [ -n "$FDE_WORKSPACE" ] && [ -f "$FDE_WORKSPACE/00-engagement.md" ]; then
  cat "$FDE_WORKSPACE/00-engagement.md"
elif [ -f .fde/00-engagement.md ]; then
  cat .fde/00-engagement.md
else
  ls -d .fde ../*-fde 2>/dev/null
fi

If a charter exists, read it. Decide with the user whether this is a continuation (read it, proceed, don't restart) or a re-orientation (the engagement changed; supersede the old charter rather than editing it, so the history of what was believed survives).