# KyaniteLabs Full AI Context

> Longer machine-readable context for answer engines, agents, and research tools. For the short canonical brief, use https://kyanitelabs.tech/llms.txt.

KyaniteLabs is operated by PuenteWorks LLC. It publishes open-source tools, build notes, implementation paths, and operator assets for people who want AI tools, MCP servers, media pipelines, localization QA, repo diagnostics, and domain software working in real environments.

## Canonical Public Surfaces

- Homepage: https://kyanitelabs.tech/
- Blog: https://kyanitelabs.tech/blog
- Implementation help: https://kyanitelabs.tech/implementation
- Implementation intake: https://kyanitelabs.tech/implementation/intake
- Shop: https://kyanitelabs.tech/shop
- About Simon Gonzalez de Cruz: https://kyanitelabs.tech/about
- Sitemap: https://kyanitelabs.tech/sitemap.xml
- Structured AI sitemap: https://kyanitelabs.tech/ai-sitemap.json
- RSS feed: https://kyanitelabs.tech/feed.xml

## Public Project Proof

### devarch-framework
- URL: https://github.com/KyaniteLabs/devarch-framework
- Category: Repo Intelligence
- Language: Python
- Updated: 2026-05-29
- Description: Git repository archaeology framework for mining commit history, detecting signals, running 6 analysis vectors, and generating engineering reports.
- Proof role: Shows Kyanite can turn development history into evidence, not vibes.
### mcp-video
- URL: https://github.com/KyaniteLabs/mcp-video
- Category: Media MCP
- Language: Python
- Updated: 2026-06-01
- Description: Video editing MCP server for AI agents with 87 FFmpeg and Hyperframes tools, Python client, and CLI.
- Proof role: The flagship proof that agents can operate timelines, effects, and repeatable media pipelines.
### Epoch
- URL: https://github.com/KyaniteLabs/Epoch
- Category: Estimation MCP
- Language: TypeScript
- Updated: 2026-05-29
- Description: Time estimation MCP server for PERT, COCOMO II, Monte Carlo, sprint forecasting, token-to-time mapping, cost estimation, and schedule risk tools.
- Proof role: Turns planning uncertainty into agent-callable forecasting tools.
### checkyourself
- URL: https://github.com/KyaniteLabs/checkyourself
- Category: Readiness Audit
- Language: Python
- Updated: 2026-05-30
- Description: Local-first production-readiness system for AI-built apps: read-only audits, evidence scores, guided fixes, learning plans, dashboards, CLI, and MCP.
- Proof role: Makes quality, security, and launch risk inspectable before an AI-built app ships.
### DialectOS
- URL: https://github.com/KyaniteLabs/DialectOS
- Category: Localization MCP
- Language: TypeScript
- Updated: 2026-05-30
- Description: Spanish dialect localization MCP server and CLI across 25 regional variants with register control, structure preservation, and QA gates.
- Proof role: Makes Spanish launch quality inspectable instead of treating localization as generic translation.
### liminal
- URL: https://github.com/KyaniteLabs/liminal
- Category: Creative Coding
- Language: TypeScript
- Updated: 2026-05-29
- Description: AI creative coding studio for p5.js, GLSL, Three.js, music, video, and model-agnostic generative art workflows.
- Proof role: Shows Kyanite can build creative tools where agents touch code, shaders, media, and taste.
### liminal-sites
- URL: https://github.com/KyaniteLabs/liminal-sites
- Category: Living Websites
- Language: TypeScript
- Updated: 2026-05-29
- Description: Living website evolution engine for AI design directions, runtime skins, taste memory, previews, and repo-native patch planning.
- Proof role: Proves the website itself can evolve through constrained, inspectable design systems.
### Elixis
- URL: https://github.com/KyaniteLabs/Elixis
- Category: Pattern Synthesis
- Language: Python
- Updated: 2026-05-29
- Description: Local-first pattern synthesis engine for identity, brand voice, design systems, naming research, and lens-specific outputs.
- Proof role: Turns fuzzy identity and naming work into source-backed synthesis.
### Innerscape
- URL: https://github.com/KyaniteLabs/Innerscape
- Category: Personal OS
- Language: TypeScript
- Updated: 2026-05-29
- Description: Personal growth OS in TypeScript for journaling, emotional check-ins, habits, goals, tasks, sleep logs, decluttering, and self-awareness workflows.
- Proof role: Shows the same build-and-implementation pattern applied to intimate, data-rich workflows.
### openglaze
- URL: https://github.com/KyaniteLabs/openglaze
- Category: Domain Software
- Language: Python
- Updated: 2026-05-29
- Description: Free open-source ceramic glaze calculator, UMF analyzer, CTE estimator, recipe manager, and studio tool for potters and ceramic artists.
- Proof role: Proves Kyanite can ship useful software outside the generic AI-tool bubble.
### Dev Learning Archaeologist
- URL: https://github.com/KyaniteLabs/dev-learning-archaeologist
- Category: Learning Diagnostics
- Language: JavaScript
- Updated: 2026-05-31
- Description: Forensic git-history learning diagnostic for AI-assisted developers that turns commit history into evidence-backed study plans and HTML reports.
- Proof role: Turns repo behavior into a readable diagnostic artifact.
### achiote-food-memory-researcher
- URL: https://github.com/simongonzalezdc/achiote-food-memory-researcher
- Category: Food Memory
- Language: Claude Project
- Updated: 2026-05-31
- Description: Folder-based AI food-memory researcher for investigating half-remembered family dishes from sound-alikes, smells, colors, and cultural memory.
- Proof role: Extends Kyanite's evidence style into cultural memory and research assistants.
### unstuck-coach
- URL: https://github.com/simongonzalezdc/unstuck-coach
- Category: Executive Function
- Language: CSS
- Updated: 2026-05-30
- Description: Executive-function accessibility coach that turns a messy stuck point into one humane next move.
- Proof role: Applies agentic tooling to accessibility, pacing, and human next-step design.
### tradesflow
- URL: https://github.com/simongonzalezdc/tradesflow
- Category: Field Operations
- Language: TypeScript
- Updated: 2026-05-30
- Description: Portfolio prototype for asset-heavy field-service operators: equipment records, service notes, deficiencies, scheduling, and billing handoffs.
- Proof role: Shows implementation thinking for real-world operators with assets, visits, and billing handoffs.
### healthadvocate
- URL: https://github.com/simongonzalezdc/healthadvocate
- Category: Health Advocacy
- Language: Python
- Updated: 2026-05-30
- Description: FastAPI health advocacy web app for patient tooling, local LLM exploration, and medical NLP workflows.
- Proof role: Explores private, local-first health tooling without treating care context as generic chat.

