名前: gスタック プリアンブル層: 1 バージョン: 1.1.0 説明: | QA テストとサイトのドッグフーディングのための高速ヘッドレス ブラウザ。ページの移動、操作 要素、状態の確認、前後の差分、注釈付きスクリーンショットの取得、レスポンシブテスト レイアウト、フォーム、アップロード、ダイアログ、およびバグ証拠のキャプチャ。開けるよう求められた場合に使用します。 サイトをテストしたり、展開を検証したり、ユーザー フローをドッグフードしたり、スクリーンショットを使用してバグを報告したりできます。 (Gスタック) 許可されたツール:

• バッシュ
• 読む
• ユーザーに質問する

{{前文}}

PROACTIVE が false の場合: 実行中に他の gstack スキルを積極的に呼び出したり提案したりしないでください。 このセッション。ユーザーが明示的に呼び出すスキルのみを実行してください。この設定は次の期間にわたって持続します gstack-config 経由のセッション。

PROACTIVE が true (デフォルト) の場合: ユーザーのリクエストがあったときに スキルツールを呼び出します スキルの目的と一致します。タスクにスキルが存在する場合は、直接回答しないでください。 スキルツールを使用して呼び出します。このスキルには、特殊なワークフロー、チェックリスト、および インラインで回答するよりも優れた結果を生み出す高品質のゲート。

ルーティング ルール — これらのパターンが表示された場合は、スキル ツールを介してスキルを呼び出します。

• ユーザーが新しいアイデアについて説明し、「これは構築する価値があるか」と尋ね、ブレインストーミングを希望している → /office-hours を呼び出す
• ユーザーが戦略、範囲、野心について質問し、「もっと大きく考えてください」→ /plan-ceo-review を呼び出します
• ユーザーはアーキテクチャを確認し、計画を確定するよう要求します。 → /plan-eng-review を呼び出します
• ユーザーがデザインシステム、ブランド、ビジュアルアイデンティティについて質問 → /design-consultation を呼び出す
• ユーザーが計画の設計をレビューするよう要求 → /plan-design-review を呼び出します
• ユーザーはすべてのレビューを自動的に実行することを望んでいます → /autoplan を呼び出します
• ユーザーがバグ、エラー、壊れた動作を報告し、「なぜこれが壊れているのか」と尋ねる → /investigate を呼び出す
• ユーザーはサイトのテスト、バグの発見、QA → /qa の呼び出しを要求します
• ユーザーはコードをレビューし、差分を確認し、着陸前レビューを要求します → /review を呼び出します
• ユーザーがビジュアルの磨き方、ライブサイトのデザイン監査について質問 → /design-review を呼び出す
• ユーザーが PR の配布、デプロイ、プッシュ、作成を要求 → /ship を呼び出す
• ユーザーが出荷後にドキュメントを更新するよう要求する → /document-release を呼び出す
• ユーザーが毎週のレトロを要求しました。何を出荷しましたか → /retro を呼び出します
• ユーザーがセカンドオピニオンを求め、コーデックスレビュー → /codex を呼び出します
• ユーザーが安全モード、慎重モードを要求 → /careful または /guard を呼び出します
• ユーザーがディレクトリへの編集を制限するよう要求 → /freeze または /unfreeze を呼び出します
• ユーザーが gstack のアップグレードを要求 → /gstack-upgrade を呼び出す

一致するスキルが存在する場合は、ユーザーの質問に直接答えないでください。 スキル は、その場限りの答えよりも常に優れた、構造化された複数ステップのワークフローを提供します。 まずはスキルを発動します。一致するスキルがない場合は、通常どおり直接回答してください。

ユーザーが提案をオプトアウトした場合は、gstack-config set proactive false を実行します。 再びオプトインする場合は、gstack-config set proactive true を実行します。

gstack 参照: QA テストとドッグフーディング

Persistent headless Chromium.最初に自動開始を呼び出し (約 3 秒)、次にコマンドごとに約 100 ～ 200 ミリ秒を呼び出します。 Auto-shuts down after 30 min idle.状態は呼び出し間 (Cookie、タブ、セッション) に維持されます。

{{BROWSE_SETUP}}

＃＃ 重要

• Use the compiled binary via Bash: $B <command>
• NEVER use mcp__claude-in-chrome__* tools. They are slow and unreliable.
• Browser persists between calls — cookies, login sessions, and tabs carry over.
• Dialogs (alert/confirm/prompt) are auto-accepted by default — no browser lockup.
• Show screenshots: After $B screenshot, $B snapshot -a -o, or $B responsive, always use the Read tool on the output PNG(s) so the user can see them. Without this, screenshots are invisible.

QA ワークフロー

認証情報の安全性: テスト認証情報に環境変数を使用します。 実行前に設定します: export TEST_EMAIL="..." TEST_PASSWORD="..."

ユーザー フロー (ログイン、サインアップ、チェックアウトなど) をテストする

# 1. Go to the page
$B goto https://app.example.com/login

# 2. See what's interactive
$B snapshot -i

# 3. Fill the form using refs
$B fill @e3 "$TEST_EMAIL"
$B fill @e4 "$TEST_PASSWORD"
$B click @e5

# 4. Verify it worked
$B snapshot -D              # diff shows what changed after clicking
$B is visible ".dashboard"  # assert the dashboard appeared
$B screenshot /tmp/after-login.png

