AIと二人三脚でChrome拡張を作ったら、同じバグを何度も直す羽目になった
Hiroba による自動要約
Amazon 向け Chrome 拡張を Claude と Codex で開発した際、テストが通るのに実際のブラウザで動作しない、修正が完了したはずなのに別の要素まで消える、といった問題が繰り返された。根本原因は AI に「完了の定義」を明文化していなかったこと。JSDOM と実際の DOM の乖離、Manifest V3 の Service Worker サスペンド、Amazon の A/B テストによる DOM 変動など、複数の落とし穴を解説し、agent-handoff.md による共通ルール化で解決した経験。
読んで良かったら、シェアしてみてください。
同じタグの記事が他に 464 件あります。
関連する記事
同じタグの記事
KIOKU v0.10：Obsidian なしでブラウザから Wiki を検索・管理する記憶プラットフォーム
ZennClaude Code / Desktop / Codex CLI / Gemini CLI 向けの記憶 OSS「KIOKU」が v0.10 に到達。Obsidian を起動せずに Web UI でダッシュボード・時間軸・検索機能を備えた Wiki を一望でき、ブラウザ検索と Claude による深掘りが統合された。設計上、ブラウザは読み取りに専念し、編集は Obsidian / VS Code に任せる分業体制を確立。
Claude Code Skills でチームの E2E ワークフローを組み立てた話
ZennClaude Code の Skills を用いて、Playwright による E2E テスト生成・実行・レポート化を自動化した事例。テストコード生成（プロンプト）と実行・レポート化（Skill）の 2 段階に分離した設計背景、Playwright 選定理由、運用上の落とし穴を解説。
激詰レビュワーSKILL：分からないコードをPRに出すな
QiitaClaude Code で生成したコードをPR前に理解度を検証する Skills「激詰レビュワー」を紹介。diff 内容を読み込み段階的に質問し、実装理由・アーキテクチャ選定理由・副作用の説明ができるまでPR作成を許さず、AI依存による学習機会の喪失を防ぐ手法。レビュー記録も自動出力。
Claude Code の Skills を「育てる資産」に変える設計指針と実装パターン
QiitaClaude Code の Skills を効果的に運用するため、CLAUDE.md との役割分業、description の書き方（「Use when 〜」形式での具体化）、チーム向けの命名規則（review-、gen-、audit- など接頭辞）、実装時の 3 つの落とし穴（動作内容の詰め込み、巨大コード埋め込み、評価フィードバックの不足）、新規 Skill レビュー時の 5 点チェックリストを整理した運用ガイド。