105 件 ・ 関連度順
概要と使いどころ
アプリ名・サービス名の命名を、5つの専門エージェントチームで多角的に評価・決定するスキル。 ブランディング、商標/法的リスク、デジタルプレゼンス(SEO/ASO/SNS)、国際展開(多言語/発音)の 4観点から候補を提案・調査・議論し、コンテキストファイルと議事録で次回セッションへ引き継ぐ。 Use when: アプリ名を決めたい、サービス名を変更したい、プロダクト名を検討したい、 ネーミングブレスト、名前の商標チェック、アプリ名のリネーム。 Triggers: "アプリ名", "サービス名", "プロダクト名", "ネーミング", "名前を決め", "リネーム", "rename", "app name", "naming", "ブランド名", "商標チェック"
新しい実験フォルダを reference/ から雛形コピーして作成する。SESSION_NOTES.md と run.sh も自動生成。Claude用は expA00, A01, ...、人間用は exp200, 201, ... の連番で命名する。
D-ZERO の HTML/Pug マークアップ規約。HTML や Pug を書く・編集する・レビューするときに使う。コンポーネント設計、クラス命名、文書構造、画像、リンク、メタ情報に適用する。
Skillを命名するとき、改名するときに読む。
SF CLI経由でSalesforceレポートを作成するスキル。Metadata APIとREST APIの使い分け、フィールド命名規則、列数制限、レポートタイプ設定を網羅。カスタムオブジェクトレポート作成時の注意点も含む。Use when creating Salesforce reports via CLI, deploying report types, or automating report generation.
E2E テストの spec を書く・編集する・レビューする際に必ず発火させる。新しいシナリオの追加、既存 E2E テストの修正・デバッグ、E2E テストの書き方の相談、slice-tdd skill から E2E spec が必要と判断された場面で使う。触る範囲に対応するプロジェクトの E2E の流儀 (spec の書き方・構造・命名) を探して従わせる入口。E2E を実行する手順は扱わない (別スキルの責務)。
使用包装文件进行渐进式文件重命名。无缝重命名，防止硬性中断 — 引用会在日常使用中有机地自动更新。
日本語の概要は準備中です。原文の説明を表示しています。
Google TypeScript Style Guide reference for writing, reviewing, and refactoring TypeScript code. Use this skill whenever you are writing TypeScript code, reviewing TypeScript code, refactoring TypeScript, configuring ESLint or linter rules for TypeScript, or when the user asks about TypeScript coding conventions, naming conventions, type system best practices, or import/export patterns. Also trigger when the user mentions 'Google style', 'gts', 'TypeScript style guide', or asks 'how should I name this', 'should I use interface or type', 'how to handle null/undefined' in a TypeScript context. TypeScriptを書く・レビューする・リファクタリングする、ESLintの設定をする、「命名規則」「型の使い方」「import/exportのルール」「interfaceとtypeどっち」「anyを使っていい？」「nullチェックどうする」「Google式」「コーディング規約」「スタイルガイド」などの質問にも対応します。TypeScriptのコードに関する質問や作業であれば積極的にこのスキルを使ってください。
ユーザーからのファイル出力依頼（分析結果・調査レポート・ログ抜粋・要約・ドラフト・一時的なメモなど）に応えて新規ファイルを作成するときの出力先ルール。プロジェクト直下の`tmp-agents/`への出力命名規則を含む。調査結果やレポートを保存するとき、ドラフトを作るとき、ユーザー向けの一時成果物を書き出すときに必ず参照する。ただし、プロジェクト本体のソースコード作成、既存ファイルの編集、プロジェクト規定のドキュメント（docs/配下等）出力は対象外。
feature ブランチを作成する。「ブランチ作成」「ブランチを作って」「新しいブランチ」「feature ブランチ」「Issue からブランチ」「作業ブランチを作成」「ブランチ切って」などで起動。Issue 番号・ブランチ名の直接指定・コンテキストからの自動命名に対応。
新しい worktree を作成する。「worktree 作成」「worktree を作って」「worktree 切って」「Issue から worktree」「作業用 worktree」「gtr new」などで起動。Issue 番号・ブランチ名の直接指定・コンテキストからの自動命名に対応。一覧・削除・クリーンアップは shiiman-git:worktree。
有馬記念分析システムのアーキテクチャ/レイヤー境界レビュー。docs/ARCHITECTURE.md のレイヤー構成（commands / domain / repositories / models / features / constants / database / utils / types）に対し、レイヤーディレクトリの意味と配置、参照系(queries)と更新系(aggregates)の分離、DB 接続の注入可能性とテスト容易性、リッチドメインモデルの維持（commands 肥大・ドメイン貧血症）、重み・閾値の constants 単一定義、ファイル配置と命名語彙の一致、不要な抽象化、種別分岐のポリモーフィズム化、生成引数の凝集（5個以上は分割シグナル）を検証。純粋性・依存方向の逆流・DB 接続の生成箇所は lint が error で担保するため扱わない。Use when user says 'アーキテクチャレビュー', 'レイヤー境界チェック', 'review architecture', or '依存方向の確認'.
テスト観点のレビューエージェント。 テスト網羅性、命名規則、フレーキーテスト、カバレッジギャップの個別スキルへルーティングする。
テストは存在するがアサーションが実質何も検証しておらず、実装が壊れても落ちない（常に PASS する）構造を diff-time で検出する。Check 1 missing assertion（テスト本体にアサーションが無い）、Check 2 tautological assertion（定数同士・入力自身・mock の戻り値自身を assert し SUT に依存しない）、Check 3 nonexistent expected literal（assertDontSee / assertNotContains 等の期待文字列が対象ファイルに実在しない）、Check 4 stale expected value（同一 diff で対象の出力が変わったのに期待値が据え置き）、Check 5 unscoped expectation（汎用的な属性・クラスを応答全体に対して assert し対象要素にスコープされていない）、Check 6 swallowed failure（例外の握り潰しや到達しない位置のアサーションで判定が成立しない）、の 6 Check を対象とする report-only。テストの有無は test-existence、未テスト経路の量は coverage-gap、非決定性は flaky-test、命名は test-naming、JS/TS の un-awaited resolves / rejects は vitest-mock-isolation、tdd-ledger artifact ベースの RED/GREEN 検証は plangate-tdd-evidence、.only / .skip / xit / @ts-ignore と空の catch は heuristic-review.mjs の決定論検出器へ委譲する
リファクタリング（構造変更）と機能変更（behavior change）が同一 diff に混在していないかを識別し、structural change に対する external behavior preservation の証拠（テスト・型・静的解析）が揃っているかを diff-time で確認する。証拠不足のときは Characterization Test 追加を促すか question とする。DTO/公開 API の破壊的変更検出は api-compatibility、完了主張の反証や抽出リファクタの性能特性退行は refactor-claim-audit、新知識の命名・責務・境界への反映は knowledge-to-code-alignment、投機的抽象化・スコープ逸脱は altitude-generalization / fix-scope-integrity へ委譲する
Spring Bootサービスのためのコーディング規約: 命名規則、イミュータビリティ、Optional使用法、ストリーム、例外、ジェネリクス、プロジェクト構成。
REST APIデザインパターン（リソース命名、ステータスコード、ページネーション、フィルタリング、エラーレスポンス、バージョニング、レート制限を含む本番API向け）
依据用户提供的特定规则执行MySQL数据库开发任务，涵盖命名约束、索引设计策略及海量数据归档方案。
日本語の概要は準備中です。原文の説明を表示しています。
現在のブランチの変更差分だけを点検し、冗長なコメントや不要な防御処理、型の強引な変換、周囲と合わない書き方を、動作を変えずレビュー前に整理するスキル。
Redisを使ったキャッシュ、アクセス回数制限、複数処理の同時実行制御、メッセージ配信を設計し、キーの有効期限や接続管理も見直すスキル。
Goのコード作成・レビュー・リファクタリングを、言語の慣習に沿って支援します。エラー処理、並行処理、パッケージ構成を整え、読みやすく保守しやすい実装を目指します。
初めて触るコードの構成や処理の流れ、開発ルールを調べ、参加時の案内資料とCLAUDE.mdを作成します。変更したい作業ごとの参照先も整理します。
MNN Metal 后端 op/kernel 开发与优化入口。索引各份 sub-doc：性能问题诊断流程（op 单测 + 对手基准定位真瓶颈，优化任务第一站）、kernel 开发规范与优化知识库（命名/写法/GEMV/GEMM/attention + 手段方法论）、算子融合全链路（导出图→converter→Metal 单 dispatch + 融合方法论）、运行时调度（fence/content-cache/H2D/replay + 调度方法论）、构建测试基线、env 开关注册表。根据当前任务选择性阅读对应 sub-doc。
日本語の概要は準備中です。原文の説明を表示しています。
把一个概念铸成杂志专题档案——真问题→失败→转折→顿悟→命名, 6 个 layout 模具 + 4 字族对比 + 探案档案细节
日本語の概要は準備中です。原文の説明を表示しています。