Communitygithub.com

lucas-flatwhite/gstack-ko

手動トリガーのみ: ユーザーが /qa と入力した場合のみ起動します。Web アプリケーションを体系的に QA テストし、発見したバグを修正します。QA テストを実行し、ソースコード内のバグをアトミックにコミットしながら繰り返し修正し、再検証します。「qa」「QA」「このサイトをテスト」「バグを見つけて」「テストして修正」「壊れたものを直して」と依頼されたときに使用します。ユーザーが機能のテスト準備ができたと言ったり、「これは動作しますか？」と尋ねたときに積極的に提案します。3 つの階層: Quick (重大/高のみ)、Standard (+ 中)、Exhaustive (+ 軽微)。Before/After の健全性スコア、修正証拠、出荷準備完了サマリーを生成します。レポートのみのモードには /qa-only を使用します。

gstack-ko とは？

このスキルは、Claude Code などの AI エージェントが Web アプリケーションの QA テストとバグ修正を自動化するための高度なワークフローです。ユーザーが '/qa' と入力することで手動で起動され、システム的にアプリケーションをテストし、発見したバグをソースコード内で修正し、各修正をアトミックにコミットしてから再検証します。3 つのテスト階層（Quick、Standard、Exhaustive）を備え、重要度に応じて修正範囲を調整できます。また、Before/After の健全性スコア、修正証拠、出荷準備完了サマリーを構造化レポートとして提供します。このスキルは主に Claude Code 環境向けに設計されており、gstack フレームワークを活用して、完全性の原則に基づいた徹底的なテストと修正を実現します。

対応✓Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/lucas-flatwhite/gstack-ko/tree/HEAD/qa
オリジナルを見る→すべてのスキルを見る

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

ドキュメント

Reference-only note: このリポジトリは upstream gstack の韓国語ドキュメントレイヤーです。以下の内容は upstream インストール版を基準としたリファレンスであり、実際の実行は upstream 環境に従ってください。

プリアンブル (最初に実行)

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_PROACTIVE=$(~/.claude/skills/gstack/bin/gstack-config get proactive 2>/dev/null || echo "true")
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"
echo "PROACTIVE: $_PROACTIVE"
source <(~/.claude/skills/gstack/bin/gstack-repo-mode 2>/dev/null) || true
REPO_MODE=${REPO_MODE:-unknown}
echo "REPO_MODE: $REPO_MODE"
_LAKE_SEEN=$([ -f ~/.gstack/.completeness-intro-seen ] && echo "yes" || echo "no")
echo "LAKE_INTRO: $_LAKE_SEEN"
_TEL=$(~/.claude/skills/gstack/bin/gstack-config get telemetry 2>/dev/null || true)
_TEL_PROMPTED=$([ -f ~/.gstack/.telemetry-prompted ] && echo "yes" || echo "no")
_TEL_START=$(date +%s)
_SESSION_ID="$$-$(date +%s)"
echo "TELEMETRY: ${_TEL:-off}"
echo "TEL_PROMPTED: $_TEL_PROMPTED"
mkdir -p ~/.gstack/analytics
echo '{"skill":"qa","ts":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","repo":"'$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "unknown")'"}'  >> ~/.gstack/analytics/skill-usage.jsonl 2>/dev/null || true
# zsh-compatible: use find instead of glob to avoid NOMATCH error
for _PF in $(find ~/.gstack/analytics -maxdepth 1 -name '.pending-*' 2>/dev/null); do [ -f "$_PF" ] && ~/.claude/skills/gstack/bin/gstack-telemetry-log --event-type skill_run --skill _pending_finalize --outcome unknown --session-id "$_SESSION_ID" 2>/dev/null || true; break; done

PROACTIVE が "false" の場合、gstack スキルを積極的に提案せず、ユーザーが明示的に要求した場合にのみ呼び出します。ユーザーは積極的な提案をオプトアウトしています。

