#Deployment #Emit/Static Site Deploy a Scraps site to GitHub Pages using GitHub Actions. The build output (_site/ by default; configurable in Configuration#root-level) is uploaded as a Pages artifact and published via the official actions/deploy-pages action — no gh-pages branch required. GitHub settings Set up GitHub Pages for the repository. Build and deployment parameter as follows: Source: GitHub Actions Workflow file Prepare a YAML file under .github/workflows/ like this: name: Deploy scraps github pages on: push: branches: - main workflow_dispatch: permissions: contents: read pages: write id-token: write concurrency: group: pages cancel-in-progress: false jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v6 with: fetch-depth: 0 # For scraps git committed date - name: Setup Scraps uses: boykush/scraps@v1 - name: Build run: scraps build - name: Configure Pages uses: actions/configure-pages@v5 - name: Upload artifact uses: actions/upload-pages-artifact@v3 with: path: _site deploy: needs: build runs-on: ubuntu-latest environment: name: github-pages url: ${{ steps.deployment.outputs.page_url }} steps: - name: Deploy to GitHub Pages id: deployment uses: actions/deploy-pages@v4 The boykush/scraps action installs the matching CLI binary from GitHub Releases. Pin to a specific tag (@v1.0.0) or to a SHA with a version comment for Renovate-managed updates: - uses: boykush/scraps@<sha> # v1.0.0 If your output_dir differs from _site/, update the path: in the upload-pages-artifact step to match.

#Integration #Emit/CLI JSON Scraps integrates with AI assistants in two ways. CLI + JSON is the primary path because shell commands plus structured output are the lowest-friction contract any agent can use. MCP is supported for clients that expect Model Context Protocol tools. CLI + JSON (recommended) Any assistant with shell access can query Scraps without a long-running server. ❯ scraps search "rust cli" --logic and --json ❯ scraps get "Getting Started" --json ❯ scraps get "Getting Started" --heading "Install" --json body ❯ scraps get "Getting Started" --json code_blocks ❯ scraps get "Getting Started" --json images ❯ scraps links "Getting Started" --json ❯ scraps backlinks "Configuration" --json ❯ scraps tag list --json ❯ scraps todo --status all --json scraps get --json defaults to title, ctx, and body. It can project specific fields (title, ctx, body, headings, code_blocks, images) so an agent can avoid loading full bodies when it only needs structure or examples. scraps links --json returns outbound link and embed references with optional heading targets; backlinks stays a scrap-level inbound lookup. The full command map is in CLI Overview. Each command's --help documents flags and JSON shape. Bundled AI skills and agents For Claude Code and Codex users, the official scraps plugin packages Karpathy-style Ingest / Query / Lint workflows around the CLI. The Claude Code agents add purpose-driven lint handling and a default Scraps LLM Wiki schema grounded in the official docs: https://github.com/boykush/scraps/tree/main/plugins/scraps Skill / Agent Role /ingest Add a new scrap from a prompt, URL, or markdown; update cross-links /query Answer a question against the wiki with [[Title]] citations lint-rule-handler agent Purpose-driven wiki health checks, one or a few rules at a time scraps-llm-wiki-schema agent Explain Scraps tool usage from the official docs and map LLM Wiki practice to ingest, query, and lint-rule-handler Install instructions live in the plugin README so that marketplace browsers have everything in one place. MCP (for MCP-compatible clients) Scraps ships an MCP server for clients that prefer the Model Context Protocol. The server is bundled as a plugin so installation and tool specifications stay together: https://github.com/boykush/scraps/tree/main/plugins/mcp-server To wire the MCP server into Claude Code manually without the plugin: claude mcp add scraps -- scraps -C ~/path/to/your/wiki mcp serve Replace ~/path/to/your/wiki with the directory containing .scraps.toml. For most read-shaped agent workflows, the CLI + JSON path above is simpler: no long-running process, no MCP client implementation required, works with any shell-capable agent. MCP is the right choice when your agent already expects MCP tools as its integration surface.

#Emit/Static Site The static site is one of the emit targets Scraps compiles to. The other first-class target is JSON from CLI Overview. See What is Scraps?#more-than-a-static-site-generator for why Scraps decenters SSG from its narrative while keeping the HTML output fully supported. Pipeline ![[Reference/Static Site/Pipeline]] Output structure ![[Reference/Static Site/Output Structure]] README and the index page ![[Reference/Static Site/README and Index]] Search index ![[Reference/Static Site/Search Index]] Color scheme ![[Reference/Static Site/Color Scheme]] Tag pages ![[Reference/Static Site/Tag Pages]] Sort and pagination ![[Reference/Static Site/Sort and Pagination]] Configuration schema The full schema lives in Configuration ([ssg] and root level); the same [ssg] block is embedded below for in-place reading. ![[Reference/Configuration#ssg-section]]

#Emit/Static Site graph LR Source[Markdown sources] --> IR[Scraps IR] IR --> HTML[Static HTML] IR --> JSON[CLI JSON] HTML --> Pages[GitHub Pages, Cloudflare Pages, ...] The HTML emitter takes the Scraps IR and produces a static directory tree, which any Pages-class host can serve. See Deploy to GitHub Pages for one such recipe.

#Emit/Static Site README.md at the wiki root is special-cased: it becomes index.html instead of scraps/readme.html. This lets the wiki render correctly both on the static site and directly on GitHub. One limitation: autolinks inside the wiki root README.md fall back to plain links — the OGP card is suppressed on the index page.

#Emit/Static Site Build output is written to the directory configured by output_dir (default _site/). ❯ tree _site _site ├── index.html # README.md or scrap index ├── scraps/ │ ├── getting-started.html │ └── guide/ │ └── links.html ├── main.css └── search_index.json # when build_search_index = true Each Markdown file is converted to a slugified HTML file under scraps/. Folders become path segments — the same folders that form Context Link. Files in static/ and the build output directory are excluded from scrap traversal.

#Emit/Static Site Each #[[tag]] referenced by at least one scrap gets a generated index page listing all scraps that reference it. Nested tags (#[[a/b/c]]) auto-aggregate to their parents — see Nested Tag.

#Emit/Static Site The wiki index page is sorted by committed_date (default) or linked_count, and optionally paginated. Configure sort_key and paginate_by under [ssg] in Configuration.

#Emit/Static Site When build_search_index = true (the default), the build emits search_index.json in the Fuse.js JSON shape and the static site mounts a search UI backed by it. [ { "title": "Getting Started", "url": "https://example.com/scraps/getting-started.html" }, { "title": "Configuration", "url": "https://example.com/scraps/configuration.html" } ] Search is scoped to the static site — it powers the in-page search box for human readers. Agent-side search is scraps search --json and is independent of this index. Set build_search_index = false in Configuration to skip both the index and the UI.