Auto-continue through todos with idle detection and safety gates. Use for multi-step orchestration.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add ils15/pantheon-legacy --skill auto-continue --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Auto Continue?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/ils15-auto-continue)More formats (shields.io, HTML) on the badges page.
---
name: auto-continue
description: "Auto-continue through todos with idle detection and safety gates. Use for multi-step orchestration."
context: fork
globs: []
alwaysApply: false
---
# Auto-Continue Mode
Disciplined automatic continuation through multi-step tasks. Eliminates unnecessary pauses while preserving mandatory safety gates.
---
## Core Principle
> **Auto-continue through unambiguous work. Stop only at real decision points.**
---
## Mandatory Gates (ALWAYS STOP)
| Gate | Trigger | What happens |
|---|---|---|
| **GATE 0 — Agora Gate** | Agora outputs `AWAITING_APPROVAL` OR `## 🏛️ Agora Council` synthesis block appears | **HARD STOP.** Do not call any tool, do not continue any todo, do not suggest next steps. Wait for user to type: APPROVE / REQUEST CHANGES / DISCARD. "ok", "yes", "sure", "continue" are NOT valid. |
| **GATE 1 — Plan Approval** | Athena generates a plan | User confirms scope before code is written |
| **GATE 2 — Phase Review** | Themis reviews implementation | User sees changes before next phase |
| **GATE 3 — Git Commit** | After each phase is approved | User controls git history; no auto-commit |
> **Agora is always GATE 0**: any response containing `AWAITING_APPROVAL` or a `## 🏛️ Agora Council` block overrides all auto-continue rules.
---
## Auto-Continue Rules
**Continue automatically when:**
- Next todo is a direct consequence of the current one
- Action is reversible (file edits, tests, linting)
- Scope is within the approved plan
- No new ambiguity has emerged
**Stop and ask when:**
- A todo requires a decision not covered by the plan
- An unexpected error changes the approach
- A dependency is missing or broken
- A task would exceed remaining `steps` budget
---
---
## Implementation Pattern
```
1. Create todos for all steps at start
2. Mark first todo in_progress
3. Complete work → mark completed immediately
4. Mark next todo in_progress → repeat
5. Do NOT ask "should I continue?" between clear steps
6. Stop at Gate 1, 2, or 3
7. After gate approval, resume with next todo
```
**Never batch-complete todos.** Mark each completed as soon as done.
---
## Safety Checks Before Continuing
- [ ] Previous step completed successfully (tests pass, no errors)
- [ ] Next step is within approved plan scope
- [ ] No new blocking issues emerged
- [ ] `steps` counter has sufficient budget remaining
---
## Cooldown Pattern
Between phases, execute a brief synthesis handoff to prevent context drift and prepare the next phase:
### Phase Summary Template
```
Phase N complete. Summary:
- What was done: <2 bullet points>
- What changed: <files modified>
- What's next: <Gate 2 review OR next phase>
- Will continue: <YES / after gate approval>
```
### Cooldown Rules
1. **Between parallel waves (no dependency):** No cooldown needed — wave results are independent
2. **Between sequential waves (with dependency):** Always run cooldown — dependencies may have changed context
3. **After Themis review (GATE 2):** Cooldown is mandatory — review findings may change the plan
4. **Session reuse check:** Before starting next phase, check if a specialist session from a previous phase can be reused (see session-goal skill)
### Abbreviated Cooldown
When auto-continuing between sequential non-gated phases, the cooldown is abbreviated to one line:
```
→ Phase N done. Next: Phase N+1. [auto-continuing]
```
Only expand to full cooldown when hitting a mandatory gate.
---
## Timeout & Retry Enforcement
When a delegated agent does not respond in time, enforce the timeout policy from routing.yml.
### Behavior by Agent Role
| Agent Role | Timeout | Retry Policy | Fallback | Timeout Parcial? |
|------------|---------|-------------|----------|------------------|
| Explorer (apollo) | 60s | 2 retries, exponential backoff | athena | ✅ Yes — partial results OK |
| Implementer (hermes, aphrodite) | 180s | 3 retries, exponential backoff | talos | ❌ No — must produce artifact |
| Reviewer (themis) | 120s | 2 retries, exponential backoff | zeus | ❌ No — must produce verdict |
| Infrastructure (prometheus) | 300s | 2 retries, exponential backoff | hermes | ❌ No |
| Hotfix (talos) | 30s | 1 retry, no backoff | hermes | ✅ Yes — one-liner fix OK |
### Timeout Parcial (Partial Results)
Timeout parcial is **only** allowed for read-only, independent agents:
- ✅ @apollo (codebase search) — can return partial file list
- ✅ @gaia (literature review) — can return partial findings
- ✅ @talos (hotfix confirmation) — can return without fix if timeout
- ❌ Never for implementers (@hermes, @aphrodite, @demeter) — must complete or fail
- ❌ Never for reviewers (@themis) — must produce a verdict
**How to signal timeout parcial:**
When dispatching, set the expectation explicitly:
```
@apollo Search for all auth-related files. If you hit timeout, return whatever you have found so far — partial results are acceptable.
```
### Timeout Tracking Table
Maintain a mental table of in-flight delegations:
| Agent | Started | Timeout | Status | Partial OK? |
|-------|---------|---------|--------|-------------|
| apollo | T+0s | T+60s | ✅ complete | ✅ |
| hermes | T+0s | T+180s | ⏳ in progress | ❌ |
---
## Examples
**Good (auto-continues):**
```
✅ Wrote migration file.
→ Running migration tests...
✅ Tests pass (3/3).
→ Next: write UserRepository query methods.
```
**Good (stops at Gate 2):**
```
✅ Phase 1 complete: migration + repository layer.
⏸️ GATE 2 — Themis review summary:
- Coverage: 87% ✅ | No OWASP issues ✅
Ready for Phase 2? Waiting for go-ahead.
```
**Bad (stops unnecessarily):**
```
✅ Wrote the migration file.
Should I now run the migration tests? [waiting]
```
## Session Heartbeat
Auto-save checkpoint every N turns (configurable, default 5).
### Heartbeat File
`.pantheon/deepwork/<slug>/heartbeat.json`
### Heartbeat JSON Format
```json
{
"slug": "task-identifier",
"last_action": "2026-07-16T20:00:00Z",
"turn_count": 10,
"current_phase": 2,
"status": "alive | warning | stalled | paused | completed",
"next_action": "brief description of next planned action"
}
```
### Heartbeat Rules
1. Update every 5 turns minimum (by default)
2. Contains NO context — only timestamps and counters
3. Single file, always overwritten (not versioned)
4. Used for quick "is this session alive?" checks
---
## Checkpoint Persistence
### Checkpoint File Structure
Each deepwork task maintains:
```
.pantheon/deepwork/<slug>/
├── PLAN.md # Immutable plan (created at start)
├── STATUS.md # Human-readable current state (updated every phase)
├── heartbeat.json # Lightweight ping (updated every N turns)
├── checkpoint-<N>.json # Full state snapshot (created at phase boundaries)
├── session.json # Session metadata (created at start, updated on stop)
└── REVIEW.md # Final Themis review (created at end)
```
### Checkpoint JSON Schema
```json
{
"slug": "string — unique task identifier",
"phase": "integer — current phase number",
"turn_count": "integer — total turns elapsed",
"timestamp": "string — ISO 8601 timestamp",
"context_hash": "string — first 8 hex chars of SHA-256 of STATUS.md",
"version": "integer — schema version (current: 2)"
}
```
### Checkpoint Rules
1. Save at every phase boundary AND before any delegate dispatch
2. Numbered sequentially (`checkpoint-1.json`, `checkpoint-2.json`, …)
3. Keep last 10 checkpoints; archive older ones
4. On resume: read the highest-numbered checkpoint for full state
---
## Safety Policy Configuration
Configurable gates for different platforms and risk levels:
| Gate | Default | Auto-Approval Condition |
|------|---------|------------------------|
| GATE 0 — Council/Plan | Always Ask | N/A — always requires human |
| GATE 1 — Plan Approval | Always Ask | Plan matches acceptance criteria + no risks flagged |
| GATE 2 — Themis Review | Ask by Default | Auto-approve if: Themis APPROVED + no CRITICAL/HIGH issues + coverage ≥80% |
| GATE 3 — Git Commit | Never Auto | N/A — always manual |
| Deploy | Always Ask | N/A — always requires human |
| Destructive DB Ops | Always Ask | N/A — always requires human |
### Configuration Format (for agents/PLAN.md)
```yaml
auto-continue:
checkpoint_interval: 5 # turns between checkpoints
idle_warning: 60 # seconds before warning
idle_stall: 120 # seconds before stall detection
idle_pause: 300 # seconds before auto-pause
gates:
plan_approval: always_ask
themis_review: auto_approve_if_clean
git_commit: never_auto
deploy: always_ask
destructive_ops: always_ask
```
### Idle Detection
| Condition | Action |
|-----------|--------|
| No tool call for 60s | Log warning heartbeat (status: warning) |
| No tool call for 120s | Trigger anti-stall protocol |
| No tool call for 300s | Auto-save checkpoint and pause session |
| Resume | User must acknowledge and restart |
---
## Scope
**Applies to:** Zeus (multi-phase), Hermes/Aphrodite/Demeter (TDD cycles), Apollo (parallel searches), Talos (bug fixes).
**Does NOT apply to:** Athena planning (always presents plan = Gate 1), Iris (confirms before push), destructive operations (always ask).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!