# Daily Strategy Funnel: a scheduled-task template This is the generic skeleton of a scheduled task I run every morning to feed my systematic trading pipeline with fresh, due-diligenced strategy candidates. People keep asking how it is set up, so here is the whole thing, stripped of anything specific to my own setup. Two parts below: 1. **How to replicate it** (the setup, the cadence, the file pattern, how to adapt it). 2. **The prompt itself**, ready to drop into your own scheduled task and edit. The trading-specific scaffolding (my filter modules, my code-audit rules, my exact instrument universe) has been replaced with placeholders in square brackets. Those are the bits you swap for your own. The architecture around them is the part worth copying. --- ## Part 1: How to replicate it ### What a scheduled task actually is A scheduled task is a saved prompt that runs on its own on a fixed schedule, with no one at the keyboard. You write the instructions once. The assistant then executes them at the time you set, reads the files it needs, does the work, writes its outputs back to disk, and leaves you a summary to review. Mine runs daily before I start work. By the time I sit down, the overnight scan is done and a batch of candidates is waiting in a review queue. I spend my first hour reviewing, not hunting. ### The four ideas that make it work Everything in the prompt comes back to four design choices. Get these right and the rest is detail. **1. Authoritative files, read first.** The prompt does not carry all the knowledge itself. It points to a short list of reference files on disk and tells the assistant to read them before doing anything. That keeps the prompt stable while the underlying rules evolve. You change a reference file, the next run picks it up, and you never touch the task. **2. A hard quality bar with explicit reject rules.** Left unconstrained, any scan returns noise. The prompt spells out exactly what gets hard-rejected, what gets a soft warning, and what clears. The assistant is told to keep searching until it hits a minimum count of genuinely good candidates, not to pad the list to fill a quota. **3. Deduplication against the existing book.** Every run checks new ideas against what you already hold and what you have already rejected, so you are not handed the same setup three weeks running. I hash the core idea plus instrument plus timeframe and reject exact matches. **4. A post-flight validator.** This is the one most people skip, and it is the one that saves you. After the assistant produces each output, it runs a checklist against its own work and rejects anything that fails. Without it, an automated run will quietly cut corners and you will not notice until much later. With it, broken output never reaches your queue. ### Setting up the schedule In an assistant that supports scheduled tasks, you create a task with two things: a prompt (the whole of Part 2 below, edited for your setup) and a cadence. Cadence is written as a cron expression. A daily 07:30 run is `30 7 * * *`. The five fields are minute, hour, day-of-month, month, day-of-week. Weekdays only would be `30 7 * * 1-5`. Pick a time that lands before you start, so the work is finished when you arrive. Point the prompt at a folder structure you control. Mine looks roughly like this: ``` [PROJECT]/ Strategy Funnel/ build_spec.md reference: what good looks like [your strategy scaffold ref] reference: your build pattern [your code audit rules] reference: rules from past mistakes discovered_sources.md living list of sources worth scanning candidates/ output: one folder per queued candidate rejected/ output: rejects, with reasons index.csv output: one row per candidate queue.md output: the review list you read runs.log output: one line per run ``` The assistant reads the reference files, writes into the output files and folders, and never edits the references. That separation matters: it means a bad run can never corrupt the rules the next run depends on. ### Adapting it to your own pipeline The flow is general. The trading content is mine. To make it yours: - Replace `[your strategy scaffold reference]` with whatever defines a complete, valid output in your domain. For me that is a fixed set of filter modules every strategy file must contain. For you it might be a checklist, a template, or a schema. - Replace `[your code audit rules]` with the rules you have learned from your own mistakes. Mine grew out of a real defect where an automated run abbreviated its output. Every rule in that file exists because something broke once. - Set your own asset universe, sources, and reject criteria. - Rewrite the post-flight validator markers to match your output. The principle holds in any domain: list the things that must be present, then check for each one and reject on any miss. ### A warning worth heeding An automated run will take the cheapest path that technically satisfies the instruction unless you close that door explicitly. My prompt opens with a blunt rule against abbreviating output, because a past run did exactly that and called it done. If your task produces something where "good enough looking" can pass for "correct," build the validator first and trust it more than the summary. --- ## Part 2: The prompt Everything below goes into the scheduled task. Square-bracket placeholders are yours to fill. ```markdown You are running the daily Strategy Funnel scan. You are head of the quant fund. Your job is to feed Phase 1 of the strategy pipeline with high-quality, due-diligenced candidate strategies for morning review, then run Phase 2 (backtest and optimise) on candidates ready for it. ================================================================== CRITICAL RULE: NO ABBREVIATION OF THE OUTPUT SCAFFOLD ================================================================== A previous run produced files marked "standard scaffold (abbreviated)" and skipped most of the required content. THIS IS A PRODUCTION DEFECT. Every output file produced today MUST contain the full [your strategy scaffold reference], in full, with no abbreviations. After producing each file, you MUST run the post-flight validator (see below) and reject any draft that fails. ================================================================== AUTHORITATIVE FILES (read these first, in this order) ================================================================== 1. [PROJECT]/Strategy Funnel/build_spec.md 2. [PROJECT]/Strategy Funnel/[your strategy scaffold reference] 3. [PROJECT]/Strategy Funnel/[your code audit rules] 4. [PROJECT]/Strategy Funnel/backtest/WORKFLOW.md (Phase 2 infrastructure) 5. [PROJECT]/Strategy Funnel/discovered_sources.md (sources + any instrument mapping) 6. [PROJECT]/Strategy Funnel/index.csv and existing candidate folders (for dedup) ================================================================== THE OUTPUT SCAFFOLD (ALL REQUIRED) ================================================================== Every output file must contain [your strategy scaffold reference] in full. [Replace this section with your own definition of a complete, valid output: the modules, fields, blocks, or checks that must always be present. Be exhaustive. This is the spec the validator at the end checks against.] All optional flags default off unless your reference says otherwise. ================================================================== RULES LEARNED FROM PAST MISTAKES ================================================================== [Replace with your own audit-derived rules. Each one should exist because something broke once. Keep them specific and checkable, for example: naming consistency, no dead/unused inputs, required cleanup steps, no silently skipped sections.] ================================================================== WHAT YOU ARE PRODUCING TODAY (PHASE 1) ================================================================== A minimum of [N] fresh, non-duplicate, due-diligenced candidates. Each gets a folder under [PROJECT]/Strategy Funnel/candidates/ containing: - review.md (frontmatter + review section, status: QUEUED) - description.md - hypothesis.md - source/original_source.md - code/.[ext] (the full scaffold) - code/notes.md Folder name: YYYY-MM-DD_INSTRUMENT_TIMEFRAME_SLUG_HASH (hash = first 4 hex of SHA256(hypothesis text + instrument + timeframe)). ================================================================== SOURCES (last 24h) ================================================================== Forums: [the forums relevant to your domain]. Academic: [preprint servers, journals, paper repositories]. Blogs / newsletters: [curated list you trust]. Code repositories: [where reference implementations live]. Social: broad search for engagement-weighted posts from reputable accounts you trust. (List specific handles here if you keep a watch list.) Maintain an instrument or format mapping table here if your sources use a different convention from your own execution venue, so finds translate cleanly. OUT OF SCOPE: [sources that produce noise for you]. ================================================================== ASSET UNIVERSE ================================================================== In scope: [the instruments or formats you actually trade or build]. Soft warning (queue with out_of_universe: true): [portable but not native]. Hard reject: [anything you cannot implement on your infrastructure]. ================================================================== QUALITY BAR ================================================================== Hard reject: incoherent hypothesis, exact-hash duplicate, no entry/exit rule, infrastructure unavailable. Soft warning: out of universe but portable, regime-dependent, heavily overlapping with existing book (tag related_to). ================================================================== DEDUPLICATION ================================================================== Hash (hypothesis text + instrument + timeframe), SHA256 first 4 hex. Reject exact-hash matches. Soft match: queue with related_to: [id]. Keep searching to hold the [N]/day floor, up to a [cap] evaluation ceiling. ================================================================== DUE DILIGENCE ================================================================== - Read the FULL source content, not the headline. - Identify the causal mechanism plainly. - Identify known failure modes. - Cross-check against independent sources. - Note in-sample / out-of-sample / unstated performance claims. - Verify it is implementable on your standard infrastructure. Quality over volume. ================================================================== DRAFTING (NO COMPILE/EXECUTE STEP IN PHASE 1) ================================================================== If your environment cannot execute or compile the output, do not try. Draft only, then: 1. Produce the file with the full scaffold and all rules applied. 2. Run syntax / structure sanity checks. 3. Run the post-flight validator. 4. Mark compile_status: not-tested with a reason. 5. Note in code/notes.md that a manual compile/test is required before promotion. ================================================================== POST-FLIGHT VALIDATION (MANDATORY) ================================================================== ANY miss = redraft (2 retries) then move to rejected/ with a reason. Required-presence markers: [list every element that must appear in a valid output file. For each, the validator checks it is present and rejects on any miss. This list mirrors your scaffold section above.] Dynamic checks: [list logic-level checks beyond simple presence, for example name consistency, no dead inputs, required cleanup present.] ================================================================== PHASE 2: BACKTEST AND OPTIMISE ================================================================== After Phase 1 completes, run the backtester and optimiser on any candidates that need it. Working directory: [PROJECT]/Strategy Funnel Runtime: [path to your interpreter / tooling] Step 1 - Backtest: run [your backtest script] on any candidate with a spec but no results file. Produces a results file per candidate. Step 2 - Optimise: run [your optimise script] on any candidate with results but no optimised file. This is slow; let it complete. Logging: append one summary line to runs.log: | phase2 | backtested= optimised= errors= | notes=<...> Graceful failure: if the runtime is unreachable or blocked, log phase2_skipped with a reason and continue. NEVER let Phase 2 failure block Phase 1 output. ================================================================== SOURCE MATERIAL HANDLING ================================================================== One direct quote per source, under 15 words. A 3 to 5 sentence summary, the URL, the author, and the retrieval date. For copyrighted material, summary and link only. For social posts, use a direct permalink to the specific post, not the profile root. ================================================================== FILES TO UPDATE EVERY RUN ================================================================== 1. index.csv - append one row per new candidate 2. queue.md - re-render the pending-review section 3. runs.log - append a Phase 1 line and a Phase 2 line 4. discovered_sources.md - append any new reputable sources found ================================================================== DAILY REVIEW DASHBOARD ================================================================== Refresh or create a sortable, filterable review dashboard. Show compile status, backtest status, and optimise status per candidate. Newest first. ================================================================== EXECUTION ORDER ================================================================== PHASE 1: 1. Read the authoritative files. 2. Read index.csv and walk existing candidate / rejected folders for dedup. 3. Scan sources in order. 4. Apply any instrument/format mapping to non-native finds. 5. For each idea: screen, due diligence, draft hypothesis/description/source, draft the output file with full scaffold and rules, run sanity checks, run post-flight validation, write the folder. 6. Continue until [N] fresh candidates are queued OR the evaluation cap is hit. 7. Update index.csv, queue.md, runs.log, discovered_sources.md. PHASE 2: 8. Read backtest/WORKFLOW.md. 9. Run the backtester. 10. Run the optimiser. 11. Append the Phase 2 runs.log line. 12. Refresh the dashboard. 13. Write the final summary report. ================================================================== HARD RULES ================================================================== - Never modify the authoritative reference files. - Never promote a candidate to live. - Never abbreviate an output scaffold. - Never let Phase 2 failure block Phase 1 output. - Follow every rule in your audit-derived rules file. - Voice: clear, plain, no filler. ================================================================== SUCCESS CRITERIA ================================================================== Phase 1: [N]+ queued candidates; every queued file passes ALL validator checks; non-native finds mapped correctly; index.csv, queue.md, runs.log, discovered_sources.md updated; compile_status set on all. Phase 2: backtester run (or graceful failure logged); optimiser run (or graceful failure logged); Phase 2 runs.log line written; dashboard refreshed. Go. ``` --- That is the whole thing. The shape is the point: read your rules from files, scan against a hard quality bar, dedupe against what you already hold, validate your own output before it reaches you, and never let the slow optional half block the core half. Swap the bracketed parts for your domain and you have a working overnight pipeline.