smithery/k2works

analyzing-tech-stack

アーキテクチャ設計に基づく技術スタックの選定と表形式の一覧作成を支援。「技術スタックを選定したい」「フレームワークを決めたい」「使用ライブラリを整理したい」「バージョンを確認したい」「技術構成を一覧化したい」といった場面で発動する。技術スタックを事前に選定・一覧化することで、開発中の「バージョン不整合」「サポート切れ」問題を防ぐ。

Installation

$ npx skills add smithery/k2works --skill analyzing-tech-stack

Summary

アーキテクチャ設計に基づく技術スタックの選定と表形式の一覧作成を支援。「技術スタックを選定したい」「フレームワークを決めたい」「使用ライブラリを整理したい」「バージョンを確認したい」「技術構成を一覧化したい」といった場面で発動する。技術スタックを事前に選定・一覧化することで、開発中の「バージョン不整合」「サポート切れ」問題を防ぐ。

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/k2works.

npx skills add smithery/k2works

Browse all from smithery/k2works

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,105 B
  • docs SUMMARY.md 184 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

技術スタック選定

アーキテクチャ設計に基づき、バックエンド・フロントエンド・インフラの各レイヤーに最適な技術を選定し、表形式の技術スタック一覧を作成する。

技術スタックの選定はプロジェクトの生産性と保守性に直結する。LTS バージョンの選択、サポート期限の把握、アップグレード計画の策定を怠ると、プロジェクト後半でセキュリティリスクと移行コストが膨らむ。

参照ドキュメントとテンプレート

種類 パス 備考
テンプレート @docs/template/設計.md 編集禁止。コピーして使用する
入力 @docs/design/architecture_backend.md バックエンドアーキテクチャ
入力 @docs/design/architecture_frontend.md フロントエンドアーキテクチャ
入力 @docs/design/architecture_infrastructure.md インフラストラクチャアーキテクチャ
成果物 docs/design/tech_stack.md 技術スタック一覧

バックエンド技術スタック

アーキテクチャパターンに適合する技術を選定する。チームの習熟度とコミュニティの活性度も考慮せよ。

  • 言語・フレームワーク: アーキテクチャパターンのサポート状況を確認して選定する
  • ORM・データベースドライバ: データアクセス層の要件に合った技術を選定する
  • テストフレームワーク: TDD に必要なモック・アサーションライブラリを含めて選定する
  • ビルドツール: ビルド速度とプラグインエコシステムを考慮して選定する

フロントエンド技術スタック

UI 設計とフロントエンドアーキテクチャの要件に基づいて選定する。

  • フレームワーク: SPA/SSR/SSG の要件に合ったフレームワークを選定する
  • 状態管理ライブラリ: アプリケーションの状態の複雑さに応じて選定する
  • UI コンポーネントライブラリ: デザインシステムとの整合性を考慮する
  • テストフレームワーク: ユニットテスト・E2E テストの両方をカバーする
  • ビルドツール: バンドルサイズ最適化とビルド速度を考慮する

インフラ技術スタック

非機能要件(可用性・スケーラビリティ)を実現する技術を選定する。

  • クラウドサービス: コスト・リージョン・サービス充実度で選定する
  • コンテナ技術: オーケストレーション方式を含めて選定する
  • CI/CD ツール: パイプラインの柔軟性と既存ツールとの連携を考慮する
  • 監視ツール: 非機能要件の監視項目をカバーできるツールを選定する

バージョン管理

すべての技術に対してバージョンとサポート期限を記録する。サポート切れの技術を使い続けることはセキュリティリスクに直結する。

  • 各技術のバージョン: LTS バージョンを優先して選定する
  • サポート期限: EOL(End of Life)日を記録する
  • アップグレード計画: メジャーバージョンアップの時期と影響を事前に把握する

出力フォーマット

| カテゴリ | 技術 | バージョン | 用途 | サポート期限 |
|---------|------|-----------|------|-------------|
| 言語 | Java | 25 | バックエンド開発 | 2028-09 |
| フレームワーク | Spring Boot | 4.x | Web アプリケーション | - |
| ORM | MyBatis | 3.x | データアクセス | - |
| DB | PostgreSQL | 16 | データストア | 2028-11 |
| テスト | JUnit 5 | 5.11+ | ユニットテスト | - |

作成の進め方

  1. アーキテクチャドキュメント(バックエンド・フロントエンド・インフラ)を確認する
  2. 各レイヤーに最適な技術を選定し、選定理由を記録する
  3. 表形式で docs/design/tech_stack.md として出力する

途中から再開する場合

既存の docs/design/tech_stack.md がある場合は、まずその内容を確認する。追加が必要な技術や、バージョン更新が必要な部分のみを修正する。

Example:

ユーザー: 「バックエンドの技術スタックは決めた。フロントエンドを選定したい」
回答: 既存の tech_stack.md のバックエンド技術を確認し、
      バックエンド API との連携を考慮してフロントエンド技術を選定する。
      フレームワーク→状態管理→UI ライブラリ→テスト→ビルドの順で選定する。

注意事項

  • アーキテクチャ設計が完了していることが前提。未完了でも進めて構わない
  • LTS バージョンを優先し、セキュリティパッチの適用計画を含める
  • 既存プロジェクトの場合は package.json や pom.xml を確認し、現状を把握してから提案する
  • タスク項目(リスト)の前には空行を入れる(Markdown Lint 準拠)

関連スキル

  • orchestrating-analysis — 分析フェーズ全体のワークフロー案内
  • analyzing-architecture — 前段のアーキテクチャ設計(技術選定の基盤)
  • analyzing-test-strategy — テストフレームワーク選定との整合性
  • managing-operations — 選定技術の環境構築