Add guidance on avoiding duplicate payments when retrying stuck invoices

[molty21]

Problem

When a Lightning payment appears to hang or get stuck, users might instinctively retry by creating a new invoice and attempting to pay again. This can result in multiple successful payments for what was intended to be a single transaction.

What happened to me

I was topping up an account with $10. The first payment seemed stuck, so I created a second invoice and tried again. Both payments eventually went through, spending $20 instead of $10.

Suggested fix

Add a section to the SKILL.md (or README) with guidance on handling stuck/pending payments:

When a payment appears stuck:

1. WAIT - Lightning payments can take time, especially during network congestion
2. CHECK - Verify the transaction status before retrying
3. ONE INVOICE AT A TIME - Never create a new invoice until the previous one is confirmed failed or expired
4. TRACK - Keep the invoice ID and check if payment succeeded before creating another

Recommended pattern:

# After creating an invoice, save the ID
INVOICE_ID="abc123"

# If payment seems stuck, check wallet transactions first
npx @getalby/cli list-transactions

# Or look up the specific invoice
npx @getalby/cli lookup-invoice -i "$INVOICE_ID"

Benefit

This would help users avoid accidental double-payments and reinforce good Lightning payment hygiene.

[lmee]

I reviewed "Add guidance on avoiding duplicate payments when retrying stuck invoices" and read all comments before proposing a patch path.

Problem I see: When a Lightning payment appears to hang or get stuck, users might instinctively retry by creating a new invoice and attempting to pay again. This can result in multiple successful payments for what was intended to be a single transaction.
Root-cause hypothesis: a state flow mismatch between action handling and final UI state.
First patch plan: reproduce the issue against acceptance criteria, isolate the root cause in the relevant module, and submit a focused fix with regression tests.
If you want this path, I can share deterministic repro notes up front and then submit the minimal fix.