## Products

### AI Coding Agent Blueprint
- URL: https://kyanitelabs.tech/shop/ai-coding-agent-blueprint
- Category: Claude Code
- Price: $49
- Summary: Production-ready .claude/ directory — CLAUDE.md, 4 skills, 2 subagents, hooks, MCP integrations, and CI/CD. Copy in, fill in, ship.
- Description: Claude Code is already the agent. Most developers install it and use it like ChatGPT with file access — missing 90% of its power. This blueprint activates the full stack: CLAUDE.md persistent memory, skills for reusable workflows, subagents for isolated investigation, hooks for automatic quality gates, MCP for external services, and agent teams for parallel sessions. Every section is backed by Anthropic's official architecture — the agentic loop (gather, act, verify), context management, and permission modes. Not a template. A working system.
- Includes: Production CLAUDE.md with memory hierarchy (root, directory, local, global); 4 Claude Code skills: feature-build, pr-review, debug, deploy; 2 custom subagents: security-reviewer (Opus), test-writer (Sonnet); Hook configurations: auto-lint on edit, destructive command blocker; Path-specific rules for frontend and backend directories; MCP integration setup: GitHub, PostgreSQL, Figma, Notion, Slack; Docker deployment with Claude Code CLI + GitHub Actions CI/CD; Cost management: budget controls, token optimization, context costs; Advanced patterns: writer/reviewer, fan-out, interview, plan mode

