rewrite SETUP_CHECKLIST.md: replace checklist items with paste-able agent prompts

Each section now contains a self-contained prompt in a code block that
adopting users can paste directly to their agent. Prompts include full
URLs to raw reference docs. Fixes 'you provide' wording to 'your human
provides'. Keeps same phase/section structure.

OPENCLAW_TRICKS.md

@@ -1482,51 +1482,9 @@ Never send internal thinking or status narration to user's DM. Output should be:
 
 ## Gitea Integration & Notification Polling
 
-For self-hosted Gitea instances, you need a way to deliver notifications (issue
-assignments, PR reviews, @-mentions) to your agent. There are two approaches,
-depending on your network setup.
-
-### Notification Delivery: Webhooks vs Polling
-
-#### 1. Direct webhooks (VPS / public server)
-
-If your OpenClaw instance runs on a VPS or other publicly reachable server, you
-can run Traefik (or any reverse proxy) on the same server and configure Gitea
-webhooks to POST directly to OpenClaw's webhook endpoint. This is push-based and
-realtime — notifications arrive instantly.
-
-Set up a Gitea webhook (per-repo or org-wide) pointing at your OpenClaw
-instance's `/hooks/wake` endpoint. Gitea sends a POST on every event, and the
-agent wakes immediately to process it.
-
-#### 2. Notification poller (local machine behind NAT)
-
-If your OpenClaw instance runs on a dedicated local machine behind NAT (like a
-home Mac or Linux box), Gitea can't reach it directly. In this case, use a
-lightweight polling script that checks the Gitea notifications API every few
-seconds and signals the agent when new notifications arrive.
-
-This is the approach we use — OpenClaw runs on a dedicated Mac Studio on a home
-LAN, so we poll Gitea's notification API and wake the agent via the local
-`/hooks/wake` endpoint when new notifications appear. The poller script is
-included below in the [Notification poller](#notification-poller) section.
-
-The poller approach trades ~30 seconds of latency (polling interval) for
-simplicity and no NAT/firewall configuration. For most workflows this is
-perfectly fine — code review and issue triage don't need sub-second response
-times. If no new notifications arrive between heartbeats, the effective latency
-is bounded by the heartbeat interval (~30 minutes), but in practice the poller
-catches most events within seconds.
-
-#### Which should you choose?
-
-| Factor              | Webhooks            | Poller                    |
-| ------------------- | ------------------- | ------------------------- |
-| Network requirement | Public IP / domain  | None (outbound-only)      |
-| Latency             | Instant             | ~2-30s (polling interval) |
-| Setup complexity    | Reverse proxy + TLS | Single background script  |
-| Dependencies        | Traefik/nginx/Caddy | Python stdlib only        |
-| Best for            | VPS / cloud deploys | Home LAN / NAT setups     |
+For self-hosted Gitea instances, you can set up a notification poller that
+injects Gitea events (issue assignments, PR reviews, @-mentions) into the
+agent's session.
 
 ### Workflow rules (HEARTBEAT.md / AGENTS.md):