# Scheduled Tasks

> Guidelines for writing reliable scheduled task prompts via the Claude scheduled-tasks MCP.

- Skill: `cleanexpo/scheduled-tasks` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cleanexpo/scheduled-tasks`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cleanexpo/scheduled-tasks/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: cleanexpo (https://skillmd.com/u/cleanexpo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/cleanexpo/scheduled-tasks

---


# Scheduled Tasks

## When to apply

Apply these rules whenever writing or editing a scheduled task prompt that runs via the Claude scheduled-tasks MCP (desktop Claude session).

## Rules

- **Minimise tool-approval surface.** Scheduled tasks run inside the desktop Claude session and do NOT inherit the repo `.claude/settings.json` allowlist. Shrink every scheduled task prompt to a single shell command that calls a standalone Python helper script. This reduces the required tool approvals to Bash alone, which is approvable with one "Run now" click.

- **Never hardcode local Mac paths.** Scheduled tasks execute inside a fresh sandbox with a new session ID on every run. Hardcoded paths (e.g. `~/...`) will fail. Always discover the repo dynamically at the top of the task prompt:
  ```
  REPO=$(find /sessions -type d -name <repo-name> | head -1) && cd "$REPO"
  ```

- **No pytest or complex multi-tool operations in sandbox.** Sandbox environments lack installed packages. Never escalate CRITICAL based on test failures inside a scheduled task. Use `--collect-only` for import-level checks only — never run full test suites from a scheduled task.

- **Standalone helper scripts must use absolute dynamic path discovery.** Any Python script called by a scheduled task must discover its own repo root at runtime (e.g. via `pathlib.Path(__file__).resolve().parents[N]`). Never hardcode paths inside helper scripts either.

## Founder-output contract — mandatory

Scheduled tasks are workers, not narrators. Their job is to finish work and record evidence internally. They MUST NOT push ordinary engineering progress into Telegram/Margot.

Allowed founder-facing outputs are ONLY:

1. **VERIFIED COMPLETE** — the requested objective is finished and verification evidence exists.
2. **PROTECTED DECISION REQUIRED** — all safe work has already continued and one specific protected action genuinely needs Phill's approval. Include one recommended answer and the minimum evidence needed to decide.
3. **RECOVERY FAILED** — a real system failure remains after the task has already attempted safe diagnosis and remediation. State the single unresolved failure, recovery attempts, and exact next machine action. Do not send a generic blocker list.

Everything else stays internal.

### Explicitly forbidden founder-facing output

Do not send any of the following to Telegram/Margot as a scheduled-task result:

- `Status: YELLOW`, `Status: RED`, or traffic-light progress reports.
- `What changed`, `Evidence`, `Blockers`, `Next action`, `Lessons`, `Lesson learned`, or similar status-report templates for unfinished work.
- Partial diffs, compile checks, lint checks, or "X is wired but Y is still missing" reports when the worker can continue safely.
- A diagnosis followed by a future action the same task could execute now.
- Repeated explanations of an issue Phill has already reported.
- "Please file manually", "please run", or "please continue" when the system has a safe write/repair path available.

### Testing Brain rule

Unfinished findings, suspected defects, ambiguous evidence, regressions, and candidate fixes go to the internal **Testing Brain** lane, not to Phill.

Testing Brain must:

1. reproduce or prove the finding;
2. challenge the diagnosis with an independent check;
3. apply the safest repair available;
4. run the relevant verification again;
5. only promote the result when it is verified complete or genuinely requires protected human authority.

Use a triple-standard evidence bar for promoted findings: **reproduce + independent challenge + post-fix verification**. One passing compile/lint command is not completion evidence for an end-to-end feature.

### Continuation rule

A scheduled task must maintain the current Mission Control objective and look ahead beyond its immediate edit. Finishing one sub-step is not a reason to return control to the founder. Continue dependency-safe work until the objective is verified complete, all remaining useful work is protected, or the kill switch is active.

If a task discovers its own prompt is stale or conflicts with a newer Mission Control/Telegram objective, the newer canonical objective wins and the stale task must retire quietly rather than emitting another progress report.