出力に UPGRADE_AVAILABLE <old> <new> が表示された場合: ~/.claude/skills/gstack/gstack-upgrade/SKILL.md を読み、「インラインアップグレードフロー」に従ってください（設定されていれば自動アップグレード、そうでなければ AskUserQuestion で4つのオプションを提示、拒否された場合はスヌーズ状態を書き込みます）。JUST_UPGRADED <from> <to> が表示された場合: ユーザーに「gstack v{to} を実行中（更新されました！）」と伝えて続行します。

LAKE_INTRO が no の場合: 続行する前に、完全性の原則を紹介します。ユーザーに次のように伝えます: 「gstack は Boil the Lake の原則に従います — AI が限界費用をほぼゼロにする場合、常に完全な作業を行います。詳細: https://garryslist.org/posts/boil-the-ocean」 次に、デフォルトブラウザでエッセイを開くことを提案します:

open https://garryslist.org/posts/boil-the-ocean
touch ~/.gstack/.completeness-intro-seen

open はユーザーが承諾した場合のみ実行します。touch は常に実行して「確認済み」としてマークします。これは1回のみ発生します。

TEL_PROMPTED が no かつ LAKE_INTRO が yes の場合: レイクイントロの処理後、テレメトリについてユーザーに尋ねます。AskUserQuestion を使用:

gstack の改善にご協力ください！コミュニティモードでは、使用状況データ（使用スキル、処理時間、クラッシュ情報）を安定したデバイス ID と共有し、トレンド追跡とバグ修正を迅速化します。コード、ファイルパス、リポジトリ名が送信されることはありません。 いつでも gstack-config set telemetry off で変更できます。

オプション:

  • A) gstack の改善にご協力ください！（推奨）
  • B) 結構です

A の場合: ~/.claude/skills/gstack/bin/gstack-config set telemetry community を実行

B の場合: フォローアップの AskUserQuestion を実行:

匿名モードはいかがですか？誰かが gstack を使用したことだけを把握します — 一意の ID はなく、セッションを結びつける方法もありません。誰かが使っているかどうかを知るためのカウンターだけです。

オプション:

  • A) はい、匿名で構いません
  • B) いいえ、完全にオフにします

B→A の場合: ~/.claude/skills/gstack/bin/gstack-config set telemetry anonymous を実行 B→B の場合: ~/.claude/skills/gstack/bin/gstack-config set telemetry off を実行

常に以下を実行:

touch ~/.gstack/.telemetry-prompted

これは1回のみ発生します。TEL_PROMPTED が yes の場合、これを完全にスキップします。

AskUserQuestion フォーマット

すべての AskUserQuestion 呼び出しで、常にこの構造に従ってください:

  1. 再基礎付け: プロジェクト、現在のブランチ（プリアンブルで出力された _BRANCH 値を使用 — 会話履歴や gitStatus のブランチではない）、現在の計画/タスクを述べます。（1〜2文）
  2. 簡略化: 賢い16歳が理解できる平易な英語で問題を説明します。生の関数名、内部用語、実装の詳細は使用しません。具体的な例と類推を使用します。「何をするか」を伝え、「何と呼ばれるか」を伝えません。
  3. 推奨: RECOMMENDATION: [X] を選択してください。理由: [一行の理由] — 常にショートカットよりも完全なオプションを優先します（完全性の原則を参照）。各オプションに Completeness: X/10 を含めます。キャリブレーション: 10 = 完全な実装（すべてのエッジケース、完全なカバレッジ）、7 = ハッピーパスをカバーするが一部のエッジをスキップ、3 = 重要な作業を先送りするショートカット。両方のオプションが8以上の場合、高い方を選択します。一方が5以下の場合、フラグを立てます。
  4. オプション: アルファベットのオプション: A) ... B) ... C) ... — オプションに労力が伴う場合、両方のスケールを示します: (human: ~X / CC: ~Y)

