Management Talk
Rewrite engineer-to-engineer updates into leadership-ready messages shaped for JIRA, Slack, standup, email, or meeting talking-points.
Overview
management-talk is an agent skill most often used in Build (also Ship, Operate) that rewrites engineer-to-engineer content for engineering leadership and formats it for JIRA, Slack, standup, email, or meetings.
Install
npx skills add https://github.com/thananon/9arm-skills --skill management-talkWhat is this skill?
- Same translation rules as a written status report, retargeted per channel (JIRA comment, Slack, async standup, email, me
- Audience reads code names and release concepts but not implementation jargon
- Triggers on exec summary, leadership update, less technical, and channel-specific rewrite requests
- Preserves accuracy while dropping engineer-to-engineer tone and depth inappropriate for leadership
- Usable whenever engineering content must flow up the org or sideways into product/release
Adoption & trust: 1.1k installs on skills.sh; 2.7k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have accurate engineering detail but leadership, PMs, or release managers need the same story in their channel—with less jargon and the right structure.
Who is it for?
Builders who regularly post status to directors, PMs, or release managers and want one skill to handle both translation and format.
Skip if: External marketing copy, deeply technical RFCs meant for peers only, or audiences with zero engineering vocabulary when the source material is already executive-ready.
When should I use this skill?
User asks to write or rewrite for management, exec, VP, director, PM, or release manager; wants executive or leadership status update; asks for less technical or less jargony copy; or needs Slack, email, standup, or meet
What do I get? / Deliverables
You get channel-shaped copy (JIRA, Slack, standup line, email, or talking-points) that leadership can read without decoding implementation depth.
- Channel-formatted leadership update
- Executive summary or talking-points derived from technical source
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build → pm because the skill translates engineering work into org-facing product and delivery communication while you are still building and coordinating releases. PM subphase covers status, scope, and stakeholder alignment—not code review—matching VP/director/PM/release-manager audiences.
Where it fits
Turn a detailed implementation note into a JIRA comment PMs can scan before prioritization.
Draft a Slack release summary for directors without listing every merged PR title.
Shape an incident timeline into email talking-points for a leadership sync.
Produce a one-line async standup that names risk and ETA without internal debug vocabulary.
How it compares
Leadership communication shaping—not a code reviewer, not a JIRA MCP integration.
Common Questions / FAQ
Who is management-talk for?
Engineers and tech leads at small companies who must explain progress, risk, and releases to VPs, directors, PMs, and release managers.
When should I use management-talk?
Use it in Build/pm for sprint and scope updates, in Ship/launch when preping release comms, and in Operate/iterate when reporting incidents or rollout status—whenever you need a management, exec, or less-jargony version in Slack, email, JIRA, or meetings.
Is management-talk safe to install?
It is prose-only with no declared shell or network tools; still review the Security Audits panel on this page before adding any skill to your agent.
SKILL.md
READMESKILL.md - Management Talk
# Management Talk 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. ## When to invoke - "write something for management / exec / VP / director / PM / release manager" - "rewrite this for [non-eng audience]" - "make this non-technical" / "less techy" / "less jargony" - "send a slack update / standup note / email" *about a piece of engineering work* - "executive summary" / "exec summary" / "leadership update" / "status update" - "talking points for [meeting]" *based on an engineering update* If the channel is unclear after the trigger, ask one short question — *"JIRA, Slack, standup, or email?"* — and stop. ## Audience — what "engineering-org leadership" means 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. ## Tone **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:** - Hedging that isn't really hedging (*"we believe," "appears to," "may have"*). State it or don't. - Re-stating the obvious for thoroughness (*"This bug is in Tada, which is used for GPU communication, which is