Unlike the diagramming-code skill (which visualizes code structure), this skill
extracts protocol semantics: who sends what to whom, what cryptographic
transformations occur at each step, and what protocol phases exist.
For call graphs, class hierarchies, or module dependency maps, use the
diagramming-code skill instead.
When to Use
User asks to diagram, visualize, or extract a cryptographic protocol
Input is source code implementing a handshake, key exchange, or multi-party protocol
Input is an RFC, academic paper, pseudocode, or formal model (ProVerif/Tamarin)
User names a specific protocol (TLS, Noise, Signal, X3DH, FROST)
When NOT to Use
User wants a call graph, class hierarchy, or module dependency map — use diagramming-code
User wants to formally verify a protocol — use mermaid-to-proverif (after generating the diagram)
Input has no cryptographic protocol semantics (no parties, no message exchange)
Rationalizations to Reject
Rationalization
Why It's Wrong
Required Action
"The protocol is simple, I can diagram from memory"
Memory-based diagrams miss steps and invert arrows
Read the source or spec systematically
"I'll skip the spec path since code exists"
Code may diverge from the spec — both paths catch different bugs
When both exist, run spec workflow first, then annotate code divergences
"Crypto annotations are optional decoration"
Without crypto annotations, the diagram is just a message flow — useless for security review
Annotate every cryptographic operation
"The abort path is obvious, no need for alt blocks"