Run any Skill in Manus with one click

deepresearch-readme

Stars81

Forks3

UpdatedMarch 3, 2026 at 04:09

GitHub OSS向け README.md の作成・改善・レビューを支援する。What/Why/How to start/Help/Maintainers の軸で情報を整理し、最短で動かせる Quickstart と docs への導線を構成する。 READMEの新規作成、既存READMEの再構成、READMEレビュー、ドキュメント分割の判断時に使用する。トリガー：「READMEを作って」「READMEを改善して」「Quickstartを追加して」「GitHub向けREADMEテンプレ」「READMEをレビューして」などのREADME関連リクエスト。

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

j5ik2o

j5ik2o/okite-ai

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

name

deepresearch-readme

description

Deepresearch Readme

GitHub OSS向けREADMEを、短時間で「何ができるか」と「どう始めるか」が伝わる状態に整える。

進め方

前提を確定する。

プロジェクト種別を特定する: ライブラリ / CLI / Webアプリ / GitHub Action
対象読者を特定する: 利用者 / 評価者 / コントリビューター
READMEの目的を確定する: 新規作成 / 改善 / レビュー

ファーストビューを構成する。

H1にプロジェクト名を書く
1〜2文で価値を書く（技術スタック説明より先に価値を出す）
Quickstartへの最短導線を置く
必要な主要リンクだけを置く（Docs、Issues、Releases）

Quickstartを最短化する。

Requirements、Install、Run の順で3〜6行程度に収める
実際に実行できるコマンドだけを残す
OS差分が長くなる場合は docs/installation.md へ分離する

構成を仕上げる。

セクションは以下を基本とする:
Highlights
Quickstart
Usage
Documentation
Getting help
Contributing
License
詳細説明は docs/ に切り出し、READMEには相対リンクだけ残す

最終検証を行う。

5分以内に「導入→最小実行」までたどれるか確認する
リンク切れ、前提バージョン、手順の古さを確認する
references/readme-review-checklist.md で網羅確認する

出力テンプレート

README本文を作るときは references/readme-template.md のテンプレートを優先して使う。

レビュー方針

既存READMEをレビューするときは以下を優先する。

Critical

Quickstartが実行不能
必須情報（What/How to start/Help）が欠落
READMEが巨大化し、開始手順が埋もれている

Warning

セクション順が読み手の意思決定順とずれている
docsへの導線が弱い
バッジやリンクが多すぎて価値が伝わりにくい

Info

表現の簡潔化
例の追加（CLI実行例、最小コード例）
FAQやトラブルシューティングへの導線追加

参照ファイル

実践チェックリスト: references/readme-review-checklist.md
README雛形: references/readme-template.md

More from this repository

same repository

pr-green

j5ik2o/okite-ai

Pull Request をグリーンにするスキル。CI チェックの失敗解消と、PR に紐づく Issue の修正・クローズを一括で実行する。GitHub Actions の CI ログ分析、ローカル CI （`./scripts/ci-check.sh`）の実行、エラーの根本原因特定と修正、PR コメントやリンクされた Issue の解消を含む。解消した Issue は確認後にクローズする。ループモード（`/loop 5 /pr-green`）にも対応し、自律的に CI 監視・修正・プッシュを繰り返す。トリガー：「PR をグリーンにして」「CI を通して」「CI エラーを直して」「PR の issue を解消して」「PR を修正して」「CI が落ちている」「テストが失敗している」「PR のレビュー指摘を直して」「PR を mergeable にして」といった PR 修正・CI 解消関連リクエストで起動。PR 番号が指定されなくても、現在のブランチから自動検出して対応する。

2026-03-2181

aggregate-design

j5ik2o/okite-ai

DDDの集約(Aggregate)設計ルールに基づくコードレビュー・設計支援・リファクタリングを行う。 Evans Rules、Vernon's 4 Rules、Design by Contractに基づき、集約の境界定義、不変条件の検証、不変(Immutable)設計、ID参照、結果整合性、ドメインイベント連携を包括的にガイドする。以下のいずれかに該当する場合は必ずこのスキルを使用すること： - 集約(Aggregate)の新規設計・実装・リファクタリング（どの言語でも） - 既存の集約やエンティティクラスのDDD観点でのコードレビュー - 集約の境界決定（「AとBは同じ集約にすべきか？」「この集約は大きすぎるか？」） - 集約内の不変条件・整合性境界の設計 - 集約間の連携方式の判断（ドメインイベント、結果整合性、Sagaパターン） - 可変(Mutable)な集約コードを不変(Immutable)設計にリファクタリングする - publicフィールド、直接参照、push/appendなどカプセル化違反の検出・修正キーワード例：集約、Aggregate、aggregate boundary、集約ルート、AggregateRoot、エンティティ設計、DDD実装、Vernon Rules、Evans Rules、集約の分割、真の不変条件

2026-03-1181

aggregate-transaction-boundary

j5ik2o/okite-ai

