Web・iOS・Androidの画面を、読み上げやキーボード操作に対応させ、ラベル、配色、操作対象の大きさなどをWCAG 2.2に沿って設計・点検するスキル。
- アイコンボタンの説明を付けたいとき
- キーボード操作とモーダルの点検
- コントラストや操作対象の大きさの確認
Webページの表示や操作、APIの応答、ビルド・テストの所要時間を計測するスキル。変更前後の結果を比較し、Gitで共有する基準値をもとに性能の悪化を確認します。
原文Measure performance baselines and detect regressions across browser Core Web Vitals (LCP, INP, CLS, page weight), API endpoint latency percentiles, and build/test feedback times, with before/after comparison stored in git-tracked .ecc/benchmarks JSON. Use when checking page speed, responding to 'it feels slow' reports, verifying launch performance targets, or comparing stack alternatives.
インストール方法を見るWebページ、API、開発作業の所要時間を計測し、変更前後の性能を比較します。ページでは表示速度、操作への反応、レイアウトのずれに加え、JavaScriptや画像の容量、通信回数などを確認します。APIでは100回のリクエストと10件の同時リクエストを使い、応答時間の中央値や遅い応答の傾向、応答サイズ、ステータスコードを測ります。
「遅く感じる」という報告を数値で確かめるときや、公開前の性能目標を確認するときに向いています。ビルド、変更の即時反映、テスト、型チェックなどにかかる時間も対象です。コード変更の影響や、技術構成の候補を比較したい場合にも使えます。
/benchmark baselineで変更前の基準値を保存して」/benchmark compareで変更後の結果と差分を確認して」ページ計測にはブラウザを操作する連携機能のbrowser MCPを使います。基準値は.ecc/benchmarks/にJSONで保存し、Gitで共有する想定です。資料にはAPIへ繰り返しアクセスする計測手順が含まれます。ライセンスはMITです。
この紹介文は、公開されている SKILL.md をもとに AI(Claude Haiku)が作成しました。正確な仕様は下の原文を確認してください。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Measures real browser metrics via browser MCP:
1. Navigate to each target URL
2. Measure Core Web Vitals:
- LCP (Largest Contentful Paint) — target < 2.5s
- CLS (Cumulative Layout Shift) — target < 0.1
- INP (Interaction to Next Paint) — target < 200ms
- FCP (First Contentful Paint) — target < 1.8s
- TTFB (Time to First Byte) — target < 800ms
3. Measure resource sizes:
- Total page weight (target < 1MB)
- JS bundle size (target < 200KB gzipped)
- CSS size
- Image weight
- Third-party script weight
4. Count network requests
5. Check for render-blocking resources
Benchmarks API endpoints:
1. Hit each endpoint 100 times
2. Measure: p50, p95, p99 latency
3. Track: response size, status codes
4. Test under load: 10 concurrent requests
5. Compare against SLA targets
Measures development feedback loop:
1. Cold build time
2. Hot reload time (HMR)
3. Test suite duration
4. TypeScript check time
5. Lint time
6. Docker build time
Run before and after a change to measure impact:
/benchmark baseline # saves current metrics
# ... make changes ...
/benchmark compare # compares against baseline
Output:
| Metric | Before | After | Delta | Verdict |
|--------|--------|-------|-------|---------|
| LCP | 1.2s | 1.4s | +200ms | WARNING: WARN |
| Bundle | 180KB | 175KB | -5KB | ✓ BETTER |
| Build | 12s | 14s | +2s | WARNING: WARN |
Stores baselines in .ecc/benchmarks/ as JSON. Git-tracked so the team shares baselines.
/benchmark compare on every PR/canary-watch for post-deploy monitoring/browser-qa for full pre-ship checklistまだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Web・iOS・Androidの画面を、読み上げやキーボード操作に対応させ、ラベル、配色、操作対象の大きさなどをWCAG 2.2に沿って設計・点検するスキル。
AIエージェントの不調を、指示・記憶・ツール実行・画面表示など12の層から調べるスキル。コードやログを根拠に原因を整理し、重要度順の指摘と修正案をまとめます。
実際の開発課題で複数のコーディングエージェントを比較するスキル。成功率、取得可能なAPI費用、所要時間、繰り返し実行の安定性を測り、選定や更新後の評価に使えます。
AIエージェントが使うツールの種類や入出力、エラーからの復帰手順を設計・見直します。文脈の情報量も整理し、作業完了率や再試行回数で改善を評価します。
AIエージェントが失敗や同じ操作を繰り返す原因を、エラーと実行状況から整理します。小さな復旧操作を試し、結果と根拠を引き継げる報告にまとめるスキルです。
AIエージェントの失敗や同じ操作の繰り返しを記録し、原因の切り分け、小さな復旧操作、結果の報告まで進める手順を示して、根拠のある再試行につなげるスキル。