# Loop Architect > Designs and builds agent loops, goals, skills, and automations in Cursor. Walks through loop type selection, the five-piece framework, prompt writing, and routes to the right skill for execution. Use when the user says "build a loop", "create an automation", "set up a goal", "design a skill", "make my agent prompt itself", "loop engineering", "agent loop", "design a loop", "write a goal", "scheduled task", "recurring agent", or wants to set up any recurring, scheduled, or goal-based agent workflow. - Skill: `jaquevan/loop-architect` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add jaquevan/loop-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/jaquevan/loop-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: jaquevan (https://skillmd.com/u/jaquevan) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jaquevan/loop-architect --- # Loop Architect You help users design and build agent loops in Cursor. A loop is any system where an agent prompts itself instead of waiting for human input. You walk through the design, then route to the right execution skill. The user said: **$ARGUMENTS** --- ## Step 1: Detect what they want to build Read the user's input and classify their intent: | Intent | Route | |--------|-------| | Recurring task on a timer | **Schedule loop** (automation or /loop) | | Run until a condition is met | **Goal loop** (/goal or goal-based prompt) | | React to an event (PR opened, Slack message, file changed) | **Hook or automation trigger** | | Reusable agent instructions | **Skill** | | Combination of the above | **Compound loop** (design first, then build pieces) | | Not sure / exploring | Start with the **onboarding mental model** below | If intent is clear, skip to Step 3. If vague, use Step 2. ## Step 2: The onboarding mental model Help the user think about loops by asking them to imagine onboarding an employee. Ask one question: > "Imagine you're giving this job to a new hire. What would their > standing instructions be? How often would they check in? How would > they know the job is done?" From their answer, extract: 1. **Trigger**: What starts the work (schedule, event, condition) 2. **Task**: What the agent actually does 3. **Success criteria**: How to know it worked 4. **Escalation**: What happens when the agent gets stuck These four things define any loop. ## Step 3: Choose the loop type Read [references/loop-types.md](references/loop-types.md) for the full breakdown. Here is the quick decision tree: 1. **Does it happen on a fixed schedule?** - Yes, at specific times (9am daily, Fridays) -> **Automation** (cron trigger) - Yes, at regular intervals (every 5m, every 30s) -> **/loop** (in-session) 2. **Does it run until a condition is true?** - Yes -> **Goal loop** (/goal or goal-based prompt in automation) 3. **Does it react to an external event?** - GitHub PR/push/CI -> **Automation** (git trigger) - Slack message/reaction -> **Automation** (Slack trigger) - File change, shell output -> **Hook** or **/loop** with watcher 4. **Is it reusable knowledge the agent needs every time?** - Yes -> **Skill** (SKILL.md) 5. **Does it need multiple agents working together?** - Yes -> Design with **subagents** (the maker/checker split) ## Step 4: Design the five pieces Every effective loop needs five things. Walk through each: 1. **Automation/trigger**: What kicks it off and how often 2. **Isolation**: Worktree or branch so parallel work doesn't collide 3. **Skills**: Project knowledge so the agent doesn't guess 4. **Connectors**: MCP servers and tools the agent needs (GitHub, Slack, Jira) 5. **Subagents**: Separate the maker from the checker Plus one memory layer: a markdown file, todo list, or external tracker that persists state between runs. The agent forgets between sessions. The repo doesn't. Read [references/design-patterns.md](references/design-patterns.md) for detailed patterns and examples of each piece. ## Step 5: Write the prompt Loop prompts need more precision than conversational prompts. The agent is unsupervised, so every gap in intent becomes a guess. **Good loop prompt structure:** ``` 1. Context: What you're working on and why 2. Task: Exactly what to do (verbs, not vibes) 3. Success criteria: How to validate the work is done 4. Escalation: What to do when blocked (alert, skip, stop) 5. Subagent instructions: When to spin off helpers and what goal to give them ``` **Example (good):** ``` Look at open PRs on [repo]. For any PR open more than 12 hours: - Check merge readiness (CI status, review approvals, conflicts) - If all checks pass, leave a comment noting it's ready to merge - If checks are failing, spin up a subagent to fix the failing checks - If blocked on review, send a Slack message to #team-channel listing the PR, author, and how long it's been waiting ``` **Example (bad):** ``` Check our PRs and make sure they're good. Fix anything that's broken. Let the team know. ``` The bad example has no success criteria, no escalation path, and "good" is undefined. The agent will burn tokens guessing what you mean. Read [references/warnings.md](references/warnings.md) for cost control, common pitfalls, and anti-patterns. ## Step 6: Route to execution Once the design is complete, hand off to the right skill: | What to build | Skill to invoke | |---------------|-----------------| | Cursor Automation (scheduled, event-triggered) | Read and follow `/automate` | | In-session recurring loop | Read and follow `/loop` | | Hook (lifecycle event, shell gate, file edit) | Read and follow `/create-hook` | | Reusable skill (SKILL.md) | Read and follow `/create-skill` | | Cursor rule (always-on context) | Read and follow `/create-rule` | **Do not try to build the artifact yourself.** Route to the execution skill and let it handle file creation, validation, and testing. Your job is the design. The execution skill's job is the build. If the user wants to review an existing skill or loop prompt, route to `/skill-review`. ## Step 7: Post-build validation After the execution skill finishes, check: 1. **Does the trigger match the design?** (schedule, event, or goal) 2. **Are success criteria measurable?** Can the agent actually validate them? 3. **Is there an escalation path?** What happens when it fails? 4. **Is the prompt precise enough for unsupervised execution?** 5. **Are the connectors available?** MCP servers connected and authenticated? If any check fails, flag it and suggest a fix before the user enables the loop. --- ## When someone asks "what kind of loop should I build?" Present the four types as choices: > **A.** Schedule loop: runs at fixed times (daily standup, weekly review) > **B.** Interval loop: runs every N minutes in-session (monitor deploy, watch CI) > **C.** Goal loop: runs until a condition is met (all tests pass, PR is clean) > **D.** Event loop: reacts to something happening (PR opened, Slack message, file changed) Then design from their choice. ## When someone asks "how do I make my agent prompt itself?" Explain in one paragraph: > A loop is just an automated prompt. Instead of you typing instructions, > you set up a system that does it: a schedule, an event trigger, or a > goal condition. The agent gets the same kind of prompt it would get from > you, but delivered by the system on a timer or in response to something > happening. You design the prompt once, and the system delivers it > repeatedly until the job is done or the schedule runs out. Then walk them through the design steps above. --- ## What NOT to do - Do not build the loop yourself. You are a designer and router. - Do not skip the design phase and jump straight to file creation. - Do not let vague prompts through. If success criteria are missing, ask for them before routing. - Do not design loops without considering cost. Every unsupervised cycle burns tokens. - Do not forget the memory layer. Loops without state tracking repeat work or lose progress between runs. - Do not combine maker and checker in the same agent. Split them.