ユーザーはこのウィンドウを20分間見ておらず、コードを開いていないと想定します。自分の説明を理解するためにソースを読む必要がある場合、それは複雑すぎます。

スキルごとの指示は、このベースラインに加えて追加のフォーマットルールを追加する場合があります。

完全性の原則 — Boil the Lake

AI は完全性をほぼ無料にします。常にショートカットよりも完全なオプションを推奨します — CC+gstack での差は数分です。「湖」（100%カバレッジ、すべてのエッジケース）は沸騰可能です。「海」（完全な書き換え、複数四半期にわたる移行）は沸騰できません。湖を沸騰させ、海にはフラグを立てます。

工数参考 — 常に両方のスケールを示します:

タスクタイプ人間のチームCC+gstack圧縮率
ボイラープレート2日15分~100倍
テスト1日15分~50倍
機能1週間30分~30倍
バグ修正4時間15分~20倍

各オプションに Completeness: X/10 を含めます（10=すべてのエッジケース、7=ハッピーパス、3=ショートカット）。

リポジトリ所有権 — 何か見つけたら、声を上げる

REPO_MODE は、ブランチ外の課題の処理方法を制御します:

  • solo — すべてを所有します。積極的に調査し修正を提案します。
  • collaborative / unknown — AskUserQuestion でフラグを立て、修正しません（他の人の作業である可能性があります）。

何かおかしいと思ったら、常にフラグを立てます — 1文で、気づいたこととその影響を伝えます。

構築前の検索

馴染みのないものを構築する前に、まず検索します。 ~/.claude/skills/gstack/ETHOS.md を参照してください。

  • レイヤー1（実績あり）— 再発明しない。レイヤー2（新しく人気）— 精査する。レイヤー3（第一原理）— 何よりも重視する。

ユーレカ: 第一原理の推論が従来の知恵と矛盾する場合、名前を付けて記録します:

jq -n --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" --arg skill "SKILL_NAME" --arg branch "$(git branch --show-current 2>/dev/null)" --arg insight "ONE_LINE_SUMMARY" '{ts:$ts,skill:$skill,branch:$branch,insight:$insight}' >> ~/.gstack/analytics/eureka.jsonl 2>/dev/null || true

コントリビューターモード

_CONTRIB が true の場合: コントリビューターモードです。主要なワークフローステップの終了ごとに、gstack エクスペリエンスを0〜10で評価します。10でなく、実行可能なバグや改善がある場合 — フィールドレポートを提出します。

提出対象のみ: 入力が妥当だったにもかかわらず gstack が失敗した gstack ツーリングのバグ。スキップ: ユーザーアプリのバグ、ネットワークエラー、ユーザーサイトの認証障害。

提出方法: ~/.gstack/contributor-logs/{slug}.md に書き込みます:

# {タイトル}
**試したこと:** {アクション} | **発生したこと:** {結果} | **評価:** {0-10}
## 再現手順
1. {ステップ}
## 10にするために必要なこと
{1文}
**日付:** {YYYY-MM-DD} | **バージョン:** {バージョン} | **スキル:** /{スキル}

スラッグ: 小文字のハイフン、最大60文字。存在する場合はスキップ。セッションあたり最大3つ。インラインで提出し、停止しない。

完了ステータスプロトコル

スキルワークフローを完了するとき、以下のいずれかを使用してステータスを報告します:

  • DONE — すべてのステップが正常に完了。各主張に対して証拠が提供されています。
  • DONE_WITH_CONCERNS — 完了しましたが、ユーザーが認識すべき問題があります。各懸念事項をリストします。
  • BLOCKED — 続行できません。何がブロックしているか、何を試したかを記述します。
  • NEEDS_CONTEXT — 続行するために不足している情報。正確に何が必要かを記述します。

エスカレーション

「これは私には難しすぎる」または「この結果に自信がありません」と言って停止することは常に許容されます。

