Atlassian

    Facilitator notes

    This session explores the moments where work moves between crafts: product management, design, engineering, research, and others.

    When we run this training at Atlassian, product managers and designers invite the teammates they work with most often. Although AI Builders Week is designed for those two crafts, this session often works well for the whole team. Consider whether that approach fits your environment too.

    Use this session to talk about craft evolution. Help people understand changing expectations as role boundaries get less rigid and the industry keeps learning what that means. The goal is to help teams feel empowered and excited, not fearful.

    The cross-craft handshake

    Atlassian AI Builders Week curriculum

    Take what's relevant and make it your own.

    When every craft gets faster on its own, the gaps between crafts become where time is lost. The cross-craft handshake is the practice of making the moment work passes from one discipline to another explicit, shared, and agent-ready.

    What a good handshake looks like

    A clean handshake carries everything the next craft needs — and nothing they have to chase down:

    The outcome

    What success looks like, stated as an outcome — not a list of instructions to follow blindly.

    The context

    The decisions already made, the constraints in play, and the reasoning behind them.

    The artifacts

    Specs, designs, research, or tickets — linked and structured so humans and agents can both act on them.

    The open questions

    What's still ambiguous, flagged up front instead of discovered halfway through.

    Phase 1 — Making the handshake (design/PM side)

    1

    Generate the Spec Hub

    Not a handoff. A handshake. You're transferring context, not translating it. For complex projects, generate a full specification from the Prototyping Sandbox — this is where the outcome, context, and artifacts from the checklist above actually get produced:

    • A full-screen, clickable prototype accessible via a public internal link (no Sandbox access required).
    • A component breakdown — every component shown in isolation, with the code and a copy-paste prompt an engineer can use to extract it into production.
    • Auto-generated Storybook stories for every component you've created — configurable panel, ready to use.
    • Only surfaces the new UI you created — not existing components — so it's immediately obvious what's net new.

    Skip this for a copy tweak or token change — go straight to Phase 2.

    2

    Run the Pre-flight Check Skill

    Before handing over:

    • Assesses your code against engineering standards.
    • Refactors where possible.
    • Returns a score (e.g. 91/100) and an issues.md file listing anything to address.
    • Gives you and the engineer confidence the code is a usable first draft, not a rejection waiting to happen.

    Phase 2 — Picking it up (engineering side)

    Review the specification

    When you receive a handshake artifact:

    • Open the Spec Hub — all the context you and your agent need is there.
    • Review the prototype against the original requirements — do the interactions match the decisions made a month ago? Is the UX static when it was supposed to be dynamic?
    • Ask your AI agent to do the same review in parallel — Codex or Rovo can read the prototype, the Loom, and the Confluence page simultaneously while you do your manual review.

    Use the prompt from the spec. Each component in the Spec Hub includes a generated prompt. Copy it, add your own requirements (data layer, performance, accessibility, i18n), and hand it to your agent with the relevant context from Teamwork Graph.

    Generate code

    • Switch to plan mode first — review the plan before execution begins. Comment on anything you'd change.
    • Most of the code in a prototype is already written against the design system and frontend standards. Generating code here is largely polish and review, not a full rewrite.
    • Use Opus 4.7 or GPT 5.5 for the initial generation; switch to Sonnet for iterative UI changes.

    Review your PR — before anyone else sees it

    Always review your own PR before sending it to others — and in the pull request view, not locally, so you see exactly what reviewers will see.

    The technique: add comments in the PR as if you're talking to your agent. Agents read PR comments as prompts and will address them when you ask. Once you've flagged everything:

    "Review this PR and fix all comments, resolving them as you go."

    It won't fix everything, but it gets further than you'd expect. What's left requires your judgment.

    Things to check:

    • i18n — are all content values using internationalization properly?
    • Token values — are they correctly mapped to the design system?
    • Interactions — do they match what was specified?
    • Blocking bugs — hover states, context menus, dynamic behavior.