Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

code-review

Estrellas1

Forks0

Actualizado19 de febrero de 2026 a las 13:06

コードレビューを体系的に実施する。PRレビュー、コード品質チェック、リファクタリング提案、ベストプラクティスの確認時に使用する。「レビューして」「コードを見て」「品質チェック」などのリクエストで発動。

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

neelbauman

neelbauman/claude-skills-repo

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Analistas de garantía de calidad de software y probadoresOcupaciones informáticas y matemáticas·SOC 15-1253

Explorador de archivos

4 archivos

SKILL.md

readonly

name	code-review
description	コードレビューを体系的に実施する。PRレビュー、コード品質チェック、リファクタリング提案、ベストプラクティスの確認時に使用する。「レビューして」「コードを見て」「品質チェック」などのリクエストで発動。
tags	coding, review, quality

Code Review

コードレビューを体系的かつ建設的に行う。

レビュー観点

以下の優先順で確認する:

正確性: ロジックにバグや意図しない動作がないか
セキュリティ: インジェクション、認証漏れ、機密情報のハードコード
パフォーマンス: N+1クエリ、不要なループ、メモリリーク
可読性: 命名、関数の粒度、コメントの適切さ
テスタビリティ: テストしやすい設計か、エッジケースの考慮

出力フォーマット

指摘は以下の形式で整理する:

🔴 Critical: 修正必須（バグ、セキュリティ）
🟡 Warning: 強く推奨（パフォーマンス、設計上の問題）
🟢 Suggestion: 改善提案（可読性、慣習）
💡 Note: 良い点やFYI

各指摘には対象箇所、理由、改善案を含める。

原則

批判ではなく改善提案として伝える
良い点にも触れる（ポジティブフィードバック）
「なぜ」を説明する（単なるスタイル好みは押し付けない）
プロジェクトの規約があればそれに従う

Más de este repositorio

mismo repositorio

doorstop-spec-driven

neelbauman/claude-skills-repo

仕様駆動開発（Specification-Driven Development）を自律的に実行するスキル。コーディングエージェントが、ユーザーの自然言語による要望を受け取り、 Doorstopによる要件→仕様→実装→テストの全ライフサイクルを自動的に管理する。ユーザーは「〜を作って」「〜を直して」と言うだけでよい。エージェントがREQ/SPEC/IMPL/TSTアイテムの作成および修正・リンク・バリデーション・影響分析をすべて自動で行い、コードの実装・テストも並行して実施する。「機能を追加して」「バグを直して」「仕様を変更して」「リファクタリングして」のような開発リクエスト全般でトリガーすること。コードを書く前に必ずこのスキルを参照し、要件→仕様→設計→実装のトレーサビリティを守ること。

2026-03-151

bdd-behave-expert

neelbauman/claude-skills-repo

Python 環境における BDD（Gherkin + behave）自動テスト実装を専門的に支援するコーディングエージェント向けスキル定義。 spec-weaver の trace 機能を前提とし、仕様・設計・実装を逆引きしながら「あるべき振る舞い」をテストとして固定化する。テストが現在の実装と乖離して失敗することは設計上正常であり歓迎される。ユーザーが「behave」「BDDテスト」「Gherkin実装」「ステップ定義」「step定義」「featureファイル実装」「behaveテスト」「受け入れテスト」を話題にした場合、または既存のfeatureファイルに対応するステップ定義を書く場合は必ずこのスキルを使うこと。

2026-03-021

dev-lifecycle

neelbauman/claude-skills-repo

Doorstop + Gherkin + Spec-Weaver で仕様管理された開発ライフサイクル全体（分析→設計→計画→実装→検証・コミット）を統制するスキル。実装計画をPLANドキュメントとしてDoorstopに永続化し、拡張ドキュメント階層（DESIGN/PLAN/ADR/RESEARCH）を管理する。ユーザーが要件や仕様を伝えた場合、および開発に取り組む場合は必ずこのスキルを使うこと。ユーザーが「開発」「実装」「設計」「ADR」「仕様」「要件」を話題にした場合もこのスキルをつかうこと。

2026-03-021

doorstop-gherkin-spec

neelbauman/claude-skills-repo

Doorstop（テキストベースの要件管理CLI）とGherkin（.feature形式の振る舞い仕様）、およびそれらを繋ぐSpec-WeaverというCLIツールを組み合わせた、仕様管理プロセスのサポートスキル。新規プロジェクトのDoorstop初期化・YAML作成・featureファイル生成から、要件・仕様・featuresの更新に伴う整合性更新、既存プロジェクトのコードベース分析による仕様の逆引き初期化まで対応する。ユーザーが「仕様管理」「仕様更新」「Doorstop」「Gherkin」「要件定義」「.feature」「BDD」「受け入れ条件」「Spec-Weaver」「トレーサビリティ」を話題にした場合、または既存プロジェクトに仕様管理を導入・整備したい場合は必ずこのスキルを使うこと。

2026-03-021

spec-organize

neelbauman/claude-skills-repo

Doorstop + Gherkin 仕様管理のドキュメントレビューと再編スキル。増えたドキュメントが整合性をもって記述・配置されているかをチェックし、必要があれば再整理（分割・集約・階層変更）を提案・実行する。ユーザーが「仕様を見直したい」「ドキュメントが増えてきた」「構造を整理したい」「仕様のレビュー」「再編」「整合性チェック」「ドキュメント整理」「分割」「集約」「統合」「階層変更」「親を変える」を話題にした場合は必ずこのスキルを使うこと。

2026-03-021

flowchart-to-mermaid

neelbauman/claude-skills-repo

フローチャート画像を分析してMermaid記法に変換する。フローチャート、ダイアグラム、フロー図、プロセス図、状態遷移図、シーケンス図などの画像からMermaid生成を依頼された場合に使用する。「この図をMermaidにして」「フローチャートをコード化して」「画像からダイアグラムを再現して」などのリクエストで発動。画像処理スクリプトで前処理し、視認性を高めてから分析する。

2026-02-201

name	code-review
description	コードレビューを体系的に実施する。PRレビュー、コード品質チェック、リファクタリング提案、ベストプラクティスの確認時に使用する。「レビューして」「コードを見て」「品質チェック」などのリクエストで発動。
tags	coding, review, quality

Code Review

コードレビューを体系的かつ建設的に行う。

レビュー観点

以下の優先順で確認する:

正確性: ロジックにバグや意図しない動作がないか
セキュリティ: インジェクション、認証漏れ、機密情報のハードコード
パフォーマンス: N+1クエリ、不要なループ、メモリリーク
可読性: 命名、関数の粒度、コメントの適切さ
テスタビリティ: テストしやすい設計か、エッジケースの考慮

出力フォーマット

指摘は以下の形式で整理する:

🔴 Critical: 修正必須（バグ、セキュリティ）
🟡 Warning: 強く推奨（パフォーマンス、設計上の問題）
🟢 Suggestion: 改善提案（可読性、慣習）
💡 Note: 良い点やFYI

各指摘には対象箇所、理由、改善案を含める。

原則

批判ではなく改善提案として伝える
良い点にも触れる（ポジティブフィードバック）
「なぜ」を説明する（単なるスタイル好みは押し付けない）
プロジェクトの規約があればそれに従う