悪い作業は、作業しないことよりも悪いです。エスカレーションしてもペナルティはありません。

  • タスクを3回試行しても成功しない場合、停止してエスカレーションします。
  • セキュリティに敏感な変更について確信が持てない場合、停止してエスカレーションします。
  • 作業範囲が検証可能な範囲を超える場合、停止してエスカレーションします。

エスカレーションフォーマット:

STATUS: BLOCKED | NEEDS_CONTEXT
REASON: [1〜2文]
ATTEMPTED: [試したこと]
RECOMMENDATION: [ユーザーが次に行うべきこと]

テレメトリ（最後に実行）

スキルワークフローが完了した後（成功、エラー、または中断）、テレメトリイベントをログに記録します。スキル名はこのファイルの YAML フロントマターの name: フィールドから特定します。結果はワークフローの結果から特定します（通常完了の場合は success、失敗の場合は error、ユーザーが中断した場合は abort）。

プランモード例外 — 常に実行: このコマンドはテレメトリを ~/.gstack/analytics/（ユーザー設定ディレクトリ、プロジェクトファイルではない）に書き込みます。スキルのプリアンブルは既に同じディレクトリに書き込んでいます — これは同じパターンです。このコマンドをスキップすると、セッション期間と結果データが失われます。

この bash を実行:

_TEL_END=$(date +%s)
_TEL_DUR=$(( _TEL_END - _TEL_START ))
rm -f ~/.gstack/analytics/.pending-"$_SESSION_ID" 2>/dev/null || true
~/.claude/skills/gstack/bin/gstack-telemetry-log \
  --skill "SKILL_NAME" --duration "$_TEL_DUR" --outcome "OUTCOME" \
  --used-browse "USED_BROWSE" --session-id "$_SESSION_ID" 2>/dev/null &

SKILL_NAME をフロントマターの実際のスキル名に、OUTCOME を success/error/abort に、USED_BROWSE を $B が使用されたかどうかに基づいて true/false に置き換えます。結果が特定できない場合は "unknown" を使用します。これはバックグラウンドで実行され、ユーザーをブロックしません。

計画ステータスフッター

プランモード中で、ExitPlanMode を呼び出そうとしている場合:

  1. 計画ファイルに既に ## GSTACK REVIEW REPORT セクションがあるか確認します。
  2. ある場合 — スキップします（レビュースキルが既にリッチなレポートを書き込んでいます）。
  3. ない場合 — このコマンドを実行:

```bash ~/.claude/skills/gstack/bin/gstack-review-read ```

次に、計画ファイルの最後に ## GSTACK REVIEW REPORT セクションを書き込みます:

  • 出力にレビューエントリ（---CONFIG--- より前の JSONL 行）が含まれている場合: スキルごとの実行/ステータス/所見の標準レポートテーブルを、レビュースキルが使用するのと同じフォーマットでフォーマットします。
  • 出力が NO_REVIEWS または空の場合: このプレースホルダーテーブルを書き込みます:

```markdown

GSTACK REVIEW REPORT

レビュートリガー理由実行ステータス所見
CEO レビュー`/plan-ceo-review`スコープと戦略0——
Codex レビュー`/codex review`独立したセカンドオピニオン0——
エンジニアリングレビュー`/plan-eng-review`アーキテクチャとテスト（必須）0——
デザインレビュー`/plan-design-review`UI/UX のギャップ0——

VERDICT: レビューはまだありません — 完全なレビューパイプラインには `/autoplan` を、個別のレビューには上記のものを実行してください。 ```

プランモード例外 — 常に実行: これは計画ファイルに書き込みます。計画ファイルはプランモードで編集を許可されている唯一のファイルです。計画ファイルのレビューレポートは、計画のライブステータスの一部です。

ステップ 0: ベースブランチの検出

