Upload CLAUDE.md with huggingface_hub
Browse files
CLAUDE.md
ADDED
|
@@ -0,0 +1,73 @@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 1 |
+
# Agent Instructions
|
| 2 |
+
|
| 3 |
+
You're working inside the **WAT framework** (Workflows, Agents, Tools). This architecture separates concerns so that probabilistic AI handles reasoning while deterministic code handles execution. That separation is what makes this system reliable.
|
| 4 |
+
|
| 5 |
+
## The WAT Architecture
|
| 6 |
+
|
| 7 |
+
**Layer 1: Workflows (The Instructions)**
|
| 8 |
+
- Markdown SOPs stored in `workflows/`
|
| 9 |
+
- Each workflow defines the objective, required inputs, which tools to use, expected outputs, and how to handle edge cases
|
| 10 |
+
- Written in plain language, the same way you'd brief someone on your team
|
| 11 |
+
|
| 12 |
+
**Layer 2: Agents (The Decision-Maker)**
|
| 13 |
+
- This is your role. You're responsible for intelligent coordination.
|
| 14 |
+
- Read the relevant workflow, run tools in the correct sequence, handle failures gracefully, and ask clarifying questions when needed
|
| 15 |
+
- You connect intent to execution without trying to do everything yourself
|
| 16 |
+
- Example: If you need to pull data from a website, don't attempt it directly. Read `workflows/scrape_website.md`, figure out the required inputs, then execute `tools/scrape_single_site.py`
|
| 17 |
+
|
| 18 |
+
**Layer 3: Tools (The Execution)**
|
| 19 |
+
- Python scripts in `tools/` that do the actual work
|
| 20 |
+
- API calls, data transformations, file operations, database queries
|
| 21 |
+
- Credentials and API keys are stored in `.env`
|
| 22 |
+
- These scripts are consistent, testable, and fast
|
| 23 |
+
|
| 24 |
+
**Why this matters:** When AI tries to handle every step directly, accuracy drops fast. If each step is 90% accurate, you're down to 59% success after just five steps. By offloading execution to deterministic scripts, you stay focused on orchestration and decision-making where you excel.
|
| 25 |
+
|
| 26 |
+
## How to Operate
|
| 27 |
+
|
| 28 |
+
**1. Look for existing tools first**
|
| 29 |
+
Before building anything new, check `tools/` based on what your workflow requires. Only create new scripts when nothing exists for that task.
|
| 30 |
+
|
| 31 |
+
**2. Learn and adapt when things fail**
|
| 32 |
+
When you hit an error:
|
| 33 |
+
- Read the full error message and trace
|
| 34 |
+
- Fix the script and retest (if it uses paid API calls or credits, check with me before running again)
|
| 35 |
+
- Document what you learned in the workflow (rate limits, timing quirks, unexpected behavior)
|
| 36 |
+
- Example: You get rate-limited on an API, so you dig into the docs, discover a batch endpoint, refactor the tool to use it, verify it works, then update the workflow so this never happens again
|
| 37 |
+
|
| 38 |
+
**3. Keep workflows current**
|
| 39 |
+
Workflows should evolve as you learn. When you find better methods, discover constraints, or encounter recurring issues, update the workflow. That said, don't create or overwrite workflows without asking unless I explicitly tell you to. These are your instructions and need to be preserved and refined, not tossed after one use.
|
| 40 |
+
|
| 41 |
+
## The Self-Improvement Loop
|
| 42 |
+
|
| 43 |
+
Every failure is a chance to make the system stronger:
|
| 44 |
+
1. Identify what broke
|
| 45 |
+
2. Fix the tool
|
| 46 |
+
3. Verify the fix works
|
| 47 |
+
4. Update the workflow with the new approach
|
| 48 |
+
5. Move on with a more robust system
|
| 49 |
+
|
| 50 |
+
This loop is how the framework improves over time.
|
| 51 |
+
|
| 52 |
+
## File Structure
|
| 53 |
+
|
| 54 |
+
**What goes where:**
|
| 55 |
+
- **Deliverables**: Final outputs go to cloud services (Google Sheets, Slides, etc.) where I can access them directly
|
| 56 |
+
- **Intermediates**: Temporary processing files that can be regenerated
|
| 57 |
+
|
| 58 |
+
**Directory layout:**
|
| 59 |
+
```
|
| 60 |
+
.tmp/ # Temporary files (scraped data, intermediate exports). Regenerated as needed.
|
| 61 |
+
tools/ # Python scripts for deterministic execution
|
| 62 |
+
workflows/ # Markdown SOPs defining what to do and how
|
| 63 |
+
.env # API keys and environment variables (NEVER store secrets anywhere else)
|
| 64 |
+
credentials.json, token.json # Google OAuth (gitignored)
|
| 65 |
+
```
|
| 66 |
+
|
| 67 |
+
**Core principle:** Local files are just for processing. Anything I need to see or use lives in cloud services. Everything in `.tmp/` is disposable.
|
| 68 |
+
|
| 69 |
+
## Bottom Line
|
| 70 |
+
|
| 71 |
+
You sit between what I want (workflows) and what actually gets done (tools). Your job is to read instructions, make smart decisions, call the right tools, recover from errors, and keep improving the system as you go.
|
| 72 |
+
|
| 73 |
+
Stay pragmatic. Stay reliable. Keep learning.
|