デプロイメントの検証/本番環境のチェック

$B goto https://yourapp.com
$B text                          # read the page — does it load?
$B console                       # any JS errors?
$B network                       # any failed requests?
$B js "document.title"           # correct title?
$B is visible ".hero-section"    # key elements present?
$B screenshot /tmp/prod-check.png

Dogfood のエンドツーエンド機能

# Navigate to the feature
$B goto https://app.example.com/new-feature

# Take annotated screenshot — shows every interactive element with labels
$B snapshot -i -a -o /tmp/feature-annotated.png

# Find ALL clickable things (including divs with cursor:pointer)
$B snapshot -C

# Walk through the flow
$B snapshot -i          # baseline
$B click @e3            # interact
$B snapshot -D          # what changed? (unified diff)

# Check element states
$B is visible ".success-toast"
$B is enabled "#next-step-btn"
$B is checked "#agree-checkbox"

# Check console for errors after interactions
$B console

レスポンシブ レイアウトをテストする

# Quick: 3 screenshots at mobile/tablet/desktop
$B goto https://yourapp.com
$B responsive /tmp/layout

# Manual: specific viewport
$B viewport 375x812     # iPhone
$B screenshot /tmp/mobile.png
$B viewport 1440x900    # Desktop
$B screenshot /tmp/desktop.png

# Element screenshot (crop to specific element)
$B screenshot "#hero-banner" /tmp/hero.png
$B snapshot -i
$B screenshot @e3 /tmp/button.png

# Region crop
$B screenshot --clip 0,0,800,600 /tmp/above-fold.png

# Viewport only (no scroll)
$B screenshot --viewport /tmp/viewport.png

テストファイルのアップロード

$B goto https://app.example.com/upload
$B snapshot -i
$B upload @e3 /path/to/test-file.pdf
$B is visible ".upload-success"
$B screenshot /tmp/upload-result.png

検証付きのテストフォーム

$B goto https://app.example.com/form
$B snapshot -i

# Submit empty — check validation errors appear
$B click @e10                        # submit button
$B snapshot -D                       # diff shows error messages appeared
$B is visible ".error-message"

# Fill and resubmit
$B fill @e3 "valid input"
$B click @e10
$B snapshot -D                       # diff shows errors gone, success state

テストダイアログ (削除確認、プロンプト)

# Set up dialog handling BEFORE triggering
$B dialog-accept              # will auto-accept next alert/confirm
$B click "#delete-button"     # triggers confirmation dialog
$B dialog                     # see what dialog appeared
$B snapshot -D                # verify the item was deleted

# For prompts that need input
$B dialog-accept "my answer"  # accept with text
$B click "#rename-button"     # triggers prompt

認証されたページをテストする (実際のブラウザーの Cookie をインポートする)

# Import cookies from your real browser (opens interactive picker)
$B cookie-import-browser

# Or import a specific domain directly
$B cookie-import-browser comet --domain .github.com

# Now test authenticated pages
$B goto https://github.com/settings/profile
$B snapshot -i
$B screenshot /tmp/github-profile.png

Cookie の安全性: cookie-import-browser は実際のセッション データを転送します。 自分が制御するブラウザからのみ Cookie をインポートします。

2 つのページ/環境を比較する

$B diff https://staging.app.com https://prod.app.com

echo '[
  ["goto","https://app.example.com"],
  ["snapshot","-i"],
  ["fill","@e3","$TEST_EMAIL"],
  ["fill","@e4","$TEST_PASSWORD"],
  ["click","@e5"],
  ["snapshot","-D"],
  ["screenshot","/tmp/result.png"]
]' | $B chain

# Element exists and is visible
$B is visible ".modal"

# Button is enabled/disabled
$B is enabled "#submit-btn"
$B is disabled "#submit-btn"

# Checkbox state
$B is checked "#agree"

# Input is editable
$B is editable "#name-field"

# Element has focus
$B is focused "#search-input"

# Page contains text
$B js "document.body.textContent.includes('Success')"

# Element count
$B js "document.querySelectorAll('.list-item').length"

# Specific attribute value
$B attrs "#logo"    # returns all attributes as JSON

# CSS property
$B css ".button" "background-color"

スナップショット システム

{{SNAPSHOT_FLAGS}}

コマンドリファレンス

{{COMMAND_REFERENCE}}

ヒント

1. 一度移動すれば、何度もクエリを実行できます。 goto がページを読み込みます。 then text, js, screenshot all hit the loaded page instantly.
2. 最初に snapshot -i を使用します。 すべてのインタラクティブな要素を表示してから、参照をクリックして入力します。 No CSS selector guessing.
3. snapshot -D を使用して確認します。 ベースライン → アクション → 差分。 See exactly what changed.
4. アサーションには is を使用します。 is visible .modal は、ページ テキストを解析するよりも高速で信頼性が高くなります。
5. 証拠としてsnapshot -aを使用します。 注釈付きのスクリーンショットはバグレポートに最適です。
6. トリッキーな UI には snapshot -C を使用します。 アクセシビリティ ツリーが見逃しているクリック可能な div を見つけます。
7. アクション後に console を確認します。 視覚的に表れない JS エラーを見つけます。
8. 長いフローには chain を使用します。 単一コマンドで、ステップごとの CLI オーバーヘッドはありません。