playbooks

home / skills / phrazzld / claude-config / fix-lightning

fix-lightning skill

/skills/fix-lightning

This skill audits Lightning health and fixes the highest priority issue in one pass, then verifies and reports results.

npx playbooks add skill phrazzld/claude-config --skill fix-lightning

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
2.6 KB
---
name: fix-lightning
description: |
  Run /check-lightning, then fix the highest priority Lightning issue.
  Creates one fix per invocation. Invoke again for next issue.
  Use /log-lightning-issues to create issues without fixing.
effort: high
---

# /fix-lightning

Fix the highest priority Lightning issue.

## What This Does

1. Invoke `/check-lightning` to audit Lightning health
2. Identify highest priority issue
3. Fix that one issue
4. Verify the fix
5. Report what was done

**This is a fixer.** It fixes one issue at a time. Run again for next issue. Use `/lightning` for full lifecycle.

## Process

### 1. Run Primitive

Invoke `/check-lightning` skill to get prioritized findings.

### 2. Fix Priority Order

Fix in this order:
1. **P0**: Node not synced, watchtower not configured
2. **P1**: Peer connectivity issues
3. **P2**: Low inbound liquidity, channel rebalancing needed
4. **P3**: Advanced routing/fees

### 3. Execute Fix

**Node not synced (P0):**
Confirm chain sync:
```bash
lncli getinfo
bitcoin-cli getblockchaininfo
```

If `synced_to_chain=false`, restart LND after backend is healthy:
```bash
sudo systemctl restart lnd
```

**Watchtower not configured (P0):**
Enable watchtower client and add a tower:
```bash
# lnd.conf
wtclient.active=1

lncli wtclient add --tower_addr=host:9911
```

**Peer connectivity issues (P1):**
Reconnect to peer:
```bash
lncli listpeers
lncli disconnect <pubkey>
lncli connect <pubkey>@host:port
```

**Low inbound liquidity (P2):**
Open a channel with pushed sats to create inbound:
```bash
lncli openchannel --node_key=<pubkey> --local_amt=1000000 --push_amt=200000
```

**Channel rebalancing needed (P2):**
Move balance from outgoing-heavy to incoming-heavy channel:
```bash
lncli listchannels
lncli rebalancechannel --from_chan_id=<from> --to_chan_id=<to> --amount=50000
```

### 4. Verify

After fix:
```bash
lncli getinfo
lncli listchannels
lncli listpeers
```

### 5. Report

```
Fixed: [P0] Node not synced

Updated: lnd service
- Restarted after chain backend healthy
- Confirmed synced_to_chain=true

Verified: lncli getinfo → synced_to_chain=true

Next highest priority: [P0] Watchtower not configured
Run /fix-lightning again to continue.
```

## Branching

Before making changes:
```bash
git checkout -b fix/lightning-$(date +%Y%m%d)
```

## Single-Issue Focus

Lightning is sensitive. Fix one thing at a time:
- Test each change thoroughly
- Easy to rollback specific fixes
- Clear audit trail for ops

Run `/fix-lightning` repeatedly to work through the backlog.

## Related

- `/check-lightning` - The primitive (audit only)
- `/log-lightning-issues` - Create issues without fixing
- `/lightning` - Full Lightning lifecycle

Overview

This skill runs a Lightning health audit and fixes the single highest-priority issue it finds. It automates one corrective action per invocation, verifies the change, and reports the outcome so you can iterate safely. Invoke repeatedly to address the next issue in the backlog.

How this skill works

The skill first calls the Lightning audit primitive to get prioritized findings. It selects the top-priority item and executes a targeted remediation (for example: restart LND if the node is out of sync, enable a watchtower client, reconnect peers, open a channel with pushed inbound liquidity, or rebalance channels). After the fix it runs verification commands and returns a concise report describing what changed and what to run next.

When to use it

  • When /check-lightning reports one or more prioritized issues and you want an automated fix for the highest priority item.
  • During incident response to quickly remediate a single blocking problem without changing multiple components.
  • When you prefer incremental, auditable changes and want to test one fix at a time.
  • When you need a verified remediation and a clear next step to continue fixing remaining issues.
  • When you want to avoid bulk changes and maintain easy rollback points.

Best practices

  • Run the audit (/check-lightning) first to confirm current priority findings before invoking this fixer.
  • Use version-controlled branches before making changes for clear audit and rollback (create a feature branch per fix).
  • Fix one issue per invocation; run the skill again for the next prioritized item to preserve safe change boundaries.
  • Verify LND and backend health manually if a P0 node sync issue is detected before restarting services.
  • Document each fix in your change log or ticketing system using the report this skill returns.

Example use cases

  • Node shows synced_to_chain=false: restart LND after backend recovery and verify chain sync.
  • Watchtower not configured: enable the wtclient and add a tower to protect channels from breaches.
  • Peer connectivity problems: disconnect and reconnect peers to restore network connectivity.
  • Low inbound liquidity: open a channel with a push amount to create inbound capacity for receiving.
  • Channel imbalance: rebalance funds from outgoing-heavy to incoming-heavy channels to improve routing.

FAQ

How many fixes does this skill apply per run?

One fix per invocation. Run the skill again to address the next highest-priority issue.

Will it automatically restart services?

Yes for specific P0 scenarios like node not synced, but only after the backend is healthy and as a single, targeted action.