Claude Skills by mae616

アーキテクチャ設計（境界/依存/データフロー/非機能/運用）を、制約とトレードオフで言語化し、ADR-liteで合意形成しながら段階的に形にする。doc/input/rdd.md にアーキテクチャ/非機能/運用の要求がある、または設計判断（分割/責務/インタフェース/データ整合/観測性/スケール）相談で使う。

Astroプロジェクトの設計・実装・レビューを、HTML中心/Islands/JS最小化の思想で整理する。doc/input/rdd.md に「技術スタック Astro」があるリポジトリ、またはAstro/Islands/SSG/SSR/パフォーマンス最適化の相談で使う。

[レビュー] Basic Review - typo/命名/フォーマットの表面チェック

事業仮説を支える一次/二次情報を整理し、意思決定に足る「根拠」「不確実性」「次の調査」を可視化する。でたらめな引用や推測の断言を避け、出典の実在を重視する。

[バグ対応] 4. 修正実行を恒久対応・段階実施＋無効時ロールバックでする

[コミット] 日本語コミットメッセージを生成（ステージ差分）

体験品質（動き/触感/視線誘導）を「実装可能な制約」に落とし、アクセシビリティとパフォーマンスを犠牲にせずに表現を実現する。UIの表現・アニメーション・インタラクション設計/実装の相談で使う。

[デザイン] 4. variants → 型付きProps/属性にマッピングして結合（再利用UI）

[デザイン] 3. 静的UI骨格 → Layout/Component を抽出して分離

[デザイン] （任意）SSOT → 静的HTML を生成し、doc/input/design/html/ に保存

[デザイン] 1.（会話起点）SSOT + 静的HTML（叩き台）を生成

[デザイン] （任意）1枚ペラHTML → ページ単位の静的HTMLに分割

[デザイン] 1.（Figma起点）SSOT（tokens/components/context/assets）を生成

[デザイン] 2. SSOT → 静的UI骨格（見た目のみ）を生成

設計と実装を「最小で正確」に進め、TDD（RED→GREEN→REFACTOR）と差分思考で品質と速度を両立する。設計の溶け込み（責務不明/重複/暫定対応）を防ぎ、レビュー可能な変更へ落とし込むときに使う。

[ドキュメント] リバースエンジニアリングによるドキュメント作成（俯瞰/引き継ぎ用）

デザインツール（Figma/Pencil等）やUI要件を「壊れない・拡張しやすい」実装へ翻訳するための判断軸。px写経を避け、比率・構造・制約・状態を先に設計してからUIを組み立てる。

[マニュアル] 1. 設定手順書の生成

[マニュアル] 2. 手順書を会話でステップ実行支援でガイド

[ペアモード] 壁打ち（企画/設計/実装/デザイン）

プロダクトのペルソナ/ユーザー像を、仮説と根拠（観察・調査・制約）で組み立て、意思決定に使える形へ整形する。※会話口調のペルソナ（にゃんこ）とは別物。

価値提案（誰に/何のために/なぜ勝てる）をレビューし、曖昧さ・矛盾・証拠不足を洗い出して、メッセージとMVPを磨くために使う。

[リポジトリ] 内容説明（初見向け）

OWASPの基本を前提に、デフォルト安全（入力検証/認可/秘密情報/監査ログ/SSR/CSRF等）を落とさずに設計・実装・レビューする。脅威と攻撃面を洗い出し、最小権限と安全な失敗で守るために使う。

[セットアップ] 前提の読み込み（推奨）

[スキル作成] 新しいスキルを壁打ち→テンプレ生成→登録確認まで

Svelte/SvelteKitプロジェクトにおいて、UI=状態の直接的な反映という思想を軸に、コンパイル時最適化・状態管理・レンダリング・配信量の設計を整理する。doc/input/rdd.md に「技術スタック Svelte」または「技術スタック SvelteKit」がある場合や、Svelteの設計・パフォーマンス・構造理解の相談で使う。

Tailwind CSSを、utility-first（早すぎる抽象化を避ける）という思想で運用し、UI実装の認知負荷を下げながら一貫性と保守性を保つための設計・レビュー・リファクタ判断を整理する。doc/input/rdd.md に「技術スタック Tailwind」または「技術スタック Tailwind CSS」がある場合や、CSS設計/命名/デザインシステム/クラス肥大化の相談で使う。

[タスク] 2. Issue詳細化 + 依存関係設定

[タスク] 1. Sprint計画（Milestone + Issue一括作成）

[タスク] 3. Issue実行 + 進捗同期

UIを「情報設計（優先度/構造）＋インタラクション（状態遷移）＋ビジュアル（トーン）」として設計し、実装可能な仕様へ落とす。見た目だけでなく、ルール化（コンポーネント/トークン）に寄せる。

認知負荷・エラー防止・学習コスト・アクセシビリティの観点からUI/フローを評価し、改善案を“検証可能な仮説”として提示する。認知人間工学/ユーザビリティ/アクセシビリティを統合して扱う。