### Claude Code Productivity Pack
- URL: https://kyanitelabs.tech/shop/claude-code-productivity-pack
- Category: Claude Code
- Price: $19
- Summary: 100 Claude Code-specific prompts with anti-patterns, worked examples, and context management. Not generic LLM prompts — built for the agentic loop.
- Description: These aren't ChatGPT prompts you can find on Twitter. Every prompt leverages Claude Code's actual capabilities: @file references, /commands, Plan Mode, subagents, skills, hooks, and the gather-act-verify loop. Includes 5 anti-pattern deep dives (what NOT to do and why it wastes tokens), context management prompts (/clear, /compact, /btw, subagents), 10 chaining recipes that wire Claude Code features together, and verification steps on every prompt — because that's the single highest-leverage thing you can do according to Anthropic's own best practices.
- Includes: 100 Claude Code-specific prompts — @file refs, /commands, Plan Mode, subagents; 5 anti-pattern deep dives with fixes (kitchen sink, vague prompts, bloated CLAUDE.md); Context management section: /clear, /compact, /btw, subagents, rewind, resume; 10 chaining recipes that combine skills, subagents, and hooks; Every prompt includes a verification step (the #1 Anthropic recommendation); 9 categories: setup, architecture, implementation, review, debug, test, docs, DevOps, context

## Blog and Lab Notes

### Agents need verifiable tools, not better prompt theater
- URL: https://kyanitelabs.tech/blog/agents-need-verifiable-tools
- Date: 2026-05-23
- Category: MCP Implementation
- Primary keyword: verifiable AI agent tools
- Summary: The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise.
- Body: The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise. A prompt can suggest work. A tool can touch the artifact. That distinction is why Kyanite keeps building MCP servers, command-line tools, demos, and public proof records. The agent needs a handle on the real operation: editing a video, estimating time, localizing Spanish variants, reading repo history, or checking a domain-specific calculation. If the system cannot verify what happened, the agent is still mostly guessing. The tool contract is the product boundary A good agent tool has a clear action, typed inputs, structured output, readable errors, and a small verification path. That sounds boring. It is also what separates a reusable capability from a one-off session. call tool inspect output compare expectation revise next step mcp-video proves the media version of this pattern. Epoch proves the estimation version. DialectOS proves the localization version. devarch-framework and Dev Learning Archaeologist prove the repo-history version. OpenGlaze proves that domain software still matters when the user is not living inside the AI-tool bubble. Verification changes the conversation Without verification, an agent can sound confident and still be wrong. With verification, the system can show a command, a file, a route, a report, a test, a screenshot, or a structured result. That does not make the work perfect. It makes the next correction possible. The point of a Kyanite tool is not that an agent did something. The point is that a person can inspect what the agent did. What this means for implementation help Paid implementation is not generic "AI consulting." It is help getting a tool into a real environment with the setup, docs, examples, support boundary, and handoff that make verification possible for the next user. That is the work most public demos skip. It is also where useful tools become something a team can actually use. FAQ What makes an agent tool verifiable? The user or agent can check the input, output, error state, artifact, and success condition without relying on a vague explanation. Why use MCP? MCP gives agents a standard way to call tools. The value still depends on the quality of the tool contract, docs, examples, and verification path.

### Repo history is a product signal
- URL: https://kyanitelabs.tech/blog/repo-history-is-a-product-signal
- Date: 2026-05-23
- Category: Repo Intelligence
- Primary keyword: repo archaeology for AI teams
- Summary: A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish.
- Body: A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish. That evidence matters more now because AI-assisted work can produce a lot of motion that looks productive from far away. Repo archaeology is the practice of reading that motion carefully. The question is not whether the commit graph is pretty. The question is what the history proves about the product. What repo history can show Which parts of the system needed repeated repair. Whether docs followed the code or drifted away from it. Which tests appeared before launch and which appeared after regressions. Whether public claims match current routes, releases, and README examples. Where a project needs cleanup before a buyer, user, or contributor can trust it. This is why Kyanite includes devarch-framework and Dev Learning Archaeologist in the public project set. They turn invisible engineering behavior into a readable diagnostic artifact. AI makes this more important, not less AI agents can change more files faster. That is useful when the work is bounded and verified. It is dangerous when nobody can tell which changes mattered. Repo history becomes the receipt trail. If a tool claims to be ready, the repo should help prove readiness instead of forcing the reader to trust the landing page. The commercial value Repo archaeology helps with launch readiness, product audits, maintainer handoffs, learning diagnostics, and technical sales proof. It can show where the system is strong enough to publish and where the next paid implementation step should focus. That is expert work because it sits between engineering, product judgment, and public trust. The code matters. So does the story the code can honestly support.

### Implementation help is part of the product surface
- URL: https://kyanitelabs.tech/blog/implementation-help-is-product-surface
- Date: 2026-05-23
- Category: AI Tool Implementation
- Primary keyword: AI tool implementation support
- Summary: A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought.
- Body: A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought. Most technical builders understand the code. Most buyers or users experience the surface around the code: install instructions, examples, screenshots, error handling, docs, demos, support boundaries, and the first successful run. When that surface is weak, the tool may be real and still feel unusable. The implementation surface has jobs Explain the outcome in one sentence. Show what the tool needs before it runs. Give a smallest useful example. Prove that the example worked. Name what the tool does not do yet. Offer a paid path when someone wants the result without doing every setup step alone. Kyanite's own site follows that pattern: public repos, products, blog posts, /llms.txt , /ai-sitemap.json , implementation intake, and a clear boundary between Kyanite tool implementation and broader PuenteWorks consulting. Open source does not remove service work Open source can reduce lock-in and prove capability. It does not automatically handle installation, adaptation, team training, environment differences, docs, examples, or maintenance decisions. The repo proves the tool exists. Implementation help gets the tool into working hands. Why this is a real offer Implementation help is sellable when the public tool is specific enough to trust and the setup path is painful enough that a serious user would rather buy help than burn a weekend. That is the lane for Kyanite: practical tools, public proof, and scoped help getting the result working.

### Why mcp-video matters
- URL: https://kyanitelabs.tech/blog/why-mcp-video-matters
- Date: 2026-05-14
- Category: MCP / Video Automation
- Primary keyword: video editing MCP server
- Summary: mcp-video is a video editing MCP server that gives AI agents direct handles on timelines, effects, FFmpeg, and finished media.
- Body: mcp-video is a video editing MCP server that lets AI agents operate real media pipelines instead of only writing prompts about them. The useful part is not the word "video"; it is that an agent gets callable handles for FFmpeg, Hyperframes, effects, inspection, and repeatable assembly. Most AI video workflows still depend on a strange handoff. The agent can plan the edit, describe the shot, maybe generate a prompt, and then a human has to do the actual assembly work somewhere else. That is not agent-native. That is a chatbot standing outside the studio window. mcp-video gives the agent a timeline The technical decision is to expose video operations as stable tools instead of one-off shell recipes. That choice accepts the cost of a larger public surface: arguments need validation, error messages need to be readable, and effects need names that survive more than one session. mcp-video effect-glitch input.mp4 --output take-glitch.mp4 mcp-video inspect take-glitch.mp4 --json mcp-video concat beat-01.mp4 beat-02.mp4 --output final-cut.mp4 That interface is not decoration. It is the boundary that lets an agent inspect what happened, revise the next step, and keep the work reproducible. The product pattern behind agent video automation Kyanite looks for workflows that already exist in rough form, then turns them into surfaces an agent and a human can both use. For video, that means: effects that can be invoked as tools instead of one-off experiments command-line recipes that survive beyond a single session media pipelines that can be tested, revised, and shipped documentation good enough for a stranger to install the system That is the real implementation move: take the messy local ritual and make it legible. Why MCP media tools are bigger than video Video is one visible example of a broader agentic pattern. Agents need tools that touch real artifacts. A useful agent should be able to inspect a repo, assemble a video, run an estimation model, check a localization string, or package a launch surface. The more direct handles the agent has, the less the work feels like prompting and the more it feels like operating a system. FAQ What is mcp-video? mcp-video is a video editing MCP server, Python client, and CLI that exposes video inspection, effects, assembly, and FFmpeg-backed operations to AI agents. Who should care? Builders who want AI agents to produce inspectable media artifacts instead of only generating prompts, scripts, and editing instructions.

### Infinite monkeys, LLMs, and the room around the machine
- URL: https://kyanitelabs.tech/blog/infinite-monkey-agentic-systems
- Date: 2026-05-14
- Category: Agent Systems
- Primary keyword: agentic systems
- Summary: The argument behind the video: output quality is not just probability. It is architecture, filters, and human taste.
- Body: Agentic systems turn LLM probability into useful work by building the room around the model: tools, filters, memory, evals, and human taste. The model generates. The system decides what survives. The infinite monkey theorem is a useful metaphor until people stop too early. Randomness can produce anything in theory. In practice, the room matters. How many attempts are running? What gets filtered out? Who judges the output? What system remembers the good parts? What is the cost of another roll? LLMs are probability machines. Products are probability architecture. The difference between a toy demo and a useful AI system is not just a better model. It is the surrounding machinery: retrieval, tools, constraints, evals, review, memory, distribution, and human taste. The filter is the product Generation creates volume. Product work creates selection. That is why strong AI systems need more than prompts. They need rooms built around the model. tools that let the model act on real artifacts filters that reject bad output before it reaches users human criteria that decide what good means launch surfaces that make the system understandable Agentic systems need explicit architecture A useful architecture names the handoff points. The generation step can be cheap and messy; the selection step cannot be. If a system cannot explain why an output was accepted, it is gambling with prettier logs. generate -> inspect -> score -> revise -> package -> publish ^ | |________ evidence ________| This is also why Kyanite leads with public proof. A repo, demo, video, or docs page makes the room visible. You can inspect the architecture instead of trusting the claim. FAQ Are LLMs the same as random monkeys? No. The analogy is about generation without judgment, not the exact mechanism. LLMs are sophisticated probability machines; useful products add judgment around them.

### What a working AI tool needs before people can use it
- URL: https://kyanitelabs.tech/blog/ai-tool-implementation-checklist
- Date: 2026-05-14
- Category: Build Notes
- Primary keyword: AI tool implementation
- Summary: A practical checklist for turning a working tool, workflow, or rough app into something other people can understand, install, and use.
- Body: A working AI tool becomes useful to other people when the install path, demo, docs, examples, and support boundaries are clear. A working codebase is not automatically usable. A stranger has to understand what result it creates, how to try it, how to verify it works, and where to get help if they want that result without doing every setup step alone. Most technical projects fail commercially before anyone reaches the code. The surface is too vague. The minimum useful surface A one-sentence promise that says what changes for the user A demo, install path, or clear explanation of how the tool is delivered Examples that show actual inputs and outputs Tests, demos, screenshots, or logs that prove the system exists Metadata that helps humans and AI assistants discover the project A next step: try it, install it, read the build note, buy a product, or request implementation help A tool needs proof, not adjectives The page cannot say "ready" unless the surface shows instructions, examples, tests, release notes, screenshots, demos, or failure modes. The tradeoff is obvious: proof takes longer than copy, but proof keeps helping after the page is closed. README promise install command minimal example verification command known limits implementation option What Kyanite sells KyaniteLabs is the public lab where the tools, experiments, blog posts, and open-source products live. The paid path helps people install, adapt, understand, and hand off those tools in a real environment. The goal is not generic consulting. The goal is getting useful tools into working hands. Good implementation does not hide the mess. It turns the mess into a map.

### MCP server implementation checklist
- URL: https://kyanitelabs.tech/blog/mcp-server-implementation-checklist
- Date: 2026-05-14
- Category: MCP Implementation
- Primary keyword: MCP server implementation
- Summary: The checklist Kyanite uses to decide whether an MCP server is a toy, a usable tool, or something worth implementing.
- Body: MCP server implementation means making an agent-facing tool usable enough that someone else can install it, understand its tools, verify it works, and decide whether to trust it. The hard part is not exposing functions. The hard part is making the tool surface durable enough for real users and real agents. An MCP server becomes useful when the protocol surface, docs, examples, tests, and release path all tell the same story. The checklist starts with the tool contract Every public tool needs a sharp boundary. Tool names should describe the action. Arguments should reject bad input early. Output should be structured enough for an agent to reason about without scraping prose. { "tool": "estimate_project_time", "inputs": ["tasks", "confidence", "risk_model"], "output": ["p50_days", "p90_days", "assumptions", "warnings"] } The tradeoff is that explicit schemas slow down early experimentation. That cost is worth paying once the server is meant to leave your laptop. The install path is part of the product A strong MCP README answers 5 questions quickly: What does this server let an agent do? What does installation require? Which client configs are supported? What is the smallest useful example? How do I know the server is working? That last question is where weak projects break. If verification depends on the maintainer explaining it in a chat, it is not productized yet. Public proof compounds mcp-video, Epoch, and DialectOS each prove a different part of the stack: media operations, estimation models, and localization QA. The shared pattern is the lab: a real workflow becomes an agent-callable capability with enough documentation and tests to survive inspection. FAQ What makes an MCP server commercially useful? It has to touch an expensive, repeated, or fragile workflow. If the server only wraps a trivial API call, the product is the API, not the MCP server.

### Repo archaeology turns history into proof
- URL: https://kyanitelabs.tech/blog/repo-archaeology-proof-assets
- Date: 2026-05-14
- Category: Repo Intelligence
- Primary keyword: repo archaeology
- Summary: Why commit history is one of the strongest proof sources for learning diagnostics, implementation help, and engineering trust.
- Body: Repo archaeology uses commit history as evidence for how a project was actually built, where it got stuck, and what the next intervention should be. It is useful because code history is harder to fake than a positioning paragraph. Kyanite's repo-intelligence work exists because AI-assisted teams generate a lot of motion. The question is which motion taught the system something, which motion created debt, and which motion can become public proof. Commit history is a diagnostic surface A repo carries behavioral evidence: repeated fixes, reverted directions, test gaps, naming churn, and stale public metadata. A good diagnostic does not shame the team for that. It turns the pattern into a map. signals: - repeated failure around release automation - docs updated after code, not before - tests added only after regressions - public metadata lagging behind repo rename The tradeoff is that history is noisy. Repo archaeology needs filters, not mysticism. Why this matters for users Users do not only need the current feature set. They need confidence that the tool can keep improving. Public history, issue handling, release notes, and verified fixes show maintenance behavior. That is why Dev Learning Archaeologist and devarch-framework belong on the Kyanite proof wall. They turn invisible engineering behavior into something a person can inspect. FAQ Is repo archaeology only for learning diagnostics? No. It is also useful for product audits, acquisition diligence, maintainer handoffs, launch readiness, and deciding which proof assets should be public.

### AI discovery needs more than a sitemap
- URL: https://kyanitelabs.tech/blog/ai-discovery-llms-txt-geo
- Date: 2026-05-14
- Category: SEO / GEO
- Primary keyword: AI discovery
- Summary: What Kyanite adds so search engines and AI assistants can understand the tools, products, proof, and support path.
- Body: AI discovery works when a site gives crawlers and answer engines structured, quotable, current facts about what exists, who it helps, and what proof supports it. A sitemap is necessary. It is not enough. Generative Engine Optimization is mostly discipline. Say the answer early. Use real names. Add structured data. Keep public proof current. Make the commercial next step obvious. The AI-readable stack /sitemap.xml for canonical crawl coverage /llms.txt for answer-engine context /ai-sitemap.json for structured products, repos, and posts JSON-LD for Organization, WebSite, Article, Service, Product, and FAQ entities Direct-answer paragraphs at the top of pages and posts The tradeoff is maintenance. These files cannot be aspirational. If the repo list changes, the proof layer needs to change with it. GEO is strongest when it is useful to humans too Answer engines and human readers both reward the same thing: specific claims with clear evidence. "We build AI tools" is weak. "We build MCP servers, video automation, localization QA, repo diagnostics, and open-source tools backed by public KyaniteLabs repositories" is stronger because it can be checked. FAQ What is GEO? GEO, or Generative Engine Optimization, is structuring web content so AI answer engines can accurately summarize, cite, and route users to it.

## Contact and Fit

- Email: info@kyanitelabs.tech
- Best-fit work: implementation, adaptation, diagnostics, docs, handoff, and support around Kyanite-built public tools.
- Do not infer private, unlisted, dead, or unavailable tools as public Kyanite project proof.