CLAUDE.md and AGENTS.md examples library

localsend/localsend

An open-source cross-platform alternative to AirDrop

# CLAUDE.md

Always use **`fvm flutter`** / **`fvm dart`**, never the bare `flutter` / `dart` binaries — this repo pins its
Flutter version in `.fvmrc` and the system-wide toolchain will not match it.

Full guidance for this repository lives in AGENTS.md:

@AGENTS.md

heygen-com/hyperframes

Write HTML. Render video. Built for agents.

# Hyperframes

Open-source video rendering framework: write HTML, render video.

## Skills

This repo ships 21 AI agent skills via [vercel-labs/skills](https://github.com/vercel-labs/skills). Install them before writing compositions — they encode framework-specific patterns that generic docs don't cover. **Default to the core set**: the `/hyperframes` router installs each creation workflow on demand; install all 21 only when the user explicitly asks for the full set.

```bash
npx hyperframes skills update                         # default: installs/refreshes the core set — workflows install on demand
npx hyperframes skills                                # all 21 published skills at once — only on explicit request
npx skills add heygen-com/hyperframes                 # interactive picker (terminal only; --all also pulls the 6 repo-internal skills under .claude/skills)
npx skills add heygen-com/hyperframes --skill <name>  # just one (bare name, no leading slash)
```

`skills add` resolves the skills.sh registry blob, which can lag `main` by hours, so a freshly added skill may be a little behind. `npx hyperframes skills update` installs from the current `main`; prefer it when freshness matters.

**`/hyperframes` is the entry skill — read it first.** It's the capability map for the domain skills below, the intent layer that confirms every creation brief up front, AND the intent router for the creation workflows. The full README skills section mirrors this list; keep them in sync (see "Skill catalog maintenance" below).

### Creation workflows

- `/product-launch-video` — any **website** URL (or a pre-written script / text brief in no-capture mode) → a product launch / promo video, or a site tour / showcase featuring the site's own captured screens; up to ~3 min (sweet spot ~30-90s).
- `/faceless-explainer` — arbitrary text, **no URL and no website capture** → faceless explainer, up to ~3 min (sweet spot ~30-90s); every visual is LLM-invented (typography / abstract graphics / diagram / data-viz).
- `/pr-to-video` — a GitHub PR (URL / `owner/repo#N` / "this PR") → code-change explainer, up to ~3 min (changelog / feature reveal / fix / refactor). A PR link, not a product website.
- `/embedded-captions` — an existing talking-head video (MP4) → the same footage with captions / subtitles added (verbatim rail + embedded climax, or pure-cinematic embed); the footage itself is untouched (no NLE-style editing).
- `/talking-head-recut` — an existing talking-head / interview / podcast video (MP4) → the same footage packaged with designed **graphic overlays** (kinetic titles, lower-thirds, data callouts, pull-quotes, side panels, PiP) synced to the transcript; the clip plays unchanged underneath, footage untouched. For plain captions/subtitles → `/embedded-captions`.
- `/motion-graphics` — a short (typically under 10s) design-led **motion graphic**, motion-is-the-message, no narration: kinetic type, a stat / number count-up, a chart, a logo sting, a lower-third / overlay, or an animated tweet / headline / captured-page highlight; rendered to MP4 or a transparent overlay. Longer / narrated / custom → `/general-video`.

sickn33/agentic-awesome-skills

AAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,400+ agentic skills. Includes CLI, local MCP, catalo

block/buzz

A hive mind communication platform

davila7/claude-code-templates

CLI tool for configuring and monitoring Claude Code

agentsmd/agents.md

AGENTS.md — a simple, open format for guiding coding agents

QwikDev/qwik

Instant-loading web apps, without effort

# Qwik v2 agents reference, instructions and rules

> [!IMPORTANT]
> **ALWAYS RUN `ruler apply` AT THE START OF A SESSION.** The agent skills are gitignored, not
> committed, so a fresh clone/worktree has none until you generate them (once per worktree):
>
> ```bash
> pnpm dlx @intellectronica/ruler@0.3.42 apply --no-gitignore --no-mcp
> ```

> Canonical source for repo-wide AI coding agent rules. For contributor setup, see
> [CONTRIBUTING.md](./CONTRIBUTING.md). For package-specific workflows, load the relevant
> `.ruler/skills/*/SKILL.md` file.

## Source Of Truth

- Shared AI guidance lives in `.ruler/`.
- Only the root `AGENTS.md` and `CLAUDE.md` are committed generated outputs; the `.claude/`/`.codex/`
  skill copies are gitignored and regenerated locally with `ruler apply` (see Setup below).
- Never hand-edit a generated output — edit `.ruler/` and regenerate with `ruler apply`. A CI check
  re-runs it and fails if the committed root files drift.
- To change assistant behavior, edit `.ruler/AGENTS.md`, `.ruler/README.md`, or `.ruler/skills/**`,
  then regenerate with Ruler when needed.

## Project Snapshot

Qwik is a resumable web framework. SSR serializes application and framework state into HTML, and
the client resumes without re-running component code. Qwik v2 is a rewrite with VNode-based
runtime work, rewritten reactive primitives, a new serialization mechanism, and package names under
`@qwik.dev/*`.

Key concepts: resumability, QRLs, `$`-suffixed optimizer boundaries, fine-grained signals, VNodes,
the cursor system, and the Rust optimizer.

## Monorepo Map

- Base branch and release branch for v2 PRs: `main`. V1 lives on the `v1` branch.

| Package | Path | Notes |
| --- | --- | --- |
| `@qwik.dev/core` | `packages/qwik` | Core runtime, SSR, optimizer-facing code |
| `@qwik.dev/router` | `packages/qwik-router` | Routing, middleware, adapters, SSG |
| `@qwik.dev/react` | `packages/qwik-react` | React integration |
| `@qwik.dev/utils` | `packages/qwik-utils` | Less-common helpers (`usePoll`, `zod$`), may use qwik internals |
| `@qwik.dev/dom` | `packages/qwik-dom` | Server-side DOM implementation |
| `@qwik.dev/qwik-vite` | `packages/qwik-vite` | `vite-plugin-qwik`, private, bundled into `@qwik.dev/core/optimizer` |
| `@qwik.dev/ts-optimizer` | `packages/ts-optimizer` | TypeScript optimizer, private, bundled into `@qwik.dev/core/optimizer` |
| `@qwik.dev/optimizer` | `packages/optimizer` | Rust optimizer, WASM, NAPI bindings; kept for parity comparison |
| `eslint-plugin-qwik` | `packages/eslint-plugin-qwik` | ESLint rules |
| `create-qwik` | `packages/create-qwik` | Project scaffolding CLI |
| `qwik-docs` | `packages/docs` | Docs site, private package |
| `insights` | `packages/insights` | Analytics dashboard, private package |

Use v2 package names (`@qwik.dev/core`, `@qwik.dev/router`, etc.). Do not introduce v1
`@builder.io/qwik` or `@builder.io/qwik-city` imports except when working on explicit
compatibility override code.

## Setup And Iteration Loop

This is the canonical loop for nearly all framework work. Default to it; do not substitute broader
commands:

### getting started

```bash
pnpm i
```

```bash

iflytek/astron-agent

Enterprise-grade, commercial-friendly agentic workflow platform for building next-generation SuperAgents.

securego/gosec

Go security checker

openclaw/gogcli

Google Workspace in your terminal.

# Repository Guidelines

## Project Structure

- `cmd/gog/`: CLI entrypoint.
- `internal/`: implementation (`cmd/`, Google API/OAuth, config/secrets, output/UI).
- Tests: `*_test.go` next to code; opt-in integration suite in `internal/integration/` (build-tagged).
- `bin/`: build outputs; `docs/`: specs/releasing; `scripts/`: release helpers + `scripts/gog.mjs`.

## Build, Test, and Development Commands

- `make` / `make build`: build `bin/gog`.
- `make tools`: install pinned dev tools into `.tools/`.
- `make fmt` / `make lint` / `make test` / `make ci`: format, lint, test, full local gate.
- Optional: `pnpm gog …`: build + run in one step.
- Hooks: `lefthook install` enables pre-commit/pre-push checks.

## Coding Style & Naming Conventions

- Formatting: `make fmt` (`goimports` local prefix `github.com/openclaw/gogcli` + `gofumpt`).
- Output: keep stdout parseable (`--json` / `--plain`); send human hints/progress to stderr.
- Gmail labels: treat label IDs as case-sensitive opaque tokens; only case-fold label names for name lookup.

## Testing Guidelines

- Unit tests: stdlib `testing` (and `httptest` where needed).
- Integration tests (local only):
  - `GOG_IT_ACCOUNT=you@gmail.com go test -tags=integration ./internal/integration`
  - Requires OAuth client credentials + a stored refresh token in your keyring.

## Commit & Pull Request Guidelines

- Create commits with `committer "<msg>" <file...>`; avoid manual staging.
- Follow Conventional Commits + action-oriented subjects (e.g. `feat(cli): add --verbose to send`).
- Group related changes; avoid bundling unrelated refactors.
- PRs should summarize scope, note testing performed, and mention any user-facing changes or new flags.
- PR review flow: when given a PR link, review via `gh pr view` / `gh pr diff` and do not change branches.
- Maintain `CHANGELOG.md`: add user-visible changes to `Unreleased` as fixes and features land, with PR/issue references and contributor thanks. Finalize that section at release; do not put later work under an already published version. The release-time-only changelog exception for `openclaw/openclaw` does not apply to this repository.

### PR Workflow (Review vs Land)

- **Review mode (PR link only):** read `gh pr view/diff`; do not switch branches; do not change code.
- **Landing mode:** temp branch from `main`; bring in PR (squash default; rebase/merge when needed); fix; update `CHANGELOG.md` (PR #/issue + thanks); run `make ci`; final commit; merge to `main`; delete temp; end on `main`.
- If landing contributor work, always add `Co-authored-by:` trailers for PR authors, even when we partially rewrite, group, or manually apply their changes; leave a PR comment with what landed + SHAs.
- New contributor: thank in `CHANGELOG.md` (and update README contributors list if present).

## Security & Configuration Tips

- Never commit OAuth client credential JSON files or tokens.
- Prefer OS keychain backends; use `GOG_KEYRING_BACKEND=file` + `GOG_KEYRING_PASSWORD` only for headless environments.

readthedocs/readthedocs.org

The source code that powers readthedocs.org

# AI Instructions for Read the Docs

This file lives in the `common` repo,
and is copied to each production repo.
Agents don't work with symlinks or submodules,
so this is best for now.

## Team interaction

We want all interaction in public to be between real people.

* **Never** comment on pull requests, commits, or other things as the user.
* Make all public-facing copy like commit messages and pull request descriptions for the reader, and not the author.
* Ensure everything is optimized for clarify, conciseness, and effective communication.

## Project Overview

Read the Docs is a documentation hosting platform that builds and hosts documentation for open source projects.
It supports multiple documentation tools (Sphinx, MkDocs, etc.) and automatically builds documentation from Git repositories.

**Technology Stack:**
- Python 3.14
- Django web framework
- Docker and Docker Compose for development
- PostgreSQL database
- Elasticsearch for search
- Redis for caching and Celery for background tasks

## Commits

* Use short descriptive commit messages
* Only provide simple context, and don't be overly verbose
* Always run `pre-commit run --files <changed files>` before committing to ensure code passes all checks

## Pull Requests

* Make the PR description as useful as possible for humans; lead with the most important context.
* Always open pull requests as drafts
* Note in a footer that the PR was generated by an AI agent, but only if no such footer is already appended automatically — never add a second one
* Use feature branches for all changes
* Write the description about *why*: the problem it solves, the approach taken, and anything a reviewer should double-check. Don't restate *what* changed — no "Changes" section, changelog, file lists, or per-change bullets — since the diff already shows that. Prefer "Sharpens the PR rules, which kept producing diff-restating descriptions" over "Reworded one bullet, fixed a typo, removed two sections."
* Don't include Test Plan unless absolutely necessary.
* Link related issues in the PR description, if there are any in the chat context
* Prefix pull request titles, example `Api:`, `Builds:`, or `Docs:`.

## Package Management

- Always use `uv` for Python package management and virtual environment operations
- Use `uv pip install` instead of `pip install`
- Use `uv run` to execute Python scripts in the virtual environment

## Docs

* Follow the style guide at https://github.com/readthedocs/readthedocs.org/blob/main/docs/dev/style-guide.rst.
* Always use the marketing name used in the public-facing docs, and not the internal code names referenced in code.
* The ``user`` directory is public docs, and ``dev`` is dev-focused. Most of what we do is focus on the user-facing docs.

## Website copy

- Direct, second-person voice. No jargon. Less is more.
- Focus on user benefit, not abstract positioning.
- Don't repeat facts within a section; use standard terminology (e.g. "files changed", "pull request").

## Testing

- Use `pytest` with the `assert foo == bar` assertion style
- Keep the test DB warm with `pytest --reuse-db` to speed up runs

### Running tests locally

joemccann/dillinger

The last Markdown editor, ever.

<claude-mem-context>
# Recent Activity

<!-- This section is auto-generated by claude-mem. Edit content outside the tags. -->

### Jan 19, 2026

| ID | Time | T | Title | Read |
|----|------|---|-------|------|
| #1873 | 2:32 PM | 🔵 | Next.js Migration Dependency Stack with Modern Equivalents | ~510 |
| #1861 | 2:25 PM | 🔵 | Next.js Config with Lucide-React Bundle Optimization | ~396 |
| #1850 | 2:24 PM | ✅ | Added Modal and Toast Z-Index Layers to Tailwind Configuration | ~354 |
| #1827 | 2:22 PM | 🔵 | Tailwind Configuration with Legacy Dillinger Design Tokens | ~463 |
</claude-mem-context>

# Dillinger Next.js - CLAUDE.md

> Cloud-enabled, mobile-ready, offline-storage-compatible Markdown editor built with Next.js 14.

## Quick Reference

```bash
npm run dev      # Start dev server (http://localhost:3000)
npm run build    # Production build
npm run start    # Start production server
npm run lint     # Run ESLint
```

## Tech Stack

| Category | Technology | Version |
|----------|------------|---------|
| Framework | Next.js (App Router) | 14.2.35 |
| Language | TypeScript (strict) | 5.x |
| UI | React | 18.x |
| Styling | Tailwind CSS | 3.4.1 |
| State | Zustand | 5.0.10 |
| Editor | Monaco Editor | 4.7.0 |
| Icons | Lucide React | 0.562.0 |
| Markdown | markdown-it + plugins | 14.1.0 |

## Architecture Overview

```
dillinger/
├── app/                    # Next.js App Router
│   ├── api/               # API route handlers
│   │   ├── github/        # GitHub OAuth + file ops
│   │   ├── dropbox/       # Dropbox integration
│   │   ├── google-drive/  # Google Drive integration
│   │   ├── onedrive/      # Microsoft OneDrive
│   │   ├── bitbucket/     # Bitbucket integration
│   │   ├── medium/        # Medium publishing
│   │   └── export/        # PDF/HTML export
│   ├── layout.tsx         # Root layout (providers)
│   ├── page.tsx           # Main editor page
│   ├── globals.css        # Global styles + Tailwind
│   ├── error.tsx          # Error boundary
│   └── not-found.tsx      # 404 page
├── components/
│   ├── editor/            # Monaco editor wrapper
│   ├── preview/           # Markdown preview pane
│   ├── navbar/            # Top navigation
│   ├── sidebar/           # Document list + integrations
│   ├── modals/            # OAuth dialogs (GitHub, Dropbox, etc.)
│   ├── providers/         # Context providers
│   └── ui/                # Reusable primitives (Toast, Skeleton)
├── hooks/                 # Custom React hooks
│   ├── useGitHub.ts
│   ├── useDropbox.ts
│   ├── useGoogleDrive.ts
│   ├── useOneDrive.ts
│   ├── useBitbucket.ts
│   └── useMedium.ts
├── stores/
│   └── store.ts           # Zustand store (documents, settings, UI)
├── lib/                   # Utilities and helpers
└── types/                 # TypeScript type definitions
```

## Code Conventions

### TypeScript

- **Strict mode enabled** - all code must pass strict type checking
- Use `interface` for object shapes, `type` for unions/intersections
- Prefer explicit return types on exported functions
- Use path alias `@/*` for imports from project root

```typescript