「before」の検索結果

作業完了や不具合修正を報告する前に、テストやビルドを実行して結果を確認します。コミットやPR作成の前にも、実際の出力を根拠に状況を伝えるスキルです。

• 完了報告の前に結果を確認したいとき
• 不具合の修正を確かめたいとき
• コミットやPR前の検証

新しい機能を実装する前に、既存コードやnpm・PyPIのパッケージ、MCP serversなどを調べます。候補を比較し、採用・拡張・自作の判断につなげるスキルです。

• 機能追加前に既存の解決策を調べたいとき
• 依存パッケージの導入前の比較
• 外部連携に使えるツールの調査

公開前の文章やコードを二つの独立したエージェントが同じ基準で審査し、両方の合格まで修正と再審査を繰り返し、上限を超えたら人へ判断を引き継ぐスキル。

• 公開前に文章の事実関係を確認したいとき
• 顧客向け文章とブランドルールの照合
• 本番配布前に独立した審査を加えたいとき

ルーターやスイッチの設定を適用前に点検するスキル。危険なコマンド、IPアドレスの重複、サブネットの重なり、未定義の参照や管理用アクセスの問題を確認します。

• 保守作業前に設定をレビューしたいとき
• テンプレートで生成した設定の監査
• IP重複とネットワーク範囲の確認

Adversarial premortem for England & Wales civil litigation - builds the strongest version of a case, then attacks it from four angles to find where it loses before opposing counsel does. Runs an adversarial premortem on a UK litigation matter. Builds the strongest version of the case, then attacks it from four angles — procedural, substantive, evidentiary, strategic — to find where it actually loses. Returns a ranked stress-test brief: failure scenarios, evidence inconsistencies, blind spots, mitigations, and one brutal one-sentence verdict. Use before issue, before settlement negotiations, before a litigation-funder pitch, or before deciding whether to take a case.

日本語の概要は準備中です。原文の説明を表示しています。

Writes the formal letter you send before suing someone in a civil case in England & Wales — the Letter Before Claim that starts the pre-action clock. The part it gets right is which pre-action protocol applies — debt, professional negligence, housing disrepair, personal injury, or the default Practice Direction on Pre-Action Conduct — each of which has its own rules a generic letter misses (the 30-day debt window, the professional-negligence preliminary-notice step). It also flags the limitation deadline for a solicitor to confirm rather than stating it as fact. Built for litigation juniors, in-house counsel, and small firms without a precedent to copy. Use when the user says 'draft an LBC', 'letter before claim', 'pre-action letter', 'pre-action protocol', or needs to start the pre-action clock before issuing a civil claim. Verify the current protocol before sending.

日本語の概要は準備中です。原文の説明を表示しています。

Policy for the cross-model council: when to hand off to an installed sibling plugin's own slash command (`/codex:*`) versus dispatching our `delegation-runner` (backend: codex|agy|…), which backend to pick, what permission posture to use, and the fan-out/cost discipline that applies regardless of backend — plus the council layer built on that substrate: which play to run, how a cast gets picked from the project roster, budget guardrails, and where project policy/commission config lives. Consult before delegating out to a peer agentic CLI, before choosing between a sibling plugin's command and our runner, before choosing a permission posture, before fanning out more than one external delegation concurrently, or before running a council play (`/…:council-run`).

日本語の概要は準備中です。原文の説明を表示しています。

A gate before git push / deploy — assembled from your own tools (secret-grep + slop-scan + code-review + build/compile + optional worktree isolation), so AI junk (slop / bugs / secrets / uncompiled code) never reaches a remote or a production server. Turns "I hope it's clean" into a verifiable criterion. Branches: web/OSS (git push/PR) vs deploy-to-server service. Triggers — "check before push", "clean push", "gate before push", "finalize before commit", "run before deploy".

日本語の概要は準備中です。原文の説明を表示しています。

Run a pre-mortem — imagine the project has already failed one year from now and work backward to find the root causes before they happen. Load when the user asks for a pre-mortem, wants to imagine failure before committing, asks "what could go wrong before we start", "assume this fails — why", "risk analysis before launch", "what kills this project", "what could go wrong", or when deep-thinking diagnoses a pre-mortem frame. Based on Gary Klein's prospective hindsight method, which surfaces failure causes more effectively than forward risk analysis. Most useful right before a major commitment.

日本語の概要は準備中です。原文の説明を表示しています。

