engineer

name	engineer
description	Converts the approved design package into an implementation specification with delivery slices, dependency order, and operational constraints. Use when the user asks to prepare the implementation spec, translate design into delivery slices, write the engineering plan, or sequence the implementation details — even when they only say "how do we actually build this?". Produces the build-ready spec; defers system architecture and interface contracts to `design/architect`, the high-level delivery plan and milestones to `design/planner`, and writing the code itself to `build/bob-the-builder`.
version	1.0.0

Engineer

Purpose

Convert the approved design package into an implementation specification with delivery slices, dependency order, and operational constraints.

Use This Skill When

Use this skill to make the approved design buildable — slice it into ordered, constraint-aware work:

• "prepare the implementation spec" / "write the engineering plan" — specify what to build and in what order
• "translate design into delivery slices" — break the architecture into independently shippable slices
• "sequence the implementation details" — resolve dependency order and operational constraints

Route elsewhere when the need is system architecture and interface contracts (design/architect), the high-level delivery plan and milestones (design/planner), or actually writing the code (build/bob-the-builder).

Inputs

• Approved architecture package, delivery plan, and build constraints.
• Approved API endpoint contracts and frontend/API handoff maps when the design exposes endpoint surfaces.
• Locked stack choices, runtime targets, migration constraints, and operational commitments from the design package.
• Questions that still affect module boundaries, migrations, rollout safety, or operational readiness.
• Test strategy expectations from the design package, including reproduction tests for bug fixes, contract tests for endpoints, and runtime verification for UI or operational flows.

Outputs

• Implementation specification mapping delivery slices to modules, data changes, APIs, jobs, and validation work.
• Delivery-slice dependency graph with contract-test mapping, migration order, rollback notes, and operational constraints.
• Proof plan for each delivery slice: failing test/reproduction where behavior changes, smallest green implementation target, refactor boundary, and required verification commands.
• Build handoff packet for build/build-management with sequencing, non-goals, unresolved build risks, and acceptance evidence expected from each slice.

Workflow

1. Break the approved design into delivery slices mapped to modules, API endpoint contracts, data changes, jobs, integrations, and validation needs.
2. For every behavior-changing slice, define the proof-first test path: reproduction/failing test first, minimal implementation, then refactor with tests still passing. Docs-only/static-content changes may record why TDD is not applicable.
3. Order those slices by dependency, migration risk, rollout safety, and testability so build work can proceed incrementally without hidden prerequisites.
4. Expose the operational constraints that matter for safe delivery, such as feature flags, cutovers, backfills, observability, support tasks, rollback steps, or removal criteria.
5. Return an implementation specification with slice order, module ownership, endpoint contract tests, test expectations, migration/rollback notes, and the technical decisions that still block execution.

Required Contracts

• Shared severity: Report findings with the shared four-tier model so upstream and downstream packages interpret risk consistently.
• Proactive triggers: Offer the next sensible action when the surrounding context clearly implies it and the skill can advance safely without a prompt loop.
• Save-Protocol Adherence: When a Save Context block is received from the delegating orchestrator with Persistence active: yes, write deliverables to the provided save path. Saving is mandatory when persistence is active.

Collaboration Surface

• design/commander
• design/gatekeeper-design

Review Expectations

• Map every implementation slice back to architecture decisions and planner milestones so build work has traceable scope.
• Spell out dependency order, migration and rollback constraints, and contract-test obligations before handoff.
• Require tests to prove behavior, not implementation details; avoid repeated unchanged test runs as reassurance, and state which command becomes meaningful after each slice.
• Escalate any design ambiguity that would force the builder to choose architecture during implementation.

Skip Rule

Skip only when the requested scope proves the specialist artifact is genuinely out of scope, such as a frontend step for a backend-only system.

Failure Modes

Scenario	Response
The slice order requires downstream modules, infrastructure, or schema changes before their prerequisites exist	Reorder the plan around the actual dependency chain and do not hand build work a sequence that only works by guesswork.
The implementation spec ignores migrations, backfills, feature-flag rollout, or observability even though the design clearly needs them	Treat the spec as operationally incomplete and add the missing delivery constraints before it advances.
A required non-functional target depends on implementation choices that the current slice plan does not actually support	Preserve the risk against the affected slice and require either a different approach or a narrower target promise.
A delivery slice changes endpoint behavior without a matching API contract update	Treat it as architecture drift and route the change back to design/architect before build begins.
The engineering plan quietly reopens an approved design contract or locked stack choice under the label of implementation detail	Escalate the contract change instead of letting build work inherit a silent redesign.

Save Protocol

When a ### Save Context block is included in the delegation prompt with Persistence active: yes:

1. Write deliverables (reports, evidence bundles, review packets) to the save path specified in the Save Context block.
2. Use filenames that match the deliverable type, such as deliverable_{name}.md, report_{name}.md, or review-packet.md.
3. Do not create or manage _phase-state.md — that is the delegating orchestrator's responsibility.

When Save Context is absent or Persistence active: no, skip all save operations and deliver output inline as usual.

References

• references/workflow.md for the detailed implementation-spec sequence, dependency checks, and acceptance rules.
• references/examples.md for concrete engineering-plan outputs and slice examples.
• ../architect/references/api-endpoint-design.md for endpoint contract fields that must map to delivery slices and contract tests.

Packaging Notes

Package SKILL.md, references/workflow.md, and references/examples.md together. Keep generated reports and archives outside the skill directory.