Marker: TERMS_DICTIONARY_RESTART_GATE_20260611 / v0.1.78
このページは OripaGate【用語辞書】terms-dictionary の6つのcron依頼文を管理するページである。対象は https://oripagate.jp/terms-dictionary/ と、辞書セット https://oripagate.jp/directory-collection/oripa-terms/ である。
v0.1.78 固定運用
- OripaGate【用語辞書】の各cronは、それぞれ1日1回起動とする。
- 収集、検査、制作、高品質チェック、訂正、改善ハンドオフのすべてを1回/日にする。
- 各cronは作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、修正報告はすべて日本語で行う。
- 各個別cron本文には、cron実行時に必要な作業内容、熟読するMD/GATE、保存/readback、FAIL条件だけを書く。
cron一覧
- OripaGate【用語辞書】収集cron: 1回/日 / model gpt-5.4
- OripaGate【用語辞書】検査cron: 1回/日 / model gpt-5.5
- OripaGate【用語辞書】制作cron: 1回/日 / model gpt-5.5
- OripaGate【用語辞書】高品質チェックcron: 1回/日 / model gpt-5.5
- OripaGate【用語辞書】訂正cron: 1回/日 / model gpt-5.4
- OripaGate【用語辞書】改善ハンドオフcron: 1回/日 / model gpt-5.4
個別cron作成依頼文
OripaGate【用語辞書】収集cron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】収集cron v0.1.78 詳細版
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.4
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 収集
- schedule intent: 1回/日
## 0. このcronの役割
これは OripaGate【用語辞書】の収集cronである。用語候補を集め、候補の出所と文脈を整理し、検査cronへ渡せる状態にする。制作、検査、公開、訂正、品質判定は行わない。記事を作ったり、公開したり、検査PASSを出したりしてはいけない。候補はあくまで候補であり、production_readyではない。検査cronがサーチコンパスを使って確認し、制作へ回せるかを判断する。
## 1. 作業ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、候補なし理由、次回確認事項はすべて日本語で行う。
- 収集cronは1日1回だけ起動する前提で動く。1日に複数回起動する前提で候補を小分けにしない。
- 収集cronは確認できた範囲、確認できなかった範囲、次回見る範囲を分けて保存する。
- 収集cronは外部の秘密情報、APIキー、認証値、個人情報を出力しない。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\COLLECTION_SOURCE_MANUAL.md`
## 作業対象
作業対象は OripaGate【用語辞書】workflow のみ。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
## 2. 対象の固定情報
対象はOripaGateの用語辞書である。通常評価記事、キャンペーン記事、ランキング記事、比較記事ではない。公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` とする。候補保存時には、必ず `workflow_id=oripagate-terms-dictionary-ja`、`article_type=terms-dictionary`、`content_set=oripagate_terms_dictionary`、`dictionary_set_url=https://oripagate.jp/directory-collection/oripa-terms/` を残す。
用語辞書で扱う候補は、オンラインオリパ、TCG、ガチャ、ポイント、発送、支払い、本人確認、SMS認証、ログイン、キャンペーン、当選、在庫、封入、還元、買取、カード状態、レアリティ、配送、退会、規約、特典、抽選方式など、OripaGate読者が理解に迷いやすい言葉である。単なるサービス名やブランド名は、用語として扱う必要があるかを慎重に分ける。サービス名そのものが評価記事やキャンペーン記事の対象になる場合、terms-dictionary候補として混ぜない。
## 3. 起動時に確認するもの
起動したら、まずOripaGate専用HUBの `agent_pack` で `site_id=oripagate`、`workflow_id=oripagate-terms-dictionary-ja` の最新Rules、Manuals、Gates、References、Work Queueを確認する。確認した結果は日本語で短く保存する。確認できない場合は、確認できなかった理由を保存し、Files fallbackに候補メモを残す。Hubが読めないのに読めたふりをしない。
次に、ローカルのOripaGate用語辞書マニュアルを参照する。参照対象は `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md` と `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\COLLECTION_SOURCE_MANUAL.md` の用語辞書関連部分である。読む必要がある箇所だけを確認し、読み取った収集ルールを候補保存に反映する。
## 4. 収集元の全体方針
収集元は1種類だけに偏らせない。公式、既存OripaGate、検索需要、読者の混乱、SNS、競合用語集の文脈確認を分けて見る。公式だけ見て「候補なし」にしない。競合用語集だけ見て候補化しない。検索結果だけで意味を断定しない。SNSだけで公式事実として扱わない。
候補は、読者が実際に困る可能性がある言葉を優先する。単語として珍しいだけ、SEOで拾えそうなだけ、競合に載っているだけでは候補化しない。OripaGateの読者がオンラインオリパやTCGを使うときに意味、条件、注意点、誤解、関連語を知る価値があるかを確認する。
## 5. 公式サービスFAQ・ヘルプ・利用規約
公式サービスのFAQ、ヘルプ、利用規約、特定商取引法ページ、支払いページ、発送ページ、ポイントページ、当選ページ、退会ページ、本人確認ページ、SMS認証ページ、ログイン関連ページを確認する。公式ページで見つけた言葉は、公式文言として強い候補になる。ただし、公式文言の意味を勝手に広げない。公式ページのURL、ページ名、確認日、見えた文言、文脈、読者が迷いそうな点を保存する。
公式ページから拾う例として、SMS認証、本人確認、初回登録、ログインボーナス、ポイント還元、還元率、発送目安、送料、当選確率、排出率、封入率、ラストワン、天井、演出、ポイント失効、退会、返品、キャンセル、特商法、古物商許可、買取、査定、未開封、傷あり、ランク、PSA、鑑定、状態表記などがある。実際の候補化は、公式で見えた文言とOripaGate読者の需要を見て判断する。
## 6. キャンペーン文中の用語
キャンペーン記事、キャンペーン告知、公式SNS、公式ニュース、バナー文言、LPの注意書きに出てくる用語も収集対象にする。特に、初回限定、招待コード、SMS認証、ログインボーナス、ポイント還元、期間限定ガチャ、限定オリパ、還元祭、送料無料、クーポン、イベント名、ガチャ名、ミッション、抽選、対象外条件、併用不可、付与時期、期限、失効、エントリーなどは読者が意味や条件を間違えやすい。
ただし、キャンペーン固有の短期情報を用語辞書にそのまま入れない。用語として長期的に説明する価値があるか、または既存キャンペーン記事の内部リンク補助として役立つかを分ける。期限つきキャンペーン名だけを用語候補にする場合は、終了後に価値が残るかを未確認点として保存する。
## 7. 既存OripaGate記事の不足語
既存OripaGate記事を確認し、読者が途中で意味を調べたくなる言葉、本文では説明しきれていない言葉、内部リンク化すると理解が進む言葉を拾う。対象は公開済みのOripaGate記事であり、下書きや古い退避記事を現在の候補数や制作済み数として数えない。
既存記事から拾うときは、記事URL、該当見出し、該当文脈、用語の出現箇所、内部リンク化したときの自然なアンカーテキスト案を保存する。既存記事の本文を丸写しせず、用語辞書記事で説明すべき不足点だけを候補化する。既存記事の内容が古い可能性がある場合は、検査cronで公式再確認が必要であると付箋する。
## 8. Search Console・関連検索・サジェスト
Search Console、Google関連検索、サジェスト、検索結果のスニペットを確認する。検索語の例は、`オリパ 用語`、`オンラインオリパ 用語`、`オリパ 天井とは`、`オリパ ラストワンとは`、`オリパ SMS認証`、`オリパ ポイント還元`、`オリパ 発送 いつ`、`オリパ PSAとは`、`TCG PSA 意味`、`カード 状態 A B C`、`オリパ 還元率 意味` のように、意味を調べる形にする。
Search Consoleやサジェストから拾った語は、検索需要の根拠として扱う。公式事実として断定しない。検索結果のスニペットだけを出典にして意味を確定しない。保存時には、検索語、見えた関連語、サジェスト、検索意図の仮説、読者が知りたいこと、公式確認が必要な点を分ける。
## 9. SNSや読者投稿で混乱している語
SNS、掲示板、レビュー、口コミ、利用者投稿で、読者が混乱している語を拾う。たとえば、`還元率が高いとは何か`、`当たり枠とは何か`、`発送が遅いとはどの状態か`、`ポイントが反映されない`、`SMS認証ができない`、`ラストワンの意味が分からない`、`PSA10とは何か` のような迷いは用語候補になる。
SNS情報は公式事実ではない。発見元URL、見えた文言、確認日、公式再確認状況、未確認点を保存する。個人の投稿を過度に引用しない。誹謗中傷、個人情報、断定できない評判は候補文脈に使わない。読者が混乱している点だけを抽出し、検査cronで公式確認するよう付箋する。
## 10. 競合用語集の扱い
競合用語集は、候補発見と文脈確認だけに使う。丸写し、表現の流用、構成のコピーは禁止。競合で見つけた語は、OripaGate読者に必要か、公式や既存OripaGateや検索需要でも確認できるかを見て候補化する。競合だけに載っていて、公式・検索需要・読者混乱・既存OripaGate不足のどれにもつながらない語は、保留または対象外にする。
競合用語集を見た場合は、競合URL、見つけた語、文脈、OripaGateで扱うべき理由、公式再確認が必要な点を保存する。競合の本文を引用しない。競合で見えた分類名や説明順をそのまま使わない。OripaGateでは、オンラインオリパ読者とTCG読者が自然に理解できる説明へ検査・制作で組み直す。
## 11. 候補にしてよい語の判断基準
候補にしてよい語は、読者が意味を調べる可能性があり、OripaGateの記事内で内部リンクとして使える可能性があり、オンラインオリパやTCG利用時の理解に役立つ語である。公式や検索需要や読者混乱のいずれかで文脈が確認でき、検査cronが深掘りできる材料があることが望ましい。
候補例として、オリパ、オンラインオリパ、TCG、パック、BOX、シングルカード、レアリティ、PSA、鑑定、PSA10、未開封、傷あり、状態ランク、封入率、排出率、還元率、天井、ラストワン、演出、当たり枠、ハズレ枠、ポイント、ログインボーナス、SMS認証、本人確認、初回登録、招待コード、クーポン、送料、発送目安、追跡番号、買取、査定、古物商許可などがある。実際には重複、既存記事、検索需要、公式文脈を見て判断する。
## 12. 候補にしない語・保留する語
サービス名、会社名、キャンペーン名、商品名、カード名、固有のガチャ名は、用語辞書ではなく評価記事、キャンペーン記事、トレカ辞書、別ディレクトリの対象になる場合がある。terms-dictionaryに入れるべきか迷う場合は、推測投入しない。想定カテゴリ、迷った理由、どの辞書セットが候補かを保存し、検査cronへ保留で渡す。
一時的すぎるキャンペーン名、公式で確認できない俗称、炎上や噂だけの言葉、個人名、誹謗中傷を含む語、アダルトや他サイト領域の語、OripaGate読者と関係が薄い語は候補化しない。候補化しない場合も、なぜ対象外にしたかを日本語で保存する。
## 13. 重複確認
候補化する前に、既存のOripaGate公開記事、terms-dictionary、directory collection、Hub素材、Work Queue、Files fallbackを確認し、同じ用語が既に存在しないかを見る。完全一致だけでなく、表記ゆれ、カタカナ、英字、略称、漢字違いも見る。例として、`PSA10` と `PSA 10`、`ログボ` と `ログインボーナス`、`SMS認証` と `電話番号認証`、`還元率` と `ポイント還元` は別記事にするか統合するかを検査に渡す。
重複が見つかった場合は、既存URL、既存タイトル、重複度、統合候補、別記事にする理由、内部リンク候補を保存する。重複しているのに新規候補としてproduction_readyへ進めるような保存をしてはいけない。
## 14. 表記ゆれの保存
用語候補には表記ゆれを必ず保存する。カタカナ、英字、略称、正式名称、ユーザーが使う俗称、公式が使う表記を分ける。たとえば、`オンラインオリパ`、`オリパ`、`ネットオリパ`、`ポイント還元`、`還元率`、`ログインボーナス`、`ログボ`、`SMS認証`、`電話番号認証` のような揺れは、検査cronがSEOタイトルや内部リンクアンカーを決める材料になる。
表記ゆれは公式表記と読者表記を混同しない。公式にない俗称は俗称として扱い、公式事実のように断定しない。表記ゆれが多い場合は、代表語、同義語、別記事候補、統合候補を保存する。
## 15. 保存する候補フィールド
候補ごとに最低限、次の項目を保存する。
- candidate_id または一意に識別できる仮ID。
- 用語名。
- 表記ゆれ。
- 想定読み。
- 想定カテゴリ。
- public_category_url。
- dictionary_set_url。
- workflow_id。
- article_type。
- content_set。
- 発見元種別。
- 発見元URL。
- 見えた文言。
- 発見した文脈。
- 読者が迷いそうな点。
- 公式確認状況。
- 検索需要の有無。
- 既存OripaGate記事での不足箇所。
- 内部リンク候補。
- 競合で見えた場合は競合URLと丸写し禁止メモ。
- 公式再確認が必要な点。
- 検査cronに渡す注意点。
- 確認日。
- 収集cron名。
保存項目が欠けた場合は、欠けた理由を保存する。重要項目が欠けたまま候補を検査へ進めない。
## 16. Hub保存とFiles fallback
候補はOripaGate専用HUBの用語辞書関連に保存する。Hub保存ができる場合はHubへ保存し、保存後にreadbackして内容が入っていることを確認する。Hub保存が失敗した場合は、`C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate` 配下のruntimeまたはcron_outputsにFiles fallbackとして保存する。Files fallbackだけで終わる場合も、保存パス、保存内容、Hub保存失敗理由、次回Hubへ戻す必要があることを日本語で残す。
Hub保存もFiles fallback保存もせず、作業報告だけで終わることは禁止。候補がゼロの場合も、候補なしレポートを保存する。保存した内容はreadbackし、候補数、候補名、保存先、次工程を確認する。
## 17. 1回の収集量
1回の収集cronで処理する候補は、無理に大量にしない。候補が多い場合は、優先度の高いものから1〜15件までを候補として保存し、16件以上は次回候補メモに回す。候補数を増やすために薄い候補を混ぜない。1日1回起動の前提で、次回見るべき場所と残候補を残す。
候補が多すぎる場合は、発見元ごとに優先順位をつける。公式FAQで複数記事に関係する語、Search Consoleで需要が見える語、既存記事で内部リンク化しやすい語、読者混乱が明確な語を優先する。競合にしかない語や公式確認が弱い語は保留にする。
## 18. 優先度の付け方
優先度Aは、公式文脈があり、読者が意味を調べそうで、既存OripaGate記事の内部リンクにも使え、検査cronがすぐ深掘りできる語である。優先度Bは、検索需要や読者混乱は見えるが、公式確認や既存記事との接点がまだ弱い語である。優先度Cは、競合やSNSで見えたが、OripaGateで扱う理由を検査で確認する必要がある語である。
優先度Aだけをproduction_readyと呼ばない。収集cronはproduction_readyを決めない。優先度は検査cronへ渡すための目安であり、制作可能かどうかは検査cronがサーチコンパスと公式確認で判断する。
## 19. 内部リンク候補の付箋
候補語を保存するときは、内部リンク候補も付箋する。既存OripaGate記事のどの文脈からリンクできるか、自然なアンカーテキストは何か、別辞書セットの記事を使えるかを保存する。内部リンク候補は最低3件を目指すが、収集段階で3件見つからない場合は、見つかった分と不足理由を保存する。
内部リンク候補は、リンク先が公開URLであることを優先する。preview、下書き、管理画面URLを候補にしない。HTTP 200の最終確認は制作・高品質チェック側で行うが、収集段階でも明らかに404や非公開と分かるURLは候補にしない。
## 20. 検査cronへ渡す付箋
検査cronへ渡す付箋には、候補語の意味を断定した文章ではなく、検査で確認すべき項目を入れる。最低限、主KW候補、関連語、共起語の仮説、読者の検索意図、誤解しやすい点、公式確認が必要な点、内部リンク候補、想定H3文脈を入れる。
H3文脈は固定で「オンラインオリパでの使われ方」にしない。TCG用語なら `H3 TCGでの使われ方`、発送関係なら `H3 発送での使われ方`、ポイント関係なら `H3 ポイントでの使われ方`、ガチャ関係なら `H3 ガチャでの使われ方`、買取関係なら `H3 買取での使われ方` のように、業界内で自然な文脈を付箋する。
## 21. 収集cronがやってはいけないこと
収集cronは記事本文を書かない。SEOタイトルを最終決定しない。H1を最終決定しない。WordPressへ投稿しない。公開しない。validator_result.jsonをPASS扱いにしない。機械Gateを自分の判断だけで通ったことにしない。収集した候補を制作済み扱いにしない。
収集cronはNode REPLを使わない。Node REPLを使う必要があると判断した場合でも使わず、別手段で進めるか、日本語で「Node REPL禁止のため未実行」と保存する。JavaScript REPLやnode_replも同じく禁止である。
## 22. 文字化けと日本語
候補名、発見元文言、保存レポート、readback、handoffはすべて日本語で読める状態にする。典型的な文字化け記号や読めない日本語が混じった保存はFAILである。文字化けを見つけた場合は、その候補を検査へ渡さず、文字コード、取得元、再取得の必要性を保存する。
英語の用語や公式英字表記は残してよい。ただし、説明、作業報告、FAIL理由、次回確認事項は日本語にする。英字だけのログや機械的なJSON断片だけを作業報告にしない。
## 23. 即FAIL
次のどれかに当てはまる場合は収集FAILとして保存し、完了扱いにしない。
- Node REPL / node_repl / JavaScript REPL を使った。
- 作業報告が日本語ではない。
- 公式、既存記事、検索需要、読者混乱のいずれも確認せず候補化した。
- 競合用語集を丸写しした。
- 発見元URL、見えた文言、確認日、辞書セットURLが欠けた。
- `workflow_id`、`article_type`、`content_set` が欠けた。
- 候補をHubにもFiles fallbackにも保存していない。
- readbackしていない。
- 候補ゼロなのに候補なし理由と次回確認場所を保存していない。
- 用語辞書workflow以外の候補として保存した。
- 記事本文を作成・編集した。
- 候補をproduction_readyや制作済みとして扱った。
- 文字化けした候補や報告を残した。
- 競合情報やSNS情報を公式事実として断定した。
- 秘密情報、APIキー、認証情報を出力した。
## 24. 候補ゼロ時の処理
候補がゼロでも、作業は空白で終わらせない。確認した収集元、検索した語句、見たURL、候補にしなかった理由、次回見る場所、次回優先する検索語を保存する。候補ゼロの理由は「ありません」だけにしない。公式ページに新しい用語がなかったのか、既存候補と重複したのか、検索需要が弱かったのか、公式確認が足りなかったのかを分ける。
候補ゼロの場合もHubまたはFiles fallbackに候補なしレポートを保存し、readbackする。保存先がない場合はFAILである。
## 25. 出力形式
保存するレポートは日本語で、次の形を基本にする。
1. 実行日時。
2. 対象workflow。
3. 参照したマニュアル。
4. 確認した収集元。
5. 見つけた候補数。
6. 候補一覧。
7. 候補ごとの発見元URL。
8. 候補ごとの見えた文言。
9. 候補ごとの読者の迷い。
10. 候補ごとの公式確認状況。
11. 候補ごとの想定H3文脈。
12. 内部リンク候補。
13. 保留候補。
14. 対象外にした語。
15. 次回見る場所。
16. 保存先。
17. readback結果。
JSONで保存する場合も、日本語の説明フィールドを入れる。機械だけが読めるキーだけで終わらせない。人間が読んで、なぜ候補化されたか分かるようにする。
## 26. 最終readback
終了前に必ずreadbackする。readbackでは、保存先に候補が入っているか、候補数が合っているか、用語名が文字化けしていないか、辞書セットURLが入っているか、検査cronへ渡す付箋が入っているか、Node REPLを使っていないことを確認する。
readback結果は日本語で保存する。readbackできなかった場合は、保存失敗または確認失敗として扱い、完了にしない。Hubが読めない場合はFiles fallbackのreadbackを行い、Hub復旧後に戻す必要があることを保存する。
## 27. サボり防止の穴封じ
収集cronは「軽く見た」「候補なし」「公式に見当たらない」「次回確認」で逃げない。最低限、公式、既存OripaGate、検索需要、読者混乱、競合文脈のうち、どれを見たか、どれを見られなかったかを明記する。見られなかったものは理由と次回見る場所を保存する。調べたふり、保存したふり、readbackしたふりは禁止。
収集cronは、候補が1件でも出たら必ず候補レコードを作る。候補レコードを作らず、作業報告の文章だけで「候補あり」と書いて終わることは禁止。候補が薄い場合は候補ではなく保留候補として保存する。保留候補にも、保留理由、必要な追加確認、次回見る収集元を入れる。
収集cronは、候補を増やすために関係の薄い語を混ぜない。逆に、面倒だから候補をゼロにしない。候補化、保留、対象外の3種類に分けて保存する。対象外にした語も、なぜ対象外かを短く残す。これにより、次回の収集cronが同じ語を何度も拾って時間を失わないようにする。
## 28. 収集作業の最低実行チェック
毎回の収集では、最低でも次の確認を行う。
1. OripaGate専用HUBの用語辞書workflowを確認したか。
2. 用語辞書READMEまたはCOLLECTION_SOURCE_MANUALの関連部分を確認したか。
3. 公式FAQ、ヘルプ、規約、キャンペーン文言のどれかを確認したか。
4. 既存OripaGate記事の不足語を確認したか。
5. Search Console、関連検索、サジェストのどれかを確認したか。
6. SNSや読者投稿の混乱語を確認したか、確認できない場合は理由を残したか。
7. 競合用語集を見た場合、丸写し禁止メモを残したか。
8. 候補、保留、対象外を分けたか。
9. 保存先へ保存したか。
10. readbackしたか。
この10項目のうち実行できなかった項目がある場合、未実行理由を日本語で保存する。未実行理由がないまま完了にしない。
## 29. 候補ごとの深さ不足を防ぐ
候補1件につき、用語名だけで終わらない。最低でも、発見元URL、見えた文言、文脈、読者の迷い、想定カテゴリ、公式確認状況、検索需要の仮説、内部リンク候補、検査で確認すべき点を残す。1語だけの候補リスト、URLだけの候補リスト、検索語だけの候補リストはFAILである。
候補の意味を収集cronが長文で断定する必要はない。ただし、検査cronが何を調べればよいか分かるだけの材料は必ず渡す。検査cronに丸投げしない。たとえば「PSA10」なら、公式カード鑑定文脈、TCGでの使われ方、オリパ賞品表記で見かける場面、読者が誤解しやすい点、内部リンク候補を付箋する。
## 30. 収集元ごとの不足メモ
公式で見つからなかった語は、公式未確認と書く。SNSで見た語は、SNS文脈と書く。競合で見た語は、競合発見と書く。既存OripaGateで見た語は、既存記事不足と書く。Search Consoleやサジェストで見た語は、検索需要候補と書く。発見元の種類を混ぜると、検査cronが公式事実と読者文脈を誤るため、必ず分ける。
同じ語が複数の収集元で見つかった場合は、候補の優先度を上げてよい。ただし、複数ソースで見つかったことと、意味が確定したことは別である。意味の確定は検査cronの仕事である。
## 31. 次工程が動ける保存名
保存ファイル名、Hubレコード名、候補IDは、次工程が見つけられる名前にする。日付、workflow、role、候補種別を入れる。日本語名だけで検索できない保存名、ランダムな一時名、上書きされる名前は避ける。保存名の例は、`oripagate-terms-collection-YYYYMMDD`、`terms_candidate_psa10_YYYYMMDD`、`terms_collection_no_candidate_YYYYMMDD` のようにする。
同じ日の再実行や手動確認があっても、上書きで前回証跡を消さない。追記または別ファイルで保存し、どちらが新しいか分かるようにする。
## 32. 作業報告で必ず言うこと
作業報告には、候補数だけでなく、何を見たか、何を保存したか、どこに保存したか、readback結果、次に検査cronが見るべきことを入れる。候補がゼロなら、候補ゼロの理由と次回見る場所を入れる。作業報告に「完了しました」だけを書くことは禁止。
作業報告では、確認した収集元、保存した候補数、保存先、readback結果、次に検査cronが見るべき点、Node REPL未使用を明記する。
## 33. 終了条件
収集cronの終了条件は、候補を保存し、readbackし、検査cronへ渡す付箋を日本語で残すことである。候補がない場合も、候補なしレポートを保存し、readbackし、次回確認場所を残すことである。保存もreadbackもない作業報告だけでは完了ではない。
完了報告には、候補数、保存先、readback結果、次工程、Node REPL未使用、対象workflowの保存先、readback結果を日本語で書く。FAILがある場合は完了と書かず、FAIL名、理由、次に必要な対応を保存する。
PROMPT_ENDOripaGate【用語辞書】検査cron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】検査cron v0.1.78 詳細版
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.5
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 検査
- schedule intent: 1回/日
## 0. このcronの役割
これは OripaGate【用語辞書】の検査cronである。収集cronが保存した用語候補を確認し、terms-dictionaryとして制作へ進められるかを判断する。記事本文を書かない。WordPressへ投稿しない。公開しない。候補を制作済み扱いにしない。検査結果と制作へ渡す付箋を保存し、readbackする。
## 1. 作業ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、修正報告はすべて日本語で行う。検査保留理由、制作へ渡す付箋もすべて日本語で行う。
- 検査cronは1日1回だけ起動する前提で動く。1回で扱える範囲を超える候補は、次回検査メモへ回す。
- 秘密情報、APIキー、認証値、個人情報を出力しない。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\COLLECTION_SOURCE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\INSPECTION_REPORTING_GATE.md`
## 作業対象
作業対象は OripaGate【用語辞書】workflow のみ。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
## 2. 対象の固定情報
対象はOripaGateの用語辞書である。通常評価記事、キャンペーン記事、ランキング記事、比較記事ではない。公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` とする。検査結果保存時には、必ず `workflow_id=oripagate-terms-dictionary-ja`、`article_type=terms-dictionary`、`content_set=oripagate_terms_dictionary`、`dictionary_set_url=https://oripagate.jp/directory-collection/oripa-terms/` を残す。
terms-dictionaryで扱う候補は、オンラインオリパ、TCG、ガチャ、ポイント、発送、支払い、本人確認、SMS認証、ログイン、キャンペーン、当選、在庫、封入、還元、買取、カード状態、レアリティ、配送、退会、規約、特典、抽選方式など、OripaGate読者が理解に迷いやすい言葉である。検査cronは、その語が用語辞書として扱うべき語か、別記事タイプへ回すべき語か、保留すべき語かを分ける。
## 3. 起動時に確認するもの
起動したら、OripaGate専用HUBの `agent_pack` で `site_id=oripagate`、`workflow_id=oripagate-terms-dictionary-ja` の最新Rules、Manuals、Gates、References、Work Queueを確認する。確認した結果は日本語で保存する。Hubが読めない場合は、読めない理由を保存し、Files fallbackに検査メモを残す。Hubが読めないのに読めたふりをしない。
次に、ローカルのOripaGate用語辞書マニュアルを参照する。参照対象は `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md` と `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\COLLECTION_SOURCE_MANUAL.md` の用語辞書関連部分である。読む必要がある箇所だけを確認し、検査結果へ反映する。
## 4. 入力候補の取り扱い
検査cronは、収集cronが保存した候補、Hub Work Queue、Files fallback、候補なしレポート、保留候補を確認する。候補がない場合も、単に「対象なし」で終わらない。収集元、候補なし理由、次回確認場所、収集cronの保存先を確認し、検査側として「検査対象なし」のreadbackを保存する。
候補が多い場合は、1回の検査で1〜15件までを扱う。16件以上ある場合は、優先度の高い候補から15件まで検査し、残りは次回検査候補として保存する。候補が多いことを理由に検査を中止しない。逆に、薄い確認で大量にproduction_readyへ流さない。
## 5. 検査cronが決めること
検査cronは、各候補について次のどれかに分類する。
1. production_ready: 制作cronへ渡せるだけの根拠、検索意図、構成案、内部リンク候補、カテゴリ確認、slug案、未確認点が揃っている。
2. inspection_hold: 候補として価値はあるが、公式確認、検索需要、カテゴリ、重複、内部リンク候補のどれかが足りない。
3. duplicate_or_merge: 既存用語や既存記事と重複し、統合または内部リンク対応が適切。
4. out_of_scope: 用語辞書ではなく、評価記事、キャンペーン記事、トレカ辞書、他記事タイプ、またはOripaGate対象外。
5. rejected: 根拠が弱い、競合にしかない、公式確認不能、読者需要が弱い、リスクが高い。
検査cronはproduction_readyを安易に出さない。production_readyは制作可能という意味であり、公開済みや品質PASSではない。production_readyにする場合も、制作cronが迷わず本文を作れるだけの付箋を必ず保存する。
## 6. サーチコンパス必須
検査は必ずサーチコンパスを使う。サーチコンパスなし、結果保存なし、readbackなしは即FAIL。サーチコンパスでは、主KW、共起語、関連語、KW出現率、検索意図、読者が誤解しやすい点、別表記、関連用語、内部リンク候補、参照URLを調べる。
サーチコンパスを使った結果は、候補ごとに保存する。保存内容には、実行日、対象語、主KW、関連KW、共起語、出現率の見方、検索意図、SERPで見えた傾向、公式確認が必要な点、読者が期待する答え、制作時に入れるべき見出し、避けるべき断定を入れる。
## 7. サーチコンパスで見る検索語
候補語そのものだけでなく、意味を調べる形、使い方を調べる形、注意点を調べる形も見る。たとえば `○○とは`、`○○ 意味`、`○○ 使い方`、`○○ オリパ`、`○○ TCG`、`○○ 注意点`、`○○ いつ`、`○○ 反映されない`、`○○ 条件`、`○○ 期限`、`○○ 認証` のように、読者が実際に検索しそうな形を確認する。
検索語の例は、`オリパ 天井とは`、`オリパ ラストワンとは`、`オリパ SMS認証`、`オリパ ポイント還元`、`オリパ 発送 いつ`、`PSA10 意味`、`TCG PSAとは`、`カード 状態 A B C`、`オリパ 還元率 意味` などである。実際には候補語に合わせて調整し、検索語を保存する。
## 8. 共起語・関連語・KW出現率
共起語は、本文構成に必要な周辺語として扱う。関連語は、内部リンク候補やQ&A候補として扱う。KW出現率は、制作時に用語が不自然に過剰にならないように使う。検査cronは、共起語と関連語をただ列挙するだけで終わらない。どのH2/H3で使うべきか、どの語は内部リンク候補にするか、どの語は断定禁止にするかを付箋する。
KW出現率は、数値だけを保存して終わらない。検索意図に対して、その用語をどれくらい自然に使うべきか、同義語や表記ゆれをどの程度混ぜるべきかを制作へ渡す。機械的にキーワードを詰め込む指示をしない。
## 9. 公式確認
候補語の意味や条件が公式で確認できる場合は、公式URL、ページ名、確認日、見えた文言、文脈を保存する。公式FAQ、ヘルプ、利用規約、支払いページ、発送ページ、ポイントページ、当選ページ、退会ページ、本人確認ページ、SMS認証ページ、キャンペーン告知、公式SNSを分ける。
公式で確認できない語は、公式未確認として保存する。SNSや競合や検索結果だけで公式事実として断定しない。公式未確認でも読者の混乱が強い語は保留またはproduction_readyにできる場合があるが、その場合は制作へ「公式未確認のため断定禁止」と明記する。
## 10. 第三者情報の扱い
比較サイト、情報サイト、ブログ、まとめ記事、SNS投稿、検索結果スニペットは、読者の迷いや検索意図を知るために使う。第三者情報は公式事実として断定しない。発見元URL、見えた文言、確認日、公式再確認状況、未確認点を保存する。
競合用語集は発見と文脈確認だけに使う。丸写しは禁止。競合で見た見出し、説明順、表現をそのまま制作へ渡さない。OripaGateでは、読者が自然に理解できる構成へ作り直す。
## 11. 重複・統合確認
候補をproduction_readyへ回す前に、既存OripaGate公開記事、terms-dictionary、directory collection、Hub素材、Work Queue、Files fallbackを確認し、同じ用語が存在しないか見る。完全一致だけでなく、表記ゆれ、カタカナ、英字、略称、漢字違いも確認する。
重複が見つかった場合は、既存URL、既存タイトル、重複度、統合候補、別記事にする理由、内部リンク候補を保存する。重複しているのに新規production_readyとして流すのは禁止。別記事にする場合は、読者の検索意図や文脈が明確に違う理由を保存する。
## 12. カテゴリ確認とreadback
公式主機能を確認せずにWPカテゴリを選ばない。主機能と違うWPカテゴリ、曖昧カテゴリへの推測投入、カテゴリreadback未確認は即FAIL。対象はterms-dictionaryであり、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
ただし、候補語が実はトレカ辞書、評価記事、キャンペーン記事、別ディレクトリの対象である可能性がある場合は、推測でterms-dictionaryへ入れない。カテゴリ迷いとして保存し、検査保留にする。制作へ渡す場合は、カテゴリ確認済み、辞書セット確認済み、readback済みであることを付箋に入れる。
## 13. 公開URL・slug案の禁止事項
公開URLやslug案に年月日や日付を入れることは禁止。`20260611`、`2026-06-11`、`2026/06/11`、`2026年6月11日`、`0611`、`-2026`、`-202606` のような日付・年月・年月日を含むslug案はFAIL。terms-dictionaryは長期的に読まれる用語辞書であり、日付入りURLにしない。
検査cronが制作へ渡すslug案は、用語を表す安定した英数字slugにする。例として、`oripa-ceiling`、`tcg-psa10`、`oripa-point-return` のように、日付を含まない形にする。キャンペーン由来の用語でも、公開URLには日付を入れない。日付入りslug案を見つけた場合は、制作へ渡さず、slug修正必須として保存する。
## 14. H3文脈ルール
`H3 【○○での使われ方】` の○○は固定ではない。用語に合わせて、`H3 TCGでの使われ方`、`H3 オンラインオリパでの使われ方`、`H3 発送での使われ方`、`H3 ポイントでの使われ方`、`H3 ガチャでの使われ方`、`H3 買取での使われ方` など、業界内で自然な文脈を選ぶ。固定でオンラインオリパにしない。
検査cronは、候補語ごとにどの文脈見出しが自然かを制作へ渡す。TCG用語ならTCG、配送用語なら発送、支払い用語なら決済、ポイント用語ならポイント、キャンペーン条件ならキャンペーン文脈を選ぶ。見出しが不自然な場合は、制作後にAIっぽい文章や硬い文章になりやすいため、検査段階で防ぐ。
## 15. 制作構成付箋
production_readyへ回す場合は、制作cronが迷わないように構成付箋を保存する。最低限、H1案、SEOタイトル候補、リード文方針、H2/H3構成、関連用語、内部リンク候補3件以上、辞書プラグイン基本情報表の項目、Q&A候補、出典URL、未確認点、断定禁止点を入れる。
辞書プラグイン基本情報表の項目は、制作cronが後から思いつきで決めるものではない。検査cronが、oripa-termsの12フィールドである `term_name`、`reading`、`aliases`、`term_category`、`one_line_meaning`、`used_in`、`related_genres`、`check_points`、`risk_note`、`related_terms`、`related_dictionary_links`、`checked_at` の中身を制作付箋として保存する。制作cronはこの付箋をもとにプラグイン基本情報欄へ入力する。
基本構成は、リード文 → H2 用語解説 → H3 文脈別の使われ方 → H3 見かける場面 → H3 注意点・誤解 → H3 使用例 → H2 関連用語・内部リンク → H2 まとめ → H2 Q&A 5件以上 → H2 用語に関する辞書プラグイン基本情報である。検査cronはこの構成を制作へ渡すが、用語によって自然な調整が必要な場合は理由を付箋する。
## 16. SEOタイトルとH1案
H1は用語名のみ。SEOタイトルは「○○とは」「○○の意味」「○○の使われ方」など複数パターンから、検索者が実際に使いそうなものを候補として保存する。SEOタイトルとH1を同じにする必要はない。通常評価記事のSEO形式を使わない。
検査cronは、SEOタイトル候補を裸の用語名だけにしない。H1は用語名のみでよいが、SEOタイトルは検索流入を取るために「○○とは」「○○って何」「○○の意味」「○○の使い方」「○○は何に使う」など、検索者が入力する疑問形・意味確認形を必ず含める。候補3案のうち最低2案は「とは」「って何」「意味」のいずれかを含める。採用候補として制作へ渡す最優先SEOタイトルにも、「とは」「って何」「意味」のいずれかを入れる。`3Dセキュア` や `追跡番号` のような用語名だけのSEOタイトルは、H1と区別できていないため制作へ渡さない。
SEOタイトル候補には、日付や年月を入れない。用語辞書は短期ニュースではない。検索意図に合う自然なタイトルにし、釣りタイトル、誇張、断定しすぎる表現を避ける。
## 17. リード文方針
制作へ渡すリード文方針は、300字以内で、この記事がどの用語について、何を理解できる記事なのかを自然に導入するものにする。検査cronは本文を書かないが、読者が最初に知りたいこと、誤解しやすいこと、公式確認が必要なことをリード方針として渡す。
リード方針にHub、cron、task、agent_pack、quality gate、production_readyなど内部語を入れない。公開本文に内部語が出る原因になるため、制作へ渡す付箋でも公開文言と内部メモを分ける。
## 18. 内部リンク候補
内部リンク候補は最低3件を目指す。候補が3件未満の場合は、見つかった分と不足理由を保存し、production_readyにするか保留にするかを判断する。内部リンクは本文中にばらけさせる必要があるため、どのH2付近で使えるかも付箋する。
アンカーテキストは自然な日本語にする。別辞書セットの記事を内部リンクに使ってよい。preview、下書き、管理画面URL、404、非公開URLを候補にしない。最終HTTP 200確認は制作・高品質チェック側でも行うが、検査段階で明らかに不適切なURLは除外する。
## 19. 辞書プラグイン基本情報
terms-dictionary記事では、記事下の辞書プラグイン基本情報表が必須である。TOPの評価スコア表は原則不要。手書き表で代替することは禁止で即FAIL。検査cronは、制作へ渡す辞書プラグイン基本情報の項目案を保存する。
基本情報項目には、用語名、読み方、主な意味、使われる場面、関連語、注意点、関連カテゴリ、参照URLなどを候補として付箋する。実際の項目は用語に合わせるが、制作が手書き表に逃げないよう、辞書プラグイン基本情報表必須と明記する。
検査cronは、次の12フィールドを制作付箋として必ず作る。各フィールドは「入力値」「根拠URLまたは確認元」「未確認点」を分けて保存する。値を確認できない場合は空欄にせず、「確認できない理由」と「制作へ渡さず保留にするか、注意書き付きで扱えるか」を判断する。
- `term_name` | 用語名
- `reading` | 読み方
- `aliases` | 別名・表記ゆれ
- `term_category` | 用語カテゴリ
- `one_line_meaning` | ひとことで言うと
- `used_in` | よく使われる場面
- `related_genres` | 関連ジャンル
- `check_points` | 確認ポイント
- `risk_note` | 注意点・リスク
- `related_terms` | 関連用語
- `related_dictionary_links` | 関連辞書リンク
- `checked_at` | 確認日
`related_dictionary_links` は、制作前に使える内部リンク候補を3件以上探し、そのうち基本情報欄へ入れる関連辞書リンク候補を分けて付箋する。別辞書セットの記事も内部リンクとして使えるが、最終的にHTTP 200確認が必要である。`checked_at` は検査日または最終確認日を入れる。古い確認日しかない場合は制作へ回さず、再確認事項として残す。
## 20. 公式主機能とカテゴリの迷い
候補語がオンラインオリパの利用用語なのか、TCGそのものの用語なのか、発送や決済の一般用語なのか、キャンペーン条件の用語なのかを確認する。主機能が違うのにterms-dictionaryへ入れると、カテゴリミスになる。迷った場合は保留にする。
カテゴリ迷いを保留にする場合は、迷ったカテゴリ候補、迷った理由、公式確認が必要なURL、次回見るべきページを保存する。曖昧なままproduction_readyへ流さない。
## 21. production_ready条件
production_readyへ回せるのは、次の条件を満たす候補だけである。
1. 用語として扱う価値がある。
2. 重複確認が済んでいる。
3. サーチコンパス結果が保存されている。
4. 主KW、共起語、関連語、KW出現率、検索意図が確認されている。
5. 公式確認状況が明記されている。
6. カテゴリと辞書セットが確認され、readbackされている。
7. 日付なしのslug案がある。
8. H1案、SEOタイトル候補、リード方針がある。
9. H2/H3構成案がある。
10. 内部リンク候補がある。
11. 辞書プラグイン基本情報表の項目案がある。
12. 未確認点と断定禁止点がある。
この条件が欠ける候補は、production_readyではなくinspection_holdにする。条件が欠けているのに制作へ渡すのは禁止。
## 22. inspection_hold条件
価値はあるが制作へ回すには足りない候補はinspection_holdにする。たとえば、公式確認が弱い、検索需要が薄い、内部リンク候補が足りない、カテゴリが曖昧、slug案が日付入りしかない、表記ゆれが整理できていない、既存記事との重複が疑わしい場合である。
inspection_holdには、保留理由、足りない情報、次に確認するURL、次回検索語、誰が見ても分かる再開条件を保存する。保留にしただけで終わらず、次回何をすればproduction_readyに近づくかを日本語で残す。
## 23. out_of_scope条件
候補が用語辞書ではなく評価記事、キャンペーン記事、トレカ辞書、ランキング、比較、別ディレクトリ領域に属する場合はout_of_scopeにする。out_of_scopeには、対象外理由、適切な記事タイプ候補、確認した根拠を保存する。
キャンペーン固有の名称や日付入りイベント名は、terms-dictionaryとして長期的に扱う価値があるかを検査する。価値が薄い場合はキャンペーン側や保留に回し、用語辞書へ無理に入れない。
## 24. rejected条件
公式確認不能、検索需要なし、読者の混乱なし、競合にしかない、SNSの噂だけ、誹謗中傷や個人情報を含む、OripaGate読者と関係が薄い候補はrejectedにする。rejectedにも理由を保存する。理由なしで削除しない。
rejectedにした語は、次回収集cronが同じ語を拾って迷わないように、対象外理由と確認済みソースを保存する。
## 25. 検査結果の保存項目
候補ごとに最低限、次の項目を保存する。
- inspection_id または一意に識別できる仮ID。
- candidate_id。
- 用語名。
- 表記ゆれ。
- 分類結果。
- 分類理由。
- 主KW。
- 共起語。
- 関連語。
- KW出現率メモ。
- 検索意図。
- 読者が誤解しやすい点。
- 公式確認状況。
- 公式URL。
- 第三者URL。
- 競合で見えた場合の丸写し禁止メモ。
- 既存OripaGate重複確認。
- WPカテゴリ確認。
- 辞書セット確認。
- カテゴリreadback結果。
- slug案。
- slugに日付が入っていない確認。
- H1案。
- SEOタイトル候補。
- リード文方針。
- H2/H3構成案。
- H3文脈案。
- 内部リンク候補3件以上。
- 辞書プラグイン基本情報表の項目案。
- Q&A候補。
- 未確認点。
- 断定禁止点。
- 制作cronへの注意。
- 確認日。
- 検査cron名。
保存項目が欠ける場合は、欠けた理由を保存する。重要項目が欠けたままproduction_readyへ進めない。
## 26. Hub保存とFiles fallback
検査結果はOripaGate専用HUBの用語辞書関連に保存する。Hub保存ができる場合はHubへ保存し、保存後にreadbackして内容が入っていることを確認する。Hub保存が失敗した場合は、`C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate` 配下のruntimeまたはcron_outputsにFiles fallbackとして保存する。
Files fallbackだけで終わる場合も、保存パス、保存内容、Hub保存失敗理由、次回Hubへ戻す必要があることを日本語で残す。Hub保存もFiles fallback保存もせず、作業報告だけで終わることは禁止。
## 27. readback必須
終了前に必ずreadbackする。readbackでは、保存先に検査結果が入っているか、候補数が合っているか、production_ready、inspection_hold、out_of_scope、rejectedの分類が合っているか、サーチコンパス結果が保存されているか、カテゴリreadbackがあるか、slugに日付が入っていないか、制作付箋が入っているかを確認する。
readback結果は日本語で保存する。readbackできなかった場合は、保存失敗または確認失敗として扱い、完了にしない。Hubが読めない場合はFiles fallbackのreadbackを行い、Hub復旧後に戻す必要があることを保存する。
## 28. 即FAIL
次のどれかに当てはまる場合は検査FAILとして保存し、完了扱いにしない。
- Node REPL / node_repl / JavaScript REPL を使った。
- 作業報告が日本語ではない。
- サーチコンパス未使用。
- サーチコンパス結果保存なし。
- サーチコンパスreadbackなし。
- 共起語、関連語、KW出現率、検索意図のいずれかが未確認。
- 公式主機能未確認のカテゴリ選択。
- 主機能と違うWPカテゴリ。
- 曖昧カテゴリへの推測投入。
- カテゴリreadback未確認。
- 制作構成付箋なし。
- slug案または公開URL案に年月日や日付が入っている。
- 日付入りslugを修正必須にせず制作へ渡した。
- 公式・第三者・競合・SNS情報を区別していない。
- 競合用語集を丸写しした。
- 重複確認なしでproduction_readyへ回した。
- 内部リンク候補なしでproduction_readyへ回した。
- 辞書プラグイン基本情報表の項目案なしでproduction_readyへ回した。
- 未確認点と断定禁止点なしでproduction_readyへ回した。
- 検査結果をHubにもFiles fallbackにも保存していない。
- readbackしていない。
- OripaGate以外のHUBや他記事タイプを触った。
- 用語辞書workflow以外の成果物として検査結果を保存した。
- 検査cronなのに記事本文を作成・編集した。
- 文字化けした候補や報告を残した。
## 29. サボり防止の穴封じ
検査cronは「サーチコンパスを見たことにする」「公式未確認のまま流す」「カテゴリをなんとなく選ぶ」「slug案を作らない」「内部リンク候補を後回しにする」「制作に丸投げする」で逃げない。production_readyにする場合は、制作cronがそのまま作業できるだけの材料を保存する。材料が足りない場合はinspection_holdにする。
検査cronは、候補ごとに最低実行チェックを行う。主KWを確認したか、共起語を確認したか、関連語を確認したか、KW出現率を見たか、検索意図を見たか、公式確認状況を書いたか、カテゴリreadbackをしたか、日付なしslug案を作ったか、H2/H3構成案を作ったか、内部リンク候補を入れたか、未確認点を書いたかを確認する。未実行項目がある場合は、未実行理由を保存する。
検査cronは、production_ready件数を増やすために薄い候補を通さない。逆に、面倒だからすべて保留にしない。候補ごとに根拠を見て、通す、保留、対象外、重複、却下を分ける。分類理由がない検査結果はFAILである。
## 30. 作業報告で必ず言うこと
作業報告には、検査対象数、production_ready数、保留数、対象外数、重複数、却下数、保存先、readback結果、サーチコンパス実行有無、カテゴリreadback有無、日付なしslug確認、次工程を入れる。候補がゼロなら、検査対象なしの理由と次回見る場所を入れる。
作業報告では、検査した候補数、分類結果、サーチコンパス確認結果、保存先、readback結果、制作cronへ渡す付箋、Node REPL未使用を明記する。
## 31. 終了条件
検査cronの終了条件は、検査結果を保存し、readbackし、production_readyまたは保留・対象外・重複・却下の分類と理由を日本語で残すことである。production_readyへ回す場合は、制作に必要な付箋を保存し、readbackする。対象外や保留の場合は、理由、再確認条件、次回見る場所を日本語で保存する。
保存もreadbackもない作業報告だけでは完了ではない。FAILがある場合は完了と書かず、FAIL名、理由、次に必要な対応を保存する。
PROMPT_ENDOripaGate【用語辞書】制作cron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】制作cron v0.1.78 詳細版
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.5
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 制作
- schedule intent: 1回/日
## 0. このcronの役割
これは OripaGate【用語辞書】の制作cronである。検査cronが `production_ready` として保存し、制作へ渡す付箋が揃っている用語だけを、OripaGateの `terms-dictionary` 記事として制作し、WordPressで公開し、公開後の機械GATEをFAIL 0件にしてからTASK8 handoffへつなぐ。収集、検査、品質判定、訂正専任作業を肩代わりしない。制作cronの仕事は、制作可能と判定された1件を正しい記事タイプ、正しいカテゴリ、正しい辞書セット、正しい構成、正しい文体、正しい装飾、正しい内部リンク、正しい公開証跡で記事にすることである。
制作cronは、用語候補を新しく集めない。サーチコンパスの調査を一からやり直して検査結果を上書きしない。検査付箋に不足がある場合は、勝手に補ったふりをせず、制作保留として保存する。制作cronは記事本文を書く役割なので、検査で未確認の公式情報、未確認のカテゴリ、未確認のslug、未確認の内部リンクを自分の推測だけで確定しない。必要情報が足りない場合は、足りない項目、なぜ制作できないか、どの工程に戻すべきかを日本語で保存する。
このcronは1日1回だけ起動する前提で動く。1日に複数回起動する前提で作業を分割しない。1回の起動で扱う制作対象は原則1記事とし、複数の `production_ready` がある場合は優先度、検査完了日時、内部リンク需要、読者の検索意図の明確さを見て1件を選ぶ。選ばなかった `production_ready` は未処理として残し、次回見る順番を日本語で保存する。
## 1. 絶対ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、制作保留理由、修正報告、次回確認事項はすべて日本語で行う。
- 外部の秘密情報、APIキー、認証値、個人情報を記事本文、作業報告、handoff、validator_result.jsonへ出力しない。
- `production_ready` ではない候補を制作しない。
- 検査付箋が読めない、文字化けしている、カテゴリが曖昧、サーチコンパス確認がない、内部リンク候補が不足している、公開slugに日付が入っている場合は、制作に進まず制作保留にする。
- preview保存、Hub Files保存、下書き保存、ローカル保存だけで制作完了にしない。
- 公開後の機械GATEでFAILが1件でもあれば、制作完了にしない。
- FAILが0件になるまで、公開後検証、修正、再検証、validator_result.json更新、readbackを繰り返す。
- FAIL 0件、公開URL HTTP 200、公開HTML本文測定、TASK8 handoff作成、TASK8 handoff readbackが揃ったときだけ制作完了とする。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。MD/GATEを読んだだけで満足せず、各GATEの必要条件を記事本文、公開設定、検証、handoffへ反映する。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\PRODUCTION_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ARTICLE_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\QUALITY_VALIDATOR_CONTRACT.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PRODUCTION_EVIDENCE_AND_SCORING_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PLAIN_STYLE_AND_QA_BOX_HOTFIX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\REFERENCE_STYLE_GATE.md`
## 2. 作業対象
作業対象は OripaGate【用語辞書】workflow のみである。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。通常評価記事、キャンペーン記事、ランキング記事、比較記事、トレカ辞書、ニュース記事として制作しない。
terms-dictionaryは通常記事ではなく、ディレクトリ・コアプラグインの用語辞書記事である。評価スコア表、口コミ評価の採点表、キャンペーンCTA、招待コード訴求、ランキング導線を主目的にしない。用語の意味、使われ方、見かける場面、注意点、誤解、使用例、関連語、Q&A、辞書プラグイン基本情報を中心にする。
制作対象の用語が、サービス名、キャンペーン名、ガチャ名、カード名、会社名、短期イベント名に近い場合は、検査付箋でterms-dictionaryに入れる理由が明記されているか確認する。理由が弱いまま制作しない。対象語が別記事タイプに寄っている場合は、制作保留にして理由を保存する。
## 3. 入力として受け取るもの
制作cronは、検査cronが保存した `production_ready` だけを入力にする。入力には最低限、用語名、読み、表記ゆれ、主KW、共起語、関連語、KW出現率メモ、検索意図、公式確認状況、第三者情報の扱い、カテゴリ確認、辞書セット確認、slug案、SEOタイトル案、H1案、リード文方針、H2/H3構成案、内部リンク候補、辞書プラグイン基本情報項目、未確認点、断定禁止点、公開前に確認すべき点が含まれている必要がある。
辞書プラグイン基本情報項目は、検査cronが付箋したoripa-termsの12フィールドを使う。制作cronが新しく項目を作って補うのではなく、検査付箋にある `term_name`、`reading`、`aliases`、`term_category`、`one_line_meaning`、`used_in`、`related_genres`、`check_points`、`risk_note`、`related_terms`、`related_dictionary_links`、`checked_at` の値を確認し、プラグイン基本情報欄へ入れる。
入力が不足している場合、制作cronは不足を自分の推測で埋めない。たとえば、共起語がない、関連語がない、KW出現率メモがない、カテゴリreadbackがない、slug案に日付が入っている、内部リンク候補が3件未満、公式確認状況が曖昧、辞書プラグイン基本情報の項目案がない、Q&A候補が弱い、H3文脈が用語に合っていない場合は、制作保留にする。制作保留には、足りない項目、制作できない理由、戻すべき工程、次に確認すべき内容を日本語で保存する。
検査付箋に12フィールドの値がそろっていない場合は、制作cronが本文で穴埋めして公開しない。`term_name`、`reading`、`aliases`、`term_category`、`one_line_meaning`、`used_in`、`related_genres`、`check_points`、`risk_note`、`related_terms`、`related_dictionary_links`、`checked_at` の不足項目名を日本語で列挙し、検査cronへ戻す。特に `related_dictionary_links` と `checked_at` は抜けやすいため、未入力なら制作保留にする。
検査付箋に「未確認」「公式再確認」「カテゴリ迷い」「内部リンク不足」「日付入りslug修正必須」「重複疑い」「別記事タイプ疑い」と書かれている場合、それを無視して公開しない。未確認点を記事本文で断定しない。断定できない情報は書かないか、注意文として公式確認が必要な表現にする。制作cronは読者向けの記事を作る役割であり、検査の弱い候補を無理に公開する役割ではない。
## 4. production_readyの選び方
複数の制作対象がある場合は、検査cronの判定日時が古いもの、内部リンク需要が高いもの、既存OripaGate記事で不足語として使いやすいもの、公式確認が済んでいるもの、検索意図が明確なものを優先する。ただし、優先度が高くても、必須項目が欠けているものは制作しない。優先度と制作可能性は別である。
制作対象を選んだら、選定理由を日本語で保存する。保存内容には、候補ID、用語名、検査結果ID、選んだ理由、選ばなかった制作対象がある場合はその残件数、次回見る順番を入れる。選定理由なしで記事制作に入らない。
## 5. H1とWordPressタイトル
H1は用語名のみである。WordPressタイトルとして表示されるH1には、余計な説明、記号、日付、ランキング表現、キャンペーン訴求、評価表現を入れない。たとえば用語が「天井」なら、H1は「天井」とする。「天井とは？オンラインオリパでの意味と注意点」のような説明付きタイトルをH1にしない。
本文内にH1を書かない。WordPressタイトル側がH1になるため、本文はリード文から始める。本文内に `<h1>` 相当の見出し、H1風の大見出し、H1と誤認される装飾を入れない。本文冒頭にH2から始めるのも避け、まず300字以内のリード文で読者を導入する。
H1案が検査付箋で用語名以外になっている場合は、用語名だけに修正する。用語名が表記ゆれを含む場合は、公式表記、検索需要、OripaGate内の表記統一を見て代表表記を決める。代表表記を決めた理由は制作メモへ残す。
## 6. SEOタイトル
SEOタイトルは、H1とは別に検索意図へ合わせて作る。基本パターンは「○○とは」「○○の意味」「○○の使われ方」「○○の注意点」「○○と関連語の違い」などである。用語を調べている人が実際に検索しそうな自然な日本語にする。
制作cronは、SEOタイトルを用語名だけで保存しない。H1は用語名のみだが、SEOタイトルは必ず検索語として成立する形にする。採用するSEOタイトルには「とは」「って何」「意味」のいずれかを入れる。必要に応じて「使い方」「注意点」「違い」を組み合わせてもよいが、用語名だけ、または `用語名 | OripaGate（オリパゲート）` のような裸タイトルはFAILである。
SEOタイトルは複数案を確認してから選ぶ。最低3案を作り、検査付箋の主KW、共起語、関連語、検索意図と合うものを採用する。例として、用語が「PSA10」なら「PSA10とは」「PSA10の意味とカード状態の見方」「PSA10はオンラインオリパでどう使われるか」のように、検索意図に合う候補を比べる。実記事では用語、文脈、読者の知りたいことに合わせて差し替える。
最低3案のうち、少なくとも2案は「とは」「って何」「意味」を含める。採用する1案が「使われ方」「注意点」中心になる場合でも、検索意図として「意味確認」が弱くならないようにする。迷った場合は「○○とは」「○○の意味」「○○って何」のどれかを含む案を優先する。
SEOタイトルに年月日、日付、公開日、キャンペーン日、短期イベント日を入れない。用語辞書は長期的に読まれる記事であり、URLやSEOタイトルを日付で古く見せない。誇張、煽り、断定しすぎ、公式未確認の効果表現も入れない。
## 7. 公開URLとslug
公開URLとslug案に年月日や日付を入れることは禁止である。`20260611`、`2026-06-11`、`2026/06/11`、`2026年6月11日`、`0611`、`-2026`、`-202606` のような年、年月、年月日、月日、公開日らしき数字を含むslug案はFAILである。
slugは、用語を表す安定した英数字またはローマ字にする。例として、`oripa-ceiling`、`tcg-psa10`、`oripa-point-return` のように、日付を含まず、用語内容が分かる形にする。実記事では用語に合わせて作る。日本語slugが許容される運用でも、文字化けやURLの扱いに不安がある場合は安定した英数字slugを優先する。
検査付箋に日付入りslugが残っている場合は、公開前に必ず修正する。slug修正をした場合は、元のslug案、修正後のslug、日付を外した理由、公開URLを制作メモへ保存する。日付入りslugのまま公開した場合は即FAILであり、公開後でも修正対象にする。
## 8. リード文
リード文は300字以内にする。リード文では、その用語が何を指し、読者がこの記事で何を理解できるのかを自然に導入する。メタ的に「この記事では候補元をもとに解説します」「このページは制作cronが作った記事です」のような内部事情を書かない。読者向けの自然文だけにする。
リード文は敬体で書く。「だ・である」調を混ぜない。硬すぎる説明、辞書を丸写ししたような無機質な文、AIが要約したような一般論は避ける。用語の意味が一文で伝わり、そのあとにオンラインオリパ、TCG、発送、ポイント、買取など、用語に合った文脈へ自然に入る形にする。
リード文には、黒太字＋黄色アンダーマーカーを1箇所以上使う。使いすぎない。リード文全体を装飾で埋めない。読者が最初に押さえるべき意味、注意点、誤解しやすい点のどれか1つに絞って装飾する。
## 9. 本文量
本文は2000文字以上必須である。本文量は公開HTMLから測定し、広告、ナビゲーション、関連記事、フッター、メニュー、パンくず、管理用文言を除いた記事本文として確認する。下書きHTML、previewだけの文字数、ローカル原稿だけの文字数で完了にしない。
2000文字を超えていても、同じ説明の繰り返し、薄い一般論、検索語の詰め込み、装飾だけで増やした文章はFAILである。用語解説、文脈別の使われ方、見かける場面、注意点・誤解、使用例、関連用語、Q&A、基本情報のそれぞれに意味がある本文にする。
文字数が不足した場合は、無理に長文化するのではなく、読者が迷いやすい具体例、公式確認が必要な条件、関連語との違い、内部リンク先の補足、Q&Aを増やして自然に補う。文字数だけを満たすための水増しは禁止である。
## 10. 基本構成
記事本文は次の流れを基本にする。用語に合わせて自然な補助見出しを足してよいが、必須要素を抜かない。
1. リード文。
2. H2 用語解説。
3. H3 業界内での使われ方。
4. H3 見かける場面。
5. H3 注意点・誤解。
6. H3 使用例。
7. H2 関連用語・内部リンク。
8. H2 まとめ。
9. H2 Q&A 5件以上。
10. H2 用語に関する辞書プラグイン基本情報。
最初のH2は「用語解説」とする。読者が最初に意味をつかめるようにするためである。H2「用語解説」の下では、意味を短く述べるだけで終わらず、読者が実際に見かける文脈へつなげる。
H2は2つ以上必須である。H3は5つ以上必須である。基本の4つのH3だけではH3数が足りないため、Q&Aの質問をH3にする、または用語に応じて「関連用語との違い」「初心者が間違えやすい点」「確認しておきたい条件」などの補助H3を自然に足す。H3数を満たすためだけの空見出しは禁止である。
## 11. H3 業界内での使われ方
「H3 ○○での使われ方」の○○は固定ではない。用語に合わせて、TCG、オンラインオリパ、発送、ポイント、ガチャ、買取、査定、本人確認、ログイン、キャンペーン、カード状態、鑑定など、業界内で自然な文脈を選ぶ。
TCG用語なら「TCGでの使われ方」、オンラインオリパの利用語なら「オンラインオリパでの使われ方」、発送関係なら「発送での使われ方」、ポイント関係なら「ポイントでの使われ方」、ガチャ関係なら「ガチャでの使われ方」、買取関係なら「買取での使われ方」のようにする。
検査付箋と違う文脈に変える場合は、なぜ変えたかを制作メモに残す。読者にとって自然な文脈を優先するが、検査結果を無視して勝手に記事タイプを変えない。
## 12. 見かける場面
H3「見かける場面」では、用語がどこで出てくるかを具体的に説明する。公式FAQ、ヘルプ、利用規約、ガチャ詳細、賞品一覧、ポイント説明、発送説明、キャンペーン文、ログイン画面、本人確認画面、買取ページ、既存OripaGate記事など、検査で確認済みの文脈を使う。
見かける場面を書くときは、未確認の公式事実を断定しない。第三者サイトやSNSで見えた文脈は、公式の説明とは分ける。記事本文では読者に混乱を与えない形に整理し、公式確認が必要な条件は断定しない。
「よく見ます」「多く使われます」だけで終わらせない。どのような画面、どのような説明、どのような注意書きで出てくるかを書く。読者がその用語に出会ったとき、何を確認すればよいかまでつなげる。
## 13. 注意点・誤解
H3「注意点・誤解」では、読者が間違えやすいポイントを必ず書く。用語の意味、条件、公式確認の必要性、似た言葉との違い、サービスごとの差、キャンペーン条件との混同、カード状態の見方、ポイント付与時期、発送時期、本人確認の範囲など、用語に合った注意点にする。
注意点には赤太字を使う。赤太字は危険、誤解、条件確認、公式確認が必要な箇所に限定する。赤太字を装飾目的だけで使わない。読者の不安を煽らず、確認すべきことが分かる表現にする。
注意点を書くときは、公式未確認の内容を断定しない。第三者情報、SNS情報、競合サイト情報をそのまま事実化しない。検査付箋に「公式未確認」とある場合は、本文では断定を避け、公式ページで条件を確認する必要があることを自然に書く。
## 14. 使用例
H3「使用例」では、読者が用語の使い方を理解できる短い例を入れる。例文は実際のサービス名、キャンペーン名、カード名を無理に入れない。公式確認が済んでいない具体名を使う場合は避ける。一般化した例で十分な場合は、自然な例文にする。
使用例は、用語の意味が分かるものにする。「この言葉はよく使われます」のような説明だけでは使用例にならない。たとえば「還元率」なら、ポイントや賞品価値の説明で見かける使い方を示す。「PSA10」なら、鑑定済みカードの状態や賞品表記で使われる例を示す。
使用例の文体も常体にする。会話調にしすぎない。例文を入れた場合は、例文と本文説明が混ざって読みにくくならないよう、短く整理する。
## 15. 関連用語・内部リンク
H2「関連用語・内部リンク」では、関連語を並べるだけでなく、読者が次に知ると理解が進む語を自然に案内する。内部リンクは最低3件必須である。内部リンクが3件未満なら即FAILであり、公開前に不足理由を解消する。どうしても3件見つからない場合は公開しない。
内部リンクは本文中にばらけさせる。1箇所に3件を固めない。H2「用語解説」付近、H2「関連用語・内部リンク」、Q&Aやまとめ付近など、読者の流れに合わせて分散させる。リンクのためだけに不自然な文を作らない。
アンカーテキストは自然な日本語にする。「こちら」「詳しくはこちら」「公式」「内部リンク」だけのアンカーは禁止である。用語の文脈が分かるアンカーにする。例として、「ポイント還元の考え方」「PSA10の意味」「発送目安を確認する場面」のように、リンク先の内容が分かる形にする。
別辞書セットで投稿されている記事を内部リンクに使ってよい。ただし、リンク先が読者の理解に役立つ場合だけにする。別辞書セットだから無理に入れるのではなく、関連語として自然に使える記事を選ぶ。
内部リンク先は公開URLであることを確認する。preview、下書き、管理画面URL、404、リダイレクト先が不明なURL、非公開URLは使わない。公開後にもHTTP 200を確認し、readbackへURL、アンカーテキスト、配置箇所を残す。
## 16. まとめ
H2「まとめ」では、用語の意味、使われる場面、注意点を短く整理する。まとめで新しい未確認情報を出さない。本文で説明していない条件や断定をまとめだけに入れない。
まとめは箇条書きにしてもよいが、機械的な羅列にしない。読者が最後に押さえるべきことを自然な日本語でまとめる。✅を使う場合は、まとめの確認ポイントとして使うとよい。ただし、✅を多用して全体が装飾過多にならないようにする。
## 17. Q&A
H2「Q&A」は5件以上必須である。質問は読者が実際に検索しそうなもの、検査付箋の検索意図に合うもの、本文で補足すると理解が進むものにする。Q&Aは記事本文の水増しではない。本文の要点を別角度から整理する。
Q&Aの質問は、H3として扱ってよい。H3数が不足しないよう、Q&Aの質問見出しをH3にする運用を基本にする。Q&A 5件をH3にすれば、H3数の最低条件を自然に満たせる。ただし、同じ質問を言い換えただけの5件は禁止である。
回答は短すぎない。1問あたり、読者が次に何を確認すればよいか分かる程度に書く。未確認の公式条件は断定しない。サービスごとに違う条件は「各サービスの公式ページで確認する必要がある」と自然に案内する。
Q&Aには、⚠️を1箇所以上使う。使う場所は、条件確認、誤解、公式確認が必要な回答に限定する。⚠️を装飾目的だけで置かない。✅と⚠️の両方を記事内に使わない場合は即FAILである。
## 18. 用語に関する辞書プラグイン基本情報
H2「用語に関する辞書プラグイン基本情報」は記事下に必ず入れる。これはterms-dictionary記事の必須要素である。TOPの評価スコア表は原則不要であり、通常評価記事のスコア表で代替しない。
基本情報は、ディレクトリ・コアプラグインの用語辞書記事として扱う。手書き表で代替しない。手書きのHTML表、Markdown表、見た目だけの表、独自の表組みで代用した場合は即FAILである。辞書プラグインが求める基本情報欄、項目、保存形式に従う。
基本情報に入れる項目は、用語名、読み方、主な意味、使われる場面、関連語、注意点、参照した公式URLまたは確認元、公開カテゴリ、辞書セットなどを候補にする。実際の項目は検査付箋とプラグイン仕様に合わせる。空欄や仮置きのまま公開しない。
oripa-termsの辞書プラグイン基本情報では、次のフィールドキーを必ず埋める。日本語ラベルだけで代替しない。フィールドキー、値、確認根拠をそろえて保存する。
- `term_name` | 用語名
- `reading` | 読み方
- `aliases` | 別名・表記ゆれ
- `term_category` | 用語カテゴリ
- `one_line_meaning` | ひとことで言うと
- `used_in` | よく使われる場面
- `related_genres` | 関連ジャンル
- `check_points` | 確認ポイント
- `risk_note` | 注意点・リスク
- `related_terms` | 関連用語
- `related_dictionary_links` | 関連辞書リンク
- `checked_at` | 確認日
`term_name` は記事タイトルの用語名と一致させる。`reading` は読者が読める表記にする。`aliases` は略称、英字、カタカナ、表記ゆれを入れる。該当がない場合も空欄放置にせず「現時点で主要な別名は確認できない」のように確認結果として書く。`term_category` は公式主機能と用語の文脈に合うカテゴリを入れ、曖昧なカテゴリへ推測投入しない。`one_line_meaning` は読者が一読で意味をつかめる一文にする。`used_in` はオンラインオリパ、TCG、ガチャ、発送、決済、キャンペーンなど、実際に見かける場面を入れる。`related_genres` は関連ジャンルを自然に整理する。`check_points` は読者が確認すべき条件や見落としやすい点を入れる。`risk_note` は誤解、損失、規約、期限、条件、対象外などの注意点を入れる。`related_terms` は本文内の関連用語と対応させる。`related_dictionary_links` は関連辞書記事のURLまたは内部リンク候補を入れ、最終的にHTTP 200を確認する。`checked_at` は確認日を入れ、古い確認日のまま公開しない。
上記12フィールドのうち1つでも欠けたまま公開した場合はFAILである。手書き表、Markdown表、HTML表、本文中の箇条書きだけで代替した場合もFAILである。辞書プラグインの基本情報欄として保存され、公開後に読者へ表示される状態を確認する。
辞書プラグイン基本情報のreadbackを行う。公開後に基本情報欄が表示されているか、手書き表になっていないか、用語名や読みが文字化けしていないか、カテゴリと辞書セットが正しいかを確認する。
## 19. 文体
記事本文は敬体で書く。「だ・である」調を混ぜない。読者に向けた自然文にする。硬い文章、官僚的な文、社内メモのような文、AIが作ったような抽象文、メタ表現が1つでもあれば即FAILである。
禁止するメタ表現の例は、「候補元」「導線」「カテゴリ」「workflow」「production_ready」「cron」「Hub」「GATE」「TASK」「validator」「検査付箋」「制作メモ」などである。これらは作業報告や制作メモには必要だが、公開記事本文に出してはいけない。読者には内部工程を見せない。
読者向け本文では、「この用語はオンラインオリパやTCGでこういう場面に出てくる」「ここを誤解しやすい」「サービスごとに条件が違うため確認が必要だ」のように、自然な説明にする。「本記事では」「以下では」も多用しない。どうしても導入で使う場合も、機械的にならないようにする。
## 20. 公式情報と断定
公式確認が済んでいる内容は、確認元の範囲内で書く。公式が明記していないことを、一般論や第三者情報だけで断定しない。サービスごとに違う条件は、共通ルールのように書かない。
第三者サイト、比較サイト、ブログ、SNS、検索結果スニペットの情報は、読者の疑問や検索意図を知る材料として扱う。公式事実として断定しない。検査付箋に第三者情報として保存されている内容を本文で使う場合は、公式確認済みの事実と混ぜない。
公式URLを参照する場合は、読者が確認すべき公式ページとして自然に案内する。用語辞書記事では、キャンペーン詳細URLをCTA先にするような作り方をしない。公式確認が必要な条件は、公式TOP、ヘルプ、FAQ、利用規約、キャンペーンページなど、検査付箋の確認元に合わせて扱う。
## 21. カテゴリと辞書セット
公開カテゴリは `https://oripagate.jp/terms-dictionary/` である。辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。制作前に、検査付箋でカテゴリと辞書セットが確認済みか見る。確認済みでなければ制作しない。
用語の主な機能や文脈を確認せずにカテゴリを選ばない。たとえば、カード名、サービス名、キャンペーン名、買取用語、発送用語、TCG用語など、terms-dictionaryに入れる理由が曖昧な場合は、推測で公開カテゴリへ入れない。曖昧カテゴリへの推測投入は即FAILである。
カテゴリreadbackは必須である。公開前または公開直後に、記事がterms-dictionaryとして扱われているか、辞書セット `oripa-terms` に入っているかを確認する。カテゴリreadbackが未確認なら即FAILであり、TASK8へ進めない。
## 22. 装飾の黄金比率
装飾は、評価評判記事で使っている黄金比率を用語辞書向けに適用する。最低基準は、黒太字6、赤太字2、黒太字＋黄色アンダーマーカー4である。比率としては黒太字:赤太字:黄色アンダーマーカーをおおむね3:1:2で維持する。2000文字台の記事では最低数を満たし、3000文字を超える場合は本文量に合わせて同じ比率で増やす。
黒太字は、読者が意味を押さえるべき語句、重要な確認点、関連語の要点に使う。赤太字は、誤解、注意、公式確認が必要な条件、日付や期限の誤認などに限定する。黒太字＋黄色アンダーマーカーは、記事の中で最も押さえるべき意味、使われ方、注意点、まとめの要点に使う。
リード文内には黒太字＋黄色アンダーマーカーを1箇所以上入れる。✅と⚠️を必ず使う。装飾BOXを1つ以上使う。装飾BOXは、用語の要点、注意点、参加前チェック、公式確認が必要な条件など、読者にとって意味のある内容に使う。装飾のためだけの空BOXは禁止である。
装飾過多もFAILである。1段落に装飾を詰め込みすぎない。赤太字を連発して不安を煽らない。黄色アンダーマーカーを連続させて、何が重要か分からない状態にしない。装飾の数だけでなく、配置と意味を確認する。
## 23. 装飾BOX
装飾BOXは1つ以上必須である。用語辞書記事では、キャンペーン概要BOXではなく、用語の要点、誤解しやすい点、確認しておきたい条件などに使う。たとえば、要点整理には `information-box`、条件確認や注意点には `blank-box` を使う候補にする。ただし、実際に使うBOXはOripaGateの既存装飾ルールに合わせる。
BOX内にも常体を使う。BOX内だけ「です・ます」にしない。BOX内に内部工程名を入れない。BOX内の文章が記事本文と重複しすぎる場合は、要点だけに絞る。
BOXが1つもない場合は即FAILである。BOXが多すぎて本文が読みにくい場合もFAILである。1記事に1〜2個を基本にし、用語の難しさに応じて調整する。
## 24. ✅と⚠️
✅と⚠️は必ず使う。✅は、読者が押さえるべき確認済みの要点、まとめ、チェックポイントに使う。⚠️は、誤解、条件確認、サービスごとの差、公式確認が必要な点に使う。どちらも文脈なく置かない。
✅/⚠️が未使用なら即FAILである。文字化けして記号が壊れている場合もFAILである。公開HTMLで正しく表示されているか確認する。装飾記号が本文の邪魔になる場合は、文頭に1つずつ自然に置く。
## 25. 画像と不要要素
用語辞書記事は、原則として通常評価記事のTOPスコア表を使わない。評価評判記事のテンプレートをそのまま流用しない。キャンペーン記事のCTA、ランキング記事の比較表、サービスレビュー用のスコア表を入れない。
必要な画像やスクリーンショットがある場合でも、公式確認や引用ルールに反しない範囲にする。用語の理解に不要な画像で記事を重くしない。画像を入れる場合は、alt、出典、表示崩れ、本文との関係を確認する。ただし、画像がないこと自体をFAILにしない。
## 26. 内部リンクのHTTP確認
内部リンクは最低3件である。リンク先は公開URLとしてHTTP 200を確認する。リンク先がリダイレクトする場合は、最終到達URLが読者に見せてよい公開ページか確認する。404、403、非公開、プレビュー、管理画面、下書き、ログイン必須URLは使わない。
HTTP 200確認は公開前に候補として行い、公開後にも記事HTML内のリンクとして確認する。公開後HTMLにリンクが入っていない、アンカーが違う、リンクが固まっている、1件でも404がある場合はFAILである。
内部リンクのreadbackには、リンク先URL、アンカーテキスト、配置した見出し付近、HTTPステータス、別辞書セットを使った場合はその理由を保存する。
## 27. 外部リンクと参照
外部リンクは、公式確認や読者が条件を確認するために必要な場合だけ使う。公式、FAQ、ヘルプ、利用規約、キャンペーンページ、カード鑑定やTCG文脈の公式資料など、検査付箋で確認済みのものを優先する。
第三者サイトを外部リンクとして出す場合は、公式事実の根拠にしない。競合記事を出典のように扱わない。SNS投稿や個人投稿を過度に引用しない。個人情報や誹謗中傷を含む投稿は使わない。
外部リンクのreadbackには、URL、リンク目的、公式確認済みか、第三者情報かを保存する。外部リンクが不要な用語なら無理に入れない。
## 28. Q&Aの品質
Q&Aは5件以上である。各質問は具体的でなければならない。たとえば「○○とは何ですか」「○○はどこで見かけますか」「○○と△△は違いますか」「○○で注意する点はありますか」「○○はサービスごとに違いますか」のように、読者が実際に知りたい形にする。
回答は本文のコピーではなく、短く再整理する。回答だけ読んでも意味が通じるようにする。Q&Aの中で新しい断定をしない。公式確認が必要な条件は、各サービスの公式ページで確認する必要があると自然に書く。
Q&AにFAQ構造化データを入れる運用がある場合は、既存のOripaGateルールに従う。JSON-LDが必要な場合は、文字化け、重複、本文と不一致がないか確認する。FAQ構造化データの有無を勝手に判断できない場合は、制作メモへ残し、高品質チェックへ渡す。
## 29. 禁止する記事化
通常評価記事として書かない。評価点、口コミ点数、ランキング、メリット・デメリット採点、総合評価、キャンペーン訴求を主目的にしない。キャンペーン記事として書かない。招待コード、限定特典、開催期間、終了日を中心にした記事にしない。
用語辞書なのに、サービスレビュー、カード買取レビュー、キャンペーン紹介、ガチャ紹介、公式誘導だけの記事になった場合はFAILである。用語の意味を理解する記事であることを最初から最後まで保つ。
記事本文に「候補」「検査」「制作」「GATE」「readback」「TASK8」「validator_result.json」「Hub」などの内部語を出さない。公開記事本文に内部語が1つでも残ればFAILである。
## 30. 文字化け
公開記事本文、タイトル、slug、カテゴリ名、辞書プラグイン基本情報、Q&A、装飾記号、内部リンクアンカー、validator_result.json、handoffに文字化けがないことを確認する。文字化けが1箇所でもあればFAILである。
日本語の句読点、カタカナ、英字、数字、記号が崩れていないかを見る。特に✅、⚠️、太字、黄色マーカー、赤太字、BOXクラス、辞書プラグイン欄は崩れやすいため、公開HTMLで確認する。
文字化けを見つけた場合は、文字化け箇所、原因の仮説、修正内容、再確認結果を日本語で保存する。文字化けを残したままTASK8へ進めない。
## 31. 公開前セルフチェック
公開前に次の項目を確認する。1つでも未確認なら公開しない。
1. 対象が `production_ready` である。
2. 用語名が確定している。
3. H1は用語名のみである。
4. 本文内H1がない。
5. SEOタイトルが検索意図に合っている。
6. 公開URLとslugに年月日や日付が入っていない。
7. リード文が300字以内である。
8. 本文が2000文字以上になる見込みである。
9. H2が2つ以上ある。
10. H3が5つ以上ある。
11. H2「用語解説」が最初のH2である。
12. H3「○○での使われ方」が用語に合った文脈である。
13. H3「見かける場面」がある。
14. H3「注意点・誤解」がある。
15. H3「使用例」がある。
16. H2「関連用語・内部リンク」がある。
17. H2「まとめ」がある。
18. H2「Q&A」があり、Q&Aが5件以上ある。
19. H2「用語に関する辞書プラグイン基本情報」がある。
20. 辞書プラグイン基本情報を手書き表で代替していない。
21. 内部リンクが3件以上ある。
22. 内部リンクが本文中にばらけている。
23. 内部リンクのアンカーが自然な日本語である。
24. 装飾の黄金比率を満たしている。
25. ✅と⚠️を使っている。
26. 装飾BOXが1つ以上ある。
27. 常体で統一されている。
28. 硬い文章、メタ表現、AIっぽい文章がない。
29. 公式未確認情報を断定していない。
30. カテゴリと辞書セットを確認した。
31. カテゴリreadbackの準備がある。
32. 文字化けがない。
## 32. 公開
公開はWordPressで行う。下書き、preview、ローカル原稿、Hub Files保存だけで完了にしない。公開時には、カテゴリ、辞書セット、slug、SEOタイトル、本文、辞書プラグイン基本情報、内部リンク、外部リンク、装飾、Q&A、公開ステータスを確認する。
公開後、公開URLへアクセスしてHTTP 200を確認する。HTTP 200でない場合は制作完了にしない。公開URLが日付入りになっていないか再確認する。公開URLに年月日や日付が入っていた場合は即FAILである。
公開後HTMLを取得し、本文測定を行う。本文内H1、H2数、H3数、Q&A数、内部リンク数、装飾数、✅/⚠️、BOX、辞書プラグイン基本情報、文字化け、メタ表現を確認する。公開画面で見えない要素は、原稿にあっても未達として扱う。
## 33. validator_result.json
公開後に機械GATEへかけ、`validator_result.json` を更新する。validator_result.jsonには、公開URL、記事ID、用語名、検査元ID、本文文字数、H2数、H3数、Q&A数、内部リンク数、内部リンクHTTP結果、装飾数、✅/⚠️使用、BOX数、カテゴリreadback、辞書セットreadback、slug確認、本文内H1確認、文字化け確認、FAIL一覧、修正履歴、最終判定を入れる。
validator_result.jsonは、日本語で読めるFAIL理由を含める。機械的なコードだけ、英語だけ、空配列だけで済ませない。FAILがある場合は、FAIL名、該当箇所、理由、修正方針、再検証結果を保存する。
validator_result.jsonを更新せずにTASK8へ進めない。validator_result.jsonが古い、公開URLと一致していない、記事IDが違う、FAILが残っている、readbackしていない場合は完了ではない。
## 34. 公開後機械GATE
公開後も機械GATEにかける。公開前の自己チェックだけでは足りない。公開後HTMLに反映された状態で、本文量、構成、装飾、内部リンク、カテゴリ、辞書セット、slug、文字化け、メタ表現、AIっぽさ、公式未確認断定、辞書プラグイン基本情報を確認する。
FAILが1件でもあればやり直す。やり直すときは、関連マニュアルとGATEを読み直し、指摘された箇所を全て潰したかを自分の感覚だけで判断しない。再度機械GATEを通す。FAIL 0件になるまで繰り返す。FAIL 0件になったあとだけ次タスクに繋ぐ。
制作cronが自分で直せる本文、装飾、slug、カテゴリ、内部リンク、基本情報、文字化けは修正して再検証する。修正範囲が制作cronで安全に扱えない場合は、訂正cronへ渡すための修正指示を保存する。ただし、FAILを残したまま制作完了とは書かない。
## 35. 即FAIL
次のどれかに当てはまる場合は制作FAILであり、完了扱いにしない。
- Node REPL / node_repl / JavaScript REPL を使った。
- 作業報告、readback、handoff、FAIL理由が日本語ではない。
- `production_ready` ではない候補を制作した。
- 検査付箋を読まずに制作した。
- サーチコンパス確認結果がない候補を制作した。
- 共起語、関連語、KW出現率、検索意図の付箋がない候補を制作した。
- H1が用語名のみではない。
- 本文内H1がある。
- SEOタイトルが検索意図に合っていない。
- 公開URLまたはslugに年月日や日付が入っている。
- リード文が300字を超えている。
- リード文が、どの用語について何を理解できる記事かを導入していない。
- 本文が2000文字未満である。
- H2が2つ未満である。
- H3が5つ未満である。
- 最初のH2が「用語解説」ではない。
- H3「○○での使われ方」が用語に合わない。
- H3「見かける場面」がない。
- H3「注意点・誤解」がない。
- H3「使用例」がない。
- H2「関連用語・内部リンク」がない。
- H2「まとめ」がない。
- H2「Q&A」がない、またはQ&Aが5件未満である。
- H2「用語に関する辞書プラグイン基本情報」がない。
- 辞書プラグイン基本情報を手書き表で代替した。
- TOPの評価スコア表を通常評価記事のように使った。
- 内部リンクが3件未満である。
- 内部リンクが1箇所に固まっている。
- 内部リンクアンカーが不自然、または「こちら」だけである。
- 内部リンクHTTP 200を確認していない。
- 別辞書セットのリンクを使った理由が本文上自然ではない。
- 黒太字、赤太字、黒太字＋黄色アンダーマーカーの黄金比率を満たしていない。
- ✅または⚠️が未使用である。
- 装飾BOXが1つもない。
- 装飾過多で読みにくい。
- 常体で統一されていない。
- 硬い文章、メタ表現、AIっぽい文章が1つでもある。
- 公式主機能または用語の主文脈を確認せずカテゴリを選んだ。
- 主文脈と違うWPカテゴリへ入れた。
- 曖昧カテゴリへ推測で入れた。
- カテゴリreadbackが未確認である。
- 辞書セットreadbackが未確認である。
- 公式未確認の内容を断定した。
- 第三者情報やSNS情報を公式事実として書いた。
- 文字化けがある。
- 公開URL HTTP 200を確認していない。
- 公開HTMLで本文測定をしていない。
- validator_result.jsonを更新していない。
- validator_result.jsonにFAILが残っている。
- TASK8 handoffを作成していない。
- TASK8 handoff readbackをしていない。
## 36. 制作保留
制作できない場合は、作業を空白で終わらせない。制作保留として保存する。制作保留には、候補ID、用語名、保留理由、不足している検査付箋、戻すべき工程、次に確認すべき内容、Node REPL未使用、保存先、readback結果を入れる。
制作保留の理由は具体的に書く。「情報不足」だけで終わらせない。たとえば「内部リンク候補が2件しかなく、最低3件を満たせない」「カテゴリreadbackがない」「slug案に日付が入っている」「公式確認状況が第三者情報のみ」「サーチコンパスのKW出現率メモがない」のように、次工程が直せる形にする。
制作保留も保存後にreadbackする。保存先に保留内容が入っているか、文字化けしていないか、次回見るべき項目が入っているか確認する。
## 37. TASK8 handoff
TASK8 handoffは、公開後の機械GATEがFAIL 0件になってから作る。FAILが残っている状態でTASK8 handoffを作らない。TASK8 handoffには、公開URL、記事ID、用語名、公開カテゴリ、辞書セット、公開日時、本文文字数、H2数、H3数、Q&A数、内部リンク一覧、内部リンクHTTP結果、装飾確認、✅/⚠️確認、BOX確認、カテゴリreadback、辞書セットreadback、validator_result.jsonの場所、FAIL 0件確認、修正履歴、次工程への注意点を入れる。
TASK8 handoffも日本語で書く。機械的なIDだけで終わらせない。次工程が、どの記事が公開され、何を確認し、どのGATEが0件になったか分かる形にする。
TASK8 handoffを作ったらreadbackする。readbackでは、公開URL、用語名、FAIL 0件、validator_result.json、カテゴリ、辞書セット、内部リンク、公開後HTTP 200が入っているか確認する。readbackできない場合は完了にしない。
## 38. 作業報告
作業報告には、制作対象の用語名、検査結果ID、読んだMD/GATE名、公開URL、記事ID、本文文字数、H2数、H3数、Q&A数、内部リンク数、装飾確認、カテゴリreadback、辞書セットreadback、validator_result.json更新、FAIL 0件、TASK8 handoff、TASK8 handoff readback、Node REPL未使用を日本語で書く。
制作保留の場合は、公開URLを書かない。制作保留として、保留理由、足りない項目、保存先、readback結果、次工程へ戻す内容を書く。制作していないのに「公開完了」と書かない。
FAILが残っている場合は「完了」と書かない。FAIL名、理由、該当箇所、次に直す内容を保存し、必要なら訂正cronへ渡す。
## 39. 公開HTMLで必ず見る箇所
公開後の確認は、WordPress編集画面だけで終わらせない。公開URLのHTMLで、読者に実際に表示される本文を確認する。編集画面にある要素でも、公開HTMLに出ていなければ未反映として扱う。公開HTMLに出ている余計な要素、崩れた装飾、抜けた内部リンク、壊れた記号、消えた辞書プラグイン基本情報はすべてFAIL対象である。
公開HTMLでは、まず記事タイトルと本文冒頭を見る。H1が用語名だけか、本文がリード文から始まっているか、本文内H1がないか、リード文が300字以内か、リード文内の黄色アンダーマーカーが出ているかを確認する。次に見出しを見る。H2「用語解説」が最初のH2になっているか、H3「○○での使われ方」が用語に合っているか、H3「見かける場面」「注意点・誤解」「使用例」が揃っているか、Q&AのH3を含めてH3が5つ以上あるかを確認する。
本文の中央では、内部リンクの配置を見る。3件以上あるか、1箇所に固まっていないか、アンカーテキストが自然か、別辞書セットを使った場合に文脈が自然かを確認する。内部リンクのHTTP 200確認は、HTMLに出ている実際のhrefを対象にする。原稿上の候補URLではなく、公開HTMLで読者がクリックするURLを確認する。
本文の下部では、Q&A、まとめ、辞書プラグイン基本情報を見る。Q&Aが5件以上あるか、回答が本文の単純コピーではないか、✅と⚠️が文字化けせず表示されているか、辞書プラグイン基本情報が手書き表ではなく正しい形式で出ているかを確認する。基本情報欄が空欄、仮置き、表記ゆれのままならFAILである。
## 40. FAIL修正ループ
FAILが出た場合は、1件ずつ潰す。複数FAILがある場合も、見落としを防ぐためにFAIL名、該当箇所、修正内容、再確認結果を対応表として保存する。修正したつもりで終わらせず、修正後に同じGATEを再度通す。FAILが0件になるまで繰り返す。
本文量不足なら、読者に必要な説明を足す。H3不足なら、用語に合う自然なH3を足す。内部リンク不足なら、公開済みでHTTP 200の関連ページを探し、自然な文脈に配置する。装飾不足なら、黄金比率を満たすように重要箇所へ意味のある装飾を入れる。装飾過多なら、装飾を減らして読みやすくする。カテゴリreadback不足なら、カテゴリと辞書セットを再確認して保存する。
AIっぽい文章や硬い文章がFAILになった場合は、語尾、主語、説明順、抽象語を見直す。用語辞書は読者が意味を理解するための記事であり、社内メモや一般論の要約ではない。読者がその用語を見かける場面を想像できるように、具体的な文脈へ置き換える。
メタ表現がFAILになった場合は、公開記事本文から内部工程名を消す。作業報告に必要な言葉と、読者に見せる本文は分ける。本文に残った「候補」「検査」「制作」「GATE」「validator」「TASK」などは、読者向けの自然な言葉へ置き換えるか、削除する。
## 41. 制作証跡保存
制作証跡は、記事を公開したことだけでなく、なぜ公開できる状態になったかを残す。保存する内容は、制作対象の用語、検査結果ID、制作開始時刻、読んだMD/GATE、採用したSEOタイトル、H1、slug、公開URL、カテゴリ、辞書セット、本文文字数、H2/H3/Q&A数、内部リンク一覧、装飾数、公開後HTTP 200、公開HTML測定結果、validator_result.json、FAIL修正履歴、TASK8 handoffである。
制作証跡は日本語で読むことができる状態にする。機械的なIDだけでなく、代表や次工程が見て判断できる説明を入れる。文字化けした証跡、URLだけの証跡、FAIL理由のない証跡、readbackがない証跡は不十分である。
保存後はreadbackする。readbackでは、保存先に制作証跡が入っているか、公開URLと記事IDが合っているか、validator_result.jsonのFAILが0件か、TASK8 handoffの内容が欠けていないかを確認する。readbackできない場合は、保存失敗または確認失敗として扱い、完了にしない。
## 42. 制作開始前の並べ替え
制作に入る前に、検査付箋を記事化の順番へ並べ替える。検査付箋のまま本文を書き始めない。まず、用語名、読み、代表表記、表記ゆれ、主KW、共起語、関連語、検索意図、公式確認済み情報、断定禁止情報、内部リンク候補、辞書プラグイン基本情報候補、Q&A候補を分ける。
次に、読者が理解する順番へ並べる。最初に意味、次に使われる文脈、次に見かける場面、次に注意点、次に使用例、最後に関連語とQ&Aへ進む。検査付箋の順番がそのまま読者にとって読みやすいとは限らない。制作cronは、読者が迷わず読める順番へ整える。
公式確認済み情報と未確認情報は分ける。公式確認済みのものは本文の説明に使える。未確認情報は、注意点や公式確認が必要な条件として扱うか、本文には出さない。第三者情報やSNS情報は、読者の疑問を知る材料であって、公式事実として断定しない。
制作前メモには、採用する代表表記、使わない表記ゆれ、採用する主KW、本文に入れる共起語、内部リンクに使う関連語、Q&Aに使う検索意図、断定しない情報を保存する。制作前メモがないまま本文を書き始めると、検査付箋の抜け漏れに気づけない。
## 43. WordPress入力項目
WordPressへ入れる前に、入力項目を確認する。タイトル、slug、本文、カテゴリ、辞書セット、SEOタイトル、メタディスクリプションがある場合の説明文、辞書プラグイン基本情報、内部リンク、外部リンク、公開ステータスを確認する。
タイトルはH1として表示されるため、用語名だけにする。SEOタイトルは検索意図へ合わせる。slugは日付なしにする。本文はリード文から始める。カテゴリはterms-dictionaryにする。辞書セットは `oripa-terms` にする。辞書プラグイン基本情報は、手書き表ではなくプラグインの項目として入れる。
WordPressへ入れる本文には、内部工程名を入れない。制作メモ、検査付箋、GATE名、validator名、TASK名、Hub名を本文に混ぜない。作業用のメモと公開本文を混ぜた場合はFAILである。
公開前に、WordPress上の保存内容をreadbackする。タイトルが用語名だけか、slugが日付なしになっているか、カテゴリと辞書セットが正しいか、本文内H1がないか、Q&Aと基本情報が入っているかを見る。保存したつもりで公開しない。
## 44. 本文作成の順番
本文は、リード文から作る。リード文では、読者がその用語を調べる理由を受け止め、この記事で理解できる範囲を300字以内で示す。リード文に長い前置きや内部事情を入れない。リード文内には黒太字＋黄色アンダーマーカーを1箇所以上入れ、記事の核になる意味を示す。
次にH2「用語解説」を作る。ここでは一文だけの定義で終わらせない。用語の意味、関連する場面、似た言葉との違いの入口を作る。検査付箋の主KWと共起語を自然に入れる。ただし、KWを不自然に詰め込まない。
次にH3「○○での使われ方」を作る。○○は用語に合わせる。TCG、オンラインオリパ、発送、ポイント、ガチャ、買取、本人確認、ログインなど、読者がその用語を見る文脈に合わせる。固定でオンラインオリパに寄せない。
次にH3「見かける場面」を作る。読者が公式FAQ、ヘルプ、ガチャ詳細、発送説明、ポイント説明、キャンペーン注意書き、賞品一覧、買取条件などでその用語を見る場面を説明する。確認済みの場面だけを書く。未確認の画面や条件を断定しない。
次にH3「注意点・誤解」を作る。ここには赤太字を必ず使う。注意点は、読者が間違えやすい条件、サービスごとの差、公式確認が必要な内容、似た言葉との混同を扱う。煽りではなく、確認すれば迷わない形で書く。
次にH3「使用例」を作る。使用例は、用語をどう読むか、どう理解するかが伝わる短い例にする。公式未確認のサービス名やキャンペーン名を無理に使わない。一般化した例で伝わる場合は、自然な例文にする。
その後、関連用語・内部リンク、まとめ、Q&A、辞書プラグイン基本情報へ進む。最初からQ&Aで水増ししない。本文全体の理解が先にあり、Q&Aは読者の疑問を補う役割にする。
## 45. メタディスクリプションと抜粋
メタディスクリプションや抜粋を設定する場合は、用語を調べている読者へ向けた自然な説明にする。用語名、意味、使われる場面、注意点を短く入れる。公開日、年月日、キャンペーン日、内部工程名、制作メモを入れない。
メタディスクリプションは、本文のコピーを機械的に切っただけにしない。検索結果で読者が「この用語の意味が分かる」と判断できる文にする。過度な煽り、「完全解説」「絶対」「必ず得する」のような断定は避ける。
抜粋がWordPress一覧や辞書一覧に出る場合は、文字化けしていないか確認する。抜粋にHタグ、装飾タグ、内部リンクのHTML断片が混ざっている場合は修正する。
## 46. 辞書セット内での見え方
公開後は、記事単体だけでなく辞書セット内での見え方も確認する。辞書セット `https://oripagate.jp/directory-collection/oripa-terms/` に対象記事が入っているか、用語名が正しく表示されているか、抜粋や基本情報が崩れていないかを見る。
辞書セットに入っていない場合は、辞書セットreadback未確認としてFAILにする。記事単体が公開されていても、terms-dictionary運用としては完了ではない。用語辞書記事は、読者が辞書セットから探せる状態にする必要がある。
辞書セット内でタイトルが長すぎる、H1に余計な説明が入っている、日付入りslugが見える、文字化けがある、カテゴリが違う場合は修正対象である。
## 47. 公式確認の書き方
公式確認済みの情報を書く場合は、読者が何を確認すればよいかが分かるようにする。たとえば、発送、ポイント、本人確認、SMS認証、退会、買取、カード状態などは、サービスごとに条件が違う可能性がある。共通語として説明しながら、具体条件は各公式ページで確認する必要があることを自然に書く。
公式未確認の情報は、本文で断定しない。第三者サイトで見えた用語やSNSで見えた混乱は、読者が迷いやすい点として整理する。公式の条件、公式の数値、公式の期限のように書いてはいけない。
競合用語集の表現を使わない。競合で見えた語を扱う場合も、OripaGate読者向けに意味、使われる場面、注意点を組み直す。見出し順や説明文を丸写ししない。
## 48. 制作時の自然文チェック
本文を書いたら、公開前に声に出して読んだときの違和感を確認する。常体で統一されているか、同じ語尾が続きすぎていないか、抽象語だけで説明していないか、読者が知りたい答えへ進んでいるかを見る。
硬い文章の例は、「当該用語は利用者の認識において重要である」のような表現である。用語辞書では、「この言葉は、ガチャ詳細や賞品説明で見かけることがある」のように自然に書く。AIっぽい文章の例は、意味の薄い一般論を長く続ける文章である。読者が使う場面へ落とす。
メタ表現は公開本文から消す。「この記事では検査結果をもとに」「候補元では」「制作時には」「内部リンク候補として」のような言い方は使わない。読者向けには「関連して知っておきたい言葉は」「あわせて確認したい点は」のように自然に言い換える。
## 49. 制作cron内の自己readback
制作cronは、公開前、公開後、TASK8前の3段階で自己readbackを行う。公開前readbackでは、タイトル、slug、本文、カテゴリ、辞書セット、内部リンク、基本情報、装飾を確認する。公開後readbackでは、公開URL HTTP 200、公開HTML、本文文字数、H2/H3/Q&A、リンクHTTP 200、文字化け、装飾表示を確認する。TASK8前readbackでは、validator_result.json、FAIL 0件、TASK8 handoff内容を確認する。
自己readbackは日本語で保存する。確認した項目、OKだった項目、直した項目、残っていないFAILを分けて書く。「問題なし」だけで終わらせない。どのGATEを通した結果、何が0件だったのかを残す。
自己readbackで1つでも未確認がある場合は、制作完了にしない。未確認項目を確認するか、制作保留として保存する。未確認のままTASK8へ進めることは禁止である。
## 50. 終了条件
制作cronの終了条件は、公開記事が存在し、公開URL HTTP 200が確認され、公開HTMLで本文測定が済み、validator_result.jsonが更新され、必須FAILが0件であり、TASK8 handoffが作成され、TASK8 handoff readbackが確認されていることである。
制作対象がない場合の終了条件は、production_readyがないことを確認し、確認した保存先、確認日時、次回見る場所、Node REPL未使用を日本語で保存し、readbackすることである。対象なしレポートも保存せずに「なし」で終わらせない。
制作保留の場合の終了条件は、制作保留レポートを保存し、readbackし、戻すべき工程と不足項目を日本語で残すことである。制作保留は制作完了ではない。
公開済みでも、機械GATEのFAILが1件でも残っている場合は終了条件を満たさない。FAIL 0件になるまで続ける。FAIL 0件になって初めてTASK8へ渡す。
## 2026-06-17 最新追記: 制作本文は敬体Strict
Marker: `oripagate-production-polite-style-strict-20260617`
この追記は、この制作cronが作る OripaGate `https://oripagate.jp/` の公開記事本文に適用する。既存本文・過去追記・既存指示は消さず、文体についてはこの最新追記を優先する。
制作cronは、公開記事本文を自然な敬体で書く。リード文、本文段落、Cocoon/style BOX本文、Q&Aの質問・回答、まとめ文、注意喚起文は「です・ます」調で統一する。過去の文体指示や古いFAIL名が同じ制作cron本文内に残っている場合でも、2026-06-17以降は敬体Strictを最新優先ルールとして扱い、常体の「だ・である」調が本文に混在する場合はFAILにする。さらに、制作cronは本文作成、自己検査、validator_result保存、公開/preview HTML読み戻し、TASK8 handoffの全工程でこの敬体Strictを同じ基準として使う。検査名、古いファイル名、旧Gate名にplain系の語が残る場合でも、読者に見える本文の要求は敬体である。修正時は語尾だけを機械的に置き換えず、主語述語、読者目線、注意喚起、Q&A回答、まとめの自然さを読み直し、違和感のある日本語を残さない。加えて、制作cronは公開前に、リード文、各H2直下の導入文、H3本文、Cocoon/style BOX本文、✅/⚠️の説明文、Q&A回答、まとめ、CTA前後文を個別に読み返す。確認時は `polite_style_gate`、`lead_polite_style_pass`、`body_polite_style_pass`、`qa_polite_style_pass`、`box_polite_style_pass`、`natural_polite_japanese_pass`、`polite_style_violation_count` をvalidator_resultへ残す。語尾だけが丁寧でも、文脈が薄い、同じ語尾が続く、説明が不自然、検索意図から外れる、読者への注意喚起が命令調に寄る、公式確認が必要な箇所を断定しすぎる、Q&A回答が短すぎる、まとめが作業報告のように見える場合はPASSにしない。本文は読者がそのまま判断材料として読める自然な敬体へ直してから公開する。見出しは別ルールどおり敬体にせず、名詞句・問い・短い説明句で自然に作る。
敬体Strictの追加確認として、制作cronは公開前に本文全体を「読者が検索から来て、そのまま判断できる文章か」という観点で再読する。特に、価格、相場、評判、口コミ、使い方、注意点、売り時、向いている人、向いていない人、公式確認が必要な箇所では、断定しすぎない敬体と、読者を迷わせない説明を両立する。文末だけを整えても、途中の接続が不自然、同じ表現の反復、箇条書きの説明不足、Q&A回答の薄さ、BOX本文の命令調、まとめの作業報告化がある場合は修正対象にする。検査・制作・高品質チェック・訂正・改善ハンドオフのいずれでも、公開記事本文に対する最終要求は自然な敬体であり、見出しだけは非敬体の自然な見出しとして分離する。
常体の「だ」「である」調、常体敬体混在、語尾だけを置換した不自然な敬体、機械的で語彙力のない敬体が公開本文に残る場合はFAILである。公式引用、表ラベル、辞書プラグイン項目名、固有名詞、商品名、カード名、サービス名、URL、コード、validator_resultのキー名、Hub内部キーは例外とする。
公開/preview HTMLを読み戻し、`polite_style_gate=PASS`、`plain_style_mixed_count`、`polite_style_violation_count`、`lead_polite_style_pass`、`body_polite_style_pass`、`qa_polite_style_pass`、`box_polite_style_pass`、`natural_polite_japanese_pass` をvalidator_resultに記録する。常体混在や不自然な敬体が残る場合、制作cronは同じrun内で修正し、FAIL0件になるまで完了してはいけない。
## 2026-06-17 追記: 見出しは敬体にしない
Marker: `oripagate-production-heading-no-polite-style-20260617`
敬体Strictは公開本文、リード文、本文段落、Q&A回答、BOX本文、まとめ、注意喚起文に適用する。ただし、H1/H2/H3/H4などの見出しには「です・ます」調を使わない。見出しを敬体にすると不自然になるためである。
見出しは、検索意図と記事構造が分かる自然な名詞句・問い・短い説明句にする。例: `買取価格相場と売り時`、`高く売れる未開封状態`、`口コミで見る注意点`、`よくある質問`。`買取価格相場です`、`売り時を解説します`、`注意点があります` のような敬体見出しはFAILである。
validator_resultには、必要に応じて `heading_polite_style_violation_count` と `heading_no_polite_style_pass` を残す。本文は敬体、見出しは自然な非敬体見出し、という分離を守る。
PROMPT_ENDOripaGate【用語辞書】高品質チェックcron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】高品質チェックcron v0.1.78
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.5
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 高品質チェック
- schedule intent: 1回/日
## 絶対ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、修正報告はすべて日本語で行う。
- 高品質チェックcronは1日1回だけ起動する前提で動く。1日に複数回起動する前提で確認を小分けにしない。
- 外部の秘密情報、APIキー、認証値、個人情報を出力しない。
- 高品質チェックcronは本文を直接修正しない。FAILを日本語で特定し、訂正cronが直せる形で保存する。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\PRODUCTION_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ARTICLE_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\QUALITY_VALIDATOR_CONTRACT.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PRODUCTION_EVIDENCE_AND_SCORING_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PLAIN_STYLE_AND_QA_BOX_HOTFIX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\INSPECTION_REPORTING_GATE.md`
## 作業対象
作業対象は OripaGate【用語辞書】workflow のみ。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
## 役割目的
制作済みまたは公開済みの用語辞書記事を、機械Gate / validatorで厳しく確認する。高品質チェックcronは勝手に本文を直さない。FAILを日本語で記録し、訂正cronへ渡す。FAIL 0件の場合は、改善ハンドオフcronがTASK8 handoffを作れるように、公開証跡とvalidator_result.jsonのreadback結果を保存する。
高品質チェックcronは、制作cronの代わりに記事を作らない。訂正cronの代わりに本文を直さない。改善ハンドオフcronの代わりにTASK8 handoffを完成させない。役割は、公開済みまたは制作済みの記事を公開HTML基準で検査し、FAILがあるかないかを明確にすることである。
対象が見つからない場合は、対象なしレポートを保存する。対象なしレポートには、確認した保存先、確認日時、対象がなかった理由、次回見る場所、Node REPL未使用を日本語で入れる。対象がないのに空報告で終わらない。
## 必須チェック
- 公開URL HTTP 200。
- 公開URLとslugに年月日や日付が入っていない。
- 公開HTMLで本文測定。
- 本文2000文字以上。
- H1は用語名のみ。
- H2 2つ以上、H3 5つ以上。
- Q&A 5件以上。
- 辞書プラグイン基本情報表あり。手書き表なし。
- 内部リンク3件以上、分散配置、自然なアンカーテキスト、最終HTTP 200。
- ✅/⚠️使用。
- 黒太字、赤太字、黒太字+黄色アンダーマーカー、装飾BOXの下限を満たす。
- 文字化けなし。
- 公式主機能、WPカテゴリ、辞書セット、カテゴリreadback確認済み。
- 公開本文にHub、cron、task、agent_pack、quality gate、production_readyなど内部語が出ていない。
## 入力条件
高品質チェックcronが見る対象は、制作cronまたは訂正cronから渡された公開済みの用語辞書記事である。入力には、公開URL、記事ID、対象用語、制作元または訂正元の記録、validator_result.jsonの場所、カテゴリreadback、辞書セットreadback、内部リンクHTTP確認結果、公開HTML本文測定結果が必要である。
入力が不足している場合は、いきなりFAIL 0件にしない。足りない入力項目を `QUALITY_INPUT_MISSING` として保存し、どの工程へ戻すべきかを日本語で残す。公開URLがない、記事IDがない、validator_result.jsonがない、カテゴリreadbackがない、辞書セットreadbackがない、内部リンク確認結果がない場合は、判定を続けず保留にする。
高品質チェックcronは、対象記事を自分で探し回って勝手に追加しない。渡された対象が複数ある場合は、1日1回の前提で優先度が高い1件から見る。選ばなかった記事は残件として保存し、次回見る順番を日本語で残す。
## 公開HTML確認
チェック対象は、原稿ではなく公開HTMLを優先する。WordPress編集画面やpreviewにある要素でも、公開HTMLに出ていなければ未反映としてFAILにする。公開HTMLから、記事タイトル、本文冒頭、H2/H3、Q&A、内部リンク、装飾、辞書プラグイン基本情報、カテゴリ表示、文字化けを確認する。
本文測定では、広告、ナビゲーション、関連記事、フッター、サイドバー、パンくず、管理用文言を除いた記事本文を見て、2000文字以上か確認する。本文外の文字を足して2000文字以上扱いにしない。本文測定結果には、測定対象、除外した範囲、本文文字数を日本語で保存する。
H1はWordPressタイトル側で用語名のみになっているか確認する。本文内H1がある場合はFAILにする。本文がリード文から始まっているか、リード文が300字以内か、読者がどの用語を理解できる記事なのか自然に導入しているかを見る。
SEOタイトルはH1と別に確認する。公開HTML、SEOメタ、WordPress SEO欄、OG titleのうち確認できる範囲で、SEOタイトルが裸の用語名だけになっていないか見る。`3Dセキュア | OripaGate（オリパゲート）`、`追跡番号 | OripaGate（オリパゲート）` のように「とは」「って何」「意味」などの検索意図語がなく、用語名とサイト名だけのタイトルはFAILである。
採用SEOタイトルには「とは」「って何」「意味」のいずれかが入っていることを確認する。入っていない場合は `TERMS_SEO_TITLE_QUERY_PHRASE_MISSING` としてFAILにする。SEOタイトルがH1と同じ裸の用語名、または用語名とサイト名だけの場合は `TERMS_SEO_TITLE_BARE_TERM_ONLY` としてFAILにする。
## 構成チェック
最初のH2が「用語解説」になっているか確認する。H3「○○での使われ方」は、用語の主文脈に合っているか見る。TCG用語なのに無理にオンラインオリパへ寄せていないか、発送用語なのにTCG文脈になっていないか、ポイント用語なのにキャンペーン記事のようになっていないかを確認する。
H3「見かける場面」「注意点・誤解」「使用例」があるか確認する。H2「関連用語・内部リンク」「まとめ」「Q&A」「用語に関する辞書プラグイン基本情報」があるか確認する。Q&Aは5件以上で、同じ質問の言い換えだけになっていないか見る。
## 装飾チェック
黒太字、赤太字、黒太字＋黄色アンダーマーカーの数と配置を見る。最低基準は、黒太字6、赤太字2、黒太字＋黄色アンダーマーカー4である。比率はおおむね3:1:2とし、本文量が増えている場合は自然に増やす。リード文内に黄色アンダーマーカーが1つ以上あるか確認する。
✅と⚠️が公開HTMLで文字化けせず表示されているか確認する。装飾BOXが1つ以上あるか、BOX内の文章が常体か、BOXが空ではないかを見る。装飾が不足している場合も、装飾が多すぎて読みにくい場合もFAILにする。
## 内部リンクチェック
内部リンクは最低3件である。公開HTML内の実際のhrefを確認し、最終HTTP 200を確認する。リンクが本文中にばらけているか、1箇所に固まっていないか、アンカーテキストが自然な日本語かを見る。「こちら」「詳細」「公式」だけのアンカーはFAILにする。
別辞書セットの記事を内部リンクに使っている場合は、本文文脈として自然かを見る。別辞書セットだからという理由だけで無理に入れたリンクはFAILにする。内部リンクの確認結果には、URL、アンカーテキスト、配置箇所、HTTPステータスを保存する。
## 辞書プラグイン基本情報チェック
terms-dictionary記事では、記事下の辞書プラグイン基本情報が必須である。手書き表で代替していないか確認する。TOPの評価スコア表を通常評価記事のように入れていないか確認する。基本情報欄に、用語名、読み方、意味、使われる場面、関連語、注意点、参照URLなど、用語辞書として必要な項目が入っているか見る。
oripa-termsでは、基本情報欄に `term_name`、`reading`、`aliases`、`term_category`、`one_line_meaning`、`used_in`、`related_genres`、`check_points`、`risk_note`、`related_terms`、`related_dictionary_links`、`checked_at` の12フィールドが入っているか確認する。日本語ラベルだけが本文中にある状態はPASSにしない。プラグイン基本情報として保存され、公開HTMLまたはreadbackで確認できることを条件にする。
12フィールドの不足は `TERMS_ORIPA_TERMS_BASIC_INFO_FIELD_MISSING` としてFAILにする。`related_dictionary_links` が空欄、内部リンク候補だけでHTTP 200確認がない、`checked_at` がない、`term_category` が曖昧、`one_line_meaning` が抽象的で意味を説明していない場合もFAILにする。
辞書プラグイン基本情報が空欄、仮置き、文字化け、手書き表、通常評価記事のスコア表流用であればFAILにする。辞書セット `oripa-terms` に入っているか、カテゴリreadbackとあわせて確認する。
## 文体チェック
本文が敬体で統一されているか確認する。常体の「だ・である」調が混ざっている場合はFAILにする。硬い文章、メタ表現、AIっぽい文章が1つでもあればFAILにする。公開本文に「候補」「検査」「制作」「GATE」「readback」「TASK8」「validator_result.json」「Hub」「cron」「production_ready」などの内部語が残っていないか確認する。
読者向けの自然文になっているか見る。用語の意味、使われ方、見かける場面、注意点、使用例が、読者の理解につながっているか確認する。抽象的な一般論だけで、用語の実際の文脈が見えない場合はFAILにする。
## validator_result.json
高品質チェックcronは validator_result.json を更新する。validator_result.jsonには、公開URL、記事ID、用語名、本文文字数、H2数、H3数、Q&A数、内部リンク数、内部リンクHTTP結果、装飾数、✅/⚠️使用、BOX数、カテゴリreadback、辞書セットreadback、slug確認、本文内H1確認、文字化け確認、FAIL一覧、修正指示、最終判定を入れる。
FAIL理由は日本語で入れる。機械的なコードだけで終わらせない。FAILがある場合は、訂正cronが見て直せるように、該当箇所、理由、修正方針、優先度を保存する。
## FAIL名の付け方
FAIL名は、訂正cronが直す対象をすぐ分かる名前にする。たとえば、本文量不足は `TERMS_BODY_UNDER_2000_CHARS`、H3不足は `TERMS_H3_COUNT_TOO_LOW`、Q&A不足は `TERMS_QA_COUNT_TOO_LOW`、内部リンク不足は `TERMS_INTERNAL_LINKS_UNDER_3`、日付入りslugは `TERMS_PUBLIC_SLUG_HAS_DATE`、辞書プラグイン基本情報不足は `TERMS_DICTIONARY_PLUGIN_INFO_MISSING`、oripa-terms基本情報の必須フィールド不足は `TERMS_ORIPA_TERMS_BASIC_INFO_FIELD_MISSING`、手書き表代替は `TERMS_MANUAL_TABLE_USED_INSTEAD_OF_PLUGIN_INFO` とする。
SEOタイトルの問題は、H1問題と混ぜない。SEOタイトルが裸の用語名または用語名とサイト名だけなら `TERMS_SEO_TITLE_BARE_TERM_ONLY`、SEOタイトルに「とは」「って何」「意味」のいずれも入っていない場合は `TERMS_SEO_TITLE_QUERY_PHRASE_MISSING` とする。H1は用語名のみで正しいがSEOタイトルだけ弱いケースをPASSにしない。
文体の問題は、まとめて「文章が悪い」と書かない。硬い文章なら `TERMS_HARD_SENTENCE_FOUND`、メタ表現なら `TERMS_META_EXPRESSION_IN_PUBLIC_BODY`、AIっぽい文章なら `TERMS_AI_LIKE_SENTENCE_FOUND` のように分ける。該当箇所には、見出し名、本文抜粋、なぜFAILか、どう直すべきかを入れる。
カテゴリや辞書セットの問題は厳しく扱う。公式主機能未確認のカテゴリ選択、主文脈と違うカテゴリ、曖昧カテゴリへの推測投入、カテゴリreadback未確認、辞書セットreadback未確認は、それぞれ別FAILとして保存する。カテゴリ系FAILを1つにまとめて曖昧にしない。
## 判定順
判定は、まず公開URL HTTP 200、slug日付なし、カテゴリreadback、辞書セットreadbackを見る。ここで失敗した場合は、記事本文が良くてもFAILである。次に本文構成、本文量、H1、H2/H3、Q&A、辞書プラグイン基本情報を見る。そのあと内部リンク、装飾、文体、文字化け、公式未確認断定を見る。
この順番にする理由は、公開URLやカテゴリが間違っている記事は、本文品質が高くても用語辞書記事として成立しないためである。本文の細かい品質だけを見て、カテゴリや辞書セットのFAILを見落とさない。
判定結果は、PASS/FAILだけで終わらせない。各チェック項目について、確認結果、根拠、該当箇所、FAIL名、訂正cronへの指示を保存する。FAIL 0件の場合も、なぜ0件と判断したかが分かる証跡を残す。
## 訂正cronへ渡す内容
FAILが1件でもある場合は、訂正cronへ渡す。渡す内容は、公開URL、記事ID、用語名、validator_result.jsonの場所、FAIL一覧、FAILごとの該当箇所、修正方針、再確認すべきGATE、優先度、公開後に再測定すべき項目である。
訂正cronへ渡す文は日本語で書く。たとえば「H3不足」だけでは足りない。「H3が4件で、最低5件に足りない。Q&Aの質問をH3化するか、用語に合った『関連用語との違い』を追加して、公開HTMLでH3数を再確認する」のように、次のcronが迷わない形にする。
FAILが複数ある場合は、修正順も書く。slug、カテゴリ、辞書セット、公開URL、本文内H1、文字化けのような土台のFAILを先に直し、そのあと本文量、H3、内部リンク、装飾、文体を直す。順番を書かないと、訂正cronが見た目の修正だけで終わる危険がある。
## 即FAIL
- ✅/⚠️不使用。
- 文字化け。
- 公開URLまたはslugに年月日や日付が入っている。
- 公式主機能未確認のカテゴリ選択。
- 主機能と違うWPカテゴリ。
- 曖昧カテゴリへの推測投入。
- カテゴリreadback未確認。
- 本文2000文字未満。
- H3不足。
- 内部リンク3件未満。
- 手書き基本情報表。
- 硬い文章、メタ表現、AIっぽい文章。
- 本文内H1がある。
- Q&Aが5件未満。
- 辞書セットreadback未確認。
- 公開HTMLで本文測定していない。
- validator_result.jsonを更新していない。
- FAIL理由が日本語ではない。
## 終了条件
validator_result.jsonを更新し、readbackする。FAIL 0件なら、改善ハンドオフcronへ渡すために、公開URL、記事ID、用語名、FAIL 0件、validator_result.json、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200、公開HTML本文測定結果を日本語で保存する。FAILが1件でもあれば、完了扱いにせず、FAIL名、日本語説明、該当箇所、直すべき内容を保存し、訂正cronへ渡す。公開URLとslugの日付禁止、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200は必ずreadback対象にする。
PROMPT_ENDOripaGate【用語辞書】訂正cron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】訂正cron v0.1.78
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.4
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 訂正
- schedule intent: 1回/日
## 絶対ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、修正報告はすべて日本語で行う。
- 訂正cronは1日1回だけ起動する前提で動く。1日に複数回起動する前提でFAILを小分けにしない。
- 外部の秘密情報、APIキー、認証値、個人情報を出力しない。
- 訂正cronは、新規候補の収集や検査判定を行わない。高品質チェックで出たFAILを直すことに集中する。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\PRODUCTION_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ARTICLE_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\QUALITY_VALIDATOR_CONTRACT.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PRODUCTION_EVIDENCE_AND_SCORING_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\PLAIN_STYLE_AND_QA_BOX_HOTFIX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\INSPECTION_REPORTING_GATE.md`
## 作業対象
作業対象は OripaGate【用語辞書】workflow のみ。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
## 役割目的
高品質チェックで出たFAILをすべて潰す。訂正cronは指摘箇所を自己判断で残さない。修正後は必ず機械Gateへ戻す。訂正cronは、FAILの修正、公開HTML再確認、validator_result.json更新、readbackまでを行い、FAIL 0件になったかを証跡として残す。
訂正cronは、FAILに書かれていない新規改修を広げない。記事全体の大改造が必要に見える場合でも、まずFAILを1件ずつ潰す。修正中に新しいFAILを見つけた場合は、新規FAILとして保存し、同じ修正ループに入れる。見つけたFAILを「今回は対象外」として放置しない。
## 訂正手順
1. FAIL名、日本語説明、該当箇所、必要修正を読む。
2. 該当マニュアルまたは該当Gateだけを確認する。不要な全文再読はしない。
3. 指摘された箇所をすべて修正する。
4. 公開URL、公開HTML、validator_result.json、内部リンクHTTP 200、カテゴリreadbackを確認する。
5. 機械Gate / validatorへ再投入する。
訂正前に、FAIL一覧を対応表にする。対応表には、FAIL名、該当箇所、原因、修正方針、修正後確認、再発防止メモを入れる。FAIL一覧を読んだだけで修正に入らない。修正後にどのFAILが消えたかを確認できる形にする。
訂正後は、公開HTMLで確認する。編集画面やローカル原稿だけで「直った」と判断しない。本文量、H2/H3、Q&A、内部リンク、装飾、辞書プラグイン基本情報、カテゴリreadback、辞書セットreadback、slug、文字化けを再確認する。
## 直す対象
- 本文2000文字未満。
- H2/H3不足。
- Q&A不足。
- 内部リンク不足、集中配置、不自然アンカー、HTTP 200未確認。
- 公開URLまたはslugへの年月日・日付混入。
- ✅/⚠️不足。
- 装飾不足または装飾過多。
- 文字化け。
- 辞書プラグイン基本情報表不足。
- 手書き表。
- カテゴリ不一致。
- 公開本文への内部語混入。
- 硬い文章、メタ表現、AIっぽい文章。
- H1が用語名のみではない。
- 本文内H1がある。
- リード文が300字を超えている。
- リード文が用語の導入になっていない。
- Q&Aが5件未満。
- 辞書セットreadback未確認。
- validator_result.json未更新。
- TASK8へ渡す証跡不足。
## 修正方針
本文2000文字未満の場合は、読者に必要な説明を足す。単なる水増しは禁止である。用語の意味、見かける場面、注意点、使用例、関連語、Q&Aのどこが薄いかを見て、必要な内容を足す。
H2/H3不足の場合は、用語に合った自然な見出しを足す。H3数を満たすためだけの空見出しは禁止である。Q&A不足の場合は、読者が実際に検索しそうな質問を足す。同じ質問の言い換えを増やさない。
内部リンク不足の場合は、公開済みでHTTP 200の関連ページを探し、自然なアンカーで本文中にばらけて配置する。1箇所にまとめて置かない。リンク先が見つからない場合は、その理由を保存し、公開完了扱いにしない。
装飾不足の場合は、黒太字、赤太字、黒太字＋黄色アンダーマーカー、✅、⚠️、装飾BOXを意味のある箇所に入れる。装飾過多の場合は、重要箇所だけに絞る。赤太字は注意点に限定し、黄色マーカーは要点に限定する。
公開URLまたはslugに年月日や日付が入っている場合は、日付なしslugへ修正する。修正後は、公開URL、リダイレクトの有無、内部リンク、validator_result.jsonを確認する。日付入りURLを残したまま完了にしない。
硬い文章、メタ表現、AIっぽい文章は、読者向けの自然な常体文へ直す。公開本文から「候補」「検査」「制作」「GATE」「readback」「TASK8」「validator_result.json」「Hub」「cron」「production_ready」などの内部語を消す。
## 再検証
修正後は必ず機械Gate / validatorへ再投入する。自分の目視だけでFAIL 0件扱いにしない。validator_result.jsonを更新し、再検証日時、修正したFAIL、残ったFAIL、FAIL 0件判定を保存する。
FAILが残った場合は、同じ訂正cron内で修正を続ける。修正できない理由がある場合は、理由、必要な追加情報、戻すべき工程を日本語で保存する。FAILを残したまま「完了」と書かない。
## 修正保存項目
訂正cronは、修正前後の差分を次工程が追える形で保存する。最低限、公開URL、記事ID、対象用語、修正前のFAIL名、修正前の該当箇所、修正内容、修正後の公開HTML確認結果、validator_result.json更新結果、残FAIL数、FAIL 0件判定、readback結果を保存する。
修正した本文の全文を作業報告に長く貼らない。必要なのは、どのFAILをどのように直したかである。本文全体の保存が必要な場合は保存先を残し、作業報告には要約とreadback結果を書く。
修正後に別のFAILが出た場合は、別FAILとして追加する。最初のFAILだけを消して、次に見つかったFAILを黙って残さない。FAIL一覧は常に最新にする。
## 戻し条件
訂正cronで直せない場合は、理由を明確にして戻す。たとえば、公式確認が不足して本文を断定できない場合は検査へ戻す。内部リンク候補が足りず3件にできない場合は、検査または改善候補へ戻す。辞書プラグイン基本情報の項目仕様が不明な場合は、制作またはGATE確認へ戻す。
戻す場合も、作業を空で終わらせない。戻し理由、確認済みの範囲、未確認の範囲、次に必要な作業、Node REPL未使用、保存先、readback結果を日本語で残す。
## 訂正後handoff
FAIL 0件になったら、改善ハンドオフcronへ渡す。渡す内容は、公開URL、記事ID、用語名、修正済みFAIL一覧、validator_result.jsonの場所、公開HTML本文測定、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200、装飾確認、Q&A数、辞書プラグイン基本情報確認である。
訂正cronはTASK8 handoffを完成させない。TASK8 handoffは改善ハンドオフcronの役割である。ただし、改善ハンドオフcronが迷わないよう、FAIL 0件の証跡を十分に渡す。
## 終了条件
FAIL 0件になるまで修正と機械Gateを繰り返す。FAIL 0件になったら、修正内容、確認結果、validator_result.json、公開URL、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200、公開HTML本文測定、改善ハンドオフcronへ渡す情報を日本語で保存する。保存後はreadbackし、FAIL 0件が保存内容に入っていることを確認する。
PROMPT_ENDOripaGate【用語辞書】改善ハンドオフcron automation作成依頼文
PROMPT_START
# OripaGate【用語辞書】改善ハンドオフcron v0.1.78
- kind: cron
- cwd: `C:\Users\Public\Documents\LLC358\_codex_cron_threads`
- model: gpt-5.4
- reasoning: highest
- site_id: `oripagate`
- workflow_id: `oripagate-terms-dictionary-ja`
- article_type: `terms-dictionary`
- content_set: `oripagate_terms_dictionary`
- public_category_url: `https://oripagate.jp/terms-dictionary/`
- dictionary_set_url: `https://oripagate.jp/directory-collection/oripa-terms/`
- hub_url: `https://oripagate-hub.secure358.com/`
- role: 改善ハンドオフ
- schedule intent: 1回/日
## 絶対ルール
- 作業時に Node REPL / node_repl / JavaScript REPL を使用しない。作業が止まるため絶対禁止。
- 作業報告、readback、handoff、FAIL理由、修正報告はすべて日本語で行う。
- 改善ハンドオフcronは1日1回だけ起動する前提で動く。1日に複数回起動する前提でhandoffを小分けにしない。
- 外部の秘密情報、APIキー、認証値、個人情報を出力しない。
- 改善ハンドオフcronは記事本文を直接修正しない。FAIL 0件の証跡を整理し、TASK8 handoffを作る。
## 起動時に必ず熟読するMD/GATE
このcronは、作業開始時に次のMD/GATEを読み、内容を作業に反映してから動く。読まずに作業を始めない。読んだMD/GATE名は作業報告に日本語で残す。
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron_prompts\current\terms-dictionary\README.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\ARTICLE_TYPE_MANUAL.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ORIPAGATE_ARTICLE_TYPE_AND_DIRECTORY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\ROLE_FAIL_CONDITION_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\JAPANESE_SYNTAX_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\cron\PRODUCTION_QUALITY_GATE.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\QUALITY_VALIDATOR_CONTRACT.md`
- `C:\Users\Public\Documents\LLC358\Autopost358\HUB\oripagate\gates\current\INSPECTION_REPORTING_GATE.md`
## 作業対象
作業対象は OripaGate【用語辞書】workflow のみ。対象workflowは `oripagate-terms-dictionary-ja`、記事タイプは `terms-dictionary`、公開カテゴリは `https://oripagate.jp/terms-dictionary/`、辞書セットは `https://oripagate.jp/directory-collection/oripa-terms/` である。
## 役割目的
FAIL 0件になった用語辞書記事について、TASK8 handoff、次回改善、内部リンク追加候補、追加候補メモを日本語で整理する。改善ハンドオフcronは記事を直接直さない。追加候補メモは、次回以降の改善や別工程が判断できるように名前と理由だけを残し、このcron自身は新規収集作業を行わない。
改善ハンドオフcronは、FAILが残っている記事を受け取らない。validator_result.jsonでFAIL 0件が確認できない場合は、TASK8 handoffを作らず、訂正cronへ戻す。FAIL 0件の証跡がある場合だけ、次工程が迷わないように公開情報と検証情報を整理する。
改善ハンドオフcronは、新しい候補を収集しない。サーチコンパスを新規実行して候補を増やさない。追加候補メモは、公開記事を読んだ結果として「次に説明するとよい可能性がある語」を残すだけである。候補化、検査、制作可否判断は別工程に任せる。
## handoff必須内容
- 公開URL。
- 対象用語。
- WordPressカテゴリと辞書セット。
- 公開URL HTTP 200。
- 公開URLとslugに年月日や日付が入っていない確認。
- 本文2000文字以上。
- H2/H3/Q&A数。
- 辞書プラグイン基本情報表の確認。
- 内部リンク3件以上とHTTP 200確認。
- validator_result.jsonの場所。
- FAIL 0件の証跡。
- カテゴリreadback。
- 辞書セットreadback。
- ✅/⚠️、装飾BOX、装飾比率の確認。
- 文字化けなし確認。
- 次回改善候補。
- 追加候補メモがある場合は、その用語名と理由。
## 入力条件
改善ハンドオフcronが受け取る入力は、FAIL 0件のvalidator_result.jsonと、公開URL、記事ID、対象用語、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200、公開HTML本文測定、装飾確認、Q&A数、辞書プラグイン基本情報確認である。
入力にFAILが残っている場合は、handoffを作らない。validator_result.jsonが存在しない、FAIL 0件が確認できない、公開URLがHTTP 200ではない、カテゴリreadbackがない、辞書セットreadbackがない場合は、改善ハンドオフではなく訂正へ戻す。
入力が複数ある場合は、1日1回の前提で1件ずつ扱う。複数記事をまとめて雑なhandoffにしない。未処理のFAIL 0件記事がある場合は、残件として保存し、次回見る順番を日本語で残す。
## TASK8 handoffの書式
TASK8 handoffには、見出し、対象記事情報、検証結果、FAIL 0件証跡、改善候補、追加候補メモ、readback結果を分けて書く。読んだ人が、記事が公開済みで、どのGATEが通り、どの証跡があるかを一目で追える形にする。
対象記事情報には、公開URL、記事ID、用語名、公開カテゴリ、辞書セット、公開日時または最終更新日時を入れる。検証結果には、HTTP 200、本文文字数、H2数、H3数、Q&A数、内部リンク数、内部リンクHTTP結果、装飾確認、辞書プラグイン基本情報確認、文字化けなし確認を入れる。
FAIL 0件証跡には、validator_result.jsonの保存先、最終判定、FAIL数0、readback日時を入れる。改善候補には、今すぐFAILではないが次回品質を上げられる点だけを入れる。追加候補メモには、候補化ではなく、次に収集や検査が必要な語を短く残す。
## 改善観点
- 関連用語を増やせるか。
- 別辞書セットから自然な内部リンクを増やせるか。
- 読者が混乱しやすい言い換えを補えるか。
- 公開後の記事内容から、追加で説明した方がよい用語が見えていないか。
- 同じ用語の別表記や略称を別記事にする必要があるか。
改善観点は、公開済み記事の品質を次に上げるためのメモである。現在の記事のFAILを見つけた場合は、改善候補ではなくFAILとして扱い、訂正cronへ戻す。改善候補には、今すぐ直さなくてもFAILではないが、次回改善で役立つ内容だけを入れる。
内部リンク追加候補は、URL、アンカーテキスト案、配置候補、追加した方がよい理由を保存する。HTTP 200未確認のものは、未確認として扱う。未確認リンクを確定リンクとして書かない。
追加候補メモには、用語名、見えた理由、この記事との関係、収集・検査が必要な点を短く残す。追加候補メモをproduction_readyや制作対象として扱わない。
## 戻し条件
次のどれかに当てはまる場合、改善ハンドオフcronは完了にしない。FAIL 0件が確認できない。validator_result.jsonがない。公開URLがHTTP 200ではない。公開URLまたはslugに日付が入っている。カテゴリreadbackがない。辞書セットreadbackがない。内部リンクHTTP 200が確認できない。文字化けがある。TASK8 handoffに必須項目が欠けている。
戻す場合は、戻し先を明記する。本文や装飾のFAILなら訂正cronへ戻す。公式確認不足なら検査cronへ戻す。内部リンク候補不足なら検査または改善候補へ戻す。handoff項目不足なら改善ハンドオフ内で補う。戻し理由と保存先を日本語で残す。
## readback
TASK8 handoffを作ったら必ずreadbackする。readbackでは、公開URL、対象用語、FAIL 0件、validator_result.json、カテゴリreadback、辞書セットreadback、内部リンクHTTP 200、公開URLの日付なし確認、本文文字数、H2/H3/Q&A数が入っているか確認する。
readbackできない場合は完了にしない。handoffを作ったつもりで終わらせず、保存先、保存内容、readback結果を日本語で残す。
## 終了条件
TASK8 handoffを作成し、readbackで公開URL、FAIL 0件、validator_result.json、内部リンク確認、カテゴリreadback、辞書セットreadback、公開URLの日付なし確認、次回改善候補を確認する。FAIL 0件でない場合は完了にせず、訂正cronへ戻す。TASK8 handoffとreadbackが揃って初めて、このcronの作業を完了にする。
PROMPT_ENDv0.1.78 readback checklist
- 個別cronのcode blockが6組ある。
- 各個別cronに「1回/日」が入っている。
- 各個別cronに「Node REPL / node_repl / JavaScript REPL を使用しない」が入っている。
- 各個別cronに「作業報告はすべて日本語」が入っている。
- 各個別cronに、作業開始時に熟読するMD/GATEが入っている。
- 検査cronにサーチコンパス、共起語、関連語、KW出現率が入っている。
- 制作cronに2000文字以上、H2 2つ以上、H3 5つ以上、Q&A 5件以上が入っている。
- 制作cron依頼文が2万文字以上である。
- 公開URLとslugに年月日や日付を入れないルールが入っている。
- H3の文脈例として「TCGでの使われ方」が入っている。
- 機械GateでFAIL 0件になるまで繰り返す終了条件が入っている。
