Menu
短いニュース 1 件を `src/content/news/` に追加するスキル。「お知らせを 1 つ追加して」「○○のニュースを書いて」と言われたときに使用する。URL を伴う「ブログ記事化」は write-blog スキルを使うこと。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
サービス名と概要を受け取って `src/content/services/` 配下にサービスページを追加するスキル。「○○というサービスページを追加して」「新サービスのページを作って」と言われたときに使用する。
受け取った URL を読み込み、指定された深掘りポイントに沿ってブログ記事化し、`src/content/news/` 配下に Markdown ファイルを追加して PR を作成するスキル。「URL を渡すからブログ記事化して」「この記事をベースに ○○ を深掘りして」と言われたときに使用する。
ページ 1 枚または PR 全体を SEO 観点でレビューするスキル。title / description の長さ、見出し階層、内部リンク、JSON-LD、画像 alt を一通り確認する。「この記事を SEO レビューして」「PR の SEO チェックして」と言われたときに使用する。
Baseado na classificação ocupacional SOC
| name | update-news |
| description | 短いニュース 1 件を `src/content/news/` に追加するスキル。「お知らせを 1 つ追加して」「○○のニュースを書いて」と言われたときに使用する。URL を伴う「ブログ記事化」は write-blog スキルを使うこと。 |
| allowed-tools | Read, Write, Edit, Bash |
短い 1 件のお知らせ（リリース告知 / イベント開催 / 価格改定 / 採用 / 受賞 等）を
src/content/news/<slug>.md に追加する。
write-blog との違い:
| 用途 | スキル |
|---|---|
| URL を渡して長文の記事化（500〜1500 字） | write-blog |
| 1 件のお知らせ（200〜600 字） | update-news（本スキル） |
announcement, service, event, release など）不足している場合は「いつから」「誰向けに」を 必ず ユーザーに確認する。
ls src/content/news/
publishedAt を確認（同日付の複数追加は OK だが、内容が分かれているか確認）pricing-update-2026、spring-campaign、team-expansion）# slug 衝突チェック
test -e src/content/news/<slug>.md && echo "CONFLICT: <slug> already exists, choose another"
---
title: <30〜50 字、お知らせの中核を 1 文で>
description: <80〜120 字、検索結果のスニペットになる文>
publishedAt: <YYYY-MM-DD>
tags:
- announcement # ほぼ必須
- <内容に応じた追加タグ>
---
publishedAt は当日 (date +%Y-%m-%d) が原則。
未来日付は使わない（予約公開には対応していないため、未来日付は記事が「公開済みなのに古く見える」事故を招く）。
短いお知らせ用の構成（200〜600 字）:
<1 段落で「何が・いつから・誰向けに」を述べる>
## <h2 見出し：詳細 or 想定される問い合わせ>
- <ポイント 1>
- <ポイント 2>
- <ポイント 3>
詳細は [サービスページ](/services/<slug>) または [お問い合わせ](/contact) からご確認ください。
src/content/news/<slug>.md を新規作成。既存ファイルの上書き禁止。
pnpm astro check
pnpm build
両方 0 errors であること。
ローカルで確認する場合（任意。基本は不要）:
pnpm dev
# http://localhost:4321/news で先頭に追加した記事が出ているか確認
pnpm dev は他作業とポート衝突する可能性があるため、ビルドが通ればスキップして構わない。Vercel デプロイ後に /news で実際の表示を確認するのが基本ルート。
ブランチ名は feature/#<issue番号>-<short-slug> 形式（AGENTS.md「PR / レビューの方針」の宣言と整合）。Issue 番号は対話的にユーザーから受け取るか、必要なら gh issue create --assignee @me で先に発行する。
git checkout -b feature/#<issue>-news-<slug>
git add src/content/news/<slug>.md
git commit -m "docs: #<issue> add news <slug>"
git push -u origin feature/#<issue>-news-<slug>
gh pr create --draft --base develop \
--title "docs: #<issue> add news <slug>" \
--body "$(cat <<'EOF'
## 概要
<お知らせのタイトル + 一言要約>
## 公開日
<YYYY-MM-DD>
## 内部リンク先
- <関連サービス / お問い合わせ>
## 検証
- pnpm astro check: 0 errors
- pnpm build: 0 errors
EOF
)"
ニュース追加は低リスクなので、本人が内容を確認すれば auto-merge してよい。
publishedAt/services/... または /contact）の省略publishedAt / tagspnpm astro check / pnpm build が 0 errors）publishedAt 降順表示）