More Superpowers Coming Your Way
Presented by Cameron Burrows, Blaise Moses & Jeremy Proffitt
You've already got the foundation — now we go deeper. This session is about the mindset shifts that separate casual Claude Code users from engineers who multiply their output. Async workflows, context mastery, planning with Claude, and the habits that make you feel like you have a whole team working for you. You're not starting from zero. You're leveling up.
"People rarely succeed unless they have fun in what they are doing." — Dale Carnegie
What we'll walk through together today
Async Workloads & The New Normal
Ping-pong prompts waste ACUs and time. Batch the whole mission into one ask and walk away.
You're the bottleneck. You sit and wait between each turn, context repeats, ACUs multiply, and you ended up sitting there for 40 minutes.
Fire. Walk away. Claude owns the whole arc — you come back to a reviewable MR.
Which file, repo, or system. What the bug/feature/goal is. What “done” looks like for a reviewer.
Numbered steps: write, test, run, commit, push, MR. Give Claude the whole route so it doesn't stop at the first gas station.
“Ping me when the MR is open,” “tell me if the pipeline goes red,” “stop and ask before deleting anything.” Let Claude know where to hand back.
“Find the NPE reported in OC-842, add a failing test that reproduces it, fix it in the smallest possible diff, re-run the full suite, then open an MR against develop.”
“Check Dynatrace for the last hour of c3_logs 5xx errors on payments-api, group by endpoint, write up the top 3 offenders with root-cause guesses, and drop it in the OC-842 ticket.”
Rule of thumb: if your next three messages to Claude are all predictable, roll them into the first one. You'll finish faster, burn fewer ACUs, and unlock the 10x mindset coming up next.
Fire and move on — don't wait for a response, that's the whole mindset
The 10x engineer doesn't wait for a response. They fire a session, move on immediately, and come back to results — like a chef with four burners going at once. Staring at the terminal is wasted time. While Claude works, you work too.
The World Around Us
Model Context Protocol — Claude's universal adapter to the rest of your world
An open standard from Anthropic that lets Claude securely reach outside the terminal — into Jira, GitLab, Dynatrace, Confluence, anywhere an MCP server exists.
Mental model: MCP servers are apps that give Claude a new set of buttons. Install once, Claude uses them forever.
Every enabled MCP ships its tool catalog into Claude's context every turn. Six idle servers can add 20–30k tokens per prompt — slower replies, higher ACU cost. Use /mcp to toggle servers off when not in use.
Hosted and wired up — already installed, updates automatic
Jira, Confluence, ProForma, comments
MRs, pipelines, issues, reviews
DQL, problems, SLOs, traces, CVEs
SQL over AWS & Ally Cloud inventory
Ally module registry, versions
Browser automation, screenshots, UI
Build one. Publish. One-line install.
confluence.int.ally.com — search "Hosted MCP Servers". One-line install, shared config, zero maintenance on your side.
> show me my assigned Jira tickets — Claude queries Atlassian MCP, returns the list. No browser tabs opened.
Both give Claude superpowers — but one is cheaper to keep loaded
Structured tool definitions baked into Claude's context at every turn. Discoverable, typed, auto-completing.
Claude shells out to glab, dyna, aws, gh, acli, etc. — zero tool definitions in context.
kubectl, terraform, jq, git--help)-o jsonLoading 6 MCP servers with 30 tools each ≈ 30,000+ input tokens every turn just for the menu. A CLI like glab or dyna adds zero. Pick MCP when you need rich structured output — reach for CLI when you just need to run a command.
…you need typed fields (Jira custom fields, Dynatrace DQL verify), interactive browsing (Playwright), or you're asking Claude to reason about rich structured data.
…you know the command, the output is small, and you care about speed or token cost. glab ci view, dyna dql run, aws s3 ls — all faster than their MCP equivalents.
Making Dynatrace MCP Work for You
Stop hunting through dashboards — ask Claude in plain English
list_problemsinvestigate_problemget_incident_briefexecute_dqlquery_metricsquery_spans / logsfind_entityfind_by_taglist_bucketslist_vulnerabilitiesget_vulnerability_detailsget_security_overviewlist_slosget_slo_statusget_service_healthlist_documentscreate_documentadd_dql_to_notebookPrompt it, don't click it: "what problems hit payments-api in the last hour, and what does the log pattern look like?" — Claude picks the right tools in the right order.
Claude learned the rules so you don't have to
1. Bucket-first. Every fetch logs filters dt.system.bucket first — drops query cost from 186 GB to 3 GB.
2. Verify before execute. verify_dql is free — catches syntax errors without burning budget.
3. Probe with maxResults: 5 before running the full query — confirms the data shape is what you expect.
4. Filter before summarize. Cut the data down first, then aggregate — faster and cheaper.
Takeaway: one sentence in — a root cause out. Claude orchestrates the tools.
Write logs AI can read — and shrink the minutes between bug report and fix
The magic prompt: “Fix error 404-RT-9f3a in @api/users.py.” — Claude opens the file, reads the function named in the log, sees the state, and ships the patch. No back-and-forth, no hunting.
Boutique to World Renowned
A markdown file that becomes a slash command — reusable, shareable, unstoppable
A skill is just a markdown file with a YAML frontmatter description. Drop it in ~/.claude/skills/ and Claude auto-loads it. Type /skill-name to invoke.
Some skills installed on your machine today:
/review-mr
/pushit
/investigate
/build-it
/audit
/send-outlook-email
/whats-next
/security-review
Ask Claude: "make this a skill" after a good workflow. It writes the file, places it correctly, and it's live on the next session.
Four stages of skill maturity — your personal hack becomes everyone's superpower
~/.claude/skills/ — just you
.claude/skills/ in repo
Everyone on the project gets it.
Ally plugin marketplace
Any engineer at Ally installs it.
Anthropic public marketplace
The whole industry uses it.
The secret: most world-renowned skills started as boutique scripts someone wrote for themselves. Build it for YOU first — polish and ship later. Every stage just promotes the same markdown file.
Building a custom agent that uses CLI tools, then invoking a real-world release workflow
confluence-agent.md in ~/.claude/agents/Bash, Read, Write, Editcurl/release-candidate on the gen-ai repoglab, jira-cli) used as the integration layerKey insight: The agent file is just markdown instructions. The skill file is just markdown steps. No SDK, no framework — just clear instructions + tool access.
Demo: Building the Confluence agent & running /release-candidate
Think npm for Claude Code skills — an internal registry of vetted, installable plugins backed by a GitLab repo
Add the marketplace config to your settings
Type /install to see available plugins
Select a plugin — skills, agents, config all install
Invoke with /plugin:skill immediately
/allyai:scaffold to generate a new agentStage 3 in action: This is the maturity model happening in real time. One engineer builds it, publishes to the marketplace, and now every Claude Code user at Ally has it.
Demo: Registering the Ally marketplace, browsing plugins, and installing the AllyAI toolkit
To Fill the Void
Schedule Claude to work while you're away — coffee, meetings, sleep
CronCreateSession-local cron that fires a prompt when Claude is idle. Standard 5-field cron in your local time zone — no timezone math, no external job runner, no setup.
Old you: stare at the terminal, refresh, wait, context-switch, refresh again.
10x you: "Claude, every 7 minutes check if the pipeline passed. Ping me when it's green or broken." Walk away. Get coffee.
Notification flow: pair scheduling with PushNotification so Claude taps you on the shoulder — phone or desktop — only when it actually matters.
Steal these. Adapt them. Ship them to your team.
Fires every 7 minutes while this session is alive. Claude checks status, pings you when it fails or passes, and auto-diagnoses broken jobs on the spot.
Weekdays at 8:47 AM, Claude scans tickets, recent commits, and open MRs. Delivers your "what to work on" before your second sip of coffee.
Timing tip: pick off-minute values like 8:47 or :57 instead of :00/:30. When everyone's crons land on the same minute, you're fighting the whole company for API capacity.
Two tools, two shapes of time — pick the right one for the job
CronCreate — clock-drivenFires a prompt on a schedule when Claude is idle. Great for things the calendar decides.
Monitor — event-drivenStreams stdout lines from a long-running script. Each line becomes a notification. Great for things the system decides.
tail -f a log for new errorsAnthropic's prompt cache has a 5-minute TTL. Set Monitor heartbeats no more than 4 minutes apart — the cache stays warm, each reply is faster, and you pay the discounted cache-hit rate instead of re-reading the whole conversation. Go beyond 5 minutes and you burn the full context again, every time.
Quick rule: is the trigger a time? Use Cron. Is it an event in a stream? Use Monitor. Do both if the job is “every 4 minutes, check if the deploy log shows errors.”
More Ingenious Precision
You're not asking Google — you're briefing a smart colleague who just walked in
Which file? Which bug? What did you try? What's the expected behavior? Claude has to guess — and guesses are expensive.
Claude knows where, what, what's been tried, the success criterion, and where to test. One shot.
The pattern: here's what's broken — here's where — here's what I tried — here's what success looks like — here's where to verify. A good brief saves three follow-ups.
Industry-standard scaffolding that makes Claude address every requirement
<role> — persona: “Senior SRE,” “Staff Sec Eng”
<instructions> — the task list Claude must complete
<context> — versions, goals, prior decisions
<code_to_review> — or <data>, the payload
<constraints> — hard “do not” rules
<thought> — chain-of-thought reasoning
<examples> — few-shot good vs. bad pairs
OC-842) > descriptive stringslocalhost URLsWhy tags work: they give Claude unambiguous boundaries between rules, data, and output. Nested tags force the model to address each layer independently instead of surface-skimming.
Four slots. Fill them. Ship it.
What's the situation? Which files, which users, which constraint? Set the stage in one line.
What do you actually want done? Use verbs: refactor, add, diagnose, summarize, generate.
What's off-limits? "Don't touch the DB schema." "Keep the public API stable." "No new deps."
How should the answer land? Diff, plan, bullet list, commit message, MR description.
Ask: "before you answer, what questions would a senior engineer ask about this?" — Claude surfaces the ambiguity you missed, you clarify, the answer is surgical the first time.
Precision when the target is a component, a div, or a single pixel
1. By text: "the 'Submit Order' button"
2. By selector: .card-purple, [data-testid=save]
3. By role / ARIA: "first primary button in the form"
4. By file + line: Button.tsx:42 — opens to that line
5. By component name: <UserCard>, <CheckoutForm>
6. By position: "third card in row 2", "top-right nav"
"fix the save button styling"
"In Button.tsx:42, the primary variant uses bg-blue-500 — change to bg-purple-600 and bump padding from py-2 to py-3. Keep the hover state."
📷 The hidden superpower: screenshot → circle the problem → paste it. Claude sees what you see. Playwright MCP automates the capture so you can describe pixels with pixels, not English.
✏ Pro move: ask "what selector uniquely identifies this?" — Claude suggests the most stable one (data-testid beats nth-child).