> For the complete documentation index, see [llms.txt](https://vigil-1.gitbook.io/vigil-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vigil-1.gitbook.io/vigil-docs/closed-beta-guide/plan-examples.md). # Plan Examples Ready-to-paste plans. Change the numbers to fit your own view. {% hint style="success" %} **Tip:** Every example below can be pasted straight into Vigil. Change the tokens, sizes and levels to match your own plan. {% endhint %} {% hint style="warning" %} **Beta limits:** watches check on a schedule or on an event, not tick by tick. A quick wick through your level can be missed between checks. {% endhint %} ## Sunrise plans — for the setups you'd see if you were awake ### Buy the dip, with a plan out > "Buy $200 of SOL if it drops below 140. Sell half at 165, the rest at 180. Stop at 132." One sentence covers the entry, two exits and the stop. No alarm needed. ### Breakout with confirmation > "If BTC breaks up through 72k on above-average volume, open a $300 long at 2x. Stop at 70.5k. Max 2 trades today." The condition is the **crossing**, not just being above the line. If BTC is already above 72k, nothing fires. ### Patient DCA with a smart exit > "Buy $50 of ETH every day for 30 days. If ETH rises more than 20% during that time, stop buying and set an 8% trailing stop." A month-long plan with a condition built in, running without you. ## Midnight plans — for the moments you'd miss ### New listing filter > "Watch new tokens with over $250k liquidity and more than 1,200 holders. Run a token check first. If it passes, ask me before buying $50." Vigil does the homework; you make the final call. ### Wallet follow, with rules > "Track this wallet: 0x1a2b…3c4d. When it buys a token with market cap above $100M, follow with $100 — never more than $300 per day." Not blind copying. You set the filter and the limits; Vigil enforces them. ### First mover wins > "Watch SOL, AVAX and SUI. Whichever breaks its 24h high first, buy $200 of it with a 4% stop. Only trade the first one." Three charts watched at once, which you can't do by hand. ## Discipline plans — for protecting you from you ### Tilt guard > "If I lose two trades in a row, pause all trading for 4 hours and tell me why." ### Quiet alerts > "Check ETH every 10 minutes. Alert me only if it's below 1,900 three checks in a row. After alerting, stay quiet for 2 hours." One wick won't wake you up ten times. ### Morning brief > "Every day at 8 AM, send me BTC and ETH overnight moves, my open positions, and anything my watches did overnight." You wake up, open your phone, and the night is already summarized. ## Go further Each example uses a different building block: levels, crossings, schedules, filters, wallets, parallel watches and guardrails. Most real plans combine several. Try one that mixes half of them. Tell us what broke. That's how the next version of Vigil gets built. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://vigil-1.gitbook.io/vigil-docs/closed-beta-guide/plan-examples.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.