메뉴
バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Marp Markdown スライドデッキの作成・拡張・再生成を支援。PlantUML 図表、AI 画像バリアント、漫画画像バリアント、PPTX/HTML 出力に対応。`tmp/k2works-wiki/スライド/YYYYMMDD` などの日本語技術スライドフォルダの構築・更新、コードサンプル追加、ビジュアル要約スライド追加、`スライド.images.md` / `スライド.images.ai.md` / `スライド.images.ai.manga.md` の生成、Marp HTML/PPTX デッキの再生成時に使用。
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
ビジネスアーキテクチャ分析を支援。要件定義の前段階として、ビジネスモデルキャンバス、バリューストリーム、ケイパビリティマップ、組織マップ、情報マップ、ビジネスシナリオを作成。「ビジネスモデルを整理したい」「バリューストリームを描きたい」「ケイパビリティマップを作りたい」「事業構造を分析したい」「ビジネスアーキテクチャを分析したい」「BA 分析をしたい」といった場面で発動する。ビジネスの全体像を理解してからシステム要件に落とし込むことで、本当に必要な機能を見極められる。
企業事例（ケーススタディ）の与件文作成を支援。経営戦略・マーケティング・生産管理・財務会計の 4 パターンから選択し、テンプレートのプレースホルダに対応する質問に回答することで与件文を生成する。「企業事例を作りたい」「ケーススタディを書きたい」「与件文を作成したい」「診断士試験の事例問題を作りたい」「仮想企業の事例を整理したい」といった場面で発動する。事例テンプレートに沿って体系的にヒアリングすることで、論理的整合性のある与件文を効率的に作成できる。
企業事例（与件文）を基に企業戦略・事業戦略・機能戦略の 3 階層を体系的に立案。環境分析（SWOT・VRIO・BMC）から始めて、ドメイン定義・成長戦略・競争戦略・価値連鎖・ケイパビリティマップまで、PlantUML を活用した可視化ドキュメントを作成する。「戦略を立案したい」「企業戦略を作りたい」「事業戦略を策定したい」「SWOT 分析をしたい」「VRIO 分析をしたい」「成長戦略を考えたい」「競争戦略を立てたい」「価値連鎖を分析したい」「ケイパビリティマップを作りたい」「診断士試験の戦略分析をしたい」「企業事例から戦略を導出したい」といった場面で発動する。事例と戦略をセットで扱うことで、経営コンサルティングの提案書や中小企業診断士の答案に相当する体系的な戦略ドキュメントを作成できる。
インセプションデッキの作成を支援。プロジェクトの「なぜ」「何を」「どうやって」を 10 の問いで整理し、チーム全体の認識を揃える。「インセプションデッキを作りたい」「プロジェクトの方向性を整理したい」「10 の問いに答えたい」「チームの認識を揃えたい」「プロジェクトを立ち上げる」といった場面で発動する。プロジェクトの方向性を最初に揃えておくことで、後工程での手戻りを大幅に減らせる。
| name | developing-backend |
| description | バックエンド開発の TDD ワークフローを支援。Red-Green-Refactor サイクルとインサイドアウトアプローチで品質の高いバックエンドを実装する。「バックエンドを実装したい」「API を作りたい」「サーバーサイドの機能を追加したい」「バックエンドのテストを書きたい」といった場面で発動する。TDD で開発することで、リファクタリングの安全網を確保し、変更を楽に安全にできるコードを維持する。 |
TDD サイクルに従いバックエンドを開発する。インサイドアウトアプローチ（データ層→ドメイン層→API 層）で、内側から外側へ段階的に構築する。
インサイドアウトの利点は、ドメインロジックのテストが外部依存なしで書けること。テストの実行速度が速く、フィードバックループを短く保てる。
| 種類 | パス |
|---|---|
| ワークフロー | @docs/reference/コーディングとテストガイド.md |
| アーキテクチャ | @docs/design/architecture_backend.md |
| データモデル | @docs/design/data-model.md |
| ドメインモデル | @docs/design/domain-model.md |
| 技術スタック | @docs/design/tech_stack.md |
| テスト戦略 | @docs/design/test_strategy.md |
10-15 分で 1 サイクルを完了させる。サイクルが長引くなら、タスクの粒度が大きすぎる。
# 全テスト実行
cd apps/backend && ./gradlew test
# 特定テストクラス実行
cd apps/backend && ./gradlew test --tests "UserServiceTest"
# テストカバレッジ確認
cd apps/backend && ./gradlew jacocoTestReport
# バックエンドを起動
cd apps/backend && ./gradlew bootRun
# Swagger UI: http://localhost:8080/swagger-ui.html
# OpenAPI JSON: http://localhost:8080/v3/api-docs
コミット前に必ず確認する。
開発セッションの途中から再開する場合は、まず現在のテスト状態を確認する。
Example:
ユーザー: 「ユーザー認証の Entity と Repository は実装済み。Service 層に進みたい」
回答: 既存テストを実行して Green 状態を確認する。
Service 層の失敗するテスト（Red）を書いてから実装に進む。
Repository の戻り値を使った Service のビジネスロジックをテストする。
タスクの区切りごとに /compact を実施して Context limit reached エラーを回避する。
/compact 前に現在の作業状態と次のタスクをメモとして出力するdeveloping-frontend — フロントエンド TDD 開発orchestrating-development — 開発フェーズ全体のワークフローgit-commit — Conventional Commits 準拠のコミット