anycap-blog-production

AnyCap ブログ制作

開始前に、このファイル全体をお読みください。 このスキルは、ユーザーから提供されたデータを AnyCap らしい記事に仕上げ、その記事に根拠が必要な箇所に証拠を加えるためのものです。

ユーザーが事実、メモ、例、ベンチマーク、製品の機能、その他の生データを提供し、AnyCap のウェブサイトらしい文体の完成したブログ記事を求めている場合は、このスキルを使用してください。主な作業は次のとおりです。

1. 入力データを整理して作業用ブリーフにまとめる
2. AnyCap のウェブサイトのトーンでページの原稿を作成する
3. 記事に一次情報による証拠ブロックが必要か判断する
4. ページを実質的に改善する場合に限り、AnyCap が生成したビジュアルを追加する

このスキルはブログ制作のワークフローを扱います。CLI の構文、認証、コマンドの動作については、anycap-cli スキルをお読みください。検索意図のより広範な計画については、anycap-ai-tool-seo スキルをお読みください。

原稿を作成する前に、次の参照ファイルをお読みください。

• voice.md
• patterns.md
• input-brief.md

最適な用途

• データに基づくブログ記事の作成
• 調査メモから作成する学習ページやチュートリアル
• 製品情報や参考例を基に作成する用語集や概念ページ
• ユーザーがベンチマーク、例、機能データを先に提供する SEO 記事
• 入力が箇条書き、表、JSON、スプレッドシート、リンク、またはラフなメモであるコンテンツ制作ワークフロー
• 一般的なコンテンツマーケティングの文章ではなく、実務的で、答えを先に示し、製品に精通した文体にする AnyCap のウェブサイトコンテンツ

始める前に

1. AnyCap が利用可能であることを確認します。

anycap status

2. 編集前にページ構造を確認します。

   • ベースページを探す
   • ローカライズされたラッパーを探す
   • ローカライズ版や重複ルートがベースページを単に再エクスポートしているだけか確認する

3. 入力をブリーフに整理します。

   • 記事のトピックは何か
   • 誰を対象にしているか
   • データが実際に証明していることは何か
   • 一文でまとめた答え、または約束は何か
   • 確信を持って述べられることと、まだ不明なことは何か

4. Git のワークツリーを確認し、無関係なユーザーの編集を上書きしないようにします。

5. 執筆前に、文体と構成の参照資料を読みます。

ワークフロー

1. 入力データから作業用ブリーフを作成する

ユーザーから提供される情報には、次のようなものがあります。

• 箇条書き
• 製品情報
• 競合に関するメモ
• スプレッドシートのエクスポート
• JSON
• URL
• ベンチマーク
• 大まかな観察結果

最初に行うのは、これらを簡潔な内部ブリーフにまとめることです。

• 対象読者
• 検索意図またはページの目的
• ページの主張
• 3～6 件の裏付けとなる事実
• 不足している証拠、または不確実な点
• 推奨するページ構成

入力情報が少ない場合は、慎重に推測しつつ、データで実際に裏付けられる範囲に記事を限定してください。

2. 内容を広げる前に、AnyCap のウェブサイトのトーンで原稿を作成する

AnyCap の記事における基本パターン：

1. 短い眉見出し
2. 具体的な約束を一つ含む、直接的な H1
3. 一般的なカテゴリーをすでに理解している読者向けの簡潔な導入
4. ページ上部付近に、答えを先に示す要約ブロック
5. 次のような構成セクションを一つ以上：
   • ワークフロー
   • 比較
   • チェックリスト
   • ユースケース
   • FAQ
6. 読者を次に関連するページへ誘導する CTA または内部リンク

一般的な状況説明から始めないでください。実際の問題、制約、または役立つ成果から始めてください。

3. ページの主張に合った証拠の種類を選ぶ

• 最終的な成果を示す：洗練されたヒーロー画像またはショーケース画像を1点生成します。
• 変化を示す：粗い元画像を生成し、同じ被写体を使った仕上がり画像を生成します。
• 幅や反復を示す：複数のバリエーションを含む三連画像、または見やすいレビュー用ボードを生成します。
• 時間ベースのワークフローを支える：概要を表す補助画像またはキーフレームを生成します。静止画像を動画の完成結果として提示しないでください。
• 音声ベースのワークフローを支える：プロンプトを補完するムード画像またはカバー画像を生成します。画像が音声出力であるかのように示さないでください。
• プロセスの説明を支える：文章による説明を把握しやすくする、すっきりとした手順イラストまたは図解風のビジュアルを生成します。

記事がメディアなしでも十分に成立する場合は、無理に証拠ブロックを追加しないでください。このスキルは有用な証拠を示すためのものであり、装飾的な埋め草のためのものではありません。

4. プロンプトを作成する前に、モデルの実際の制約を確認する

記事にメディアが必要な場合は、まず最新のモデルカタログとスキーマを調べます。

anycap image models
anycap image models <model> schema --operation generate --mode <mode>

anycap video models
anycap video models <model> schema --operation generate --mode <mode>

anycap music models
anycap music models <model> schema --operation generate

モード名、パラメーター名、対応するアスペクト比を決めつけないでください。

5. 再利用可能な公開パスにアセットを生成する

