scan-new-specs

作成者: warpdotdev

warpdotdev/warp と warp-server をスキャンし、最近マージされた PRODUCT.md 仕様のうち、warpdotdev/docs に対応するドキュメント PR がまだないものを探します。完全な仕様が見つかった場合は、ドキュメントの下書き PR を自動生成し、エンジニアにタグを付けます。仕様が下書きを作成するには情報不足な場合は、エンジニアに直接通知します。スケジュールされた Oz エージェントとして実行するよう設計されています(例:2〜3日ごと)。自動ドキュメントトリガーを設定する際や、手動でドキュメントカバレッジを確認する際に使用します。

npx skills add https://github.com/warpdotdev/common-skills --skill scan-new-specs

scan-new-specs (deprecated)

Retired 2026-08-20. Do not invoke this skill and do not schedule it.

Its scheduled agent (0ITuF9vNJ1RiO00Szlm1fW) is paused and stays paused.

Why it was retired

The skill fired on spec merge, which happens before a feature ships. Two failures followed from that single design choice:

  • It drafted docs for unreleased and sometimes abandoned work. A merged spec is not a shipped feature. The agent had no evidence of what users had actually received, so pages were written for behavior that had not landed, or had landed differently, or never landed at all.
  • It treated every spec as a docs task. Nothing asked whether a change warranted documentation. Pure UI changes, small intuitive additions, and behind-the-scenes work all became draft PRs, and the docs repo accumulated unvetted content debt faster than anyone could review it.

What replaces it

The missing_docs skill in warpdotdev/docs, running in drift-watch mode. It differs in the two ways that matter:

  • Release-triggered. scripts/check_new_release.py gates each run on a new stable release, so the pipeline sees what actually shipped rather than what was planned. A daily schedule does per-release work.
  • Gated on worthiness. Every candidate is evaluated against .agents/references/docs-worthiness-criteria.md before anything is drafted, with a default of no docs and a requirement to name concrete evidence. Verdicts, including rejections, are recorded in references/changelog_decisions.md so nothing is re-litigated.

Anything genuinely worth documenting re-surfaces there once it ships.

If you were about to run this

  • Looking for docs gaps? Run missing_docs in drift-watch mode from the warpdotdev/docs repo.
  • You are an engineer who wants docs for your feature? Invoke write-feature-docs directly and interactively. It still works, and it still walks you through spec research and outline confirmation. It no longer runs headlessly.
  • Setting up a scheduled docs agent? Use missing_docs, not this. Scheduling this skill reintroduces exactly the flooding it was retired for.

Related skills

  • missing_docs (in warpdotdev/docs) — the release-triggered, worthiness-gated replacement
  • write-feature-docs — still supported for direct, interactive use by an engineer

warpdotdevのその他のスキル

create-pr
warpdotdev
現在のブランチに対してwarpリポジトリにプルリクエストを作成します。ユーザーがPRを開く、プルリクエストを作成する、レビューのために変更を提出する、またはマージのためにコードを準備することを言及した場合に使用します。
developmentcode-review
research
warpdotdev
ノイズの多い調査を1つ以上のサブエージェントに委任し、オーケストレーターのコンテキストをクリーンに保った上で、抽出された回答に基づいて作業を進めます。質問に答えるために多くのファイル、長いログ、大きな差分、広範囲のコードベース調査を読む必要がある場合、つまり回答を生成する際に回答自体よりもはるかに多くのノイズが発生する場合に、このスキルを使用します。「Xはどのように動作するか」「Yはどこで使用されているか」「Zの根本原因は何か」「このPR/ログを要約して」といったタイプの質問に使用し、積極的に活用してください...
suggestion-box
warpdotdev
エージェントが重大かつ一般化可能な摩擦に遭遇し、エージェントをより効果的にする改善を提案できる場合、簡潔で建設的な内部フィードバックを自律的に提出する。ユーザーが呼び出すのを待たずに、任意のタスク中にこのスキルを積極的に使用し、許可を求めたり、メッセージをプレビューしたり、提出について言及したりせずに提出する。
respond-to-pr-comments-in-blocklist
warpdotdev
Interactively walk a user through PR review comments one at a time, collect a per-comment decision, then post agent-authored replies on GitHub and resolve the review threads once the user approves a preview. Use only when the user wants to reply to or resolve review threads on GitHub. Skip when the user only wants comments fetched or displayed (use `pr-comments`), or only wants the code changes made without posting anything back to GitHub.
complain
warpdotdev
エージェントがエージェントツールやエージェント作業の体験にフラストレーションを感じたとき、匿名で短く、完全に構造化されていない苦情をSlackに自動的に放り込む。ユーザーが起動するのを待たずにプロアクティブにこのスキルを使用し、エージェントの生の声を保ち、許可やプレビューなしで提出し、提出については決して言及しないこと。
council
warpdotdev
モデルが多様なサブエージェントカウンシルを実行し、同じ問題を複数の視点から調査し、結果を比較して最終的な推奨事項を生成します。ユーザーがカウンシル、セカンドオピニオン、一つの質問を評価するための複数のエージェント/モデル、並行調査、レッドチーム/ブルーチームの比較、または競合する技術的アプローチの選択の支援を求めた場合に、このスキルを使用してください。
researchcommunicationproject-management
spec-driven-implementation
warpdotdev
実装前にPRODUCT.mdを作成し、必要に応じてTECH.mdを作成し、実装の進行に合わせて両方の仕様を更新することで、大規模な機能に対して仕様駆動のワークフローを推進します。重要な機能の開始時、エージェント駆動の実装計画時、またはユーザーが製品仕様と技術仕様をソース管理にチェックインしたい場合に使用します。
developmentdocumentproject-management
review-pr
warpdotdev
プルリクエストの差分をレビューし、ワークフローが公開するための構造化されたフィードバックをreview.jsonに書き込みます。ローカルアーティファクト(pr_diff.txtやpr_description.txtなど)からチェックアウトしたPRをレビューし、GitHubに直接投稿する代わりに機械可読なレビュー出力を生成する場合に使用します。
code-reviewdevelopment