Skill.md検索

ダーツボードの全20セグメントの配置と、各リング（ブル、シングル、ダブル、トリプル）の点数ルールを正確に参照できます 0点から50点まで、44種類の有効な得点値を判定でき、実装時の値検証に使用できます ブル（25点/50点）、シングル（1-20点）、ダブル（2-40の偶数）、トリプル（セグメント番号×3）の違いを確実に区別できます よくある誤解（例：22はダブル11、21はトリプル7など）を正確に理解し、バグを防げます ダーツゲーム実装時の得点検証ロジックやシミュレーション機能の開発に直接活用できます ダーツゲームやスコアリングシステムを開発するエンジニア ダーツのスコア検証機能を実装・テストする開発者 ダーツアプリの要件定義や仕様書を作成する企画者 ダーツゲームのビジネスロジックをテストするQAエンジニア ダーツボードの構造を中心から外側へ定義します。インナーブル（半径0-6.35mm、50点）、アウターブル（半径6.35-16mm、25点）、インナーシングル（16-99mm、セグメント番号そのまま）、トリプルリング（99-107mm、セグメント番号×3）、アウターシングル（107-162mm）、ダブルリング（162-170mm、セグメント番号×2）、アウト（170mm以上、0点）の7リングで構成。セグメント配置は真上から時計回りに[20,1,18,4,13,6,10,15,2,17,3,19,7,16,8,11,14,9,12,5]の順。有効な得点は0、1-20、2-40の全偶数、3-60の3の倍数（セグメント1-20のみ）、25点、50点の計44種類。取りえない値は23、29、31、35、37、41、43、44、46、47、49、52、53、55、56、58、59など。ビジネスドメイン知識として、点数ルール検証、シミュレーション、スコアリング機能実装時に使用します。

次のタスクを自動選定: GitHub Project の Todo アイテムから実装可能な Issue を自動で取得し、優先度の高いものを選びます。 TDD パイプラインの自動実行: Issue のテストパターンを自動判定し、適切なテスト駆動開発（TDD）パイプラインを確認なしで最後まで実行できます。 ローカルでの自動検証: local-ci コマンドでコードチェック・テスト・ビルドを並列実行し、PR 作成前に品質を確認します。 PR 作成と CI 監視の自動化: 実装完了後、自動で PR を作成し、リモート CI の実行を監視・レビュー対応・修正サイクルを自動で回します。 レビュー指摘の自動処理: スコープ内の指摘は自動修正し、スコープ外の指摘は別 Issue に切り出します。 実装フェーズに入ったとき、どのタスクから始めるか迷う開発者 テスト駆動開発（TDD）を実践したいが、手続きが煩雑に感じるエンジニア PR 作成から マージまでの手作業を最小化したいチーム Issue ベースの開発フローを確立したいプロジェクト このパイプラインは「確認なしで自律的に最後まで進行」するのが特徴です。確認不要な項目（Issue 選定、classify-files 結果、レビュー指摘の修正、テストの Red 化、local-ci リトライ、PR 作成、PR マージ）は自動で進め、確認が必要な項目（classify-files が判定不能な場合、リトライ上限到達、設計判断が必要な場合）のみユーザーに確認します。 CI チェックについて、local-ci（ローカル実行、このパイプラインで使用）と remote CI（GitHub Actions、PR マージ後に監視）を区別します。PR 作成後は /pr-watch スキルで remote CI を監視しますが、サンドボックス環境の制約を考慮し、gh run view --log-failed でログを取得します（gh api の Azure Blob Storage リダイレクトはサンドボックスで遮断されるため使用禁止）。

正確な描画順序で視覚的な正確性を保証：背景→ダブルリング→アウターシングル→トリプルリング→インナーシングル→外側スパイダー→ブル→ブル用スパイダー→番号という10ステップの描画順序により、レイヤリングの問題なく忠実なダーツボードを描画できます。 スパイダー（ワイヤー）の色被りを完全に防止：2ステップ分割描画（放射線+リング境界→ブル塗布→ブル境界）により、放射線がブルエリアに被らず、ブル境界線が明確に見える描画が実現できます。 セグメント境界の角度を正確に計算：セグメント番号配置の計算式を統一し、放射線とセグメント境界が完璧に一致させることで、視覚的なズレを排除できます。 物理座標と画面座標を明確に分離管理：mm 単位の物理座標でビジネスロジックを記述し、描画時のみ画面座標に変換することで、可読性・保守性・再利用性が向上します。 p5.js の描画パフォーマンスを最適化：描画状態設定をループ外で実行し、不要な関数呼び出しを削減することで、フレームレートを維持できます。 ダーツゲーム・ダーツトレーニング Web アプリの開発者：正確で美しいダーツボード表示を実装したい p5.js で複雑な図形描画を行う開発者：レイヤリング・座標系の扱いに関するベストプラクティスを学びたい ゲーム開発・ビジュアライゼーション担当者：描画順序と色処理の正確な実装方法を参考にしたい Web キャンバス描画のテスト・レビュー担当者：描画パターンと品質基準を統一したい ダーツボード描画に関する実装パターンとベストプラクティスを定義します。描画原則は「外側から内側へ、下レイヤーから上レイヤーへ」で、10ステップの順序：背景クリア→ダブルリング(170mm)→アウターシングル(162mm)→トリプルリング(107mm)→インナーシングル(99mm)→外側スパイダー→アウターブル(7.95mm)→インナーブル(3.175mm)→ブル用スパイダー→セグメント番号。スパイダー描画は必ず2ステップ分割（drawSpiderOuter 後ブル塗布、その後 drawSpiderBull）して、放射線がブル色に被らない、ブル境界線が見える状態を実現。セグメント境界角度は (i - 0.5) * SEGMENT_ANGLE で計算（drawRingSegments の計算式と統一）。座標系は物理座標(mm)でビジネスロジック記述し、CoordinateTransform で画面座標(pixel)に変換。p5.js 最適化は描画状態設定(noStroke など)をループ外で実行。