内容がわかるファイル名を使い、関連するアーティファクトをまとめて配置します。

mkdir -p web/public/content-evidence

anycap image generate \
  --model <model> \
  --prompt "<subject-specific brief> ... no readable text, no watermark" \
  --param aspect_ratio=16:9 \
  -o web/public/content-evidence/<page-slug>-hero.png

ルール：

• 常に、内容がわかるファイル名とともに -o を使用します。
• レイアウトに別の比率が必要な場合を除き、ヒーロー画像やショーケースには 16:9 を優先します。
• ビフォー／アフターのワークフローでは、ファイルを明確にバージョン分けするか、分割します。
• 生成時にはアセットをトピックに特化させますが、スキル自体は特定のトピックに限定しないでください。
• ラッパーファイルを通じてページをローカライズする場合、特定のロケール向けの画像が本当に必要な場合を除き、アセットは共通のままにします。

6. ページに組み込む前に、生成したアセットを検証する

AnyCap のビジョン機能を使ってアーティファクトを検証します。

anycap actions image-read \
  --file web/public/content-evidence/<page-slug>-hero.png \
  --instruction "Describe this image, confirm it matches the intended page claim, and mention any visible text or watermark."

編集ワークフローでは、元画像と修正版を比較します。

anycap actions image-read \
  --file web/public/content-evidence/<page-slug>-before.png \
  --file web/public/content-evidence/<page-slug>-after.png \
  --instruction "Confirm whether the second preserves the same subject while improving composition and background cleanliness."

検証で目に見えるテキスト、意図しない看板、被写体の誤り、またはプロンプトからの逸脱が見つかった場合は、コードを編集する前にプロンプトを修正して再生成します。

7. アセットを最適化し、再利用可能なコードに組み込む

• 画質の差が許容できる場合は、サイズの大きい PNG を JPG または WebP に圧縮します。
• 各ページに大きな JSX ブロックを複製するより、再利用可能なコンポーネントとルックアップテーブルの組み合わせを優先します。
• キャプションは事実に即した内容にします。
  • 静止画像には、そのページ向けに AnyCap で生成した画像であると記載できます。
  • 時間ベースまたは音声ベースのページでは、そのビジュアルが補助画像またはカバー画像であることを明記します。
• ローカライズされたルートが単にベースページを再エクスポートする場合は、ローカライズ版を個別に修正せず、ベースページを一度だけ編集します。
• 再利用可能なブロックは、コンポーネント自体を書き直さなくても記事、ガイド、ランディングページに組み込める程度に汎用的に保ちます。

8. ページへの組み込みを検証する

変更したファイルを対象に、的を絞ったチェックを実行します。

pnpm exec eslint \
  'src/components/seo/ContentEvidenceBlock.tsx' \
  'src/lib/content-evidence.ts' \
  'src/app/(seo)/<section>/<page>/page.tsx'

既存の問題が原因でリポジトリ全体の型チェックに失敗する場合は、阻害要因となっているファイルを正確に記録し、スキルの出力は実際に検証できた内容に絞ります。

出力要件

標準の成果物：

• 入力データから要点をまとめた簡潔な概要
• AnyCap ウェブサイトのトーンに合わせた記事の草稿
• 安定した公開ディレクトリに保存した生成アセット
• 複数のページで同じ証拠パターンが必要な場合に使う、再利用可能なコンテンツまたは UI コンポーネント1点
• アセットが何を証明するのかを説明するページコピー
• 実際のアーティファクトに合った代替テキスト、キャプション、プロンプトブロック
• 生成、検証、コードチェックを網羅した簡潔な検証メモ

ガードレール

• どの SaaS サイトにも当てはまるような、ありきたりな「AI ブログ」の文章は書かないでください。
• 提供されたデータで裏付けられる範囲を超えて、記事の内容を広げないでください。
• 長い前置きで回答を埋もれさせないでください。
• AnyCap の自社出力を見せることが要点なら、ストック画像を使わないでください。
• 動画や音楽のモデルによる実際の出力であるかのように、静止画像を提示しないでください。
• ページで特に必要とされていない限り、ショーケース用の素材に見えるテキストや透かしを残さないでください。
• ラッパーがベースページをすでに再利用している場合は、ローカライズしたページ実装を重複させないでください。
• 不足しているのが証拠である場合に、ありきたりな文章でページを水増ししないでください。
• ページのトピック、キーワードクラスター、ニッチ固有の名詞をスキル自体に埋め込まないでください。それらは再利用可能なワークフローではなく、実際のタスク入力に属します。

クイックリファレンス

# Check auth and feature availability
anycap status

# Normalize the topic with a small brief before writing
# Then inspect model parameters only if the article truly needs media

# Discover image models and parameters
anycap image models
anycap image models <model> schema --operation generate --mode text-to-image

# Generate a page-specific artifact
anycap image generate --model <model> --prompt "..." -o web/public/content-evidence/<page-slug>-hero.png

# Validate the artifact with vision
anycap actions image-read --file web/public/content-evidence/<page-slug>-hero.png --instruction "Describe this image and mention visible text."

# Compress a heavy PNG to JPG
sips -s format jpeg -s formatOptions 80 web/public/content-evidence/<page-slug>-hero.png --out web/public/content-evidence/<page-slug>-hero.jpg