SnapDoczilla

Skills by Julio Varas

English · Español

Agent skills I use on real projects. Small, readable, easy to adapt. They follow the open Agent Skills format (SKILL.md), so they work in Claude Code first and also in Codex, OpenCode, Antigravity, Gemini CLI and other agents.

Skills

A component page generated by SnapDoczilla: real usage and real source, pulled from the repo on every build.

Installation (30-second setup)

Two options. The Claude Code plugin is a managed bundle that updates when I ship. skills.sh copies editable files into your project, for any agent. Pick one: installing both gives you every skill twice.

Claude Code (plugin)

claude plugin marketplace add julvc/skills

claude plugin install snapdoczilla@juliovc

Or from inside a session:

/plugin marketplace add julvc/skills

/plugin install snapdoczilla@juliovc

Invoke it with /snapdoczilla:snapdoczilla, or just ask *"document this project"*: Claude picks it up on its own.

Codex, OpenCode, Antigravity, Gemini CLI and other agents

npx skills@latest add julvc/skills

Pick the skills and the agents to install them on. Or install one skill on one agent with no prompts:

npx skills@latest add julvc/skills --skill snapdoczilla -a codex -y

Agent ids: claude-code, codex, opencode, antigravity, gemini-cli. Add -g to install globally instead of in the current project.

Manual (no tooling)

Copy skills/snapdoczilla/ into your agent's skills folder:

MCP server (Claude Desktop, Cursor and any MCP client)

Prefer MCP over skills, or your client has no skills support? SnapDoczilla also ships as a local MCP server (stdio, Python). The agent still writes the docs from your code; the server does the deterministic parts: install, "what changed since the last documented commit", safe page writes and the strict build.

claude mcp add snapdoczilla -- uvx snapdoczilla-mcp

Claude Desktop, Cursor and other mcpServers clients:

{

"mcpServers": { "snapdoczilla": { "command": "uvx", "args": ["snapdoczilla-mcp"] } } }

Codex CLI (~/.codex/config.toml):

[mcp_servers.snapdoczilla]

command = "uvx" args = ["snapdoczilla-mcp"]

Needs uv, git and bash (on Windows: Git for Windows). The server does not read your code: your client does with its own file tools (in Claude Desktop, add a filesystem server). Use the MCP server or the skill in a given agent, not both.

It also exposes the prompt document_project. Then just ask: *"Document this project"*.

SnapDoczilla: step by step

What you get: a documentation/ folder in your repo. Anyone opens documentation/html/index.html with a double click: search and diagrams included, no install, no internet. Docs can't drift from code: pages embed the real source files on every build. See a full result in examples/shop (an Express API + React app; download the repo and open examples/shop/documentation/html/index.html).

Scope. It documents what lives in the repo, for any stack: Spring, Node (Express/Nest), Python (FastAPI/Django/Flask), .NET, Go, PHP, Ruby; Vue, React, Angular, Svelte.

It does not take screenshots, run live demos, host anything or replace your OpenAPI/Swagger. Docs are written in the language you choose (English by default).

Requirements. To read: a browser. To generate/update: Git (with bash; on Windows, Git for Windows), Python 3 and an agent.

1. Install the skill

See Installation.

2. Ask your agent, inside your repo

Document this project

The agent detects your areas (e.g. back=backend/, front=frontend/), installs the scaffolding, writes the first pages from your real code, builds the site and checks the diagrams. It never commits.

3. Read it

Open documentation/html/index.html.

4. Review and commit

Check git diff, fix anything flagged as *to be confirmed* and commit documentation/ (including html/, so readers need nothing installed).

5. Keep it updated (any dev, one command)

./documentation/update.sh              # all areas

./documentation/update.sh --front # one area ./documentation/update.sh --html-only # rebuild the HTML only, after editing .md by hand

On Windows, double-click documentation\update.cmd. Only what changed since the last sync goes to the agent. A pre-push hook reminds you (never blocks) when code changed without docs.

Claude Code is the default. Using another agent? Set DOCS_LLM:

Or ask your agent *"update the docs"* inside a session. That works with every agent, Antigravity included.

6. Document a component

Add a SnapDoczilla page for the Button component

You get what it is, how it works, props/events/slots, a real usage example from your app and the real source code.

7. Working under CMMI? Use the cmmi profile

Document this project with SnapDoczilla using the CMMI profile

Same flows, plus a Process evidence page that maps CMMI practice areas (TS, DAR, PI, RDM, VV, PR, CM, PQA, OT, PAD) to the evidence in your repo, a *Requirement → Code → Tests → Page* traceability matrix and a baselines table per release tag. ADRs follow DAR (criteria + alternatives). Requirement IDs come only from real commits, branches or issues. The docs support an appraisal; they never claim compliance. Script: install.sh " " cmmi. MCP: snapdoczilla_install with profile: "cmmi".

8. Need a user manual? Add it on any profile

Write the user manual for this app with SnapDoczilla

Adds a User manual section for the people who use the app: requirements, first steps, a screen map and one page per function with numbered steps, the exact button and field labels, the expected result and a *Message → Cause → What to do* table built from the real messages in the UI code. Screenshots are left as placeholders (img/ -NN.png) for a human to capture. With the cmmi profile the manual is also referenced as OT/VV evidence. Script: add-manual.sh . MCP: snapdoczilla_add_manual.

Architecture page, dark mode, diagram rendered offline.

SnapDoczilla or Docusaurus?

They solve different problems. Docusaurus is an engine to build a site you write by hand. SnapDoczilla is a workflow: your agent writes the docs from the code and keeps them in sync.

Pick Docusaurus for a public product site with versions and many languages. Pick SnapDoczilla to make any codebase understandable to your team, today, and keep it that way.

Publish on the web (optional)

documentation/html/ is a static site. To serve it with GitHub Pages, add .github/workflows/docs.yml to your repo and set *Settings → Pages → Source* to GitHub Actions:

name: docs

on: push: branches: [main] paths: [documentation/html/**] permissions: { contents: read, pages: write, id-token: write } jobs: deploy: runs-on: ubuntu-latest environment: github-pages steps:

• uses: actions/checkout@v4
• uses: actions/upload-pages-artifact@v3 with: { path: documentation/html }
• uses: actions/deploy-pages@v4

What gets added to your repo

documentation/

├── source/ # ed