.md
Skill.mdサーチャーJP
Skill.md一覧に戻る
M
v1.0.0

UI要件から必要なコンポーネントと依存を自動抽出できる

by monoharada

1
265
2026-03-18

説明

できること

  • 画面のUI要件を入力すると、Web Component Framework(WCF)で実装するのに必要な「最小コンポーネント構成」を自動で提案します。
  • 必要なコンポーネントID・依存関係・パターンを、レジストリ(部品カタログ)から自動検索して、JSON形式で構造化して返します。
  • 要件の「状態」(ローディング中・エラー・空・デフォルト)が不足していれば自動で補完し、何を補完したかを記録します。
  • 曖昧な要件には「これについて確認したいこと」を明示し、実装前の齟齬を減らします。

こんな人におすすめ

  • WCFを使ったコンポーネント設計・実装を行うフロントエンド開発者
  • 新しい画面を設計する際に「どのコンポーネントを組み合わせるか」を効率的に決めたい設計者
  • インストール前に最小構成を確認して、作業スコープを明確にしたい開発チームリーダー
SKILL.md の内容
# wcf-discovery

目的: 画面要件を、WCFで実装可能な最小コンポーネント構成へ変換する。

## Required Input

- `screen_goal: string`
- `target_user: string`
- `states: string[]`

Skill.md 情報

バージョン
v1.0.0
カテゴリ
design-dev
作成日
2025-12-29

インストール

ワンコマンドで導入
1

下の「Skill.mdをダウンロード」ボタンを押す

2

お使いのAIツール(Claude Code・Cursor・Copilot など)にファイルをアップロードして「このスキルを追加して」と入力する

ターミナルから追加する場合
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/monoharada/web-components-factory" -o ~/.claude/skills/SKILL.md

関連 Skill.md

注目
K

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形式で本文を渡します。

テストドキュメントPR
95111.5k2026-04-13
T

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参照。

コミット
3814.8k2026-03-29
N

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:マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。

レビューテストドキュメント
274982026-01-01