Skill.md検索

過去に実際に発生したバグパターンを参考に、PRマージ前に問題を見落とさず検出できます。 バックエンド（Go）とフロントエンド（Next.js/TypeScript）の両方の言語別チェックポイントを確認できるため、フルスタック開発チームで品質を統一できます。 環境変数のハードコーディング・テスト設定漏れ・型名の不一致・認証状態の更新タイミングなど、再発しやすい具体的な問題を予防できます。 チェックリスト形式なので、誰でも均一な品質でセルフレビューでき、レビュー漏れを削減できます。 Go・Next.jsで開発するフルスタック開発者 PRマージ前に品質を確保したい開発チーム 過去のバグを繰り返さないようにしたいプロジェクトリード APIレスポンスの型一致やSSRハイドレーション（サーバーとクライアント同期）の問題に悩むフロントエンド開発者 このスキルは、過去のfixコミット履歴から抽出した実際の問題パターンに基づくセルフレビューチェックリストです。Go向けには、環境変数のハードコーディング防止・go mod tidy実行・テスト時のServerConfig設定・モック動作の一致・APIレスポンスのプリミティブ型変換を確認します。Next.js/TypeScript向けには、APIレスポンスプロパティ名の一致・変数重複宣言・useSearchParams/usePathname のSuspense対応・SSR時のlocalStorage参照回避・ダークモード対応・OAuth/2FAコールバック後の認証状態更新確認・URLトークンクリア・null/undefinedハンドリングを確認します。各項目はチェックボックス形式で、関連するfixコミット番号と対策を記載します。

ファイルを編集する前に現在のブランチを確認し、mainブランチへの誤った直接編集を防ぐことができます 修正内容に応じてfeat（新機能）、fix（バグ修正）などの規則に従ったブランチを自動で作成でき、コードの管理が整理されます 新しいブランチを作成する際の命名規則が示されるため、チーム全体で統一されたGitワークフローが実現します コミットメッセージもConventional Commits形式で統一され、プロジェクト履歴が読みやすく保たれます チーム開発で、mainブランチを誤って変更してしまったことがある開発者 Gitワークフローを統一したいチームリーダーやプロジェクトマネージャー ブランチ戦略を導入したいものの、どの命名規則を使えばいいか分からない初心者開発者

Issue作成時にテンプレートに従うことで、バグ報告や機能提案に必要な情報を漏れなく含められます 既存のIssueとの重複を防ぎ、タイプ別（Bug・Feature・Task等）に分類することで、プロジェクト内の課題が整理されます ラベル（優先度・領域・ステータス等）を活用することで、複数のIssueの中から自分が対応すべきものをすぐに見つけられます 受け入れ基準をチェックリスト形式で明確に定義するため、Issue完了の判定が明確になり、チーム内の認識のズレが減ります プロジェクトマネージャーやチームリーダーで、Issueの品質を高めたい人 バグ報告を受け取る側で、必要な情報が不足していることに困っている開発者 複数人で開発しており、誰が何を対応するのか一目で分かるようにしたい人