PENGIN Tools Product Quality Gate

更新: 2026-08-26

なぜ作り直すか

これまでの評価は「ファイルがある」「説明が詳しい」「単体テストが通る」に寄りすぎていた。 利用者が欲しいのは手順書ではなく、面倒な仕事が安全に終わることである。

今後、README・SKILL.md・テスト数は品質の根拠にしない。次の実務成果で判定する。

公開できる条件

成果物は、次の全項目を満たすまで公開候補にしない。

1. 入口が簡単 — 利用者は対象と目的を伝えるだけで開始できる。手順を組み立てる作業を利用者へ戻さない。
2. 作業を実行する — チェックリストを返すだけではなく、許可された環境で読み取り・生成・検証を実行する。
3. 途中状態を保持する — 再開時に、完了・未完了・承認待ち・失敗箇所を機械的に復元できる。
4. 失敗時に戻せる — 変更前の証跡と復元経路を持ち、ロールバックを実行または具体的に案内できる。
5. 成果物が残る — 実行ログ、検証結果、残課題、引き渡し情報を1つのレポートへまとめる。
6. 実環境で完走済み — モックや文字列テストだけでなく、破棄可能な実環境で入口から出口まで完走している。
7. 既存手段より明確に楽 — 手作業や既存無料ツールと比べ、時間・事故率・確認漏れのどれかを具体的に減らす。
8. 初見の第三者が使える — 作者の補足なしで、対象ユーザーが成功または安全に停止できる。

1項目でも未達なら、状態は NOT RELEASE READY とする。

再査定（2026-09-01 / Day 16 更新）

Migrationの実環境完走の根拠は e2e-result.md。この1本だけが8項目を満たしている。

この基準に対して、自分が破ったこと（Day 16に確認）

上の「当面のルール」を自分で書いておきながら、2つ破っている。事実として残す。

「未検証と明記すれば出してよい」と、いつの間にか基準を読み替えていた。 Mission側の「完成度70%で出す」と、この文書の「実環境完走まで公開しない」が衝突していたのに、 衝突を明示せず、都合よく前者だけを使った。

正しくは、衝突していることを先に書いて、どちらを採るかを1回決めるべきだった。

現時点での整理（衝突の解消）

• 実行コードを含まないSkill（Triage / Launch Check）→ 下振れは「誰も来ない」。Mission側の70%基準を採る
• 実行コードを含むもの（CLI 8本、Migrationのスクリプト）→ この文書の基準を採る。実環境で一度も走らせずに出さない

CLI 8本は読み取り専用なので他人のサイトは壊さないが、壊さないことと、役に立つことは別。 verify_all.py を1回通すだけで INTERNAL ALPHA から一段上がる。そこが最短の1手。

当面のルール（維持）

• SKILLの行数、テスト数、READMEの完成度を進捗率に含めない。
• 実行コードを含む成果物は、実環境E2E前の外部公開申請を作らない。
• 既存公開物は「公開済みだから完成」とみなさず、同じ基準で再審査する。
• 新しいツール案を増やす前に、1つを入口から出口まで完走させる。
• 基準どうしが衝突したら、都合のよい方を黙って採らない。 衝突を書いてから決める。