The following article originally appeared on “Dan Shapiro’s blog” and is being reposted here with the author’s permission.
Companies are now producing dark factories—engines that turn specs into shipping software. The implementations can be complex and sometimes involve Mad Max metaphors. But they don’t have to be like that. If you want a five-minute factory, jump to Trycycle at the bottom.
The engine in the factory
Deep in their souls, dark factories are all built on the same simple breakthrough: AI gets better when you do more of it.
How do you do “more AI” effectively? Software factories use two patterns. One of them I’ve already told you about—slot machine development. Instead of asking one AI, you ask three at once, and choose the best one. It feels wasteful, but it gives better results than any model could alone.
Does three models at a time seem wasteful? Well, wait until you meet the other pattern: the trycycle.
The simplest trycycle
It seems trivial, but it’s an unstoppable bulldozer that can bury any problem with time and tokens. And of course, you can combine it with slot machine development for a truly formidable tool.
Every software factory has a trycycle at its heart. Some of them are just surrounded by deacons and digraphs.
(And as a side note, they’re all more fun with freshell, which is free and open source and makes managing agents a joy!)
Let’s meet the factories, shall we?
Gas Town
Steve Yegge saw this coming like a war rig down a cul-de-sac. His factory, Gas Town, dropped the day after New Years, and I was submitting PRs before the code was dry. It launched as a beautiful disaster, with mayors, convoys, and polecats fighting for guzzoline in the desert of your CPU. It’s now graduated to a fully fledged MMORPG for writing code. It’s amazing, it’s effective, and it’s pioneering in a fully Westworld sort of way.
The StrongDM Attractor
Justin McCarthy, the CTO of StrongDM, talks about the factory as a feedback loop. It used to be that when a model was fed its own output, it would fix 9 things and break 10—like a busy and productive company that was losing just a bit of money on every transaction. But sometime last year, the models crossed an invisible threshold of mediocrity and went from slightly lossy to slightly gainy. They started getting better with each cycle.
Justin’s team noticed and built the StrongDM attractor to cash in.
If Gas Town is Mad Max, StrongDM is Factorio: an infinitely flexible, wildly powerful system for constructing exactly the factory you need.
But the StrongDM team did something interesting: They didn’t ship their factory. Instead, they shipped the specification for the Attractor so everyone can implement their own.
And you can absolutely implement your own! But you can also just steal the one I made for you.
Kilroy
Kilroy is a StrongDM Attractor written in Go (although it works with projects in any language). It has all the flexibility of the Attractor design, but it also ships with an actual functioning factory configuration, tests, sample files, and other things that make it more likely to work.
In theory, you don’t need Kilroy—you can just point Claude Code or Codex CLI at the Attractor specification and burn some tokens. My friend Harper built three (and you should read his post for some meditations on where the Attractor approach is heading).
In practice, it took the better part of a month for me and some wonderful contributors to polish up Kilroy to the point where it is now, so you may save yourself some time, tokens, and effort by just stealing this.
Enter the trycycle
The other night I was carefully building the dotfiles and runfiles for a Kilroy project—configuring the factory to build the project.
Then a thought struck.
What if this was just a skill?
Enter Trycycle, the very simplest trycycle. It’s a very simple skill for Claude Code and Codex CLI that implements the pattern in plain English.
Define the problem.
Write a plan
Is the plan perfect? If not, try again.
Implement the plan.
Is the implementation perfect? If not, try again.
That’s basically it. To use it, you open your favorite coding agent and say, “Use Trycycle to do the thing.” Then sit back and watch the tokens fly.
It’s simple because it’s just a skill. Under the hood, it adapts Jesse Vincent’s amazing Superpowers for plan writing and executing. It will take you literally minutes to get started. Just paste this into your agent and you’re off to the three-wheel races.
Hey agent! Go here and follow the installation instructions. https://raw.githubusercontent.com/danshapiro/trycycle/main/README.md
Trycycle is barely 24 hours old as of the time of this writing. I’ve shipped well over a dozen features with it already, and I was in meetings most of the day. While I was having dinner, it ported Rogue to Wasm(!). Last night it churned for 7 hours and 56 minutes and landed six features for freshell.
The best part, though, is that because it’s just a skill, it’s instantly part of your dev flow. There’s no configuration or learning curve. If you want to understand it better, just ask. If you don’t like what it’s doing, have stern words.
Which one to use?
Here’s how I’d decide right now.
If you want to become part of a growing movement of collaborators burning tokens together to build software, individually and collectively—try Gas Town.
If you want to invest in building a powerful, configurable, sophisticated engine that can drive your projects forward 24 hours a day—try Kilroy.
If you just want to get things done right now, give Trycycle a spin. Heck, it’s fast enough that you can spin up a trycycle while you read the docs on Kilroy and Gas Town.
And whatever you choose, I recommend you do it with freshell, because it’s just more delightful that way!
Platform engineering requires something of a leap of faith. Developers need to “believe” that foundation-level tools, libraries, and repositories will always offer a fully stocked larder of services, all optimized to the requisite weight, sharpness, and durability.
Seeking to ensure its store cupboard is presented properly, the Eclipse Foundation announced on Tuesday the Open VSX Managed Registry. The technology represents the open source community’s first foundation-operated managed service for critical developer infrastructure.
What is Open VSX?
While Microsoft’s proprietary parentage means it logically owns the VS Code Marketplace, Open VSX is the open source, vendor-neutral extension registry for tools built on the VS Code extension API. With Open VSX denoting Visual Studio eXtensions, an extension registry in this sense can be defined as a central repository for software developers to search (or publish) and install code extensions (bug fixers, automated formatting, and code autocompletion tools, etc.) or plugins.
Open VSX Managed Registry offers an ecosystem of AI-native IDEs, cloud development environments, and VS Code-compatible platforms. These include Amazon’s Kiro, Google’s Antigravity, Cursor, VSCodium, Windsurf (an AI-native coding assistant), Ona (built on Gitpod foundations), and others. Commercial adopters receive a 99.95% uptime SLA, service credits, defined support tiers, and enterprise-grade operational assurance for sustained production-scale usage.
“Open VSX remains open and accessible to developers, open source projects, and organizations of all sizes, but long-term reliability and security don’t happen by accident.” – Mike Milinkovich, executive director, Eclipse Foundation.
Balancing openness & robustness
Working the helm of this project is Mike Milinkovich, executive director of the Eclipse Foundation. Explaining that there’s a real balancing act here, Milinkovich tells The New Stack that his team’s approach is all about finding the right level at which to stay true to open-source principles while ensuring the funding is in place to enable critical infrastructure at scale to operate.
“Open VSX remains open and accessible to developers, open source projects, and organizations of all sizes, but long-term reliability and security don’t happen by accident. This model allows us to preserve openness while ensuring the platform can be operated and trusted at scale,” Milinkovich says.
As software engineers now work with AI-driven development tools that accelerate automation, drive continuous installs, and create new ever-busier channels of machine-to-machine traffic, extension registries have become high-throughput elements of a worthy always-on infrastructure.
From community to business continuity
Thabang Mashologu, CMO of the Eclipse Foundation, tells The New Stack that there’s an important point of progress to note on the evolutionary curve for extension registries; what was once a technology that enjoyed primarily community-scale usage now needs to reflect sustained commercial platform dependency at a global scale.
“The priority for Open VSX Managed Registry is simple: keep critical open source infrastructure open, secure, reliable, and sustainable for the developers and projects that depend on it,” Mashologu says. “Free access remains for the broader community while vendors and enterprises benefit from a resilient, vendor-neutral platform that delivers the stability and performance they need to build and scale with confidence.”
Open VSX now serves more than 300 million downloads per month, with peak daily traffic exceeding 200 million requests. The registry hosts over 10,000 extensions from more than 7,000 “publishers” (meaning teams, special interest groups, commercial software engineering units, but mostly individuals), and it continues to grow rapidly as adoption expands across AI-native developer tooling and cloud-based platforms.
AWS, Google, & Cursor sign up
Initial customers of the Open VSX Managed Registry include Amazon Web Services, Google, and Cursor. Collectively, these organizations say they are adopting the managed service to secure production-grade reliability, defined service levels, and predictable scaling for enterprise developer platforms.
Operating a global extension registry at this scale requires significant investment in compute capacity, bandwidth, storage, security operations, and the engineering expertise necessary to maintain availability and resilience. AI-driven development is accelerating that demand. Again, these factors underline the Eclipse Foundation’s decision to battle-harden the total offering here.
With automated workflows and coding agents, a single developer can now generate infrastructure load comparable to that of dozens of traditional users, increasing both traffic volume and operational complexity. The service is designed for organizations that use Open VSX as critical infrastructure in commercial products, AI-scale services, or enterprise development environments; as such, it aligns operational accountability with the expectations of production systems.
The price of freedom
Individual developers and open source projects never pay to use the Open VSX Registry. Publishing, search, and standard development workflows remain unchanged. Open source IDEs and community projects continue to benefit from what the Eclipse Foundation calls “generous” free-tier limits.
The team further states that managed service is typically significantly more cost-effective than self-hosting equivalent global infrastructure at scale. At the commercial level, it states that organizations can now rely on defined service levels while maintaining vendor neutrality and transparent governance.
There’s a defined shift happening here. Eclipse CMO Mashologu calls this point in time out as a moment when AI agents have “changed the economics” of developer infrastructure.
Where extension registries were typically accessed by human developers, AI agents, as part of platform engineering projects, now require a new level of machine-scale traffic throughput. This likely underpins the Eclipse Foundation’s two-tiered approach to bolstering both the open community and commercial enterprise use cases.
So this month Marcus and I get into a slightly uncomfortable question. If AI can knock out decent interfaces from a text prompt, where does that leave the people whose day job is opening Figma and making screens look nice?
We start with Google Stitch, which has been getting a lot of attention lately. Then we zoom out into something I have become mildly obsessed with, which is building AI skills. Not prompt snippets, but reusable, documented processes that let you get consistent work out of AI without drowning it in context.
App of the Month
This month’s tool is Google Stitch (v2), Google’s AI UI generator. You describe what you want, it produces an interface, and you can do some light manual tweaking.
It is not a full replacement for Figma. The editing controls are basic. The bigger story is what it represents. We are now at the point where a decent, usable UI can be generated fast enough that the real value shifts from "can you draw the screens" to "can you judge what good looks like." That is where experience, and yes, taste, starts to matter.
If you want to compare approaches, I mentioned Figr again, which I still prefer for the quality of what it produces.
Are UI Designers Becoming Vinyl?
The question Stitch raises is not "can AI design interfaces". It clearly can. The question is what happens to the job market when "good enough" becomes cheap, fast, and widely available.
I found myself telling 2 different clients recently that they could probably skip hiring a UI designer. They had tight budgets, tight timelines, and already had solid brand guidelines or a design system. In those situations, I could push the work through AI, iterate it a bit, and get something perfectly serviceable.
That line of advice made me feel a bit grubby. Not because it was wrong for those clients, but because it hints at a bigger shift.
My worry is that UI design becomes like vinyl records. Most people will not need it. A small number will care deeply and pay for it. The middle ground shrinks.
Marcus made the important caveat here. Some designers will still be in demand because they bring something AI cannot easily fake. A distinctive visual style. Creative judgment. Brand thinking. The ability to make something feel like it came from a real point of view, not a model averaging the internet.
We also talked about where UI designers can expand their value, because "I make pretty screens" is not a great long-term career plan.
Broaden into UX and problem solving. Look past the interface and into the business problem, user needs, and research.
Own the stuff between screens. AI still tends to think screen by screen. Humans are better at flows, journeys, and the messy reality of how people actually get from A to B.
Lean into information architecture. For websites especially, the structure and content model matter as much as the visual design.
We used a music analogy that will probably annoy some people, which makes it perfect. AI tools can generate "background" output that is fine for low-stakes use. They will not replace great musicians. But they will reduce the number of gigs available.
AI Skills As a Career Asset
After we finished terrifying UI designers, we moved on to something more useful. I think a lot of roles are going to need an AI toolkit. Not a handful of clever prompts, but a proper library of reusable skills.
When I say "AI skills," I mean documented processes that an AI can follow reliably. Think SOPs you can run repeatedly, not prompt snippets you copy and paste.
I now have around 60 skills in my library, and it is growing constantly. Outside of the Boagworld website, it might be the most valuable business asset I have.
The reason is consistency and context management. AI can produce terrible output when you dump too much information on it at once. Skills let you break work into focused chunks and chain them.
We talked about 3 levels of skills:
Company-level skills
Standard processes that keep things consistent. Proposals. Expense claims. Holiday booking. The sort of stuff that should not depend on one person remembering every step.
Team or discipline skills
For example, UX teams can create skills for personas, journey mapping, surveys, and top task analysis. That helps remove bottlenecks and lets colleagues do decent work without reinventing the wheel.
Individual skills
This is where it gets interesting for your career. These are the skills that capture how you do something, including all the weird little bits you have learned over the years.
A key point here is that the value is not only in having the skill. It is in creating it. Writing down a process forces you to surface assumptions and explain what "good" looks like.
We also got into AI agents. If you describe your skills well, an agent can chain them to complete bigger jobs. I gave a sales example where a meeting transcript can be turned into a CRM entry, follow-up tasks, company research, and a draft proposal with very little manual effort.
That is exciting. It is also mildly terrifying if you are attached to the idea of being indispensable.
I mentioned an article that helped me connect a few threads in my own work. UX, conversion rate optimization, and design leadership can look like 3 different things until you realize they all operate on the same system.
It frames CRO and UX as two sides of the same coin. CRO asks, "Did they convert?" UX asks, "Was it easy and enjoyable?" I would add that UX also cares about what happens after conversion, because retention is often where the real money is.
The shared foundation is data. Analytics, event tracking, heat maps, session recordings. The same signals can tell you where people struggle and where the biggest conversion wins are likely to be.
It also reinforced something I believe strongly. CRO and UX should not sit in separate silos. Both work best when they cover the entire journey, not just one page at a time.
Marcus’ Joke
"I just purchased an original Van Gogh coffee table. I know it’s original because there’s a bit of veneer missing."
Viktor Glinka: When Internal and External Team Members Have Divergent Goals — The Silent Killer of Agile Teams
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"The root causes for destructive team patterns often lie outside the team itself." - Viktor Glinka
Viktor shares a story from a manufacturing organization where one team stood out — and not in a good way. The team was composed of both internal and external members, and what no one saw coming was that their implicit goals were fundamentally divergent: the external members were focused on maximizing revenue for their own company, while the internal members cared deeply about product quality. The signs were visible to anyone who approached them — they barely talked to each other and preferred to work individually. When Viktor tried to raise the topic of cooperation and trust, he was met with awkward silence. One team member finally told him: "I don't want the team to blow up. In my previous experience, I raised this topic and that was the end of the team." Fear kept the truth underground. Viktor brought his observations to the manager, who acknowledged the lack of a shared goal as the root cause — but couldn't fix it because he wasn't authorized to manage the external people. The takeaway was clear: three key success factors for any team are the right team composition with people who want to work together, a shared goal that unites diverse perspectives, and clear expectations set by their manager.
Self-reflection Question: Does your team have a shared goal that everyone — including external members and contractors — genuinely understands and cares about? When was the last time you checked?
Featured Book of the Week: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland
Viktor recommends The Art of Doing Twice the Work in Half the Time by Jeff Sutherland as the book that sparked his passion for Scrum. As he puts it: "I know the title is very controversial and often criticized, but I could deeply relate to the stories inside the book. They sparked a passion that is still with me." Viktor also recommends a bonus book: Reinventing Organizations by Frederic Laloux, which showed him the real power of self-organization and validated what he had already started experimenting with in his project management career. It pushed him to explore holacracy, sociocracy, intent-based leadership, and coaching.
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
Viktor is an organisational consultant and Professional Scrum Master who helps teams and leaders find simpler ways to deliver value while keeping the human side of work at the center. He's practical, curious, and focused on real outcomes rather than buzzwords. His true passion is adaptability - both in business and in personal life.
Ever wondered what your favorite vacation photo sounds like? In this episode, we dive into how Lyria 3 AI helps you find your creative voice by transforming inside jokes, memories, and images into custom audio. #AI#Lyria3#MadeByGoogle#TechPodcast
TL;DR: Syncfusion Code Studio can read your codebase and generate structured documentation automatically. You can control how that documentation is written using Custom Agents, and reuse documentation workflows using Skills. The result is clear, searchable documents that help new developers understand the system faster and avoid wasted work.
From codebase chaos to clear documentation
Imagine a new developer joining your team. They open your project and see 50 folders and 500 files in your project.
Then, they check the README, which says: “Start with auth, then payment, then notifications.”
But where are these modules exactly?
What functions do they export?
How do they interact with each other?
They have no idea.
So, they ask a senior engineer. Now, a senior engineer is spending an hour explaining code that should have been documented years ago. Or worse, the new hire misunderstands the system, ships a bug, or rebuilds something that already exists.
The real problem isn’t the code. It’s the lack of organized, readable documentation.
What if your entire codebase could explain itself?
That’s exactly what Syncfusion® Code Studio does. It automatically transforms your code into professional documentation that new developers can read within hours to understand your entire architecture.
What really breaks without good documentation
Here’s what actually happens when your codebase lacks organized documentation:
1. New hires are lost (Day 1 problem)
A new developer joins the team, clones the repository, and sees 500 files spread across dozens of files. There’s no organized documentation to guide them. They start reading random source code and still understand nothing. They interrupt seniors with a question, “What does this module do?” over and over.
2. Everyone rebuilds what already exists
Without documentation showing all existing modules and their APIs, developers end up rebuilding features that already exist. You might even discover three different implementations of the same thing, such as user authentication.
3. Onboarding takes weeks, not days
Slow onboarding kills productivity. Instead of contributing value in their first few days or weeks, new hires spend their time trying to figure out how the system works.
4. Bugs pile up because of misunderstandings
When developers don’t understand the architecture, mistakes are inevitable. A new engineer may not realize how error handling works and accidentally write code that fails silently instead of logging errors, leading to bugs that are hard to diagnose and fix.
All of this traces back to one issue: your codebase has knowledge, but it isn’t accessible.
Here’s the solution: Syncfusion Code Studio writes your code documentation automatically
Syncfusion Code Studio is an AI-powered integrated development environment (IDE) with built-in assistance to support modern software development workflows. It reads your entire codebase and automatically generates clear, structured documentation in just minutes.
To learn more about Code Studio, please visit our introduction blog.
Think of it this way: If your codebase is a messy library of 500 books, Code Studio reads all 500 books and then creates a completely well-organized library catalog automatically.
Without Code Studio:
New hires are confused and spend weeks reading raw source code.
Senior developers repeatedly explain the same concepts.
With Code Studio, you get:
Clear documentation that explains your entire system.
Beginner-friendly explanations that cover both what the code does and why it exists.
Powerful search, so developers can find what they need in seconds.
As a result, a new developer can read your documentation for just a few minutes and understand more than spending several days digging through unstructured code.
Prerequisites
Before we start, ensure you have:
Installed and configured Syncfusion Code Studio using our installation guide.
How Syncfusion Code Studio generates documentation using a custom agent
Syncfusion Code Studio can automatically read your codebase and generate documentation, but different teams need documentation in different styles. That’s where the Custom Agents come in.
Custom Agents let you control how documentation is written, who it’s written for, and how it’s structured.
What is a custom agent?
A custom agent is like a template or instructions that tells Code Studio exactly how to format and write your documentation.
Think of it this way:
Code Studio = A powerful AI that understands your codebase deeply.
Custom agent = A set of instructions (stored as a text file) that tells Code Studio how to write your documentation.
Why do you need a custom agent?
1. Different audiences need different documents
A senior engineer needs detailed technical explanations, while a junior developer needs simple, beginner-friendly guidance. Without a custom agent, Code Studio wouldn’t know which style to use. A custom agent tells it exactly who the document is for.
Example: “For this team, write for junior developers.”
2. Consistency
Without clear rules, documentation can become inconsistent over time. Custom agents ensure every generated document follows the same format, style, and structure.
3. Full control
You are not guessing what Code Studio will generate. You explicitly write the rules, so the output matches your expectations exactly.
4. Reusability
You create a custom agent once and reuse it whenever your code changes without rewriting instructions each time.
What actually happens (Step-by-step)
You create a custom agent (a text file with rules) such as “write for beginners, limit code to max 10 lines per code example, use analogies, avoid jargon”.
You tell Code Studio: “Generate documents for this project”.
Code Studio reads your codebase and your custom agent instructions.
Code Studio generates documentation exactly as you instruct.
Result: Documentation that matches your team’s needs perfectly.
The simple analogy:
Code Studio is an intelligent librarian who reads all your books and writes a summary.
Custom Agent is your instructions to that librarian (“Make the summary for beginners” or “Make it technical for experts“).
The librarian (Code Studio) does the work. Your instructions (custom agent) control the style and rules.
To learn more about custom agents, visit our documentation.
How to create a custom review agent in Code Studio
Follow these steps to create a custom agent that controls how Code Studio reviews or documents your code.
Step 1: Open chat panel
First, open the Code Studio chat panel using the Ctrl+Shift+I (Windows) or Cmd+Shift+I (macOS) shortcut key. This opens the chat view.
Step 2: Open the settings menu
In the chart view, click the gear icon in the top-right corner to open the settings menu.
Step 3: Navigate to custom agents
Select “Custom Agents” from the settings menu.
Step 4: Create a new agent
Click the Create new Custom agent button to start creating your agent.
Step 5: Choose where to save
Select where the agent should be stored:
.codestudio/agents → Available only for the current workspace.
User data → available across all your Code Studio workspaces.
Step 6: Name your agent
Next, enter a name such as “document-agent” and click “Create”.
Step 7: Define the agent instructions
Code Studio creates a text file called ‘document-agent.agent.md’. This is where you write your review instructions.
This file contains two main parts:
Header (optional, between lines): Add metadata such as the agent’s name and description, etc.
Body (required): Write the rules, instructions, and guidelines the agent should follow.
Save the file. Once saved, your custom agent will appear in the mode dropdown and be ready.
Code example for Documentgenerator.agent.md file:
---
description: Transform any codebase into beginner-friendly documentation and tutorials
name: Codebase Documenter
---
# Codebase Documenter Agent - Quick Reference
Transform complex code into clear, accessible documentation for beginners.
## Workflow (7 Stages)
1. **Analyze Repository**: Scan `*.py`, `*.js`, `*.ts`, `*.java` etc.; skip `node_modules/`, `tests/`, `.git/`; max ~100KB/file
2. **Identify Core Abstractions**: Find 5-10 key classes/functions with beginner-friendly names and analogies
3. **Analyze Relationships**: Map how abstractions interact; tie every abstraction to the architecture
4. **Determine Chapter Order**: Foundational concepts first, high-level to low-level
5. **Write Chapters**: Motivation, key concepts, usage examples (<10 lines), diagrams, cross-references; format: `{number:02d}_{safe_name}.md`
6. **Combine Into Tutorial**: Create `index.md` (architecture diagram + TOC) in `output/[project-name]/`
7. **Create `mkdocs.yml` & Serve**: Auto-generate config, install MkDocs, serve, and open in Simple Browser
## Key Guidelines
- **Tone**: Warm, beginner-friendly — use "you", avoid jargon, use real-world analogies
- **Code**: Max 10 lines per block; explain immediately after; no links to files outside `docs_dir` (use backticks instead)
- **Visuals**: Mermaid diagrams (`flowchart`, `sequenceDiagram`, `classDiagram`); max 5-7 elements
## MkDocs Setup (Always Do Automatically)
After writing docs, without waiting for the user, run these steps:
1. **Install** (if needed): `pip install mkdocs mkdocs-material`
2. **Create `mkdocs.yml`** at project root:
- `site_name` from project name; `docs_dir: output/[project-name]`
- `theme: material` with dark/light toggle, `navigation.tabs`, `search.highlight`, `content.code.copy`
- `pymdownx.superfences` with mermaid custom fence + `extra_javascript: [https://unpkg.com/mermaid@10/dist/mermaid.min.js]`
- `nav:` listing every chapter in order
3. **Serve**: Run `mkdocs serve` as a background terminal from project root
4. **Open**: Once `Serving on http://127.0.0.1:8000/` appears, open `http://127.0.0.1:8000/` in Simple Browser
## Quality Checklist
✅ All abstractions covered | ✅ Mermaid diagrams clear | ✅ Code blocks <10 lines | ✅ Beginner-friendly tone | ✅ Navigation links included | ✅ `mkdocs.yml` created | ✅ No broken links outside `docs_dir` | ✅ Simple Browser opened automatically
Note: What is MkDocs in the example instructions, and do you need it? MkDocs turns your generated .md files into a styled, browsable website, similar to converting plain text files into a mini documentation site.
It’s completely optional. Even without MkDocs, the AI still generates all documentation as .md files.
To skip MkDocs, remove the following three parts from the instructions before using them:
Stage 7 in the Workflow section.
The entire ## MkDocs Setup section.
In the Quality Checklist, remove the last three items:
How to use a custom agent for creating documentation in Code Studio
Once your custom agent is created, using it is simple:
Open the chat view using Ctrl+Shift+I (Windows/Linux) or Cmd+Shift+I (Mac) shortcuts.
Select your custom agent.
Type your prompt, such as “create documentation for this project.”
The agent will automatically:
Analyze your codebase and generate all documentation as .md files inside “output/[project-name]/.”
Serve the documentation as a local website and open it directly in Code Studio’s Simple Browser.
Refer to the following GIF for a better understanding.
Converting the codebase to documentation using a custom agent in Code Studio
Creating codebase documentation using Skills in Code Studio (Alternative approach)
You have learned one way to create documentation using Custom Agents. Code Studio also offers another approach: Skills.
Both methods achieve the same goal: automatically generate documentation from your codebase, but they work in different ways.
Skills are folders of instructions, scripts, and resources that Code Studio can load when needed to perform specialized tasks.
Skills vs Custom Agents: When to use which
Purpose
Custom Agents define a persona with tailored instructions, tool access, model preferences, and multi-step workflows. They are ideal for tasks such as planning, code reviews, or security audits.
The Skills bundle specialized workflows, including scripts, examples, and resources, for specific tasks.
Content format
Custom agents are .agent.md files containing YAML frontmatter followed by instructions.
Skills are directories that include a SKILL.md file (YAML header plus instructions) along with optional scripts or examples.
For example, if you need to generate technical API documentation, you can create a Technical Docs Skill once and reuse it across projects. Refer to the Skills in Code Studio documentation to learn how to create a skill.
Where Skills live (Understanding the folder structure)
Skills are folders stored in your project. You can save them in multiple locations. Common skill locations(you can use any of these locations to save your skill):
.github/skills/
.codestudio/skills/
.agents/skills/
Example structure (using .github/skills/):
your-project/
├── .github/
│ └── skills/
│ └── Your skill folder
│ ├── SKILL.md
│ ├── structure/ (optional)
│ │ └── your structure md file
│ └── template/ (optional)
│ └── your template md file
└── ... (your other files)
Example SKILL.md file:
---
description: Generate technical API documentation from your codebase
name: generate-technical-docs
---
# Generate Technical Documentation from Codebase
## What is This Skill?
Automatically extract technical documentation (API references) from your codebase by analyzing code structure, functions, classes, interfaces, and dependencies.
## When to Use
- Generate API references from your source code
- Document function signatures, parameters, and return types
- Create technical documentation for developers
- Auto-generate structured API docs for any codebase
# Technical Documentation Generator - Quick Reference
Extract and document all APIs from your codebase automatically.
## Workflow (4 Stages)
1. **Analyze Repository**: Scan `*.py`, `*.js`, `*.ts`, `*.java`, `*.cs` files; skip `node_modules/`, `tests/`, `.git/`; max ~100KB/file
2. **Extract Technical Metadata**: Find all functions, classes, interfaces, parameters, return types, dependencies
3. **Generate API Reference**: Create structured documentation following rules in `structure/technical-docs-structure.md`; format: `output/[project-name]/api-reference.md`
4. **Create `mkdocs.yml` & Serve**: Auto-generate config, install MkDocs, serve, and open in browser
## MkDocs Setup (Always Do Automatically)
After writing docs, without waiting for the user, run these steps:
1. **Install** (if needed): `pip install mkdocs mkdocs-material`
2. **Create `mkdocs.yml`** at project root with `docs_dir: output/[project-name]`
3. **Serve**: Run `mkdocs serve` as background terminal
4. **Open**: Once serving, open browser to `http://127.0.0.1:8000/`
## Quality Checklist
✅ All public APIs documented | ✅ Method signatures with types | ✅ File locations included | ✅ `mkdocs.yml` created | ✅ Docs served on localhost | ✅ Browser opened
## Additional Resources
- `structure/technical-docs-structure.md` - Rules and guidelines for what technical docs should include
- All docs generated in: `output/[project-name]/`
Note: Here the‘mkdocs’steps are also completely optional. Without it, the AI still generates all docs as .md files. I have added ‘structure/technical-docs-structure.md’ file as a reference for the structure that needs to be followed when creating technical docs. It’s also completely optional.
Example ‘structure/technical-docs-structure.md’ file:
# Technical Documentation Structure & Rules
## Purpose
For developers who need **API details, signatures, and integration info**. Focus on WHAT and HOW, not WHY or how-to guides.
## Required Sections
1. **Overview** - 1-2 sentence module description
2. **Classes & Interfaces** - All public classes with methods, parameters, return types
3. **Functions** - All exported functions with signatures and file locations
4. **Data Models** - Interfaces, types with exact code structure
5. **Dependencies** - External libraries and internal imports
## Tone & Style
- Technical, precise language
- Target: Senior/intermediate developers
- Code examples: signatures only, no implementation
- No beginner explanations, tutorials, or "why" sections
## What MUST Include
✅ Exact method signatures with types
✅ Parameter names and types
✅ Return types with descriptions
✅ File paths and line numbers
✅ All public APIs
✅ External dependencies
✅ Type definitions
## What NOT to Include
❌ Implementation details
❌ Internal/private methods
❌ Long code examples
❌ Tutorial steps or getting started guides
❌ Beginner-friendly explanations
❌ Philosophy or "why" sections
How to use a Skill
Once you’ve created a Skill in Syncfusion Code Studio, using it is simple and intuitive. Skills let you run predefined workflows, such as generating documentation, directly from the chat. The steps below show how to select a Skill and trigger it to run automatically.
Step 1: Open the Code Studio chat
First, open the Code Studio chat panel. Press Ctrl+Shift+I on Windows or Linux, or Cmd+Shift+I on macOS. This launches the chat interface where skills and agents are available.
Step 2: Find the Skill you want
Next, type / in the chat panel to display all available skills. Browse through the list and locate the skill you want to use.
Step 3: Select your Skill
Now, click on the skill you created or the one that best matches your task. Selecting the skill activates it and prepares Code Studio to follow its defined workflow.
Step 4: Enter your request
After selecting the skill, type your request in the chat input. For example, you can enter: “Generate technical documentation for this project” or any other instruction relevant to the skill.
Step 5: Review the output
Finally, the skill takes over. It analyzes your codebase, generates the output based on the skill’s purpose, serves the result on a local server, and opens it automatically in Code Studio’s simple browser. For a clearer understanding of this flow, refer to the accompanying GIF.
Creating codebase documentation using Skills in Code Studio
Best practices: Making your documentation excellent
To get the best results from Syncfusion Code Studio, especially if you’re new to automatic documentation generation, follow these best practices.
1. Start with one small piece, not everything
Resist the urge to document your entire codebase on day one. Instead:
Choose one module that is difficult to understand.
Generate documentation only for that module.
Share it with a new or recently onboarded developer and ask:
“Did this help you understand how this module works?”
Once you confirm it’s effective, expand documentation to the rest of the codebase.
This approach helps you validate quality early and avoid unnecessary rework.
2. Always check the generated documents yourself before sharing
After Code Studio generates documentation, take time to review it before sharing it with the team.
Read through the documentation completely.
Ensure it accurately reflects the current behavior and structure of your code.
A quick review ensures correctness and builds confidence in the generated output.
3. Create different documents for different people (using custom agents)
Not everyone on your team needs the same level or type of documentation. Use custom agents to tailor documentation for different audiences.
Junior developers: Beginner‑friendly explanations with clear examples.
Senior developers: Technical details, API references, and architecture deep dives.
Team leads: High‑level overviews that explain how systems fit together.
By using multiple custom agents, you can generate different documentation styles from the same codebase.
4. Get feedback from people who don’t know your code
The best feedback comes from people who haven’t memorized your system.
Share the documentation with someone who recently joined the team
Ask questions like:
“Was this easy to understand?” and “What felt unclear?”
Improve the documentation based on their feedback
This ensures your documentation truly supports onboarding and knowledge sharing.
Frequently Asked Questions
Is the generated documentation always accurate?
Code Studio analyzes your code and generates documentation, but you should always review the output yourself. Test all code examples, correct any inaccuracies or unclear explanations, and ask someone unfamiliar with your code to read it and provide feedback. Think of Code Studio as a powerful assistant that completes about 80% of the work, while you handle the final 20% through review and refinement.
Do I need MkDocs to use Code Studio’s documentation?
No. MkDocs is completely optional. Code Studio generates documentation as .md files regardless of whether you use MkDocs. MkDocs simply turns Markdown files into a styled documentation website. You can work directly with the generated .md files or use MkDocs if you want a more polished, professional documentation site.
Can Code Studio document legacy code or older projects?
Absolutely. Code Studio works with any codebase, regardless of its age or complexity.
How do I write a good Custom Agent rule for my team’s style?
Start by reviewing documentation you already like, whether from other projects or tools you admire. Identify what makes that documentation effective, such as simple language, clear structure, or well-chosen examples. Write those preferences explicitly as rules in your Custom Agent. For example, you might specify using simple words, limiting paragraphs to 100 words, or keeping code examples under 10 lines. Test the rules on a small module, then ask a teammate whether the result feels right. Refine the rules based on feedback and document them clearly so everyone on the team understands and follows the same documentation standards.
What if I have multiple Code Studio Custom Agents or Skills for different documentation types?
That is an excellent practice. You can create a Technical Docs Skill for API references, a Getting Started Guide Skill for onboarding new users, an Architecture Overview Agent for system design documentation, and an API Reference Skill for endpoint-level details. Each Skill or Agent analyzes the same codebase but produces a different type of documentation. Creating a separate Skill or Agent for each documentation style allows your team to choose the most appropriate one based on what they are documenting.
Ready to stop writing documentation manually?
Thanks for reading! Stop spending weeks writing and maintaining documentation. Syncfusion Code Studio reads your entire codebase and automatically generates professional documentation within minutes. It’s about creating complete, organized, searchable documentation that explains your entire system.
With Code Studio, you get:
Full documentation generated automatically: Architecture overviews, module guides, API references, code examples.
Professional, consistent format: Everything looks polished and organized.
Real onboarding speed: New developers become productive in days, not weeks.
The result: Your team spends less time explaining code and more time building features. New hires learn independently. Senior developers stay focused on building. Your entire team grows without burnout.
That’s the power of automatically converting your entire codebase into comprehensive documentation.
Ready to stop writing documentation manually? Download Syncfusion Code Studio today and see how your team can ship with confidence.
Log in
The real problem isn’t the code. It’s the lack of organized, readable documentation.
