説明
できること
- 業務領域とデータ構造の複雑さに基づき、適切なアーキテクチャパターン(レイヤード、ヘキサゴナル、クリーン等)を選択してドキュメント化できます。
- バックエンドでCQRS(コマンド・クエリ責任分離)やイベントソーシングの導入判断を、過剰適用を避けながら検討できます。
- REST、GraphQL、gRPCなどのAPI設計方針を、プロジェクト要件に合わせて決定できます。
- フロントエンドフレームワークの選定から状態管理パターン、コンポーネント設計指針までを、チームスキルとUXを考慮して整理できます。
- クラウド・オンプレミス選定、コンテナ化戦略、CI/CDパイプラインなどのインフラ構成を、運用コストを踏まえて設計できます。
こんな人におすすめ
- 新規プロジェクトの技術構想をまとめる企画・PMの人
- プロジェクト初期段階で設計判断を記録したいアーキテクト・リードエンジニアの人
- 複雑なドメインに対応するアーキテクチャの選定に悩むチームリーダーの人
- 既存アーキテクチャの見直しや拡張を検討する開発チームの人
# アーキテクチャ設計 業務領域とデータ構造の複雑さに基づき、バックエンド・フロントエンド・インフラの各アーキテクチャパターンを選択し設計ドキュメントを作成する。 アーキテクチャは後から変えるコストが最も高い設計判断。要件定義の段階で適切なパターンを選定することで、開発全体の方向性を確定し、手戻りを最小化する。 ## 参照ドキュメントとテンプレート | 種類 | パス | 備考 | |------|------|------|
Skill.md 情報
- バージョン
- v1.0.0
- カテゴリ
- design-dev
- 作成日
- 2026-02-28
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール(Claude Code・Cursor・Copilot など)にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/k2works/getting-started-tdd" -o ~/.claude/skills/SKILL.md関連 Skill.md
SmartHR UI で規格に沿ったPRを素早く作成
by kufu
Conventional Commits形式に自動対応したPRタイトルを生成できるため、リリースノートに反映されやすいPRが作成できます PR本文テンプレートに沿った構造化された説明を自動生成することで、レビューに必要な情報を漏れなく記載できます 破壊的変更(!マーク)や関連URL、プロダクト側対応事項などを体系的に整理できるため、チーム全体の確認漏れを防げます gh CLIのHEREDOC形式に対応したコマンドを提供するため、手作業でのフォーマット確認が不要になります SmartHR UIリポジトリに定期的にコードを貢献する開発者 PR作成時にテンプレート形式を毎回確認するのが手間と感じている人 プロダクト側の対応が必要な変更を忘れずに記載したい人 Conventional Commitsのルールを正確に守りたい人 SmartHR UIリポジトリのPR作成ルールを定義します。PRタイトルはConventional Commits形式((): )で日本語記述し、破壊的変更は!で示します。PR本文は「関連URL」「概要」「変更内容」「プロダクト側で対応が必要な事項」「確認方法」の5セクションで構成し、該当なしの場合は「なし」と記載します。変更内容にはBefore/Afterコード例やキャプチャを添付し、破壊的変更の場合は具体的な対応方法を記載します。確認方法ではStorybookやChromatic URLを記載します。実行時はgh pr createコマンドのHEREDOC形式で本文を渡します。
Another Quick Switcherのリリース運用を自動化
by tadashi-aikawa
リリース前の検証(CI状態確認)から、Release workflowの実行、完了待機、新規releaseの検出まで一連のリリース運用を再現可能な手順で実行。 リリースノートから関連Issue・PRを自動抽出し、Issue返信文とSNS投稿案(Bluesky)を自動生成。手作業での返信文作成が不要。 --dry-runオプションで事前検証。本実行前に動作確認してからリリースを進められるので安全。 Codex LLMと同梱スクリプトの役割分離。確定的な検証・実行はスクリプト、非確定的な文章生成はLLMが担当する堅牢な設計。 obsidian-another-quick-switcherのメンテナー。毎回のリリース作業を効率化・標準化したい。 オープンソースプロジェクトの管理者。リリースフローの属人性を減らし、再現可能な手順を確立したい。 チーム開発で複数人がリリース対応する環境。誰でも同じ品質でリリース運用できる仕組みが欲しい。 GitHub Actionsと連携したリリース自動化を実装している人。リリースノート生成やIssue通知まで含めた完全自動化を目指す。 実行前提:bun、gh、gh auth statusが利用可能。Codex CLI実行時はghコマンドを最初からエスカレート実行(sandbox・host間の認証コンテキスト差異対応)。基本フロー:リポジトリルートでbun .agents/skills/another-quick-switcher-release/scripts/release.ts実行→スクリプト出力のJSON(RELEASE_RESULT_JSON)を読み取り→assets/templatesのテンプレート使用して標準出力(Bluesky投稿案・Issue返信テンプレート)。Script Options:--branch (対象ブランチ指定、既定master)、--dry-run(dispatch/git pull非実行)、--skip-issue-notify(Issue候補表示スキップ)。Output Contract:スクリプトはJSON出力でrelease・issueCandidatesフィールドを含む。Issue返信はPR除外(isPullRequest=false対象)、author重複除去、tagName・URL置換。Bluesky投稿は利用者視点の日本語要約・URL直記載で標準出力。失敗時は references/release-workflow.md のtroubleshooting参照。
AppleデザインガイドラインでUIを一括設計
by nahisaho
iOS・macOS・watchOSなどAppleプラットフォーム向けのUIを、Apple Human Interface Guidelines(HIG)に自動準拠させて設計できます マージン・スペーシング・グリッド・タイポグラフィ・カラーなど、プラットフォーム別の厳密な仕様に基づいて設計できます Dynamic Type対応やダークモード対応など、ユーザーアクセシビリティに配慮した設計が実装できます Navigation Bar・Tab Bar・Buttons・Lists・Cardsなど、標準コンポーネントの正確な仕様(寸法・色・配置)がすぐに参照できます SF Symbols を活用したアイコン設計を、統一的なガイドラインで実行できます iOS・iPadOS・macOS向けアプリのUIデザインを行うUI/UXデザイナー Appleプラットフォーム開発初心者で、デザインシステムの標準的な仕様を学びたい開発者 複数Appleプラットフォーム(iPhone・iPad・Mac・Watch・TV)で一貫性あるUIを構築したいプロダクトチーム ユーザーのアクセシビリティニーズに配慮したアプリ設計を実装したいプロダクトマネージャー Apple Human Interface Guidelines(HIG)に準拠した洗練なUIデザイン作成スキルです。核心原則は明瞭性(すべてのサイズで読みやすく、装飾は適切)、敬意(UIはコンテンツを補助)、奥行き(レイヤーと動きで階層表現)です。iOS/iPadOS:セーフエリア8pt基本グリッド、マージン最小16pt、Dynamic Type対応フォント(San Francisco)、14段階のテキストスタイル、セマンティックカラー+ダークモード対応が必須。Navigation Bar高さ44pt(コンパクト)/96pt(ラージ)、Tab Bar高さ49pt、ボタン最小タップ領域44x44pt、リスト行最小44pt、カード角丸12pt/16ptが標準。macOS:ウィンドウ最小800x600pt、ツールバー高さ52pt/76pt、サイドバー幅150-250pt、ボタン高さ22-32pt。watchOS:マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。