القائمة
Deploy to production safely. Pre-flight checklist, canary deploy, verified rollback. No surprises.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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-ship |
| description | Deploy to production safely. Pre-flight checklist, canary deploy, verified rollback. No surprises. |
Load context.md and delivery.md only. Load trust-profile.md if the deployment touches regulated data or requires approval chain confirmation.
Shipping is the moment everything either lands or blows up. This skill makes sure every deployment has a tested rollback, goes out in stages, and gets verified before it touches 100% of traffic.
Talk like a calm tech lead before prod: has anyone actually run the rollback, or is it still a slide? If it's only planned, that's today's work — say so plainly.
Work through this before any deployment:
Don't proceed until every item is confirmed. Not assumed, confirmed.
Canary first. 1 to 5% of traffic for at least 10 minutes. Watch error rates, latency, and the business metric this change affects.
If anything looks wrong, roll back immediately. Don't investigate during the canary. Roll back, investigate safely, redeploy when confident.
Expand in stages. 5% confirmed stable, go to 25%. 25% stable, go to 100%.
A canary deploy covers one service going to one environment. A transformation rollout covers an AI programme going to an enterprise. These are different problems.
For programme-scale deployments, the sequence is not canary → 25% → 100%. It is:
Pilot -- one team, one use case, controlled conditions. The goal is not to prove it works technically. It is to prove it works with real users in a real environment. Define success metrics before the pilot starts. If you define them after, you will fit the metrics to the result.
Limited release -- three to five teams, real production load, monitored closely. The goal is to find the failure modes that the pilot did not surface. There will always be failure modes the pilot did not surface. The limited release is where you find them before they affect everyone.
Broad release -- available to all qualifying teams with self-serve onboarding. The goal is adoption without your involvement. If teams need you to get started, the onboarding is not finished. Fix that before broad release.
Enterprise standard -- part of how the organisation works, not a special programme. The goal is that the FDE is no longer needed for this use case. This is the end state.
The FDE who goes straight from pilot to enterprise standard will have a high-profile failure at scale. The FDE who sequences deliberately will have a programme that builds confidence at each step and survives the inevitable political scrutiny that comes when something goes wrong.
Run smoke tests against production. Verify the business metric moved in the right direction.
Define the pulse before you close the deploy:
A deployment without a defined pulse check is a deployment you will only hear about again when something breaks. Before you close the laptop, write three things into delivery.md:
The metric: what number tells you this is working? Not "error rate is low" -- "p99 latency on the payment endpoint is below 800ms" or "document processing success rate is above 94%."
The frequency: how often do you check it? Daily for the first week. Weekly after that. Monthly once stable.
The threshold: what number triggers an incident response? Write the exact value. If it drops below this number, someone acts. If nobody knows the threshold, nobody acts until it is too late.
For AI components specifically: define what "normal" output looks like before you leave. If the model starts drifting -- producing outputs that are technically valid but subtly wrong -- nobody will notice until a human complains. The pulse check for an AI component is not just latency and error rate. It is output quality on a sample of real production inputs, checked weekly.
Write the pulse definition in delivery.md alongside the deployment record. The person who inherits this system needs to know what to watch, not just what was built.
.fde/delivery.md: deployment record updated -- what shipped, when, what it delivers in business terms, and how to roll back.