[ { "id": "agent-harness", "data": { "title": "Agent Harness", "status": "alive", "started": "2026-02-06T00:00:00.000Z", "current_question": "Can one editable source-of-truth for agent configuration make Codex, Claude Code, GitHub Copilot, and Cursor feel like provider targets rather than separate project setup chores?", "help_welcome": "Useful pressure here is operational: migration edge cases, provider parity gaps, registry workflows that feel too magical, and places where generated files make ownership less clear instead of more clear.", "links": { "repo": "https://github.com/madebywild/agent-harness" }, "related_thoughts": [ "agent-harness-is-the-new-ide" ], "related_claims": [], "tags": [ "agents", "open-source", "wild", "typescript", "cli", "mcp", "codex", "claude", "copilot", "cursor" ] }, "body": "Agent Harness is an open-source Made by Wild monorepo for managing AI agent configuration from one canonical `.harness/` directory. It treats prompts, skills, MCP server configs, subagents, commands, settings, lifecycle hooks, presets, and registries as source-controlled entities, then renders the provider-native outputs expected by Codex, Claude Code, GitHub Copilot, and Cursor.\n\nThe core package, `@madebywild/agent-harness-framework`, is both a TypeScript library and the `harness` CLI. It handles workspace initialization, provider enablement, planning, validation, apply, watch mode, schema migration, registry pulls, third-party skill imports, and U-Haul migration from existing provider files such as `AGENTS.md`, `CLAUDE.md`, `.mcp.json`, and Copilot instructions. The model is deliberately close to shadcn: shared agent assets are copied into the project as editable source, not hidden behind opaque package imports.\n\nThe supporting packages keep the boundaries explicit. `@madebywild/agent-harness-manifest` owns the Zod schemas and TypeScript types for manifests, lock files, overrides, registries, and generated indexes. `@madebywild/agent-harness-tui` provides the Ink and React terminal UI used when `harness` runs interactively, so the same engine can serve both direct commands and a guided setup flow.\n\nThe repo is less about a single CLI command than about a source-of-truth contract. Canonical files live under `.harness/src/**`; generated artifacts land where each provider expects them: `AGENTS.md`, `CLAUDE.md`, `.github/copilot-instructions.md`, provider skill folders, MCP config files, subagent definitions, hook files, and Codex TOML state. Planning detects drift, collisions, unmanaged outputs, stale generated files, and schema mismatches before apply writes anything.\n\nWhat makes the project interesting to me is that it turns agent setup into infrastructure rather than folklore. As agents become the working surface for software development, the project-specific harness starts to matter as much as the editor configuration did. Agent Harness is the attempt to make that layer inspectable, portable, provider-aware, and owned by the repository." }, { "id": "crane-app", "data": { "title": "CRAN/E", "status": "shipped", "started": "2022-08-27T00:00:00.000Z", "current_question": "How far can CRAN/E move from a faster CRAN search interface toward an intelligence layer for R packages, authors, trends, and agents?", "help_welcome": "R users can help most by pointing out missing discovery workflows: package comparison, author lookup, search relevance, trend interpretation, and MCP queries that should exist.", "links": { "repo": "https://github.com/flaming-codes/crane-app" }, "related_thoughts": [], "related_claims": [], "tags": [ "r", "search", "pwa", "react-router", "supabase", "mcp", "analytics" ] }, "body": "CRAN/E is \"The Comprehensive R Archive Network, Enhanced\": a modern search and discovery surface for R packages and authors hosted on CRAN. It is not a package host. It is an interface layer over the archive, built because finding the right package should not require fighting the shape of the old CRAN website.\n\nThe public app lives at [cran-e.com](https://cran-e.com) and is designed as a progressive web app. The current codebase is a TypeScript and React 19 application on React Router 7 with Vite, Tailwind CSS, Supabase, Arcjet, OpenTelemetry, Vitest, Playwright, Storybook, the Vercel AI SDK, Google Gemini, and embedding-backed search. It also has a Raycast extension ecosystem nearby, because package search belongs where developers are already moving.\n\nThe core user experience is search, but the project has grown into a broader map of the R package ecosystem. Package pages pull together dependencies, relations, maintainers, authors, downloads, binaries, documentation, teams, insights, structured metadata, and FAQ data. Statistics pages track page trends, package downloads, package trends, and R releases, with some summary work delegated to Gemini.\n\nCRAN/E also exposes a read-only MCP server at `/api/mcp`. That matters because package discovery is no longer only a browser workflow. Agents should be able to ask the same structured questions that a person asks: find a package, inspect an author, search broadly, or look for related packages through stable `cran://` resources.\n\nThe project is shipped and maintained, with versioned releases and dependency/security work still happening. The next version of the question is less \"can CRAN be searched better?\" and more \"what does an agent-readable software ecosystem index make possible for working R programmers?\"" }, { "id": "flaming-codes-web", "data": { "title": "flaming.codes", "status": "alive", "started": "2022-07-10T00:00:00.000Z", "current_question": "How should a long-running personal publishing site keep evolving without losing the speed, searchability, and low-friction archive that made it useful?", "help_welcome": "The useful feedback is editorial and architectural: migration sharp edges, content model mistakes, search quality, and whether the site still feels fast and legible.", "links": { "repo": "https://github.com/flaming-codes/flaming-codes-web" }, "related_thoughts": [], "related_claims": [], "tags": [ "web", "writing", "react-router", "publishing", "frontend", "ai", "internationalization" ] }, "body": "flaming.codes is my long-running technical publishing surface: articles, tutorials, experiments, project notes, and a public profile wrapped into one site. It is also a web-platform playground, which means the implementation keeps changing as the edge of the frontend stack changes.\n\nThe current tracked app is a React Router 7 and React 19 site using TypeScript, Tailwind CSS, Vite, Motion, Fuse.js, Satori/Resvg, and a Markdown pipeline built on Unified, Remark, and Rehype. Content is served from a static-file CMS under locale folders, with Markdown posts plus JSON previews, suggestions, categories, and addenda. The archive is substantial enough to make the system matter: the local English content index contains 125 posts, 21 categories, and the CMS spans 17 locale directories.\n\nThe site has accumulated the kind of infrastructure that only appears when a personal site is used for years rather than launched once: fuzzy search, RSS, sitemap generation, generated Open Graph images, locale routing, RTL support, privacy-friendly analytics, and a homepage visual built from animated depth-aware flocking. Some content also records when AI tools were part of the writing or image workflow, because publishing experiments should leave an audit trail.\n\nThere is a newer migration sitting beside the current app, aimed at Next.js 16 and PayloadCMS. That work is a sign of the project's present tense. flaming.codes is already shipped, but it is not finished in the museum sense. The question is how to preserve the publishing loop while giving the content model more room to grow.\n\nThe site matters because it is not only a place where work is displayed. It is one of the places where the work happens: a durable archive, a testbed for modern web architecture, and a public record of what I was trying to understand at the time." }, { "id": "flamli", "data": { "title": "Flamli", "status": "alive", "started": "2026-03-31T00:00:00.000Z", "current_question": "Can a chat-native agent safely grow its own tool surface while keeping identity, policy, terminal access, and scheduling explicit?", "help_welcome": "Useful pressure here is practical: safer mutation approvals, better Slack workflows, and clear boundaries around when an agent may touch the local machine.", "links": { "repo": "https://github.com/flaming-codes/flamli" }, "related_thoughts": [], "related_claims": [], "tags": [ "agents", "ai", "deno", "slack", "automation", "self-hosting" ] }, "body": "Flamli is a self-hosted chat agent that treats Slack and Discord as the primary interface, not as notification sidecars. The interesting part is not that it can answer messages. The interesting part is that the agent runtime is built around identity, policy, memory, scheduling, and a deliberately constrained ability to change its own skills.\n\nThe project runs on Deno 2 with TypeScript, Hono, the Vercel AI SDK, Ollama support, Slack Bolt, Zod, Deno KV, and optional Redis. Its HTTP surface is operational rather than decorative: health checks, readiness, and webhooks for Slack and Discord. Most of the real design lives behind that surface in adapter handling, caller-scoped state, scheduler dispatch, and the set of tools assembled for each agent turn.\n\nFlamli is also a test of how much agency can be made boring enough to trust. Mutation tools can write, delete, and roll back skills, but only through explicit policy gates. Terminal access exists, but is optional, non-interactive, and routed through a dedicated workdir. The scheduler can create recurring agent turns or shell commands, but persistence and dispatch are made visible rather than hidden inside a chat transcript.\n\nThe current version is still more runtime than product. Slack Socket Mode is the main local testing path, Discord is webhook-based, state persists through Deno KV or Redis, and generated skills load dynamically from the `skills/` directory. The missing pieces are the pieces that should not be rushed: human approval UI for mutation-capable tools, richer progress streaming, more adapters, and a heavier secondary harness for code-changing work.\n\nWhat I want from Flamli is a chat agent that can become more useful without becoming slippery. It should be able to remember, schedule, inspect, and even alter its own capabilities, while leaving enough explicit structure that a human can still tell where permission ends." }, { "id": "sveltekit-runelayer", "data": { "title": "SvelteKit RuneLayer", "status": "alive", "started": "2026-03-28T00:00:00.000Z", "current_question": "Can a SvelteKit app get a useful CMS without adopting a separate runtime, framework, or admin server?", "help_welcome": "Useful pressure here is practical: Payload parity gaps that matter, SvelteKit integration edge cases, admin workflows that feel underpowered, and storage/auth boundaries that should be sharper before v1.", "links": { "repo": "https://github.com/flaming-codes/sveltekit-runelayer" }, "related_thoughts": [], "related_claims": [], "tags": [ "sveltekit", "svelte", "cms", "typescript", "drizzle", "libsql", "better-auth", "admin-ui", "open-source" ] }, "body": "SvelteKit RuneLayer is a CMS-as-a-package for SvelteKit apps. Instead of running as a separate service or asking the host app to move into a new framework, it lives inside the existing Node process and exposes the pieces a content-heavy app needs: schema-driven collections and globals, request-scoped query APIs, auth, persistence, file storage, hooks, and an admin UI.\n\nThe project is published as `@flaming-codes/sveltekit-runelayer` and is still pre-v1. That matters because the package is already usable and tested, but the API should be expected to move while the platform hardens. The current work is less about proving that a Svelte admin can exist and more about deciding which CMS guarantees belong in the core contract.\n\nThe architecture keeps the source of truth in TypeScript collection definitions. Those definitions drive generated Drizzle table shape, libsql-backed storage, access-controlled CRUD, admin rendering, globals, versions, uploads, and the host application's drizzle-kit migrations. Better Auth handles authentication, while RuneLayer wraps it in SvelteKit request handling, role checks, anti-spoofing headers, and deny-by-default access behavior.\n\nThe example app in `apps/web` is part of the product, not a throwaway demo. It runs a marketing site and its package-owned admin on the same content model, with public pages, site chrome, pricing, docs, changelog content, seeded data, and admin editing all exercising the same runtime path. That keeps the package honest: authoring and rendering have to stay aligned.\n\nThe interesting tension is Payload-shaped ambition inside a SvelteKit-native package boundary. RuneLayer intentionally borrows the useful CMS vocabulary: collections, globals, fields, access control, hooks, uploads, drafts, versions, and admin screens. But it has to translate that vocabulary into Svelte, SvelteKit, Drizzle, libsql, Better Auth, and host-managed migrations without quietly becoming a second application framework.\n\nWhat I want from RuneLayer is a boringly embeddable CMS layer for SvelteKit: enough structure that real content products can trust it, enough restraint that the host app remains the host app, and enough parity with established CMS patterns that choosing Svelte does not mean rebuilding the same authoring machinery from scratch." }, { "id": "thinkinglabs", "data": { "title": "Thinking Labs", "status": "alive", "started": "2026-04-30T00:00:00.000Z", "current_question": "Can a personal knowledge site become a trustworthy operating surface for both humans and agents without giving up plain-text authorship?", "help_welcome": "Useful pressure here is architectural and editorial: schema edges that feel wrong, agent workflows that need clearer confirmation, MCP views that should exist, and places where the public surface stops explaining the underlying system.", "links": { "repo": "https://github.com/flaming-codes/thinkinglabs" }, "related_thoughts": [], "related_claims": [], "tags": [ "knowledge", "agents", "astro", "markdown", "mcp", "sqlite", "validation" ] }, "body": "Thinking Labs is a markdown-canonical personal knowledge and agentic-space site. The durable state is not a CMS, hosted database, or generated index. It is the `content/` tree: one markdown file per thought, claim, project, prediction, decision, question, post, input, or provenance event, with YAML frontmatter validated by kind-specific Zod schemas.\n\nEverything else is a projection of that source tree. Astro renders the public site and JSON routes from typed content collections. Offline builders derive `public/llms.txt`, JSON feeds, brain-diff feeds, and `dist/index.sqlite`, the local agent query layer. The MCP server reads the same corpus through a shared server factory, with both stdio and Streamable HTTP transports exposing fixed resources and tools for agents.\n\nThe repo is also an experiment in useful background agency with a strong confirmation boundary. Scanners such as `dormant-flip`, `review-decisions`, `resolve-predictions`, `freshness-review`, and `triage-questions` enqueue deterministic proposals into a local queue. They do not mutate content directly; accepted changes flow back through `pnpm review-proposals`, where a human can accept, edit, reject, or defer.\n\nThat makes the project less a static website than a small operating system for thinking in public. Schemas, ADRs, validation commands, and build artifacts are the guardrails. Markdown remains the thing that matters, but the surrounding surfaces let humans, browsers, feeds, and agents ask sharper questions of the same underlying material." } ]