From marsai-dev-team
Generates or audits llms.txt files for V4-Company repositories following the llmstxt.org specification. Creates LLM-friendly entry points that help AI agents, coding assistants, and chat models understand a project quickly without parsing full HTML docs. Also generates CLAUDE.md / AGENTS.md when missing.
npx claudepluginhub v4-company/marsai --plugin marsai-dev-teamThis skill uses the workspace's default tool permissions.
This skill generates AI-friendly entry point files for V4-Company repositories:
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
This skill generates AI-friendly entry point files for V4-Company repositories:
These files solve different problems:
| File | Audience | Purpose |
|---|---|---|
| llms.txt | Any LLM (ChatGPT, Gemini, Perplexity, coding agents) | Structured overview: what the project is, key docs, API refs |
| CLAUDE.md | Claude Code, Anthropic agents | How to work in the codebase: build, test, lint, conventions |
| AGENTS.md | Any coding agent | Same as CLAUDE.md but vendor-neutral |
Scan the repository to gather context:
1. Read README.md — project name, description, purpose
2. Read CONTRIBUTING.md — build, test, lint instructions (if exists)
3. Read Makefile / package.json — build system, language, dependencies
4. Scan /docs/ or /documentation/ — available documentation
5. Scan /api/ or OpenAPI specs — API surface
6. Read existing llms.txt / CLAUDE.md / AGENTS.md (if mode=audit)
7. Identify: language, architecture pattern (DDD, hexagonal, etc.), test framework
MUST follow the llmstxt.org specification exactly:
# {Project Name}
> {One-line description. Key information: language, what it does, license.}
{Optional paragraph with more detail — architecture, key concepts, domain terminology
that an LLM needs to understand to work with this project.}
## Docs
- [{Doc title}]({url}): {Brief description of what this doc covers}
- [{Doc title}]({url}): {Brief description}
## API Reference
- [{API name}]({url}): {What this API covers}
## Code
- [{Key module}]({path or url}): {What this module does}
- [{Key module}]({path or url}): {What this module does}
## Optional
- [{Secondary resource}]({url}): {Description}
| Rule | Detail |
|---|---|
| H1 is project name | REQUIRED. Only one H1. |
| Blockquote is summary | REQUIRED. One paragraph, concise. Must include language and license. |
| Sections are H2 | Each H2 contains a list of links with optional descriptions |
| Links are markdown | [title](url): description format |
| Optional section | URLs here can be skipped for shorter context windows |
| No H3+ headings | Spec only allows H1, H2, and content between them |
| File must be in repo root | /llms.txt path |
| Keep it concise | Target: fits in ~2K tokens. Not a full docs dump. |
MUST include:
MUST NOT include:
CLAUDE.md is read by Claude Code at session start. It must be actionable:
# {Project Name}
## Quick Start
{How to build and run locally — exact commands}
## Testing
{How to run tests — exact commands, including single-test commands}
## Linting & Formatting
{Lint/format commands. CI expectations.}
## Architecture
{Brief architecture description: layers, key directories, patterns used}
## Key Conventions
{Naming conventions, error handling patterns, logging patterns, etc.}
## Common Pitfalls
{Things that trip up new contributors or AI agents}
| Rule | Detail |
|---|---|
| Commands must be copy-pasteable | No placeholders, no "run your test framework" |
| Architecture must name directories | "Business logic in /internal/domain/" not "business logic layer" |
| Conventions must have examples | "Functions use camelCase: processTransaction" not "use camelCase" |
| Keep it under 3K tokens | Agent context is expensive — be dense, not verbose |
AGENTS.md is identical in structure to CLAUDE.md but uses vendor-neutral language. If the project already has CLAUDE.md, AGENTS.md can reference it:
# {Project Name} — Agent Instructions
See [CLAUDE.md](./CLAUDE.md) for full development instructions.
## Additional Notes
{Any agent-specific notes not in CLAUDE.md}
If no CLAUDE.md exists, AGENTS.md follows the same template as Step 3.
When mode=audit or mode=full, check existing files against these criteria:
| Check | Pass Criteria |
|---|---|
| Exists at repo root | /llms.txt present |
| Has H1 | Project name as H1 |
| Has blockquote summary | > block after H1 |
| Has at least one H2 section | With linked resources |
| Links are valid | URLs resolve (non-404) |
| Concise | Under ~2K tokens |
| Accurate | Description matches current state of the project |
| Check | Pass Criteria |
|---|---|
| Exists at repo root | File present |
| Build commands work | Commands are valid for current build system |
| Test commands work | Test commands match current test framework |
| Architecture matches | Directory references match actual structure |
| No stale references | No references to removed files/modules |
## Audit Results
**Repository:** {name}
**Result:** [PASS|PARTIAL|FAIL]
| File | Status | Issues |
|------|--------|--------|
| llms.txt | [EXISTS/CREATED/MISSING] | {issues or "None"} |
| CLAUDE.md | [EXISTS/CREATED/MISSING] | {issues or "None"} |
| AGENTS.md | [EXISTS/CREATED/MISSING] | {issues or "None"} |
## Files Generated
| File | Action | Size |
|------|--------|------|
| llms.txt | [CREATED/UPDATED/UNCHANGED] | {tokens} |
| CLAUDE.md | [CREATED/UPDATED/UNCHANGED] | {tokens} |
| AGENTS.md | [CREATED/UPDATED/UNCHANGED] | {tokens} |
## Next Steps
{What remains to be done — PRs to open, links to verify, docs to write}