---
name: management-talk
description: Rewrite engineer-to-engineer content for engineering-org leadership (VPs, directors, PMs) and shape it specifically for Taskboard MCP operations (submit_task_result, add_comment, create_sub_task). Trigger when the user asks to write/rewrite an update, report, or summary for management, or asks to make technical text less jargony specifically for taskboard updates.
---

# Management Talk for Taskboard MCP

Same audience and translation rules as a traditional written status report, but **shaped specifically for Taskboard MCP operations** — `submit_task_result`, `add_comment`, or `create_sub_task`. The audience reads project names, task numbers, and high-level impacts, but not deep code logic.

Use this any time engineering content needs to be summarized and logged into the Taskboard for management, product teams, or cross-functional tracking.

## When to invoke

- "write something for management / PM to put in the taskboard"
- "rewrite this technical update for the taskboard comment"
- "make this non-technical" / "less techy" / "less jargony" for a task update
- "executive summary" / "status update" to submit the task result
- "create a sub-task description based on this technical bug"

## Audience — what "engineering-org leadership" means

Engineering-savvy non-engineers: VPs, directors, PMs, release managers. They read product/framework names and cross-reference Task IDs. 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, or customer-facing audiences — those need a different rewrite. Flag and confirm before producing one.

## Tone

**Keep.** Product names, framework names, team-owned component names, Task IDs, PR numbers, customer/workload identifiers. 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. 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."*

**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."*

## Channel shapes (Taskboard MCP Tools)

Same content, different shell. Pick the shape that matches the target MCP tool.

### 1. Task Result (`submit_task_result`)

Full structured block used when closing a task. Easy to scan.
Building blocks (use as many as fit):
- **Status / TL;DR.** One clear line. *"Fixed and merged."* / *"Workaround applied, full fix pending next sprint."*
- **Impact.** Who's affected, how badly, what they see.
- **What broke / What was done.** Short paragraph. Plain-English mechanism, no code identifiers.
- **Owner / Links.** PR number or reference links.
- **Next steps / Risks.** Real risks only or what follows after closing this.

### 2. Task Comment (`add_comment`)

Used for continuous updates, flagging blockers, or daily progress. No walls of text.
- One **TL;DR** as the first line.
- 2–3 short bullets underneath: current state, blockers (if any), next step.
- Do not use heavy bolded section labels like the Task Result. Keep it brief and scannable.

### 3. Sub-Task Description (`create_sub_task`)

Used when breaking down a highly technical issue into actionable work for others.
- **Goal:** One sentence explaining what needs to be done.
- **Context:** Why we are doing this (plain English).
- **Technical Hints (Optional):** Keep this brief, pointing to where the engineer should look (this is the only place some technical jargon is acceptable if the assignee is an engineer, but keep it high-level).
- **Acceptance Criteria:** How to know it's done.

## Source material

The input is one of:
1. **A Task ID** → fetch via `call_mcp_tool` `get_task_detail` to read current status and comments.
2. **Pasted technical text** → use directly.
3. **The current conversation** → if you just produced engineering content, reuse what's in context.

## Output flow

1. **Confirm the target tool** if it's not stated (Result, Comment, or Sub-task).
2. **Produce the draft** formatted for the Taskboard as a chat message.
3. **Ask before executing:** Show the exact drafted text, wait for explicit *"post it"* / *"go ahead"*, then execute the corresponding MCP tool (`submit_task_result`, `add_comment`, etc.).
4. **Never post automatically** without the user seeing the drafted management-talk first.

## Rules

- **Never invent facts** to make the rewrite cleaner.
- **Never strip a Task ID, PR number, or product name** during de-jargoning.
- **Get sign-off before executing the MCP tool.**