96 lines
7.3 KiB
Markdown
96 lines
7.3 KiB
Markdown
---
|
||
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.**
|
||
|
||
> [!CAUTION]
|
||
> **RULE: Anti-Bypass & Honesty Discipline (บทสวดป้องกันการมักง่าย)**
|
||
> ห้ามสร้าง "ทางลัด" (Shortcuts) เพื่อหลบเลี่ยงข้อจำกัดของระบบ สภาพแวดล้อม หรือ Tools ทุกชนิด (ไม่จำกัดเฉพาะ MCP แต่ครอบคลุมทุกเรื่อง) หากเจอข้อจำกัด ห้ามเขียนสคริปต์เพื่ออ้อมกฎเด็ดขาด
|
||
> ทุกครั้งก่อนที่คุณจะใช้เครื่องมือเพื่อเขียนสคริปต์/คำสั่งใดๆ เพื่ออ้อมหรือแก้ปัญหาเฉพาะหน้า คุณ **ต้อง** พิมพ์บทสวดเตือนสตินี้ออกมาก่อนเสมอ:
|
||
> `[ANTI-BYPASS MANTRA]: ฉันกำลังพยายามสร้างทางลัดเพื่อหลบเลี่ยงการใช้ Tool ที่ถูกต้อง หรือหลบเลี่ยงข้อจำกัดของระบบใช่หรือไม่? ถ้าใช่ ฉันต้องลบทิ้งและหยุดการกระทำทันที!`
|
||
|
||
> [!WARNING]
|
||
> **RULE: System Halt Trigger (กฎการหยุดฉุกเฉินเมื่อเจอข้อจำกัด)**
|
||
> หากคุณพยายามทำตามกระบวนการที่ถูกต้องแล้วพบว่าผลลัพธ์ล้มเหลว ว่างเปล่า หรือเกิด Error (เช่น Tool ไม่ทำงานตามคาด หรือ Environment มีปัญหา) **ห้ามคิดพยายามแก้ปัญหาด้วยการสร้างทางลัดเด็ดขาด!** ให้คุณหยุดทำงานทันที และพิมพ์คำสั่ง **`[SYSTEM HALT: REQUIRE USER INTERVENTION]`** ลงในคำตอบ เพื่อแจ้งข้อจำกัดทางเทคนิคให้ User ทราบตามตรงและรอการตัดสินใจจาก User เสมอ
|