What problem is worth solving?
Teaching scenario: replenishment analysis depends on one experienced operator whose method is spread across spreadsheets, scripts and tacit rules. Build a skill with inputs, tools, acceptance and maintenance.
Help teams reuse expert methods consistently and reduce opaque variation and handoff cost.
- WORKING ROLES
- Domain expert, operators, tool engineers and FDE
How does an FDE turn symptoms into a solvable problem?
The following discovery and implementation exercise uses a synthetic scenario.
Observe expert exceptions
Observe stockouts, stale data, minimum order quantities and budget limits; exceptions reveal hidden rules.
Work backward from acceptance
Compare accepted and rejected outputs to identify required quantities, units, dates, assumptions and evidence.
How does the solution enter the workflow?
- 01
Specify
Define triggers, input fields and scope; exclude unauthorized purchasing.
- 02
Encode
Use deterministic calculation and model-assisted explanation with explicit failure paths.
- 03
Test
Cover missing fields, unit conflicts, stale stock and unavailable tools.
- 04
Maintain
Track source, license, owner and update triggers; regress each version.
Which decisions make the solution reliable?
Not every step needs a model
Code makes inventory arithmetic and thresholds testable; models must not alter budgets or expand authority.
Reuse needs applicability conditions
Preserve third-party attribution and licenses; revalidate units, timezones, permissions and fixtures for each tenant.
Calculate a replenishment proposal before explaining it
Synthetic simplification: demand four units/day, five-day lead time, safety stock six, available stock ten, no inbound or reservations.
- Calculate
- Target 4×5+6=26; proposed gap 26−10=16 units.
- Check
- Check minimum orders, budget and variability; flag unresolved conditions.
- Authority
- Return a proposal and explanation, not a live purchase order.
What should you do and deliver?
Validate the input contract
- OUTPUT
- Skill spec + validators
- PASS CONDITION
- Units and nulls have explicit handling
Define tool failure and recovery
- OUTPUT
- Negative tests + runbook
- PASS CONDITION
- Failures cannot silently report success
Publish a portable method package
- OUTPUT
- Version, attribution and transfer checklist
- PASS CONDITION
- A second operator can run it independently
How do you prove completion and reuse the work?
Acceptance checks
Assess inputs, reproducible calculation, negative coverage, recovery and portability; a long prompt is insufficient.
Reusable assets
Modularize specifications, tools, tests and maintenance for procurement reconciliation, content reuse and business analysis.
Further reading and original sources
- Building effective agents ↗Anthropic · 2024-12-19
- Demystifying evals for AI agents ↗Anthropic · 2026-01-09