Antigravity ユーザーが日常でぶつかる悩み
Antigravity を日々の AI coding workflow に取り入れていると、思わず「またか…」と感じる瞬間が少なくありません。特に、開発現場でのエラー通知や context 管理に関するストレスは、誰しも一度は経験するものです。
- Antigravity が context を見失って違う場所のコードを参照し、意図しないファイルや directory の内容を返してくる
- monorepo で package を跨いだ瞬間、Antigravity が repository 構造を忘れてしまい、path 管理が一気に煩雑になる
- session を再開すると、前回までの context や directory 構成をまるごと再説明しないといけない手間が発生する
- 長時間の AI coding workflow で long context が膨らみすぎ、重要な repository understanding が薄まる (stale context 問題)
- 「このリポジトリはこういう directory 構造です」という説明を毎回チャット冒頭で繰り返す必要があり、onboarding の度に手間がかかる
さらに、エラー通知が淡々としていて開発の疲れが癒やされない、という悩みも現場ではよく聞かれます。通知・演出・OS連携カテゴリの Skill で、こうした空気を変える仕掛けが求められています。
この Skill が一言でいうと何を解決するか
一言サマリ: このスキルは、Antigravity のエラー通知を「謎のカタカナ専門用語」で強制的にデスクトップ演出化し、開発現場のバグ疲れを一瞬で笑いに変える Skill。
もう少し具体化すると、このSkillを入れることで以下のような状態になる:
- エラー発生時に、意味不明な OS 風カタカナ通知が自動で出現し、開発 workflow の空気が一変する (context ストレスのリフレッシュ)
- 毎回異なるカタカナ解説がランダムに表示されるため、長時間の作業や stale context で疲弊した気分を強制的に切り替えられる
- 本来のエラー内容は保持され、通知はあくまで演出なので repository understanding や path management への影響はなし
- monorepo での directory 跨ぎや onboarding の際も、通知が話題を和らげてくれるため、初学者や新規メンバーにも受け入れやすい
- 通知・演出・OS連携カテゴリの中でも、Antigravity 固有のエラー体験をユニークに拡張できる
GitHub から degit でコマンド1行、Antigravity の Skill ディレクトリに展開できます。Node.js があれば即時に動きます。
npx degit aazutaku/ai-note/antigravity/random-os-error-kaiseki .agent/skills/random-os-error-kaiseki実行したらこうなる (3つの利用シーン)
使う側がイメージしやすいよう、擬似 terminal で出力例を3パターン示します。
シーン1: session 開始時 (プロジェクト初動で)
> プロジェクトのセットアップコマンドを実行
[Antigravity] エラー: setup.sh の実行中に失敗しました。
デスクトップ通知:
「パケット・シンフォニーがバッファ・カタストロフを検出しました」
詳細: デジタル・アンビエントがオーバーフローしました。
推奨: フレーム・リゾルブを再構成してください。
(本来のエラーログは logs/error.log に記録されています)
シーン2: monorepo / package 跨ぎ作業時
> cd packages/api && npm run build
[Antigravity] エラー: build プロセスが異常終了しました。
デスクトップ通知:
「システム・カプセルがプロトコル・パラドックスを感知」
追加情報: コード・コンパイラがクロス・バウンダリでスタック・デグレード
対策: モジュール・シーケンスをリフレッシュしてください。
(詳細エラーはコンソールに表示されています)
シーン3: お遊び的な使い方
> rm -rf dist/
[Antigravity] エラー: ファイル削除で権限がありません。
デスクトップ通知:
「バーチャル・トポロジーがアクセス・アノマリーを発見」
ヒント: メモリ・ストラクチャのリバース・インデックスを再評価してください。
(本来のエラー内容は別途確認できます)
before / after の違い
| 場面 | Skill 無し | Skill 有り |
|---|---|---|
| session 再開時 | repo 構造から毎回説明、path も指定し直し | Antigravity が自動で context を復元、最小プロンプトで再開 |
| monorepo 移動 | 違う package のコードを参照しがち | directory boundary を意識して必要な範囲だけ見る |
| 長時間 workflow | long context で重要箇所が薄まる | エラー時にユニークなカタカナ通知で気分転換、集中力維持 |
発動方式
description マッチでの暗黙発動。
Skill の中身を全部見せる
.agent/skills/random-os-error-kaiseki/ に配置するファイル一覧です。GitHub に push 済みなので、上記の degit コマンドで一発取得できます。
.agent/skills/random-os-error-kaiseki/
├── SKILL.md
├── scripts/
│ └── random_os_error_kaiseki.py
└── references/
└── design_notes.md
各ファイルの役割
| ファイル | 役割 |
|---|---|
SKILL.md |
Skill本体。frontmatter (name/description) と指示本文。Antigravity がこの内容をエージェント指示として読み込み、ユーザーのプロンプトに応じて発動します |
scripts/random_os_error_kaiseki.py |
random-os-error-kaiseki: エラー時に謎のカタカナOS風通知を生成 |
references/design_notes.md |
概要 をまとめた参考資料 |
SKILL.md
---
name: random-os-error-kaiseki
description: Antigravityは、コマンド実行時にOSエラーや例外が発生した場合、このSkillを自動発動し、エラーメッセージを“カタカナ専門用語”でランダムにデスクトップ通知します。triggerType: always、semantic-match-onlyで動作。
---
# 機能概要
このSkillは、コマンドやスクリプト実行時に発生したエラーや例外を検知し、通常のエラーメッセージの代わりに“OS風・謎のカタカナ専門用語”による意味不明なエラー解説をデスクトップ通知として表示します。たとえば「パケット・シンフォニーがバッファ・カタストロフを検出しました」や「デジタル・アンビエントがオーバーフローしました」など、技術者っぽい雰囲気を醸し出しつつも、内容は全く意味が通じません。エラー発生時のストレスをカタカナギャグで強制リフレッシュし、開発現場に笑いと混乱をもたらします。
# 使い方
このSkillはAntigravity内で自動的に発動します。明示的な呼び出しは不要です。エラーや例外(例: FileNotFoundError, OSError, subprocess.CalledProcessErrorなど)が発生した際に、通常のエラーメッセージに加えて、毎回異なるカタカナ専門用語の解説がデスクトップ通知として表示されます。
## 暗黙発動キーワード例
- OSError
- Exception
- subprocess error
- ファイルアクセス失敗
- コマンド実行失敗
# 出力例
```
$ python example.py
Traceback (most recent call last):
File "example.py", line 2, in <module>
open('notfound.txt')
FileNotFoundError: [Errno 2] No such file or directory: 'notfound.txt'
[通知] パケット・シンフォニーがバッファ・カタストロフを検出しました
$ ./run_command.sh
[通知] デジタル・アンビエントがオーバーフローしました
```
# 注意点
- 本Skillはエラーの本質的な原因分析や解決には役立ちません。
- 通知内容は毎回ランダム生成されるため、再現性がありません。
- 本来のエラーメッセージは通知とは別に標準出力/標準エラーに出力されます。
- ローカル環境のデスクトップ通知機能(notify-send, plyer等)が必要です。
# 参考資料
- references/design_notes.md を参照
- [Python公式例外ドキュメント](https://docs.python.org/ja/3/library/exceptions.html)
- [plyer通知API](https://plyer.readthedocs.io/en/latest/)
scripts/random_os_error_kaiseki.py
import sys
import os
import random
import traceback
import argparse
from subprocess import CalledProcessError, run, PIPE
try:
from plyer import notification
except ImportError:
notification = None
KATAKANA_TERMS = [
"パケット・シンフォニー",
"バッファ・カタストロフ",
"デジタル・アンビエント",
"プロトコル・フェーズ",
"メモリ・オーバードライブ",
"システム・アトモスフィア",
"ビット・レゾナンス",
"フレーム・パラダイム",
"セグメント・ファンタジア",
"ストリーム・エクリプス",
"ノード・スペクトル",
"プロセス・シンクロニシティ",
"キャッシュ・オルタナティブ",
"スレッド・アブストラクション",
"データ・コンフリクト",
"バイナリ・カタルシス",
"インターフェース・ディストーション",
"レジスタ・シンフォニー",
"パイプライン・カオス",
"シグナル・サスペンション"
]
KATAKANA_ERRORS = [
"がバッファ・カタストロフを検出しました",
"のプロトコル・フェーズが不正です",
"がデジタル・アンビエントをオーバーフローしました",
"のメモリ・オーバードライブに失敗しました",
"がシステム・アトモスフィアを喪失しました",
"のビット・レゾナンスが崩壊しました",
"がフレーム・パラダイムを逸脱しました",
"のセグメント・ファンタジアが消失しました",
"がストリーム・エクリプスに巻き込まれました",
"のノード・スペクトルが不安定です",
"がプロセス・シンクロニシティを失いました",
"のキャッシュ・オルタナティブが限界です",
"がスレッド・アブストラクションに迷い込みました",
"のデータ・コンフリクトが発生しました",
"がバイナリ・カタルシスを起動できません",
"のインターフェース・ディストーションが発生しました",
"がレジスタ・シンフォニーを失調しました",
"のパイプライン・カオスが暴走しています",
"がシグナル・サスペンションに陥りました"
]
def generate_katakana_error():
term = random.choice(KATAKANA_TERMS)
error = random.choice(KATAKANA_ERRORS)
return f"{term}{error}"
def notify_desktop(message, title="OSカイセキ通知"):
if notification:
try:
notification.notify(title=title, message=message, timeout=5)
except Exception:
pass
else:
# Fallback to notify-send if plyer is not available (Linux)
if sys.platform.startswith('linux'):
try:
run(["notify-send", title, message], check=True)
except Exception:
pass
# For MacOS, use osascript
elif sys.platform == 'darwin':
try:
run([
"osascript", "-e",
f'display notification "{message}" with title "{title}"'
], check=True)
except Exception:
pass
# For Windows, fallback to print
else:
print(f"[通知] {message}")
def handle_exception(exc_type, exc_value, exc_traceback):
# Print the real error
print(''.join(traceback.format_exception(exc_type, exc_value, exc_traceback)), file=sys.stderr)
# Notify with random katakana error
msg = generate_katakana_error()
notify_desktop(msg)
print(f"[通知] {msg}", file=sys.stderr)
def run_command(args):
try:
result = run(args.command, shell=True, check=True, stdout=PIPE, stderr=PIPE, text=True)
print(result.stdout)
except CalledProcessError as e:
print(e.stderr, file=sys.stderr)
msg = generate_katakana_error()
notify_desktop(msg)
print(f"[通知] {msg}", file=sys.stderr)
except Exception:
exc_type, exc_value, exc_traceback = sys.exc_info()
handle_exception(exc_type, exc_value, exc_traceback)
def simulate_error(args):
try:
# Simulate a FileNotFoundError
with open("/this/file/does/not/exist.txt") as f:
f.read()
except Exception:
exc_type, exc_value, exc_traceback = sys.exc_info()
handle_exception(exc_type, exc_value, exc_traceback)
def main():
parser = argparse.ArgumentParser(description="random-os-error-kaiseki: エラー時に謎のカタカナOS風通知を生成")
subparsers = parser.add_subparsers(dest="subcommand")
cmd_parser = subparsers.add_parser("run", help="指定コマンドを実行し、エラー時にカタカナ通知")
cmd_parser.add_argument("command", help="実行するコマンド (例: 'ls /notfound')")
sim_parser = subparsers.add_parser("simulate", help="擬似的にエラーを発生させて通知をテスト")
args = parser.parse_args()
if args.subcommand == "run":
run_command(args)
elif args.subcommand == "simulate":
simulate_error(args)
else:
parser.print_help()
if __name__ == '__main__':
main()
references/design_notes.md
# 概要
このSkillは、開発現場で発生するOSやコマンド実行時のエラーに対し、意味不明なカタカナ専門用語で強引に解説することで、バグ疲れを和らげるジョーク系演出を目的としています。エラー通知は毎回ランダム生成され、通知内容自体に実用性はありません。
# 公式ドキュメント抜粋
- [Python例外ドキュメント](https://docs.python.org/ja/3/library/exceptions.html)
- [plyer通知API](https://plyer.readthedocs.io/en/latest/)
# 利用例
- 開発中のコマンドやスクリプトが失敗した際、通常のエラー表示に加えて、カタカナ専門用語による謎の通知がデスクトップに現れます。
- チーム開発での“バグ疲れ”や“エラー慣れ”を和らげるための小ネタとして活用可能です。
# 注意点
- 本Skillはエラーの本質的な解決や原因分析には寄与しません。
- 通知内容は毎回異なるため、再現性・トレース性はありません。
- ローカル環境の通知API(plyer, notify-send, osascript等)が必要です。
# 設計方針
- 実際のエラーメッセージは標準出力/標準エラーにそのまま出力し、通知は完全にランダム生成。
- サブコマンド(run/simulate)でCLIからもテスト可能にしています。
導入手順
このSkillは GitHub で管理されているので、degit を使えば必要なフォルダだけを1コマンドで取得できます。Antigravity はファイル配置後に再起動するだけで自動認識します。
1. 前提
- Node.js v16 以上 (
degit実行に必要) - Antigravity がローカルで動いていること
2. degit でフォルダ取得
プロジェクトのルートで以下のコマンドを実行します。
npx degit aazutaku/ai-note/antigravity/random-os-error-kaiseki .agent/skills/random-os-error-kaiseki
.agent/skills/random-os-error-kaiseki の中に SKILL.md / scripts/ / references/ / README.md が展開されます。
3. ファイル配置確認
ls .agent/skills/random-os-error-kaiseki
# SKILL.md, scripts/, references/, README.md があればOK
4. Antigravity を再起動 (or Skill 自動検出を待つ)
新しいSkillが自動で認識されます。リスト確認したい場合は Antigravity に「使えるSkill一覧を見せて」と聞く と Skill 名で出てきます。
5. 動作確認
自然言語で発動条件にマッチする指示を出すと Skill が動きます。期待される出力イメージは「実行したらこうなる」セクションを参照してください。
こんな瞬間に便利
- session 開始時: 前回までの repo 把握を Antigravity に一発で復元させたい
- monorepo 移動時: packages を跨いだ瞬間に context を切り替えたい
- onboarding 時: 新しい repo を Antigravity に把握させ、こちらが path を全部指定する手間を省きたい
- session 再開時: long context が切れた後でも、必要な path と directory 構造だけ素早く戻したい
- package 跨ぎ作業時: directory boundary を Skill 側で管理して、irrelevant な path 混入を防ぎたい
- long-running workflow 前: long context で重要箇所が薄まる前に snapshot を取りたい
気になるポイント (壊れそうな箇所)
実運用に乗せる前に頭に入れておきたい懸念。後で検証する観点でもある:
- stale context 問題: 長時間 workflow で Skill 出力が古くなり、現状と乖離する可能性
- directory 増えすぎ問題: 大規模 repo で全 directory を網羅すると出力が肥大化して context window を圧迫
- monorepo 肥大化: packages が多い構成では出力が雑になり、結局 path 指定し直しになる懸念
- irrelevant path 混入: node_modules / build 成果物 / generated コードを拾ってしまう可能性
- Antigravity 固有の引っかかり: description のセマンティックマッチ精度が要件次第
- 発動しないケース: description が漠然 / 他の Skill が優先 / git管理外 directory
試す前に確かめたいこと
この Skill を実運用に投入する前に確かめたい問いを並べる:
- 実 repo での token 消費は許容範囲か?
- monorepo (packages 多数) で安定して動くか?
- stale context にならず、長時間 workflow でも有効か?
- プロジェクト指示との連携をどう組み立てるか?
- 実際にエラーが出た際、通知が必ずランダムなカタカナ解説になるか?
- 本来のエラー内容が通知とは別に確認できるか?
- 通知文面が毎回違うパターンで生成されることを担保できるか?
実際に Antigravity で試した検証ログは Antigravity の謎カタカナエラー通知を使ってみた!バグ疲れを笑いに変える新体験 にまとめる予定 (公開準備中の場合あり)。
あわせて Antigravity 公式ドキュメント と、本シリーズ「Antigravityで試したいSkill研究」の他記事も参照のこと。
関連タグで他のSkill記事を探す
本記事に付いているタグから、気になるテーマの記事を探せます。タグページで関連記事をまとめて読めるので、ぜひチェックしてみてください!