マジックナンバーを排除：コード内の意味不明な数値を定数として定義することで、将来の修正時に数値の意図がすぐに理解でき、間違った値への修正ミスを防げます。 型安全性を大幅に向上：型アサーション（as）を避けて型ガード関数を使用することで、コンパイル段階でバグを検出でき、実行時エラーを減らせます。 重複コードを自動的に検出・統一：同じロジックが複数箇所に存在する場合を関数化することで、メンテナンス工数を削減し、バグ修正時の対応漏れを防げます。 テストの保守性を向上：実装コードと同じ定数をテストから参照することで、テストと実装のズレを防ぎ、テスト信頼性を高められます。 パフォーマンス問題を予防：ループ処理内での無駄な操作を事前に排除するルールで、不要な遅延を防げます。 チーム全体のコード品質を統一したい技術リード・アーキテクト バグの発生を事前に防ぎたい開発チーム コードレビューの基準を明確にしたいエンジニアリング組織 新しい開発者のオンボーディングを効率化したいプロジェクトマネージャー このスキルは6つの基本原則（マジックナンバーの排除、定数参照、ループ最適化、型安全性、マジック文字列の定数化、重複コード排除）とヘルパー関数の命名規則（is～は型ガード、get～は取得、to～は変換）を定義します。マジックナンバーの排除では「ドメイン知識としてみなせる数値」を特に強調し、テストコード内でも同じ定数をインポートして使用することで参照元が一元化されます。型ガード関数はasによる強制キャスト回避を徹底し、繰り返し使用される文字列リテラルも定数化対象に含めます。実装時の確認項目としてチェックリスト形式で7項目を示し、コードレビュー時にこの項目を確認することでチーム全体での規約遵守を促進します。

PR 作成後のCI実行状況を自動で監視し、失敗時にはエラーログを自動分析して修正計画を立案・実装する流れを一貫して実行できます レビューコメントに対して、PR スレッド上で対応方針を提案し、合意を得た上で修正を進めることで、意思決定プロセスを透明に残せます CI 失敗の修正（エラー分析 → 修正計画 → 実装 → ローカル検証 → 再 push）までを確認なしで自律的に進行させ、開発者の手間を大幅に削減できます レビュー指摘が Issue の受け入れ条件に合致しない場合は自動で別 Issue に切り出し、スコープ管理も一体化させることができます PR #123 のようにPR番号を指定するか、引数なしで現在ブランチの PR を自動検出して監視できます GitHub で頻繁に PR を作成し、CI 通過とレビュー対応のサイクルを高速化したい開発者 複数の PR が並行している環境で、各 PR の進行状況を一元管理したいチームリード CI 失敗時のエラー分析や修正作業を自動化し、開発に集中したいエンジニア レビュー議論の過程を PR スレッドに残し、チーム全体の知見共有を進めたい組織 このスキルは PR 作成後の「CI 監視 → レビューコメント議論 → 修正実装」を一貫して処理し、PR マージまでのサイクルを回します。自律行動原則として、CI 失敗の修正・レビュー指摘への返信・スコープ内の修正は確認なしで自動進行し、レビュー方針の合意・リトライ上限到達・設計判断の場合のみユーザーに確認します。実行フロー は Phase 1（CI 監視）と Phase 2（レビューコメント議論）で構成され、Phase 1 では全ワークフロー完了を gh run watch で監視、失敗時はエラーログを XDG_CACHE_HOME=$TMPDIR を使ってサンドボックス環境で取得し、plan-fix エージェントで修正計画を立案、implement で実装、local-ci で検証、git push で再実行という流れを最大3回リトライします。Phase 2 では graphql を使用して未解決レビュースレッドを取得し、コメント履歴を分析してユーザーへ報告・合意待機するプロセスが定義されています。