SKILL
Loopify
Plain markdown at a stable URL. Fetch it, follow it.
Interview a human about a job and write a reviewed markdown loop plan with goal, trigger, state, steps, checks, stop rule, approvals, evidence, runner, and first-run check.
Before you paste the prompt, you can build your own loop by naming the repeated steps, checks, stop condition, and approval gates.
Loopify
Loopify — the loop-design interview.
Loopify interviews you about a job, then writes the loop plan: goal, steps, check, stop rule, approvals, and evidence. Nothing runs until you approve it and verify one supervised pass.
Fetch https://loopmaster-ai.pages.dev/skills/loopify/SKILL.md and follow it.
Interview me, one question at a time, to define an agent loop for a job I want done.
Capture the goal, trigger, state, repeated steps, check, stop rule, approvals, logs or artifacts, runner or harness, and first-run check.
Do not set up or schedule anything until I approve the plan.The loop plan, written down:
Example: morning issue triage
- goal
- Every new issue has an owner and a next action.
- trigger
- Weekdays at 9:00, or on demand before standup.
- state
- Last checked issue ID, labels used, routing notes.
- steps
- Find new issues, label them, route each one, summarize.
- check
- Every new issue has a label, owner, and next action.
- stop
- Stop when no untriaged issues remain.
- escalate
- Closing, changing priority, or posting publicly comes to you.
- evidence
- Save a run log, routing summary, and links changed.
- runner
- Supervised first; add a harness only after the pass is verified.
- first run
- One supervised pass before trusting any repeat trigger.
Played transcript
› Loopify: What is the job, and what outcome should it produce?
you: watch our GitHub issues and triage new ones each morning
› Loopify: What should count as done?
you: every new issue has a label, an owner, and a next action
› Loopify: What should it escalate instead of deciding alone?
you: closing an issue, changing priority, or posting publicly
# Loop: morning issue triage
Goal: every new issue has an owner and a next action.
Trigger: weekdays at 9:00, or on demand before standup.
State: last checked issue ID, labels used, routing notes.
Steps each pass:
1. Find issues opened since the last pass.
2. Label each by area and severity.
3. Route each issue to an owner.
Check: every new issue has a label, owner, and next action.
Stop when: no untriaged issues remain.
Escalate: closing, reprioritizing, or posting publicly.Check before repeat: verify the first pass, keep stop and escalation rules visible, and approve any schedule or harness only after the run log proves the check works.
Output
What Loopify produces
- Goal
- Trigger
- State
- Steps each pass
- Check
- Stop when
- Ask a human before
- Logs/artifacts
- Runner/harness
- First-run check
- Open questions
Boundaries
What Loopify will not do
- Schedule or set up the loop before approval
- Publish publicly
- Spend money
- Ask for credential values
- Make destructive or production changes without approval
Goal vs loop
Loopify and /goal
/goal is for giving Codex a durable objective and a finish line. Loopify is for designing the repeated workflow around that objective: what the agent checks, which actions it may take, when it repeats, and when it stops or asks you.
Use /goal when one agent should keep working toward a measurable done state. Use Loopify when you need to define the loop first: trigger, context, actions, checks, stop condition, and approval gates.
| Thing | What it is for |
|---|---|
/goal | Keep Codex working toward one measurable objective. |
define-goal | Turn vague intent into a measurable goal. |
Loopify | Turn a job or agentic workflow into a loop plan. |
Loop Check | Review whether the plan has clear checks, stop rules, and approval gates. |
Loopify
Loopify turns a job into a loop plan. It does not set anything up first. It interviews the human, writes a plain markdown loop plan with the goal, state, action path, check, stop rule, runner, and evidence path, and waits for approval before scheduling, publishing, spending, or changing systems.
What to ask
Ask one question at a time. Do not ask for facts the human already gave you. Stop when you can answer these core questions:
- What is the job and what outcome should it produce?
- What should trigger a pass?
- What state should the loop read or save between passes?
- What steps repeat on each pass?
- What proves that a pass worked?
- When should the loop stop?
- What needs human approval before the agent acts?
If the human wants the work to recur, also ask what should trigger it and what timezone or event matters. Treat the trigger as a start signal, not as the loop itself.
Before writing the plan, ask only the follow-ups that are still missing and matter for execution: which runner or harness should own the repetition, what logs or artifacts should be left behind, and what first-run check would prove one pass worked.
Never ask for credential values. Ask only for credential names or scopes if they are needed.
Output format
Write the plan in plain markdown:
Loop: name
Goal: the outcome the loop is trying to produce.
Trigger: on demand, or the schedule or event the human requested.
State: what the loop reads and writes between passes.
Steps each pass:
- First repeated step.
- Second repeated step.
- Third repeated step.
Check: what proves a pass worked.
Stop when: the goal is met, no useful work remains, the step limit is reached, or approval is needed.
Ask a human before: public posting, destructive changes, spending money, creating or changing credentials, changing production systems, or anything else the human named.
Logs/artifacts: where the transcript, report, pull request, screenshot, saved state, or other evidence should go.
Runner/harness: native loop-capable agent mode, scheduled task, cron job, queue worker, workflow, script, or unknown.
Dry-run check: how to run one supervised pass and prove it behaved correctly.
Pass log: after the dry run is approved and executed, record what ran, what the check found, what state was written, and what was skipped.
Open questions: list only the questions that still block safe execution.
Safety rules
Never schedule, publish, spend, change credentials, delete data, overwrite user work, or make production changes without approval.
Never invent sources, owners, schedules, permissions, credential details, runner capabilities, or evidence. If something is missing, say what is missing.
If the plan is approved, offer to set it up using the native tools available to the agent: a scheduled task, cron job, saved prompt, repository workflow, or task runner. loopmaster.ai defines the loop plan. The user's own agent chooses the runtime.