mcpField
P
prose-style

prose-style

github.com/avelikiyエージェントワークフロー11155 回インストール今日更新
リポジトリ

prose-style について

prose-styleは、忙しいCTO向けのgreat_ctoエージェント報告を書くためのスキルです。結論を先に示し、具体的な根拠を挙げ、曖昧な表現や冗長な前置きを避け、機械可読な判定で締めくくります。

主な機能

  1. 01結論から報告を始める
  2. 02具体的な根拠で判断を裏付ける
  3. 03曖昧な語句や冗長な前置きを避ける
  4. 04機械可読な判定で締めくくる
  5. 05レビューとアーキテクチャのテンプレート

活用シーン

  1. 01簡潔なCTOレビュー報告の作成
  2. 02位置と根拠を添えた指摘の報告
  3. 03ボードツールが解析する判定の生成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/avelikiy/great_cto --skill prose-style

インストール後、Claude Code で/prose-styleを入力して読み込まれたか確認します。

詳細

文章スタイル — エージェントレポートの作成ルール

great_cto のレポートを読むのは、火曜日の午後3時、忙しい CTO です。事実、決定事項、対応が必要な内容を素早く確認します。マーケティング調の表現や曖昧な言葉は、時間の無駄です。

5つのルール

1. 結論から始める

悪い例：

アーキテクチャ文書を確認し、スケーラビリティ、セキュリティ、保守性などを含むさまざまなトレードオフを検討した結果、提案されたアプローチは概ね許容できますが、改善できる可能性のある箇所もあると考えます。

良い例：

2点の変更を条件に承認します：（a）PII の暗号化を KMS に移す、（b）Webhook ハンドラーに冪等性キーを追加する。詳細は以下のとおりです。

2. 形容詞ではなく、具体的な根拠を示す

悪い例：「パフォーマンスは許容範囲です。」 良い例：「5万件のリクエストで p99 レイテンシは 142ms（k6 実行 2026-05-12 14:00 UTC、tests/load/<your-scenario>.js）。SLO は 200ms です。」

悪い例：「セキュリティに問題はなさそうです。」 良い例：「Critical または High の指摘事項はありません。Medium が2件あります：src/logger.ts:14 のログレベルのハードコード、src/middleware/cors.ts:8 の CORS ヘッダー不足。」

3. 曖昧な言葉を使わない

禁止語：概ね、やや、かなり、おおむね、なんとなく、どちらかといえば、ほぼ、場合によっては、よく、ときどき、時折、可能性がある、おそらく、たぶん、改善を検討したほうがよいかもしれない。

具体的な内容に置き換えるか、省略してください。本当に分からない場合は、「<理由>のため不確かです」と書いてください。それも情報です。

4. 前置きの水増しをしない

禁止表現：

  • 「この文書では、……について説明します」
  • 「重要なのは……という点です」
  • 「何よりもまず……」
  • 「結局のところ……」
  • 「言うまでもありませんが……」

情報を失わずに削除できる文は、削除してください。

5. 最終行に判定を記載する

すべての最終レポートは、次のいずれかで終わります。

VERDICT: APPROVED — <one-line summary>
VERDICT: DONE — <one-line summary>
VERDICT: BLOCKED reason="<specific blocker>"
VERDICT: FAIL reason="<specific failure>"

これはボードの readVerdicts() 関数で解析されます。形式は機械可読です。飾り立てないでください。

テンプレート

レビュアーレポート
# REVIEW-<feature> — <reviewer name>

Reviewed: <commit-sha or file paths>
Standard: <regulation / framework you applied>

## Findings
- [Critical|High|Med|Low] <one-sentence finding>
  - location: <path:line>
  - rationale: <why this matters in this domain>
  - remediation: <specific fix>

## Verdict
VERDICT: APPROVED|BLOCKED reason="<short>"
アーキテクチャ / ADR
# ARCH-<feature> | ADR-<NNN>

Date: <ISO>
Status: proposed | accepted | superseded

## Context
2-4 sentences. What problem, what constraint.

## Decision
Imperative single sentence: "Use X for Y."

## Consequences
- Positive: <bullets>
- Negative: <bullets>
- Reversible? yes/no — if no, document migration cost

## Alternatives considered
<bullets with one-line dismissal reason each>

grep で確認するアンチパターン

判定行を書く前に、下書きを検索してください。

\b(generally|somewhat|fairly|mostly|kind of|sort of|possibly|perhaps|maybe)\b

引用文以外で該当箇所が見つかった場合は、具体的に書き直すか削除してください。

重要な理由

ボードの readVerdicts() はすべてのレポートを解析します。マーケティング調の表現はパーサーを壊します。曖昧な言葉を含むレポートは、読み手の時間を無駄にします。具体的な情報があれば、CTO はエージェントの判断を信頼できます。

コメント

Markdown 対応