---
name: fde-engineering
description: End-to-end agentic engineering on client engagements. Small tasks, source-first context, build, cleanup, review-fix loop, verify. Use when shipping code solo on an FDE project.
---

# @fde-engineering

## Purpose

FDEOS is an operating system for one engineer running an engagement end to end. This skill is the **execution layer**: how you build, clean up, review, and verify on the client site without a team behind you.

Engagement judgment lives in land, discover, and rescue. **This skill is how you ship at staff-engineer rigor once scope is clear.**

Talk like a tech lead pair-programming — status in plain English ("here's what I changed, what I ran, what's still risky"), not a compliance checklist.

## Token efficiency

Load `context.md`, `decisions.md`, and `success.md`. Load `terrain.md` only when touching code. Load `trust-profile.md` when regulated data or AI policy applies.

## When to use

- You are implementing a feature, fix, or integration on a client codebase.
- You need a repeatable loop: small change → verify → cleanup → review → ship.
- You are solo and cannot afford thousand-line PRs or vibe-coded mess.

Do not use for a one-line typo in your own repo with no engagement context.

## The FDE agentic loop

Always in this order:

1. **Confirm scope in writing.** Read `success.md` and the relevant slice in `decisions.md`. If the task is not in the plan, run `@fde-plan` or name scope creep before coding.

2. **Keep the unit small.** One feature, one fix, one reviewable PR. If the plan item is bigger than ~90 minutes of focused work, split it in `decisions.md` before starting.

3. **Search before creating.** Read existing code in the area you will touch. Do not add parallel helpers when one service already exists.

4. **Source-first for external packages.** If integrating an SDK, framework, or vendor API, search local reference source or official repo before guessing names. Document paths used in `decisions.md`.

5. **Build the minimal working path.** Thin vertical slice the customer can see. No opportunistic refactors.

6. **Verify with evidence.** Run tests, typechecks, or the smallest script that proves the change. State what ran and what did not.

7. **Cleanup pass after it works.** Run the structure cleanup rules in `@fde-build` (dedupe mechanics into services, same behavior).

8. **Review-fix loop.** Run `@fde-review`. Fix only real findings. Re-run tests. Repeat until clean or blocked on a human decision.

9. **Log and deliver.** Update `decisions.md`, `delivery.md`, and `risks.md`. Stakeholder-visible progress beats invisible perfection.

## Source code as context (client integrations)

When the agent hallucinates APIs or docs are stale:

1. Add vendor/SDK source under a stable path, e.g. `reference/repos/github.com/org/project`.
2. In `CLAUDE.md` or project memory: *When using X, search `reference/repos/...` first. Do not guess API names.*
3. Before implementing, record in `decisions.md` which source files informed the design.

Never paste entire repos into chat. Search on disk.

## Craft rules (surgical, verifiable)

- State assumptions before coding. If uncertain, ask once, then proceed.
- Minimum code for the agreed scope. No speculative abstractions.
- Touch only what the task requires. Match existing style.
- Transform tasks into verifiable checks: *"Add validation"* → tests for invalid inputs, then implementation.
- Every changed line should trace to the agreed task in `decisions.md`.

## Security on client sites

- Do not install packages less than 14 days old without explicit customer approval.
- Never paste secrets, credentials, or PHI into prompts.
- When a supply-chain issue trends, grep the client repo for affected packages.
- Confirm `trust-profile.md` AI and data policy before sending customer data to external models.

## Engagement-specific guardrails

- **Stakeholder cadence:** After every 2–3 completed tasks, something visible exists or you send a one-paragraph update. Solo does not mean silent.
- **PR size:** If diff stat is hundreds of files or thousands of lines, stop and split before review.
- **Regulated work:** Human sign-off on AI-generated code where `trust-profile.md` requires it.

## Routes to other skills

| Situation | Skill |
|-----------|--------|
| No terrain map yet | `@fde-discover` |
| No plan in `decisions.md` | `@fde-plan` |
| Legacy / fragile code | `@fde-build` |
| Review feedback or pre-ship check | `@fde-review` |
| Production or trust crisis | `@fde-rescue` |
| Deploy | `@fde-ship` |

## Writes to `.fde/`

**`decisions.md`:** task split, reference sources used, verification commands run, review outcomes.

**`delivery.md`:** what shipped and business-visible value.

**`risks.md`:** new technical or delivery risks found during implementation.

## Principles

- The FDE owns the outcome; the agent does mechanical work under tight loops.
- Small diffs, objective verification, no thousand-line hope PRs.
- Working code still gets a cleanup pass before review.
- Launch visible slices early; perfect private branches do not earn trust on site.