k2works/analyzing-architecture
.agents/skills/analyzing-architecture/SKILL.md
バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成を支援。「アーキテクチャを設計したい」「システム構成を検討したい」「レイヤード/ヘキサゴナル/クリーンどれが適切か」「CQRS を導入すべきか」「フロントエンドのアーキテクチャを決めたい」といった場面で発動する。アーキテクチャを早期に設計することで、開発フェーズでの技術的負債の蓄積を防ぐ。
tools
Updated Apr 16, 2026
$ install --global
skillsauthnpx skillsauth add k2works/getting-started-tdd analyzing-architectureInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 16, 2026, 5:24 PM4.6s1 file scanned
SKILL.md
- name:
- analyzing-architecture
- description:
- バックエンド・フロントエンド・インフラのアーキテクチャパターン選択と設計ドキュメント作成を支援。「アーキテクチャを設計したい」「システム構成を検討したい」「レイヤード/ヘキサゴナル/クリーンどれが適切か」「CQRS を導入すべきか」「フロントエンドのアーキテクチャを決めたい」といった場面で発動する。アーキテクチャを早期に設計することで、開発フェーズでの技術的負債の蓄積を防ぐ。
アーキテクチャ設計
業務領域とデータ構造の複雑さに基づき、バックエンド・フロントエンド・インフラの各アーキテクチャパターンを選択し設計ドキュメントを作成する。
アーキテクチャは後から変えるコストが最も高い設計判断。要件定義の段階で適切なパターンを選定することで、開発全体の方向性を確定し、手戻りを最小化する。
参照ドキュメントとテンプレート
| 種類 | パス | 備考 |
|------|------|------|
| ガイド | @docs/reference/アーキテクチャ設計ガイド.md | アーキテクチャ設計の進め方詳細 |
| テンプレート | @docs/template/設計.md | 編集禁止。コピーして使用する |
| 入力 | @docs/requirements/requirements_definition.md | 要件定義 |
| 入力 | @docs/requirements/business_usecase.md | ビジネスユースケース |
| 入力 | @docs/requirements/system_usecase.md | システムユースケース |
| 入力 | @docs/requirements/user_story.md | ユーザーストーリー |
| 成果物 | docs/design/architecture_backend.md | バックエンドアーキテクチャ |
| 成果物 | docs/design/architecture_frontend.md | フロントエンドアーキテクチャ |
| 成果物 | docs/design/architecture_infrastructure.md | インフラストラクチャアーキテクチャ |
バックエンドアーキテクチャ設計
業務ロジックの複雑さに応じてパターンを選択する。単純な CRUD ならレイヤードで十分だが、ドメインが複雑な場合はヘキサゴナルやクリーンアーキテクチャを採用せよ。
- アーキテクチャパターンの選択: レイヤード、ヘキサゴナル、クリーン等から要件に最適なものを選定する
- CQRS/イベントソーシングの適用判断: 読み書きの特性が大きく異なる場合に検討する。過剰適用は複雑さを増すだけなので慎重に判断せよ
- API 設計方針: REST/GraphQL/gRPC の選択基準を明確にする
フロントエンドアーキテクチャ設計
ユーザー体験とチームのスキルセットを考慮して設計する。フレームワーク選定はプロジェクト全体に影響するため、ADR で判断根拠を残せ。
- フレームワーク選定: プロジェクト要件に合ったフレームワークを選択する
- 状態管理パターン: アプリケーションの状態の複雑さに応じて適切なパターンを選定する
- コンポーネント設計方針: 再利用性と保守性を両立する設計指針を定める
インフラストラクチャアーキテクチャ設計
非機能要件（可用性・スケーラビリティ）を実現するインフラ構成を設計する。運用コストとの兼ね合いも考慮せよ。
- クラウド/オンプレミス選定: コスト・セキュリティ・運用負荷を総合的に判断する
- コンテナ化戦略: コンテナ化の適用範囲とオーケストレーション方式を決定する
- CI/CD パイプライン設計: ビルド・テスト・デプロイの自動化方針を定める
作成の進め方
- 入力ドキュメント（要件定義、ユースケース、ユーザーストーリー）を確認する。なければ基本情報をヒアリングする
- @docs/reference/アーキテクチャ設計ガイド.md を読み込む
- バックエンド→フロントエンド→インフラの順に設計する。各アーキテクチャの選定理由を明記せよ
- 重要な設計判断は ADR（Architecture Decision Record）で記録する
途中から再開する場合
既存の docs/design/architecture_*.md がある場合は、まずその内容を確認する。不足している領域や更新が必要な部分のみを修正する。
Example:
ユーザー: 「バックエンドはクリーンアーキテクチャで決めた。フロントエンドを設計したい」
回答: 既存の architecture_backend.md を確認し、
バックエンドの API 設計方針を踏まえてフロントエンドアーキテクチャ設計に進む。
フレームワーク選定→状態管理→コンポーネント設計の順で作成する。
注意事項
- 要件定義とユースケースが完了していることが前提。未完了でもプロジェクト情報から進めて構わない
- アーキテクチャ決定は必ず ADR で記録する。「なぜその選択をしたか」が後で最も重要になる
- 業務の複雑さとチームのスキルセットを考慮して選択する。技術的に「正しい」選択よりチームが運用できる選択を優先せよ
- タスク項目（リスト）の前には空行を入れる（Markdown Lint 準拠）
関連スキル
orchestrating-analysis— 分析フェーズ全体のワークフロー案内analyzing-requirements— 前段の要件定義analyzing-domain-model— 後続のドメインモデル設計analyzing-data-model— 後続のデータモデル設計analyzing-tech-stack— 後続の技術スタック選定
Related Skills
k2works/validating-iteration-plan
tools
VerifiedTrustedCommunity
イテレーション計画と上流設計ドキュメント群（ユーザーストーリー、ドメインモデル、データモデル、UI 設計）との整合性を検証する。「イテレーション計画を検証したい」「計画の整合性をチェックして」「イテレーション計画を作成した」「計画と設計ドキュメントの不整合を確認したい」といった場面で発動する。planning-releases でイテレーション計画を作成した直後にも積極的に使用すること。計画作成後に必ず本検証を実施することで、開発着手前にドキュメント間の不整合を検知・修正できる。
SKILL.mdUpdated Apr 16, 2026
k2works/tracking-progress
tools
VerifiedTrustedCommunity
プロジェクトの開発進捗を多角的に分析しレポートを生成。イテレーション達成度、技術実装状況、品質メトリクスを確認し、計画ドキュメントを自動更新する。「進捗を確認したい」「プロジェクトの状態を知りたい」「イテレーションの達成度を分析したい」「進捗ドキュメントを更新したい」といった場面で発動する。定期的な進捗可視化により、遅延や品質低下を早期に発見しプロジェクトの透明性を確保する。
SKILL.mdUpdated Apr 16, 2026
k2works/syncing-github-project
testing
VerifiedTrustedCommunity
リリース計画を GitHub Project・Issue・Milestone に反映し一元管理。初回の一括同期から差異検出・自動同期まで対応する。「GitHub Project に同期したい」「Issue を作成したい」「計画と GitHub の差異を確認したい」「Milestone を設定したい」といった場面で発動する。計画ドキュメントを Single Source of Truth とし GitHub に自動反映することで、二重管理の手間と不整合を排除する。
SKILL.mdUpdated Apr 16, 2026
k2works/practicing-getting-start-tdd
development
VerifiedTrustedCommunity
テスト駆動開発から始めるプログラミング入門」の対話式チュートリアル。FizzBuzz を題材に TDD の Red-Green-Refactor サイクルを 14 言語で体験する。「TDD を練習したい」「FizzBuzz で TDD を学びたい」「テスト駆動開発の入門をしたい」「Java で TDD を体験したい」「Python で TDD を始めたい」「プログラミング入門チュートリアルをやりたい」「getting-start-tdd をやりたい」「TDD のハンズオンがしたい」「Red-Green-Refactor を体験したい」といった場面で発動する。TDD チュートリアルやプログラミング入門の要望があれば積極的に使用すること。
SKILL.mdUpdated Apr 16, 2026