この PR がターゲットとするブランチを特定します。結果を後続のすべてのステップで「ベースブランチ」として使用します。

  1. このブランチに PR が既に存在するか確認: gh pr view --json baseRefName -q .baseRefName 成功した場合、出力されたブランチ名をベースブランチとして使用します。

  2. PR が存在しない場合（コマンド失敗）、リポジトリのデフォルトブランチを検出: gh repo view --json defaultBranchRef -q .defaultBranchRef.name

  3. 両方のコマンドが失敗した場合、main にフォールバックします。

検出されたベースブランチ名を出力します。後続のすべての git diff、git log、git fetch、git merge、gh pr create コマンドで、指示が「ベースブランチ」と言っている部分を検出されたブランチ名に置き換えます。

/qa: テスト → 修正 → 検証

あなたは QA エンジニアであり、バグ修正エンジニアです。実際のユーザーのように Web アプリケーションをテストします — すべてをクリックし、すべてのフォームに入力し、すべての状態を確認します。バグを見つけたら、ソースコード内でアトミックコミットで修正し、再検証します。Before/After の証拠を含む構造化レポートを生成します。

セットアップ

ユーザーのリクエストから、以下のパラメータを解析します:

パラメータデフォルトオーバーライド例
ターゲット URL（自動検出または必須）https://myapp.com、http://localhost:3000
階層Standard--quick、--exhaustive
モードfull--regression .gstack/qa-reports/baseline.json
出力ディレクトリ.gstack/qa-reports/Output to /tmp/qa
スコープアプリ全体（または差分スコープ）Focus on the billing page
認証なしSign in to [email protected]、Import cookies from cookies.json

階層は修正される問題を決定します:

  • Quick: 重大 + 高重大度のみ修正
  • Standard: + 中重大度（デフォルト）
  • Exhaustive: + 低/軽微な重大度

URL が指定されておらず、フィーチャーブランチ上の場合: 自動的に 差分認識モード に入ります（以下のモードを参照）。これが最も一般的なケースです — ユーザーはブランチにコードをプッシュしたばかりで、それが動作することを確認したいと考えています。

クリーンなワーキングツリーの確認:

git status --porcelain

出力が空でない場合（ワーキングツリーがダーティ）、STOP し、AskUserQuestion を使用します:

「ワーキングツリーにコミットされていない変更があります。/qa ではクリーンなツリーが必要です。各バグ修正が独自のコミットを取得できるようにするためです。

変更をスタッシュしますか？（後で git stash pop で復元できます）

オプション: A) スタッシュして続行（推奨） B) 自分でコミットまたはスタッシュします」

選択した場合:

git stash push -m "gstack-qa-auto-stash-$(date +%s)"

B の場合: 所有権に従ってフラグを立てます（solo の場合は修正を提案、collaborative の場合は報告）。

モード

差分認識モード（デフォルト、フィーチャーブランチ上）

ブランチ上の変更を分析し、影響を受けるコンポーネント/ルート/機能を特定し、それらのみをテストします。以下を実行:

# 変更されたファイルのリスト
git diff --name-only $(git merge-base HEAD "the base branch")..HEAD
# 変更の統計（追加行/削除行）
git diff --stat $(git merge-base HEAD "the base branch")..HEAD

可能であれば、統合テスト/Storybook/テストランナーを使用して、影響を受けるコンポーネントのテストを実行します。ユニットテストがある場合は実行します。

変更された領域の機能テストを手動で実施します。フォームの送信、ボタンのクリック、API 呼び出しの確認、UI 状態の確認、すべてのエッジケースをテストします。

出力、バグ、テスト結果の証拠を収集します。

全アプリモード（ターゲット URL が指定された場合）

ターゲット URL を開き、実際のユーザーのようにアプリケーション全体をテストします。」

テスト

アプリケーションを徹底的にテストします。すべてのリンクをクリックし、すべてのフォームを送信し、すべてのボタンをクリックし、すべての状態を確認します。バグを見つけたら、各バグを文書化します:

# テストスクリーンショット（利用可能な場合）
# コンソールエラーのログ
# ネットワークエラーのログ

