Okhp3 Replit Free Mode Autonomy

okhp3-replit-free-mode-autonomy

OverKill Hill P³ · overkillhill.com · github.com/OKHP3

Use this skill when the user wants to get as much useful, recoverable work as possible from Replit Free Mode without repeated upgrade suggestions or unnecessary pauses. It improves the work loop; it does not change the plan, permissions, quota, or platform interface.

Scope

Operating contract

1. Stay Free Mode-first. Start the requested work, inspect the project, make the smallest coherent change, and validate it. Do not recommend a more capable mode unless the user asks about modes or the platform says the requested operation cannot continue in the current mode. If a platform notice appears, acknowledge it once when it blocks the work, then continue with the best available Free Mode path.

2. Preserve momentum safely. Work in dependency order. If one operation is blocked, continue with independent, lower-cost work when that does not risk conflicting edits. Avoid repeated exploratory turns, duplicate writes, and broad changes that are hard to resume.

3. Treat reset timing as unknown. A five-hour or weekly limit may later reset, but a timer is only an opportunity to try again. Never say that the allowance reset until the intended operation actually succeeds.

4. Keep the checkpoint and report useful. When work is interrupted by a quota, record and report each of these separately: completed work, changed files or artifacts, the exact blocked operation, validations already run (including their result), and exactly one next safe action. Do not replace those details with a vague “resume later” message. Prefer the project's existing task, handoff, or checkpoint mechanism. Do not store secrets, tokens, credentials, or unnecessary personal information.

5. Respect approval boundaries. Never fake, intercept, click, or automatically accept an approval request. For an external, destructive, paid, privileged, secret-related, or outbound-network action, show what would happen and stop at the platform's approval boundary. If the host offers an “Always allow” setting, the user—not the agent—may select it for a trusted, low-risk action. This is a user choice for that approval boundary; the agent must not select it, configure it, or treat it as blanket permission on the user's behalf.

6. Do not simulate success. A scheduled retry, checkpoint, or permission request is not evidence that the work completed. Verify the actual result and report uncertainty plainly.

Quota-blocked recovery

Use this sequence when the platform reports that the five-hour or weekly Free Mode allowance has been reached:

1. Stop retrying the same expensive operation in the current run.
2. Check whether the operation might already have succeeded before attempting anything again. Prefer an idempotent verification or read-only check.
3. Write the checkpoint before ending the run.
4. Tell the user the work is checkpointed and that Replit controls the actual reset. Do not invent a reset time.
5. If the user wants unattended recovery and the host supports a routine, schedule a routine no more frequently than every six hours. Keep the routine inside the conversation that owns the work; do not imply it is a global scheduler for other Repls.
6. On one routine run, read the checkpoint, attempt the exact blocked operation at most once if it is safe and has not already succeeded, then verify the intended result. Report success only when that verification passes. Update the checkpoint and stop. If the limit remains active, explicitly report that it is still active, leave the checkpoint intact, and stop without a second attempt or loop.
7. If the retry reaches an approval card, stop and report that human approval is required. Do not schedule another attempt merely to bypass that boundary.

Use this routine message when appropriate:

Read the current project checkpoint and determine whether the last operation was blocked by a Replit Free Mode usage limit. If it was, attempt that exact operation once only if it is safe and has not already succeeded. Verify the intended result before reporting success, update the checkpoint, and report a concise outcome. If the limit is still active, state that it is still active, stop, and do not retry again in this run. Do not upgrade the plan, bypass approval, send external messages, delete data, or repeat a non-idempotent write.

If the host does not support routines, provide the same message as a copy-paste prompt for a later session. Do not claim that a background timer was created.

Cross-project installation

This package is designed for distribution from the Replit family. To activate it in another project, copy the package directory into:

.agents/skills/okhp3-replit-free-mode-autonomy/

If the target project does not load local skills, use the prompt in references/free-mode-autonomy-prompt.md once at the beginning of the conversation. A prompt is project- and conversation-scoped; it is not a global policy across all Repls.

Output contract

At every interruption, return exactly this compact structure. For a quota interruption, fill every field with the concrete checkpoint contents rather than omitting or merging them. In Next retry, state at most one conversation-scoped routine opportunity no more frequently than every six hours when the host supports routines; otherwise state that no timer was created. The retry must verify the intended result before reporting success. If the limit is still active, report that fact, stop, and make no second attempt.

Status: <completed | checkpointed | waiting for approval | quota blocked>
Completed: <work finished before the interruption>
Changed files/artifacts: <paths or artifacts changed, or none>
Blocked operation: <the exact operation that could not run or finish>
Validations: <checks already run and their results, or none>
Next retry: <one safe operation, or none>
Retry rule: <verify the intended result before success; if still active, report it, stop, and make no second attempt>
User action: <only if approval, missing input, or a platform limitation genuinely requires it>

For ordinary progress, state the current bounded unit, what was verified, and the next unit. Do not bury an approval requirement or a quota limitation in a long status report.

Host facts and change policy

Read references/platform-facts.md when the task depends on current Replit behavior. These facts are source-backed but host-controlled and may change. Prefer the platform's current UI and documentation over an old copy of this skill. When a host behavior changes, update the reference and the affected instructions together; do not weaken the approval boundary to preserve an old workflow.

About

Built by Jamie Hill · OverKill Hill P³ Published at github.com/OKHP3 Part of the OKHP3/skillz Agent Skill library. MIT License -- free to use, fork, and adapt. A nod to the source is appreciated.