# Move my recurring AI task to GitHub Actions

Help me make this project run on GitHub-hosted infrastructure when my computer is off. I am completely new to GitHub. Explain unfamiliar terms when they first appear, use short steps, and help me perform the setup rather than giving me a list of things to research.

My task: [What the project should do.]
My schedule and time zone: [For example, weekdays at 7:17 a.m., America/Denver.]
The information it needs: [Files, websites, or connected applications.]
Where I want the result: [A downloadable report is fine for my first version.]
My current project folder or repository: [Location, or use the project already open.]
My budget: [Monthly amount, or help me estimate before enabling paid calls.]

First inspect the project and its working instructions. Identify what already works and the smallest repeatable task we can move. Ask only for missing decisions that affect the implementation. Do useful preparation while I supply them.

Explain which computer will run the job. A cron job on my own laptop or a self-hosted runner on it does not meet my goal. Use GitHub-hosted runners for this setup. If this task requires an always-running service or access GitHub cannot provide, explain the specific mismatch before changing the approach.

Build the complete job, not just a schedule:

- Reuse existing code when possible. Use an AI model only where the task requires it. Choose a currently supported API or official agent integration and verify its documentation, authentication, and version before writing the workflow.
- List every dependency on local files, chat history, browser sessions, desktop plugins, or credentials. Move necessary instructions into project files and establish authorized cloud access to current inputs. Do not assume a desktop connection transfers to GitHub. Explain which inputs are snapshots and which refresh each run.
- Create a private repository if needed, a sensible ignore file, the task instructions, dependency files, the executable job, and the workflow in .github/workflows/. Avoid copying unrelated files or existing secrets.
- Make an initial manual test available with workflow_dispatch. Prepare the recurring cron schedule with an explicit IANA time zone, and show me its meaning in ordinary language. Check GitHub's current support rather than assuming schedules must be UTC. Put the completed workflow on the repository's actual default branch.
- Separate setup credentials from the limited access the recurring job needs. Use repository Actions secrets for required keys. Tell me the exact names and where to enter values privately. Never ask me to paste a key into this chat, put it in source code, or expose it in a screenshot or log. Check whether my chosen authentication uses API billing or a supported subscription token.
- Use minimum permissions and verified, pinned action versions. Avoid untrusted-event triggers in this first setup. Keep fetched content separate from trusted instructions and give the job only the tools its assignment requires.
- Add a sensible timeout, bounded requests or agent turns, failure reporting, and overlapping-run protection. Explain actual spending controls and estimates; do not call an alert or timeout a guaranteed dollar cap.
- Save a dated result outside the runner before it disappears. For a report, an Actions artifact is acceptable; set its retention and show me how to download it. If the job needs memory across runs, implement durable state. If it sends or changes anything, implement a durable duplicate-prevention key and recovery behavior; concurrency alone is not duplicate prevention.
- Begin with a draft or read-only result unless I have specified an automatic external action. Prepare the job and a clear cost estimate before enabling recurring paid work or external delivery.

Guide me through GitHub one screen at a time when I need to act. Give the exact page, tab, field, and button. If browser access is available, inspect the current screen and perform authorized steps. Use screenshots that omit secrets and private data. If you cannot see my screen, say so and use clearly attributed reference images or ask what I see. Never fabricate screenshots or successful runs.

Test the real job manually and inspect the saved output. Include checks for missing credentials, bad input, and repeat execution where applicable. Repair failures before calling the setup complete. After I enable the schedule, help me verify a scheduled result produced while my computer is off. Do not claim that test passed until we have its run record and output.

Leave me a short README with the task, schedule, result location, costs, failure notifications, and instructions to change or pause it. Explain how we detect a missed run if the delivery time matters. Show the repository link, workflow link, first verified result, and any remaining setup step. Distinguish prepared, manually tested, and verified on schedule.