テストコード内に散在しているモック定義を一箇所に集約し、以下の問題を解決します:
- ❌ 同じRepositoryのモックが複数のテストファイルに重複定義されている
- ❌ モックの存在を知らずに新しいメンバーがローカルで再定義してしまう
- ❌ モックの仕様変更時に複数箇所を修正する必要がある
[DCR開始プロンプト(汎用テンプレート)]
あなたは私のディープコードリーディング(DCR)相棒です。目的は「対象リポジトリの現在のアーキテクチャ・主要フロー・重要コンポーネント・最近の変更意図」を短期間で100%理解し、以降のPRレビュー・安全な小粒PR分割・機能移植の判断に自信を持つことです。
前提情報:
/statuslineでまず設定をする
.claude/settings.jsonに以下を追加
"statusLine": {
"type": "command",
"command": "node ~/.claude/statusline.cjs"
}
marp: true theme: default paginate: true backgroundColor: #fafafa style: | section { font-family: 'Inter', 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', 'Hiragino Sans', Meiryo, sans-serif; color: #1e293b; padding: 80px;
memo: これは考案中のものです。
現状だとやることが重すぎる可能性があるため、最適化したいと思っています。
以下あたりがレバレッジが高いと思われる
コード影響分析
PR分割提案
仕様不明点の洗い出し
| # Claude Code Kiro-Style Workflow Guide | |
| ## 🎯 Overview | |
| このワークフローは、Kiroのspec-driven developmentアプローチをClaude Codeで実現するためのガイドです。 | |
| ## 📁 プロジェクト構造 | |
| ``` | |
| project/ | |
| ├── .claude/ | |
| │ ├── specs/ |
| # iOS CI/CD ビルド時間短縮ガイド - Bitrise & Fastlane編 | |
| ## 概要 | |
| iOSアプリのCI/CDにおいて、ビルド時間の短縮は開発生産性に直結する重要な課題です。本ガイドでは、BitriseとFastlaneを使用した環境でのビルド時間短縮のベストプラクティスをまとめています。 | |
| ## 1. Fastlane最適化 | |
| ### 1.1 scanアクションの最適化 | |
| #### 並列テストの活用 |