1
Identify the incident session worth capturing
After resolving a production incident, you have a Devin session transcript that captured every diagnostic step, every command run, and every decision made under pressure. That transcript is the raw material for a skill your on-call team can reuse next time.Not every incident session is skill material. Look for sessions where Devin followed a clear, repeatable methodology — the kind of incident your team sees regularly:
- Memory leaks — identified the source, applied the fix, verified heap usage post-deploy
- Connection pool exhaustion — traced the root cause, tuned pool settings, added monitoring
- Cascading timeouts — isolated the failing upstream, added circuit breakers, validated recovery
2
Create the skill
Open the Devin home page and start a new session. Describe the session you want to turn into a skill. (From inside that session, the session menu’s Create skill entry starts this prompt for you.)Paste the incident session link and describe what the skill should capture. Be specific about the scope of generalization — the skill should work for the class of incident, not just the one service that broke.If you have multiple resolved incidents of the same type (e.g., two different memory-leak sessions), add them all. Devin identifies common patterns across sessions and produces a more robust skill.
3
Test it on the next incident
The real test is whether the skill works on a different instance of the same class of incident. When the next memory issue surfaces, start a new Devin session, mention the skill, and point it at the affected service.If the session resolves the incident cleanly, your skill generalizes well. If it struggles — maybe the leak pattern is different, or the service uses a different database driver — feed that session back into Devin and ask it to improve the skill. See Fix a Flaky DB Migration Skill for that workflow.