loopify
When you want to set up an agent loop, cron-scheduled task, or recurring workflow that runs autonomously in Claude Code. Judgment layer on top of ScheduleWakeup, CronCreate, and the /loop skill — decides whether to use dynamic pacing (self-scheduling wake-ups), cron scheduling (fixed intervals), or a one-shot loop; tunes delay to avoid the 5-minute cache-miss cliff; designs idempotent loop bodies; sets bail-out conditions so loops don't run forever. Examples of loops to loopify — weekly review pulse, daily brief generation, hourly monitoring of a metric, periodic vault compilation, upstream-check for an adapted skill, sponsorship-pipeline refresh, YouTube-transcript-batch-download, morning startup routine. Triggers on "/loopify," "set up a loop," "schedule this task," "run this daily," "run this weekly," "cron this," "make this recurring," "automate this on a schedule," "keep this running until X." Part of the -ify trifecta (skillify / toolify / loopify) for extending Claude Code. NOT for authoring a new skill — that's skillify. NOT for adding a tool/integration — that's toolify.
git clone --depth 1 https://github.com/coreyhaines31/makerskills /tmp/loopify && cp -r /tmp/loopify/skills/loopify ~/.claude/skills/loopifySKILL.md
# /loopify — Set up an agent loop
Wizard for going from *"this task should run periodically"* to a working loop with the right pacing, idempotency, and bail-out. Reference: `ScheduleWakeup` (dynamic pacing), `CronCreate` (fixed schedule), and the built-in `/loop` (dynamic self-paced re-entry).
## Step 0 — Confirm what you're looping
Ask if not obvious from context: *"What task should this loop do each iteration?"*
Then get the essentials:
| Question | Why it matters |
|---|---|
| **How often?** | Determines cron vs dynamic vs one-shot |
| **When to stop?** | Bail-out condition — loops must have one |
| **What's the loop body doing?** | Determines idempotency requirements |
| **Where does output go?** | File / notification / commit / nothing |
| **What's the failure mode if it runs twice?** | Idempotency validation |
## Step 1 — Pick the pattern
Three primary patterns. Route by the answer to "how often":
### Pattern A — Cron (fixed schedule)
**Use when**: task runs at predictable intervals — daily at 8am, weekly on Fridays, hourly on the hour.
Tool: `CronCreate` — schedules a recurring task with a cron expression.
```
CronCreate({
schedule: "0 8 * * *", // daily at 8am local
prompt: "<loop body prompt>",
timezone: "America/Los_Angeles"
})
```
Common cron patterns:
- `0 8 * * *` — daily at 8am
- `0 9 * * 1` — Mondays at 9am
- `0 9 * * 5` — Fridays at 9am
- `0 */2 * * *` — every 2 hours
- `*/15 * * * *` — every 15 minutes
**Trade-offs:**
- ✅ Predictable, human-readable, easy to reason about
- ✅ Best for time-of-day-dependent tasks (morning brief, EOD summary)
- ❌ Runs at the scheduled time even if the last run isn't done — need idempotent body
- ❌ No self-pacing — over-schedules if the task duration varies wildly
### Pattern B — Dynamic pacing (self-scheduled)
**Use when**: task should react to state, not the clock. Monitor-until-condition-met patterns. Waiting on an external event.
Tool: `ScheduleWakeup` — the current run schedules its own next wake-up.
```
ScheduleWakeup({
delaySeconds: 270, // stay in cache window (< 5min)
reason: "checking build status; sleeping under 5min to stay cache-warm",
prompt: "<same task, re-entered>"
})
```
**Critical delay rules** (from `ScheduleWakeup` docs — internalized in the wizard):
| Delay range | Use for | Cache impact |
|---|---|---|
| **60s–270s** | Active work — polling build, waiting for state that's about to change | Stays in 5-min prompt cache — fast + cheap |
| **300s** ❌ | **DON'T USE THIS** | Worst of both worlds — pay cache miss without amortizing |
| **300s–3600s** | Waiting on something that takes minutes to change | Pay cache miss but justified |
| **1200s–1800s** (20–30 min) | Idle ticks with no specific signal | Default for autonomous loops |
Never pick 300s literally — either drop to 270 (cache stays warm) or commit to 1200+ (cache miss buys longer wait).
**Trade-offs:**
- ✅ Adaptive — sleeps longer when idle, shorter when active
- ✅ Cache-optimal when tuned right
- ❌ Requires the loop body to know when to schedule next (extra logic)
- ❌ Harder to reason about when it'll run
### Pattern C — One-shot loop (until-condition)
**Use when**: task runs until a condition is met, then stops. No recurrence after that.
Tool: `/loop` (built-in) with an exit condition in the prompt itself.
```
/loop
Check if the deploy is healthy. If yes → stop. If no → wait 5 min and check again.
Max 10 iterations. If still failing after 10, alert and stop.
```
**Trade-offs:**
- ✅ Simplest for check-until-condition
- ✅ Bounded — always eventually terminates
- ❌ Not for indefinite recurrence — that's Pattern A or B
## Step 2 — Design the loop body for idempotency
Idempotent = running the loop twice produces the same result as running it once. **Non-negotiable for cron and dynamic patterns** because they'll fire while the previous iteration is still running or partially complete.
Idempotency patterns:
- **Use "already done" markers**: e.g., commit a state file `<vault>/.loopify/<name>-last-run.txt` with the timestamp of last successful run. Loop body checks the timestamp before doing work.
- **Use dedupe keys**: if the loop writes to a DB or file, key by content-hash or timestamp so re-runs are no-ops.
- **Use transactions**: DB writes in the loop body should be atomic — either all commit or all roll back.
- **Query before mutate**: check current state before applying the change. If already applied, skip.
Show the user the loop body draft, highlighting the idempotency check. If none exists, add one.
## Step 3 — Bail-out condition
Every loop needs one. Options:
| Bail-out | When to use |
|---|---|
| **Max iterations** (e.g., stop after 100 runs) | Cron loops — prevents runaway |
| **State-based** (e.g., stop when metric X drops below Y) | Monitoring loops |
| **Time-based** (e.g., stop after 24 hours) | Bounded monitoring |
| **Error-based** (e.g., stop on 3 consecutive failures) | All loops — catches degradation |
If the loop is truly indefinite (e.g., a weekly cron with no end), still add a manual bail-out via `CronDelete`. Document it in the SKILL/loop notes so the user knows how to stop it.
## Step 4 — Set the schedule
Based on the pattern from Step 1:
**Cron (Pattern A):**
```
CronCreate({
schedule: "<expression>",
timezone: "<tz>",
prompt: "<loop body>",
})
```
Report the `cron_id` returned so the user can `CronDelete` later.
**Dynamic (Pattern B):**
Wrap the loop body prompt so it ends with a `ScheduleWakeup` call:
```
<do the work>
Then: ScheduleWakeup({delaySeconds: <tuned per Step 1>, prompt: "<same body>", reason: "<why this cadence>"})
```
**One-shot (Pattern C):**
Just run `/loop <prompt with exit condition>`.
## Step 5 — Verify the first run
Wait for the first iteration (or trigger it manually via `/loop` with the same prompt for a dry-run). Confirm:
- Output landed where expected
- Idempotency check works (run twice — second should be a no-op)
- Bail-out condition wouWhen you want to pressure-test a potential new business, product, or side project against the serial-founder filter. Not \"marketing ideas for a product\" (that's marketing-skills:marketing-ideas) — this is \"should this business exist + can you win it.\" Runs the idea through a structured framework (problem, audience, wedge, monetization, moat, portfolio fit, distribution, energy fit, opportunity cost), checks domain availability via /domain, optionally triggers /deep-research for market validation, and outputs a viability brief: build / sleep on it / pass. Archives every idea to ~/.config/makerskills/business-brainstorm/archive/ so past work is searchable. Triggers on \"/business-brainstorm,\" \"/brainstorm,\" \"new business idea,\" \"should I build X,\" \"pressure test this idea,\" \"validate this idea,\" \"is X a good business,\" \"what about a [type] for [audience].\"
Your team's shared, AI-ready knowledge base — people, companies, meetings, SOPs, and decisions structured so Claude can answer questions on your team's behalf. Team-scope sibling to second-brain (which is personal-scope). Seven modes — capture (drop something into the right structured dir), compile (process into wiki pages, update INDEX.md), query (answer from the corpus with trust weighting, save to outputs/), review (triage queue — verify / deprecate / supersede unreviewed and stale captures so wrong info never becomes context), lint (orphans / stale / contradictions / gaps), connect (suggest new wikilinks), search (quick lookup). Structured raw dirs (people/, companies/, meetings/, sops/, decisions/, customer-language/, recurring-questions/, sales-objections/) instead of second-brain's flat type-prefixed raw/. Multi-author aware — every capture stamps author + timestamp + trust status. Optional auto-sync from Fathom/Gong/Granola call transcripts, Slack/email exports, CRM. Defaults to a vault at ${COMPANY_BRAIN_VAULT:-$HOME/Documents/CompanyBrain}/. Triggers on "/company-brain," "/cb," "capture this into the team brain," "log this meeting," "add this person to the team brain," "save this SOP," "compile the company wiki," "query the team brain," "what does the team know about X," "review the company brain," "cull the team brain," "lint the company brain," "who's the internal expert on X.
Monthly CFO workflow for a company or agency — pull raw data from bank + payment processor + payroll + expense management, categorize and reconcile, compute end-of-month cash via transaction-sum method, update a scenario projector for forward forecasting, write the monthly snapshot report, surface decisions to leadership. Modes — monthly (default; the standing report), weekly (thin cash pulse), scenario (ad-hoc modeling in the projector), pickup (resume where the prior run left off). Anonymized team-scope sibling to personal-cfo (which handles personal household finances). Composes with company-brain (report gets stored + wiki-indexed there), toolify (wire company-specific data sources), loopify (schedule the monthly + weekly runs). Triggers on "/company-cfo," "/cfo," "monthly cash report," "do the CFO snapshot," "CFO monthly," "let's run CFO," "cash projection," "runway forecast," "monthly financials," "cash pulse.
When you have a decision to make and want a structured workflow that picks the load-bearing questions, walks through them, reaches a call (or "wait"), and archives the rationale for future reference. Based on the 37signals Guide to Making Decisions (38 questions) plus house additions like Q39 opportunity cost ("what does saying yes displace?"). Triages to 6–8 relevant questions per decision instead of forcing the full set. Archives every decision to ~/.config/makerskills/decide/archive/ with a revisit date so you can check later whether the call was right. Triggers on "/decide," "help me decide," "should I [X]," "I need to make a decision about," "stuck on a decision," "deciding between," "go/no-go on," "what should I do about." This is both the decision-making workflow AND the decision log — making the decision is the act of logging it.
When you want multi-source, multi-step research on a topic — competitor research before a sales call, market research for a new business idea, positioning angles, due diligence on a partnership or podcast guest, tech decision research (which DB, which auth), or any \"I need to actually understand X.\" Combines WebSearch, WebFetch, agent-browser, /last30days (Reddit/X/YouTube/HN/web recency), memory, and Notion. Outputs a structured brief with citations, contradictions, gaps, and recommended next steps. Archives every research run to ~/.config/makerskills/deep-research/archive/ so past work is searchable. Triggers on \"/deep-research,\" \"research X,\" \"investigate X,\" \"do a deep dive on X,\" \"look into X,\" \"what's actually happening with X,\" \"due diligence on X,\" \"validate this market.\" Differs from a one-shot WebSearch: this is multi-pass with verification.
When you want to brainstorm and check available .com domains for a new project — brand naming, aftermarket pricing (HugeDomains / Afternic / Sedo / Dan), USPTO trademark screening, and social handle availability. Built on Laura Roeder's \"work backwards from availability, not from a name you fell in love with\" methodology. Uses Vercel CLI + whois + Domainr API + Namecheap API + agent-browser for the pieces each tool actually reliably supports (multi-tool ensemble because no single tool covers everything cleanly). 11-step workflow: budget → brainstorm → primary availability check → whois cross-check → Domainr aggregation → Namecheap price → aftermarket sweep (+ liveness probe for parked/dead domains, drop-watch for expiring ones) → bucket → negotiate → NAME research (trademark + socials) → buy. Triggers on \"/domain,\" \"find a domain,\" \"check domain availability,\" \"brainstorm a domain,\" \"what .com is available for X,\" \"domain hunt,\" \"name my project,\" \"is X.com available,\" \"aftermarket price on X.com,\" \"trademark check for X.\"
Gary Vaynerchuk's jab-jab-jab-right-hook framework applied to a personal portfolio rotation on X and LinkedIn. Jabs = build-in-public + educational (value). Hooks = promo (the ask). Each property in the user's configured portfolio (see `~/.config/makerskills/jab-hook/properties.yaml`) gets a hook at least once every ~3 weeks; jabs fill the rest. Drafts go into the user's Typefully workspace via MCP. Modes — plan (7-day plan), pick-next (single post), audit (coverage report), draft (specific post). Triggers on "/jab-hook," "what should I post," "plan my socials," "next promo," "next jab," "next hook," "social rotation," "promote [property]," "BIP post," "audit my socials," "what haven't I posted about.
When you want multiple expert perspectives on a founder/operator question — a simulated personal board of advisors staffed by legendary founders, CEOs, and operators (Jason Fried, Elon Musk, Jeff Bezos, Jensen Huang, Bob Iger, Paul Graham, Naval Ravikant, Sara Blakely). Bring a real decision — \"should I raise prices?\", \"hire my first employee?\", \"raise or bootstrap?\", \"kill this project?\" — and the council weighs in through their documented frameworks, surfaces where they disagree, and synthesizes a recommendation. Also use when the user mentions 'maker council,' 'board of advisors,' 'what would Bezos do,' 'what would Jason Fried say,' 'channel Naval,' 'ask the council,' 'get multiple perspectives on this decision,' or asks how a famous founder would approach their problem. Optional live-research pass grounds takes in what each member has actually said (via deep-research / watch-video / last30days). Sibling of marketing-skills' marketing-council (marketing questions go there; company-building and operator questions come here). Archives sessions to ~/.config/makerskills/maker-council/archive/. For committing to one of the surfaced directions, hand off to decide.