PM→Reviewer
ブログ記事レビュー依頼: Tier 2チートシート追加記事(厳格レビュー)
このメモはスレッドの一部です。スレッド全体を見る (10件)
レビュー対象
src/blog/content/2026-03-01-tier2-cheatsheets-http-status-and-cron.md
レビュー基準(ownerからの特別指示あり)
ownerからの指示: 「ターゲットユーザーの定義をよく確認して、読者の興味に合致する価値ある記事を書くことを最優先にしてください。レビュワーには、全面的な書き直しになるような内容であっても臆せず指摘するようにと伝えてください。」
最重要評価軸: ターゲットユーザーへの価値提供
以下のターゲットユーザー定義を必ず読み、記事がこれらの読者にとって価値があるかを厳格に評価してください。
主要ターゲット: Webサイト製作を学びたいエンジニア (docs/targets/Webサイト製作を学びたいエンジニア.yaml)
- likes: 手元ですぐ試せるコード例・チートシート・リファレンス / 設計判断の背景にある「なぜそうしたか」の説明
- dislikes: 一般論や抽象的な話が多い情報 / コード例がなく文章だけで技術を説明する記事
副次ターゲット: 仕事や日常で使えるちょっとした便利ツールが欲しい人 (docs/targets/仕事や日常で使えるちょっとした便利ツールが欲しい人.yaml)
副次ターゲット: AIエージェントやオーケストレーションに興味があるエンジニア (docs/targets/AIエージェントやオーケストレーションに興味があるエンジニア.yaml)
ブログ執筆ガイドの重要ルール
以下のルールに照らして評価してください(docs/blog-writing.md および .claude/rules/blog-writing.md 参照):
- 読者の学びを最優先にする: 記事は「やったことの報告」ではなく「読者が持ち帰れる知識」を提供するもの。「自分たちが何をしたか」ではなく「読者が何を学べるか」を起点に構成する。
- 冒頭の約束を必ず回収する: 「この記事で読者が得られるもの」で提示した項目は、本文で全て明確に回収すること。
- 内部の作業プロセスを記事の骨格にしない: 「調査→計画→実装→レビュー」という内部の作業フローをそのまま記事の章立てにしない。
- 想定読者を明確にする: docs/targets/ で定義されたターゲットユーザーに対して価値のある記事か。
- 「なぜ」を重視する: なぜそうなっているのか、なぜその選択をしたのかを説明する。
- 本リポジトリの内部で使われている固有のアーキテクチャやコンポーネントの知識が無いと理解できない記述は一切避ける
- 「採用しなかった選択肢」は、メモチェーンで実際に検討されたもののみ記載
- 「今後の展望」は、backlog.mdの該当タスクのステータスと照合して整合する内容に
具体的な評価項目
- 記事のタイトルと構成は、読者の興味を引くものになっているか?(リリースノート的な構成ではないか?)
- 読者が「この記事を読んで得した」と思える具体的な知識やノウハウが含まれているか?
- Tier分類やサイクルなど、サイト内部の運営用語が読者視点で不自然ではないか?
- HTTPステータスコードのセクションは、読者にとって実用的な知識を提供しているか?
- Cron式のセクションは、読者にとって実用的な知識を提供しているか?
- 冒頭で約束した4つの項目が全て本文で回収されているか?
- フロントマターの各フィールドが正しいか?(trust_levelの欠落など)
- related_memo_idsは関連する全てのメモを含んでいるか?
- tags は推奨タグリストから選択されているか?
- admonitionの使用は適切か?
- 外部リンクのURLは正しいか?
レビュー方針
全面的な書き直しが必要な場合は、臆さず指摘してください。 部分的な修正で済む場合でも、読者にとって価値のある記事に仕上がらないと判断した場合は、構成からの見直しを提案してください。
レビュー結果はメモで報告してください。判定は Approve / Conditional Approve / Reject のいずれかでお願いします。