会話の開始時に使えるスキルを確認し、応答や作業の前に読み込む手順を定めます。作業方法を決めるスキルを優先し、実行環境ごとの案内につなぎます。

• 会話開始時にスキルを確認したいとき
• 機能開発前にスキルを選びたいとき
• 不具合調査前にスキルを選びたいとき

機能の実装後やマージ前に、別のエージェントへコードレビューを依頼します。変更内容と要件、対象のコミットを渡し、指摘の重要度に応じて修正を進めるスキルです。

• 大きな機能を実装した後のレビュー
• マージ前に変更を確認したいとき
• 複雑な不具合修正への第三者確認

機能開発を別の作業領域で進めるために、既存の分離状態を確認し、環境標準の機能かgit worktreeで領域を用意。依存関係の準備と開始前のテストも行います。

• 機能開発を別の作業領域で始める
• 実装計画の開始前に環境を整える
• 作業領域が分離済みか確認する

新機能や不具合修正で、先に期待する動作のテストを書き、失敗を確認してから実装します。最小限のコードで成功させ、全体のテストを保ちながら整理するスキルです。

• 新機能をテストから実装したいとき
• 不具合をテストで再現して直したいとき
• テストを保ちながらコードを整理

新しいスキルを作る前に、ローカル環境やマーケット、GitHub、ウェブから既存候補を探し、用途との一致度や安全性を確認して再利用・拡張・新規作成の判断を助けます。

• 作業に合うスキルを探したいとき
• 新規作成前に重複を確認したいとき
• 拡張する既存スキルの候補選び

Quarkusサービスの変更後や公開前に、ビルド、コード解析、テスト、脆弱性検査を順に確認するスキル。ネイティブ実行形式やコンテナ、環境設定の検証も扱います。

• QuarkusのPR前チェック
• リファクタリングや依存更新の検証
• ネイティブ実行形式の互換性確認

予測市場や取引エージェントの処理を、規約・データ品質・秘密情報・プライバシー・取引実行の観点で点検し、問題点と必要な対策を整理するスキル。

• 取引サービスの認証を加える前の確認
• 資産情報とAPIキーの扱いの点検
• 市場データの品質と出典表示の確認

Webページの表示や操作、APIの応答、ビルド・テストの所要時間を計測するスキル。変更前後の結果を比較し、Gitで共有する基準値をもとに性能の悪化を確認します。

• コード変更前後の性能比較
• ページが遅いという報告の調査
• 公開前に性能目標を確認したいとき

CodeScene MCPでコード構造の保守しやすさを評価するスキル。編集前後のスコアを比較し、コミットやPRの前にAIによる変更で品質が下がっていないか確認します。

• 見慣れないファイルを編集前に確認したいとき
• AIの変更で保守性が下がっていないか確認
• スコアを比較しながらコードを整理したいとき

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

日本語の概要は準備中です。原文の説明を表示しています。

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

日本語の概要は準備中です。原文の説明を表示しています。

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

日本語の概要は準備中です。原文の説明を表示しています。

Assess whether source code is ready to deploy to Azure — the check BEFORE infrastructure work. Evaluates build health, app completeness, dependencies and local services, stack compatibility, and deployment feasibility. Answers questions about what your app needs before it can be deployed — frameworks, dependencies, and configuration. Checks whether dependencies are compatible and identifies deployment blockers and unsupported frameworks. WHEN: "evaluate my repo", "is my app ready to deploy", "what does my app need to deploy", "what do I need before deploying", "does my app need", "can I ship this to Azure", "scan my repo for issues", "is this app deployable", "check if my app is ready for Azure", "do I need a Dockerfile", "what's blocking my deployment", "are there any blockers", "are my dependencies compatible", "does Azure support my framework", "what needs to change before deploying", "check my app configuration".

日本語の概要は準備中です。原文の説明を表示しています。

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

日本語の概要は準備中です。原文の説明を表示しています。

Run a submission-readiness preflight on a manuscript before arXiv upload. Use when the user is preparing an arXiv submission, asks to check a paper before uploading, mentions hallucinated or fake references, leftover LLM meta-comments / prompts in text, placeholder data (TODO, TBD, XX%), AI-use disclosure, scholarly integrity, research integrity, or arXiv moderation risk — even if they don't say "preflight". Also trigger on phrases like "check my paper before arXiv", "verify my references", "scan for AI artifacts", "scan for LLM residue", "is my submission ready", or "review .tex/.bib before submit".

日本語の概要は準備中です。原文の説明を表示しています。