Here I explore wiki-agent-testing or WAT which involves the setting up a minimal local first agent based testing setup for creating javascript and wasm based code for wiki and federated wiki plugins.
> Let your agents read this as context, and they'll get smarter over time.
# What is this document? This is a **Workflow Plan and Prompt Spec** — you can think of it as a hybrid: * 📘 **`README.md`** for human reference * 🧠 **`instructions.md`** for agents and LLMs * 🧩 Future prompt input for Open Interpreter and Claude agents Recommended filename: `yam-agent-workflow.md` Keep updating this file to: * Refine prompt behavior * Log changes to expected behavior * Track what works / what doesn’t
# Agent-Based Testing Workflow This document outlines a practical, agent-based workflow for testing and iteratively improving simple composable scripts like yam.js within the context of a local Federated Wiki installation. yam.js is a bi-directional round-robin parser for markdown files (using Yam Back Matter) to page-json)
It is designed to be: - **Minimal**: works on a local machine with no external infrastructure - **Autonomous**: agent iterates until test output matches expectations - **Composable**: integrates cleanly with existing tools like `n8n`, local editors, and static files in `~/.wiki/localhost/assets/...`
# Why This is a Good Idea 1. **Test loops are fragile manually**: You often have to check multiple places (JS, HTML, browser console, JSON diffs) to debug a failing test. 2. **Autonomous iteration saves time**: You can walk away and return when the agent has solved the mismatch. 3. **Federated Wiki already supports assets**: No need for extra infrastructure — your test suite can live in `~/.wiki/localhost/assets/yam-demo`. 4. **n8n can act as orchestrator**: This ties it all together and lets you create future workflows (e.g., auto-publishing, notifications).
# Tools Considered | Tool | Pros | Cons | | -------------------- | ---------------------------------------- | ----------------------------------- | | Open Interpreter | Local file access, CLI, Claude support | Slightly chatty CLI format | | AutoGen | Structured LLM-to-LLM workflows | Requires Python scripting | | CrewAI | Multi-agent architecture | Requires planning and orchestration | | LangGraph | Visual, directed agent flows | Complex for this use case | | Claude API (manual) | Claude quality + functions | Requires custom wrapper code |
**Chosen:** Open Interpreter + n8n because: - Both run locally and require minimal setup - Easy to observe/debug - Support Claude 3 models via API key - Compose well with Federated Wiki’s static file structure
# See