communication-style

星标11

分支0

更新时间2026年7月17日 17:38

Write concise, calm technical responses whose structure matches the decision, evidence, or sequence being communicated. Use when drafting substantial plans, reviews, findings, documentation, or completion summaries.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

aryaminus

aryaminus/controlkeel

打开 GitHub 仓库查看创作者相关仓库

下载

Communication Style

Make technical communication easy to act on. Preserve evidence, caveats, and required governance fields; remove only material that does not change the reader's decision or next action.

Workflow

Open with the answer, decision, or observed result. Include the central caveat immediately when it changes the call.
Choose structure from the content: prose for causality, numbered steps for a sequence, bullets for parallel facts, and headings for genuinely distinct sections.
Keep connected reasoning together. If statements depend on “because,” “but,” or “so,” express that relationship instead of splitting it into fragments.
Put evidence next to the claim it supports. Distinguish observations, interpretations, and recommendations.
Cut repeated summaries, generic preambles, hype, theatrical labels, and advice the reader already supplied.
End when the request is answered. Add a final recommendation only when the response weighs a real decision.

Boundaries

Concision never overrides required security findings, uncertainty, approval conditions, commands, test evidence, or rollback instructions.
Do not manufacture confidence or remove qualifications to make prose sound decisive.
Do not force every response into headings or bullets.
Do not copy an external style guide verbatim; apply these repository-owned principles to the current audience and task.

Output check

Before sending, verify that the first two sentences contain the result, every section changes understanding or action, and no conclusion is repeated in a second format.

同仓库更多 Skills

同仓库

bounded-loop

aryaminus/controlkeel

Run objective, repeatable improvement work under an immutable verifier and hard iteration, cost, time, and no-progress limits. Use for approved experiments with an automated metric and sandboxed worker.

2026-07-1711

controlkeel-governance

aryaminus/controlkeel

Operate inside a ControlKeel-governed session. Use this before code edits, shell execution, delegation, deploy work, or any task that needs CK validation, findings, budget, proof, or routing context.

2026-07-1711

cost-optimization

aryaminus/controlkeel

Keep a governed session within budget. Use this before long-running agent work, bulk processing, or any task where spend pressure could change the plan.

2026-07-1711

end-of-shift

aryaminus/controlkeel

Close a governed work session with validation, proof, findings, budget, digest, learning, and handoff checks. Use when the user asks to wrap up, stop for the day, or leave work ready for another agent.

2026-07-1711

false-confidence-test-audit

aryaminus/controlkeel

Audit tests that may pass without proving the claimed behavior. Use for periodic test-quality reviews or when coverage looks healthy but regressions still escape.

2026-07-1711

handoff

aryaminus/controlkeel

Persist session state and hand off in-progress work to a background agent or delegated execution. Use when work outgrows the current session, context is near limit, or a task needs to continue unattended.

2026-07-1711

name	communication-style
description	Write concise, calm technical responses whose structure matches the decision, evidence, or sequence being communicated. Use when drafting substantial plans, reviews, findings, documentation, or completion summaries.
when_to_use	Activate when the user asks for clearer writing, or when producing a substantial human-facing plan, review, finding, or summary. Do not use to shorten required safety evidence or machine-readable output.
argument-hint	[text or response type]
license	Apache-2.0
compatibility	["codex","claude-standalone","claude-plugin","copilot-plugin","github-repo","open-standard","cursor-native","opencode-native"]
metadata	{"author":"controlkeel","version":"1.0","category":"communication"}

Communication Style

Make technical communication easy to act on. Preserve evidence, caveats, and required governance fields; remove only material that does not change the reader's decision or next action.

Workflow

Open with the answer, decision, or observed result. Include the central caveat immediately when it changes the call.
Choose structure from the content: prose for causality, numbered steps for a sequence, bullets for parallel facts, and headings for genuinely distinct sections.
Keep connected reasoning together. If statements depend on “because,” “but,” or “so,” express that relationship instead of splitting it into fragments.
Put evidence next to the claim it supports. Distinguish observations, interpretations, and recommendations.
Cut repeated summaries, generic preambles, hype, theatrical labels, and advice the reader already supplied.
End when the request is answered. Add a final recommendation only when the response weighs a real decision.

Boundaries

Concision never overrides required security findings, uncertainty, approval conditions, commands, test evidence, or rollback instructions.
Do not manufacture confidence or remove qualifications to make prose sound decisive.
Do not force every response into headings or bullets.
Do not copy an external style guide verbatim; apply these repository-owned principles to the current audience and task.

Output check

Before sending, verify that the first two sentences contain the result, every section changes understanding or action, and no conclusion is repeated in a second format.