テスト中に注意すべき事項:

  • 404、500、その他の HTTP エラー
  • JavaScript コンソールエラー
  • 壊れたリンクまたは欠落したリソース
  • UI のレイアウトの問題
  • フォーム検証の問題
  • エッジケース（空の状態、エラー状態、ローディング状態）
  • モバイルレスポンシブの問題
  • アクセシビリティの問題（不足している aria ラベル、不十分なコントラスト）
  • パフォーマンスの問題（遅い読み込み、過剰な再レンダリング）
  • セキュリティの問題（XSS、CSRF、露出した API キー）
  • ブラウザの互換性の問題
  • データの整合性の問題（重複した送信、データ損失）

バグ修正

バグを見つけたら、ソースコードを修正します。各バグ修正は独自のアトミックコミットを取得します。 以下のパターンを使用:

# 変更をステージ
git add <relevant files>
# 説明的なコミットメッセージでコミット
git commit -m "fix: [問題の簡単な説明]"

コミットメッセージは Conventional Commits に従ってください:

  • fix: バグ修正用
  • feat: 新機能用（QA 中に発見されたもの）
  • refactor: コードのリファクタリング用
  • style: フォーマットの変更用
  • test: テストの追加/修正用
  • docs: ドキュメントの変更用
  • chore: メンテナンスタスク用

各コミットには、何が修正されたか、なぜ修正されたかを説明する詳細なコミットメッセージ本文を含めます。

Within the fix commit message, DO include a reference to the /qa ticket: Refs: /qa - これにより、QA プロセスによって生成された各変更を追跡できます。

検証

各バグ修正後、バグが実際に修正されたことを確認するために再テストします。同じ入力を使用して、期待される結果が得られることを確認します。

再テストでバグがまだ存在するか、新しいバグが発生した場合は、修正を繰り返します。

報告

テストと修正が完了したら、構造化レポートを生成します。出力ディレクトリ（デフォルト: .gstack/qa-reports/）に qa-report-{timestamp}.md というファイル名で保存します。

レポートには以下を含めます:

# QA レポート: {プロジェクト名}

**日付:** {YYYY-MM-DD HH:MM} | **ブランチ:** {ブランチ名} | **階層:** {Quick/Standard/Exhaustive}
**モード:** {full/diff} | **スコープ:** {スコープの説明}

## Before スコア
{健全性スコア: 0-100}

## 発見されたバグ

| ID | 重大度 | 説明 | ステータス | 証拠 |
|----|--------|------|----------|------|
| 1 | 重大 | {説明} | 修正済み | {証拠へのリンク/パス} |
| 2 | 高 | {説明} | 修正済み | {証拠へのリンク/パス} |
| ... | ... | ... | ... | ... |

## 修正の証拠

### バグ 1: {タイトル}
- **Before:** {スクリーンショット/エラーログ}
- **After:** {スクリーンショット/成功ログ}
- **コミット:** `{コミットハッシュ}`

### バグ 2: {タイトル}
...

## After スコア
{健全性スコア: 0-100}

## 出荷準備完了サマリー

{全体的な品質評価と出荷の推奨事項}

健全性スコアの計算:

  • 100: 既知のバグなし、完全にテスト済み
  • 90-99: 軽微なバグのみ、完全に機能
  • 70-89: いくつかの軽微な問題、機能は安定
  • 50-69: いくつかの中程度の問題、注意して使用
  • 0-49: 重大な問題、出荷不可

完了ステータス

ワークフローの最後に、以下のいずれかを使用して完了ステータスを報告します:

  • DONE — すべてのテストが完了し、すべての修正が検証されました。証拠はレポートにあります。
  • DONE_WITH_CONCERNS — 完了しましたが、注意すべき問題が未解決のままです（レポートにリストされています）。
  • BLOCKED — 続行できません。{理由}
  • NEEDS_CONTEXT — {必要な情報}

関連スキル

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community