create-checklist

Create a behavior verification checklist from GitHub issue ( $ARGUMENTS ).$ARGUMENTS is the issue number (123、#123) or URL.

Procedure

1. tmp/issues/<issue番号>/ Read the following under
   • research.html: Acceptance criteria(AC) — serves as the starting point for the checklist
   • plan.html: Implementation plan (task and AC coverage) — material for assembling concrete operational steps to verify each AC
2. research.html Only when there is no gh issue view fetch the issue with/research first is desirable, but it works as a fallback)
3. git log main..HEAD --stat Check the commit-by-commit change summary with git show <hash> understand individual commit contents with
4. Assemble behavior verification items starting from each AC
   • Describe concrete browser operations and expected results for confirming that each AC is satisfied
   • For each AC, normal cases, error cases, and edge cases (if the AC is "error on invalid input", enumerate various invalid patterns)
   • Include the corresponding AC number alongside each checklist item (e.g. [AC1] 不正なメールでエラーが表示される）
5. Add viewpoints that are not explicitly covered by the AC but require behavior verification (performance, impact on other features, UI breakage, etc.) as supplementary items
6. Write the result with the Write tool as tmp/issues/<issue番号>/checklist.html に HTML write as

Reason for outputting in HTML rather than Markdown: The checklist deals with information for which structuring and visual distinction are useful, such as classification into normal cases / error cases / edge cases, the correspondence between AC numbers and each item, browser operation steps, and screen transition flows. By adopting HTML, you can make use of rich expressions that are difficult to achieve with Markdown, such as the implementation of checkboxes, AC number badges, color-coding by phase, screen transition diagrams with Mermaid, and collapsing of preconditions with<details> .

Output structure (required sections)

The layout and diagrams may be designed freely according to the content (no template is provided). However, so that /test / /create-pr-text / /review etc. can easily reference it, include the following sections as headings (<h2> etc.).

• Preconditions: Preparation required for test execution (environment, test data, etc.)
• Normal cases: Check items for standard cases that satisfy the AC (include the corresponding AC number for each item)
• Error cases: Check items for error situations
• Edge cases: Check items for boundary values and special conditions
• Supplementary items: Viewpoints not explicitly stated in the AC but requiring confirmation (performance, UI breakage, etc.)

Each check item is <input type="checkbox"> to track progress in the browser. If illustrating screen transitions or user flows would make it easier to understand, you may add Mermaid.

Notes

• In principle, do not create checklist items that do not cover ACs (ACs are precisely the definition of "working"). Exceptions should be clearly indicated as supplementary items
• If ACs are ambiguous and cannot be broken down into verification items, ask the user for confirmation
• If the codebase is large, limit investigation to the parts related to the issue