Help us improve
Share bugs, ideas, or general feedback.
From 9arm-skills
Rewrites engineer-to-engineer content for engineering-org leadership (VPs, directors, PMs, release managers) and shapes it for JIRA, Slack, email, standup, or meeting talking-points.
npx claudepluginhub thananon/9arm-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/9arm-skills:management-talkThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Same audience and translation rules as a written status report, but **shaped for the channel** — JIRA comment, Slack post, async standup, email, or meeting talking-points. The audience reads code names but not code. The channel decides the length, formatting, and how much structure to leave on the page.
Provides scannable structures, honest framing, and warm recognition for team status updates, progress reports, and stakeholder communications.
Drafts concise stakeholder Slack/email updates from project context. Useful for communicating status, blockers, decisions, or release readiness.
Transforms raw notes into polished stakeholder updates for email, Slack, or deck bullets. Structures TL;DR, progress, blockers, decisions needed, and next priorities. Ideal for crisp status reports.
Share bugs, ideas, or general feedback.
Same audience and translation rules as a written status report, but shaped for the channel — JIRA comment, Slack post, async standup, email, or meeting talking-points. The audience reads code names but not code. The channel decides the length, formatting, and how much structure to leave on the page.
Use this any time engineering content needs to flow up the org, sideways into product/release, or into a non-engineering meeting — regardless of the destination.
If the channel is unclear after the trigger, ask one short question — "JIRA, Slack, standup, or email?" — and stop.
Engineering-savvy non-engineers: VPs, directors, PMs, release managers, execs in companies that ship technical products. They read product/framework names and cross-reference JIRA keys and PRs. They do not read code.
They want: what's the state, what does it mean for customers, who owns it, what's next. They do not want: how the bug works at the function level.
This is not for marketing, finance, customer-facing, or true ELI5 audiences — those need a different rewrite. Flag and confirm before producing one.
Keep. Product names, framework names, team-owned component names, JIRA keys, PR numbers, customer/workload identifiers (Tada, DeepSpeed, PyTorch, Llama-2-70B, vLLM, JIRA-12345, PR #5751). These are the bridge between engineering and leadership tracking.
Strip. Function names, file paths, struct fields, commit SHAs, code expressions, env var names, line numbers, internal data-structure jargon (tadaLaunchPrepare, tada/prim.h::syncWaitPeer, scratchBuf, 0e0a6bac). None of this is actionable to the audience.
Translate. Mechanism into one or two sentences of plain-English cause-and-effect. Not "the kernel reads from scratchBuf == NULL" but "the GPUs end up reading from an uninitialized buffer and wait forever for a signal that never arrives." Translate without lying — a race stays a race; a regression stays a regression.
Don't over-strip. Engineering-org leadership reads concept-level technical vocabulary fluently — race condition, synchronization, uninitialized buffer, fast-path, workaround, registration, queue, driver, kernel (in the GPU sense). The line is between concept exists and matters here (keep) and here's the function/struct/file/SHA (strip). Replacing "race" with "timing issue" patronizes the reader.
Bias toward active voice, concrete subjects, short paragraphs. "We found the bug. Alex wrote the fix. PR is up for review." beats "The root cause has been identified and a fix has been authored and submitted for review."
Avoid:
Same content, different shell. Pick the shape that matches where it's going.
Full structured block. Bolded section labels. Easy to scan from the ticket page.
Building blocks (use as many as fit):
Order by what matters most for this item.
Single message, no walls of text. Heavy bolded section labels read as "I escaped from JIRA" — don't.
JIRA-12345 / PR #5751). Not a link wall.Length target: under ~80 words for a top-level post; under ~40 for a thread reply.
The audience scans 10 of these in 30 seconds. Front-load the verb.
Subject line is half the value.
You're going to say this, not show it.
The input is one of:
JIRA-12345) → fetch via GET /rest/api/3/issue/<KEY>?fields=summary,status,priority,assignee,comment plus any custom fields your instance uses for technical evaluation — usually the cleanest source of current state. The most recent substantive comment is what to reframe; don't dump the full thread.If the source is ambiguous, ask one question and stop.
POST /rest/api/3/issue/<KEY>/comment.Source (engineering JIRA comment):
Mechanism: the single-stream fast-path in
tadaLaunchPrepare/tadaLaunchKernel/tadaLaunchFinish(gated onscheduler->numStreams == 1 && !plan->persistent) skipped the cross-stream event betweenlaunchStreamandhandle->shared->deviceStream. dumbModel hits this gate exactly. Kernel launched before deviceStream's IPC publish / scratch-buffer writes (the ones that populatescratchBuf) were visible to launchStream →scratchBuf == NULLin the kernel → stray pointer dereference → ring ready-flag read from garbage → thread spins forever.
Status: Fixed pending merge. Bug found, fix validated, PR up for review.
Impact: LLM-7B fine-tuning on 8 GPUs would hang every time it tried to evaluate the model — blocking the entire workload. Affects customers using dumbModel (a popular framework for training large models that don't fit on a single GPU), which means most large-model fine-tuning runs on the platform were exposed.
What broke: Our GPU communication library (Tada) skipped an internal synchronization step under a specific configuration that dumbModel happens to trigger. The GPUs ended up reading from an uninitialized buffer and got stuck waiting for a signal that would never arrive. The unsafe shortcut had been in the code for months but wasn't reached by any real workload until now.
A previous fix attempt added a defensive check that hid the symptom in some paths but left the underlying race in place. This new fix removes the unsafe shortcut entirely and tightens the safety check on the device side.
Owner: Alex (Tada team). PR org/platform#5751.
Next steps: code review → merge. Customers hitting this today can disable IPC registration as a temporary workaround.
Tada hang affecting dumbModel LLM-7B fine-tuning is fixed pending merge. (JIRA-12345)
- Skipped synchronization in the comms fast-path → GPUs read uninitialized memory → hang. Latent for months; dumbModel was the first workload to hit it.
- Owner: Alex, PR #5751 in review.
- Workaround until merge: disable IPC registration.
Fixed Tada hang on dumbModel LLM-7B (JIRA-12345). Alex's PR #5751 in review. Workaround posted in the ticket; backport to v7.2 next.
What changed between channels: same diagnosis, same owner, same next step. JIRA gets every block. Slack drops "why now" and "previous fix attempt" — too much for the channel. Standup keeps just state + key + owner + next. None of them mention scratchBuf or tadaLaunchPrepare.
git blame or recent commits.