このリポジトリは、frontendchecklist.io というフロントエンド開発チェックリストサービスの本体です。README前面にある GitHub Action は、公開URLをMCP API経由で監査し、重大度別の問題件数をCIに返す部品の1つです。実体は Next.js製アプリ(apps/web)を中心に、チェックリスト・ルール・ガイドの閲覧、ユーザープロフィール、MCPサーバーまで含む大規模なmonorepoです。
apps/web配下には、checklists・rules・guides・listsなど多数のルートがあり、content-collectionsでMDXコンテンツをビルドしてページ化しています。認証はbetter-auth、データはPrismaクライアント経由で扱い、apps/web/actionsにチェックリストやプロフィールの操作ロジックがあります。app/api/mcp/route.tsはMCPサーバーの窓口で、AIエージェントからのアクセスに対応します。README前面が説明するのは.github/actions/audit配下のGitHub Actionで、これはcurlとjqを使いmcp.frontendchecklist.ioへ対象URLを送信し、返ってきたcritical・highの件数をfail-on-critical・fail-on-highしきい値と比較してジョブを合否判定します。CI自体は.github/workflows/ci.yml、e2e.yml、pr.ymlなどに分かれ、Playwright(apps/e2e)によるE2Eテストも別途用意されています。
- STEP 01
pnpm installを実行すると、多数のworkspaceパッケージ(packages配下やconfigs配下)の解決に時間がかかることが予想されます。
- STEP 02
apps/web/.env.exampleに相当する環境変数(Supabase、better-auth、OpenPanelなど)を用意しないと、devサーバー起動時にエラーが出る可能性があります。
- STEP 03
pnpm devに相当するcontent-collections watchとnext devを並行起動すると、MDXコンテンツのビルドとWebサーバー起動が同時に進みます。
- STEP 04
ブラウザでchecklists配下やrules配下のページを開くと、content-collectionsが生成したチェックリストやルールの一覧が表示されます。
- STEP 05
GitHub Actionを試す場合は、対象リポジトリのワークフローに.github/actions/audit@mainを追加し、urlにhttpsの公開URLを指定してpushします。
- STEP 06
実行後のCIログにissues-found、critical-count、high-countが出力され、しきい値を超えるとジョブが失敗してPRチェックが赤くなります。
手元で動かすと、チェックリスト・ルール・ガイドを閲覧できるWebアプリと、AIエージェント向けMCPサーバー、CIに組み込める監査Actionの3つが揃った状態が手に入ります。README前面のAction単体を使う場合は、対象サイトの重大度別issue件数がCI結果として得られます。
Webアプリ全体を動かすにはSupabase、better-auth、OpenPanelなど複数の外部サービスの認証情報が必要で、README前面だけでは構成の全体像は見えません。
Audit Actionはlocalhostを監査対象にできず、公開済みかつhttpsのURLが必須という制約があります。
mcp.frontendchecklist.ioという外部MCPエンドポイントへの依存があり、その可用性次第でAction自体が失敗する可能性があります。
README前面はAudit Actionの説明が中心で、プロフィールや認証、ダッシュボードなどWebアプリ本体の機能については記載がありません。
自社サイトのフロントエンド品質チェックをCIに組み込みたいチームや、AIエージェント向けにチェックリストをMCP経由で参照させたい開発者に向いています。file treeとpackage.json、実際のルートやAction定義から構成を確認できるため、大掛かりなセットアップを試さなくても、Webアプリ+MCPサーバー+監査Actionという三層構造であることは十分判断できます。