new-issuelisted

相談者としてIssueを作成する。**実装しない**。書き出したら止まる（実装は user が `issue()` で起動する）。 0. 軽量経路チェック: 以下3条件を**全て**満たすなら、Issue化せずここで止まり、対象ファイルと理由を一言添えて相談者が直接編集してよい（単発例外の宣言は不要） 1. diff がロジックに触れない（config・README・コメント・デバイス名の置換など） 2. 保証台帳（`docs/guarantees.md`）に触れない（挙動の契約を変えない） 3. 単一ファイル・数十行以内 1. 正本テンプレート `~/.claude/skills/repo-standardize/reference/issue-template.md` を読む 2. 既存の `issues/*.md` を確認し、次の `id` を決める（2桁連番。検証NGからの派生は元をcloseして `{id}a`） 3. userの要望を要件・制約・対象ファイル（行の指し先まで）に整理する。曖昧な点はここで質問する 4. テンプレート後半の「Issue作成ルール」（粒度・分割基準）に従い設計する - 1セッションで完走できる量・対象7ファイル以下・確認手段は1種類 - 大きければ分割を提��する - コードは書かず、要件・制約・指し先で書く。ただし自由度を残すと実行者が迷う・手戻りすると判断した箇所はコードを書いてよい - 保証節を必ず起草する。対象リポに保証台帳 `docs/guarantees.md` があれば、変更が触れる範囲の保証はそこから引いて「維持する保証」に列挙する（台帳が無ければ既存テストから直接読み取る）。台帳の記載に変更が出る場合（新保証・変更・廃止）は台帳を対象ファイルに含める - 新たに宣言する保証が契約面（公開API・CLI・外部から観測可能な振る舞い）なのに裏付けテストが対象に無い場合、台帳スコープ外を理由に素通りしない。draft 報告時にテスト欠落として明示し、本Issueにテストを含めるか・理由を保証節に記録して見送るかを user に確認する 5. 機密マスク: `~/dotfiles/secrets-agents/` の辞書を読み、説明文中の固有接続情報（ドメイン実値・公開ポート・Tunnel UUID・本番絶対パス・Tailscale IP / SSH ユーザ等）を `<PLACEHOLDER>` に置き換える 6. `issues/{id}_{slug}.md` に `status: draft` で書き出す 7. ファイルパスと概要を報告して止まる。user が保証節を裁可したら `status: open` に変更するよう伝える