Introducing /migrate-to-e2e Allow your agent to migrate your existing end-to-end test suite to agentic e2e one slice at a time. ~/ npx skills add tester-army/e2e --skill migrate-to-e2e

pstack ガイド（Part 2）を読んだメモ Part 2では、Part 1で整えた検証環境を使いながら、問題の調査、設計、プロトタイピング、実行計画をどう進めるかを説明している pstack使わなくても学びが多くあったため、スレッドで詳細もまとめてます！ 1. エージェントに質の高い仕事をしてもらうには、目的と背景を十分に伝える。**実装方法を細かく決めすぎず**、人間が思いつかなかった解決策を探す余地も残す。 2. 実装前に、問題をエージェント自身の言葉で説明させる。雑多な会話を整理し、誤解を早く見つけ、人間の仮説によって調査の方向を狭めることを避ける。 3. /howで現在の仕組み、/whyで設計の背景を調べ、/teachで理解できる説明にする。説明のための調査は、人間の判断を助けるとともに、エージェント自身の理解にも役立つ 4. /recallで過去の会話から関連する作業を振り返る。**以前の調査や判断、失敗を新しい作業に引き継ぎ、目の前の症状だけで解決策を考えないようにする** 5. READMEやチュートリアルを先に書き、**利用者の使い方からAPIや内部設計を考える**。使い方を具体化することで、人間が完成形を理解でき、エージェントも実装を確かめる対象を持てる。 6. /technical-writingで、文書をチュートリアル、ハウツー、リファレンス、解説に分ける。文書を用途ごとに分け、/unslopで文章を整え、設計や使い方が伝わる文書にする。 7. **最初の設計をそのまま採用せず、複数案をプロトタイピングして比較する**。プロトタイプは判断のために作り、実際の操作、スクリーンショット、動画、測定結果を使って案を選ぶ。 8. **実験（小さく作って動かし、結果を確かめること）で答えられる疑問は、エージェント自身に確かめさせる**。抽象的な計画へのレビューを重ねて、根拠のない懸念を増やすより、プロトタイプと検証で不確かな点を減らしていく 9. **大きな変更では、/architectで既存の制約を調べ、利用例、データ構造、型、API、責任分担を設計する**。複数モデルによる独立した案と評価を使い、比較・統合してから実装する 10. 実装で設計との食い違いや再利用可能な回避策（処理）が見つかったら、設計を見直す。**細かな実装はエージェントに任せ、人間はデータの持ち方・構造やシステム間の連携を重視**し、実装で得た証拠によって、当初の設計をやり直す判断もする。 11. **設計が具体化したら、計画プレイブックで小さく検証できる作業やPRに分ける**。各作業に完了の証拠を定め、テストだけで済ませず、実際に動かして確認する。計画の構造や書式もスクリプトでチェックする。 12. **計画書は、実行や進行中の作業共有のために使う**。@poteto さんは、大きな作業では一時的にリポジトリへ置くこともあるが、完了後は混乱を残さないよう通常は削除している。 13. **/poteto-modeは、依頼に応じてプレイブックや関連スキルを使う入口となっている**。人間が毎回すべての手順を列挙する必要はなく、目的、制約、確認したい結果、必要なレビューのタイミングを伝える