Transfer an AI Service

SkillDev tools

Transfer an AI-enabled service from a delivery team to its accountable operating team. Use for adoption planning, customer enablement, production handoff, training, support readiness, ownership transfer, exit criteria, or proving that a team can operate, change, recover, and retire the service.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Transfer an AI Service skill

What this skill tells your AI

The instructions your AI receives, as published by davidahmann/applied-ai-field-guide in .agents/skills/transfer-ai-service/SKILL.md and read by ahel’s review.

Make handoff an exercised capability, not a document delivery event. Start adoption and operating ownership during the pilot.

Read first

  1. Read Solution Design and Delivery and Operate and Scale.
  2. Use the delivery and adoption plan and customer-enablement handoff.
  3. If the service uses a solution artifact, resolve it through the solution portfolio and read only the selected business-flow pattern and optional vertical profile. Use customer-specific decisions and operating contracts as checklist inputs, not exercised evidence or acceptance.
  4. Apply ADP-001, ADP-002, FDE-003, DEL-001, OPS-002, OPS-003, and OPS-007 from the control catalog.

Workflow

  1. Name the customer or internal service owner, technical owner, support owner, release authority, risk owner, business metric owner, sponsor or business owner, and an independent backup for material ownership or continuation decisions. Resolve approval-role separation required by the release gate.
  2. Map affected users, workflow changes, persistent review surfaces, access, training, communications, feedback, adoption measurements, and unresolved profile-specific operating decisions. Follow eligible work through exposure, completion, independent acceptance, business effect, and sustained net value; assign the first weak transition from representative cases rather than calling every break resistance.
  3. Transfer the exact release, architecture, data and context sources, tools and capabilities, evaluations, dashboards, runbooks, costs, known limitations, and retirement plan.
  4. Exercise routine operation, one representative user cohort, adoption calculation and diagnosis, permission changes, release and rollback, incident containment and recovery, evaluation refresh, vendor or model change, and verified shutdown. Exercise review, support, overflow, and escalation capacity for the proposed cohort.
  5. Record gaps, owner, due date, evidence, and whether each gap blocks delivery-team exit or autonomy expansion.
  6. Confirm the receiving team can perform the work without delivery-team heroics, and exercise the succession or escalation path for a sponsor or owner change. Keep a time-bounded support and escalation path after exit.

Output contract

Return the adoption status and first broken transition, named ownership, exercised-capability evidence, unresolved blockers, review and support capacity, support model, exit decision, post-exit review date, and field-learning entries.

Do not declare handoff complete because documents exist, training was delivered, or a named owner attended a meeting. Require demonstrated operation, change, recovery, and retirement capability.

Signals

GitHub stars
105
Forks
22
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
transfer-ai-service
Source
github.com/davidahmann/applied-ai-field-guide