I want an agent that can calculate the minimum calories burned by basal metabolism based on the amount of muscle mass (in kilograms), then distribute those calories into a ratio of 50% carbohydrates, 20% healthy fats, and 30% protein, and finally create a one-week meal plan (breakfast, lunch, dinner, plus three small snacks) based on a shopping list that I compile and provide to the agent myself. I’m somewhat familiar with Claude, though I still need to get used to Cursor.

So i just completed day 5 and took the 16 personalities test, and wow, you wouldn't think from the questions answered that it would be able to give such a detailed description of my personality, but i am blown away by how correct the test has described me. That being said when i came to question 2 on the claude prompt i was having a hard time just picking a few characteristics. so i worked out a prompt and thought process that i think would help others on here. Basically i just took screen shots of the results and gave them to claude to read completely, and then for the remaining questions i didn't even have to really think of answers because the answer was already written, i just had to retype. Another thing that i think could help others is that a few days ago, i prompted claude to create an organization system within the "zero one systems" folder and a .md document for how claude should organize any future documents ill post some pictures of my chat for other to look at. Hopefully this will help others accomplish the lessons! P.s. adding the screenshots and rereading one of the first paragraphs seems to support and confirm what i am saying in this post 😂 starting to get the hang of when Lewis said "just trying things and promting claude" in a previous lesson 👊

My First Agent: Daily Action Coach (getting started on things) because I tend to get distracted, go down rabbit holes and fall into analysis paralysis.

For my first agent, I’m designing a trading assistant for forex and, eventually, stocks. I’ve mapped the initial file ecosystem in Miro before writing the individual files. The entry point is Agent.md, which defines the agent’s purpose and workflow. It links to Soul.md, which describes my preferences and decision-making style and serves as the central directory for: - Goals: objectives and measures of success. - Rules: shared risk limits and market-specific rules. - Configuration: enabled strategies, instruments and trading periods. - Knowledge: market analysis, strategies, economic news and reference material. - Skills: tasks such as analysing markets, running backtests and evaluating risk. - Tools: connections to trading platforms and data sources. - Memory: observations, trading results and lessons learned. I’m taking an ITIL-inspired approach: clear responsibilities, controlled changes, traceable decisions and continual improvement. The intention is for the agent to propose and test improvements before applying them, while keeping risk limits separate from its learning process. This is an architecture sketch, not a working or proven trading system. I’ll start with historical testing and a demo account, building one part at a time. My biggest takeaway so far: a useful file ecosystem is about giving each piece of information a clear home—not creating as many files as possible. How have you separated knowledge, rules and memory in your own agent projects?

Most of us can now build a working trading bot in an afternoon. What almost none of the tutorials give you is a way to answer the only question that matters: **does this strategy make money, or does it just run without crashing?** Those are different questions. Joseph made this split really clearly in his posts here — strategy evidence and operational readiness are independent, and a bot that never errors while trading a worthless strategy is a very efficient way to lose money. I want to show the missing half: how to get strategy evidence cheaply, in minutes, before anything touches an exchange. I'll use a real worked example, including the part where I found a bug in my own test. ### The trap that started this I deployed a bot on a 4-hour schedule and planned to paper trade for 72 hours to "see how it does." Then I did the arithmetic: - 72 hours ÷ 4-hour cron = **18 evaluations** - Historically, only **0.9%** of evaluations on that timeframe produced a trade - Expected trades in 72 hours: **0.16** I was going to wait three days to collect approximately zero trades, and then probably deploy anyway. Forward testing at low frequency is almost useless for judging a strategy. A backtest produced **2,581 trades in three minutes**. ### The one rule that makes a backtest mean anything **The backtest must run the exact same code the bot runs.** If you reimplement the strategy in your backtest, you are validating code that never trades, and trading code that was never validated. They drift, silently. The fix is simple: extract the decision logic into a shared module both import. ``` strategy.js <- indicators + entry/exit decisions, pure functions | +-- bot.js (live/paper: prints, places orders) +-- backtest.js (replays history) My backtest asserts indicator parity on every run and **refuses to print results** if the numbers diverge from what the live bot computes. That assertion is worth more than any statistic in the output. ## Bias controls you need or the numbers lie