.cursor/skills/continuous-agent-loop/SKILL.md
Use when building autonomous Claude Code loops for Salesforce Apex and LWC projects. Patterns from sequential pipelines to RFC-driven multi-agent DAG systems with quality gates. Do NOT use for single-shot Apex tasks.
npx skillsauth add jiten-singh-shahi/salesforce-claude-code continuous-agent-loopInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Patterns, architectures, and reference implementations for running Claude Code autonomously in loops on Salesforce projects. Covers sequential claude -p pipelines through RFC-driven multi-agent DAG orchestration with Apex test gates.
Start
|
+-- Need strict CI/PR control? -- yes --> continuous-pr
|
+-- Need RFC decomposition? -- yes --> rfc-dag
|
+-- Need exploratory parallel generation? -- yes --> infinite
|
+-- default --> sequential
| Pattern | Complexity | Best For | |---------|-----------|----------| | Sequential Pipeline | Low | Daily Apex dev steps, scripted SFDX workflows | | Infinite Agentic Loop | Medium | Parallel Apex/LWC generation from a spec | | Continuous Claude PR Loop | Medium | Multi-day Apex TDD iterations with CI gates | | De-Sloppify Pattern | Add-on | Quality cleanup after any Implementer step | | Ralphinho / RFC-Driven DAG | High | Large Salesforce features with parallel units and merge queue |
The simplest loop. Chain claude -p calls — each is a focused step with a clear prompt.
#!/bin/bash
set -e
# Step 1: Implement with TDD
claude -p "Read docs/order-service-spec.md. Implement OrderService.cls with TDD.
Target 85% coverage. No SOQL or DML inside for loops."
# Step 2: De-sloppify
claude -p "Review changes. Remove: unnecessary null checks, tests verifying platform
behavior, System.debug statements, commented-out code.
Run 'sf apex run test --class-names OrderServiceTest' after cleanup."
# Step 3: Verify
claude -p "Run 'sf project deploy start --dry-run --source-dir force-app/main/default/classes'.
Fix any failures. Do not add new features."
# Step 4: Commit
claude -p "Commit with message: feat: add order service with test coverage"
Variations: Use --model opus for architecture analysis, --model haiku for simple fixes. Use --allowedTools "Read,Grep,Glob" for read-only analysis passes.
Two-prompt system for parallel sub-agents. Useful for generating multiple Apex test class variants or LWC component iterations from a spec.
PROMPT 1 (Orchestrator) PROMPT 2 (Sub-Agents)
┌─────────────────────┐ ┌──────────────────────┐
│ Parse spec file │ │ Receive full context │
│ Scan output dir │ deploys │ Read assigned number │
│ Plan iteration │────────────│ Follow spec exactly │
│ Assign creative dirs │ N agents │ Generate unique output │
└─────────────────────┘ └──────────────────────┘
Don't rely on agents to self-differentiate. The orchestrator assigns each agent a specific test scenario and iteration number. Batching: 1-5 simultaneously, 6-20 in batches of 5, infinite in waves of 3-5.
Production-grade shell script that runs Claude Code in a continuous loop, creating PRs, waiting for CI (including Apex test runs), and merging automatically.
┌─────────────────────────────────────────────────────┐
│ 1. Create branch (continuous-claude/iteration-N) │
│ 2. Run claude -p with Apex TDD prompt │
│ 3. (Optional) Reviewer pass │
│ 4. Commit + Push + Create PR │
│ 5. Wait for CI (sf apex run test --code-coverage) │
│ 6. CI failure? → Auto-fix pass (claude -p) │
│ 7. Merge PR (squash) → Return to main → repeat │
│ Limit by: --max-runs N | --max-cost $X │
└─────────────────────────────────────────────────────┘
The critical innovation — a file that persists across iterations:
## Progress
- [x] OrderService.cls — 82% coverage (iteration 1)
- [ ] OrderController.cls — 45% coverage, needs work
## Next Steps
- Focus on OrderController.cls
- Named credential for external API is set up
Claude reads this at iteration start, updates at iteration end.
Add-on for any loop. When you ask an LLM to implement Apex with TDD, it over-tests:
Solution: Don't constrain the Implementer — let it be thorough. Then add a focused cleanup pass:
# Implement (thorough)
claude -p "Implement OrderService.cls with full TDD."
# De-sloppify (separate context)
claude -p "Review changes. Remove tests for platform behavior, redundant null checks,
System.debug statements, commented-out code. Run 'sf apex run test' after cleanup."
Two focused agents outperform one constrained agent.
Most sophisticated. RFC-driven pipeline that decomposes a Salesforce feature into a dependency DAG, runs each unit through quality stages, and lands via merge queue.
Salesforce RFC/PRD
│
DECOMPOSITION (sf-architect)
Break into: Apex → LWC → Integration → Metadata layers
│
┌──────────────────────────────────────────────────┐
│ For each DAG layer (sequential, by dependency): │
│ │
│ Quality Pipelines (parallel per unit): │
│ Research → Plan → Implement → Test → Review │
│ Apex: governor check + ≥75% coverage gate │
│ LWC: Jest tests + accessibility check │
│ │
│ Merge Queue: │
│ Rebase → sf deploy validate → Apex tests → │
│ Pass → Land | Fail → Evict + re-enter │
└──────────────────────────────────────────────────┘
| Tier | Pipeline Stages | |------|----------------| | trivial | implement → sf deploy validate | | small | implement → apex test → code-review | | medium | research → plan → implement → apex test → governor-check → review-fix | | large | + sf-architect final review |
| Signal | Ralphinho | SCC-Native | |--------|----------|------------| | 10+ interdependent work units | Yes | No | | Need worktree isolation | Yes | No | | Single feature with 3 layers | No | Yes | | Quick Apex + LWC iteration | No | Yes |
| Pattern | Loop Type | Stop Condition | |---------|-----------|---------------| | Governor Fix | sequential | No more governor violations | | Coverage Ramp | sequential | All classes at 75%+ (85% target) | | PB→Flow Migration | continuous-pr | All Process Builders converted | | Trigger Framework Migration | sequential | All triggers use handler pattern | | Deployment Monitor | infinite (30s) | Deploy succeeds/fails/cancelled |
── SF Checkpoint #N ────────────────────────
Apex Tests: 142/145 passing (+3)
Coverage: 78% → 82% (target: 85%)
Governor: 2 violations remaining (was 8)
Deploy: Validates against scratch org
Iteration: N/max
────────────────────────────────────────────
Is the task a single focused Salesforce change?
├─ Yes → Sequential Pipeline
└─ No → Is there a written RFC/spec?
├─ Yes → Need parallel layers?
│ ├─ Yes → RFC-Driven DAG
│ └─ No → Continuous Claude PR Loop
└─ No → Need many variants from a spec?
├─ Yes → Infinite Agentic Loop
└─ No → Sequential + De-Sloppify
--review-prompt with de-sloppify directive.sf-review-agent agent as a gate before commits.--model haiku for simple fixes, --model opus for architecture.SHARED_TASK_NOTES.md to bridge claude -p invocations.| Project | Author | SCC Context | |---------|--------|-------------| | Ralphinho | enitrat | Adapted for Salesforce layers | | Infinite Agentic Loop | disler | Useful for Apex test generation | | Continuous Claude | AnandChowdhary | Use with sf apex run test as CI gate |
loop-operator — For monitoring and managing autonomous agent loopsdevelopment
Update Salesforce platform reference docs with latest release features and deprecation announcements. Use when SessionStart hook warns docs are outdated or a new Salesforce release has shipped. Do NOT use for Apex or LWC development.
development
Use when syncing documentation after Salesforce Apex code changes. Update README, API docs, and deploy metadata references to match the current org codebase.
development
Use when managing context during long Salesforce Apex development sessions. Suggests manual compaction at logical intervals to preserve deploy and org context across phases.
tools
Visualforce development — pages, controllers, extensions, ViewState, JS Remoting, LWC migration. Use when maintaining VF pages, building PDFs, or planning VF-to-LWC migration. Do NOT use for LWC, Aura, or Flow.