集約とトランザクション境界の関係を明確化し、複数集約を単一トランザクションに含めるアンチパターンを検出・是正する。集約は強い整合性境界であり、ユースケースで複数集約を更新する場合は結果整合性を使うべきという原則を適用する。コードレビュー、ユースケース設計、リファクタリング時にトランザクション境界の問題を検出する場合に使用。対象言語: 言語非依存（Java, Kotlin, Scala, TypeScript, Go, Rust, Python等すべて）。トリガー：「複数集約を同じトランザクションで更新している」「ユースケースに@Transactionalがある」「集約間の整合性をどう取るか」「Sagaパターンを使うべきか」「トランザクション境界の設計」「1トランザクション1集約」「結果整合性の実装」「集約をまたぐトランザクション」といったトランザクション境界関連リクエストで起動。

2026-03-0381

backward-compat-governance

j5ik2o/okite-ai

後方互換性がゴミコードを量産する構造を検出し、互換性を「契約と撤去計画」として管理するガバナンスを支援するスキル。公開API境界の明確化、非推奨化サイクル（deprecation cycle）の制度化、互換層の局所化（Adapter/Strangler Fig）、契約テスト（CDC）による互換性検証、 AI生成コードの互換性ゲート設計を含む。コードレビュー、API設計、リファクタリング、レガシー移行時に互換性起因の技術的負債を防ぐために使用。対象言語: 言語非依存（Java, TypeScript, Go, Python, Rust等すべて）。トリガー：「後方互換性を保ちたい」「非推奨APIをどうする」「互換層が増えてきた」「レガシー移行の戦略」「API設計レビュー」「互換性のためのコードが多い」「deprecation policyを作りたい」「破壊的変更の管理」といった互換性管理関連リクエストで起動。

2026-03-0381

breach-encapsulation-naming

j5ik2o/okite-ai

getterの濫用を防ぐための命名規約スキル。ドメインモデルでgetterが必要な場合（永続化、JSON変換など）に `breachEncapsulationOf` プレフィックスを付与することで、カプセル化を破っていることを明示する。これにより、Tell Don't Ask原則の違反を未然に防ぎ、getterの意図しない使用を抑制する。コードレビュー、新規実装、リファクタリング時にgetter設計が必要な場合に使用。対象言語: Java, Kotlin, Scala, TypeScript, Python, Go, Rust。トリガー：「getterの命名規約」「カプセル化を破るgetter」「永続化用のgetter」「breachEncapsulation」「getterを作りたいが濫用を防ぎたい」といったgetter命名関連リクエストで起動。

2026-03-0381

clean-architecture

j5ik2o/okite-ai

クリーンアーキテクチャを採用しているプロジェクト向けの設計・レビュー支援。4層構造（ドメイン層、ユースケース層、インターフェースアダプタ層、インフラストラクチャ層）に基づく。特にインフラ層は横断的関心事（ロギング、設定管理）のみ、永続化やRPCはインターフェースアダプタ層に配置すべきという原則を適用する。トリガー：「クリーンアーキテクチャで」「クリーンアーキテクチャに従って」「クリーンアーキテクチャのレビュー」など、クリーンアーキテクチャを明示的に指定した場合のみ起動。一般的な「設計レビュー」「アーキテクチャ相談」では起動しない。

2026-03-0381

name

deepresearch-readme

description

Deepresearch Readme

GitHub OSS向けREADMEを、短時間で「何ができるか」と「どう始めるか」が伝わる状態に整える。

進め方

前提を確定する。

プロジェクト種別を特定する: ライブラリ / CLI / Webアプリ / GitHub Action
対象読者を特定する: 利用者 / 評価者 / コントリビューター
READMEの目的を確定する: 新規作成 / 改善 / レビュー

ファーストビューを構成する。

H1にプロジェクト名を書く
1〜2文で価値を書く（技術スタック説明より先に価値を出す）
Quickstartへの最短導線を置く
必要な主要リンクだけを置く（Docs、Issues、Releases）

Quickstartを最短化する。

Requirements、Install、Run の順で3〜6行程度に収める
実際に実行できるコマンドだけを残す
OS差分が長くなる場合は docs/installation.md へ分離する

構成を仕上げる。

セクションは以下を基本とする:
Highlights
Quickstart
Usage
Documentation
Getting help
Contributing
License
詳細説明は docs/ に切り出し、READMEには相対リンクだけ残す

最終検証を行う。

5分以内に「導入→最小実行」までたどれるか確認する
リンク切れ、前提バージョン、手順の古さを確認する
references/readme-review-checklist.md で網羅確認する

出力テンプレート

README本文を作るときは references/readme-template.md のテンプレートを優先して使う。

レビュー方針

既存READMEをレビューするときは以下を優先する。

Critical

Quickstartが実行不能
必須情報（What/How to start/Help）が欠落
READMEが巨大化し、開始手順が埋もれている

Warning

セクション順が読み手の意思決定順とずれている
docsへの導線が弱い
バッジやリンクが多すぎて価値が伝わりにくい

Info

表現の簡潔化
例の追加（CLI実行例、最小コード例）
FAQやトラブルシューティングへの導線追加

参照ファイル

実践チェックリスト: references/readme-review-checklist.md
README雛形: references/readme-template.md