Start here
A little guidance. A lot to build.

GitCafe documentation

Create repositories, collaborate on changes, and manage your account and organizations.

Start with creating a repository or importing from GitHub. Coding agents and other tools can start with What can I do with GitCafe?.

Paths such as /settings/account are relative to your GitCafe site. Replace <owner>, <repo> and similar placeholders with your own values. Some features require your instance operator to enable an integration; the relevant guide explains what is available and what to expect when it is unavailable.

Find and read content

Use Search GitCafe in the site navigation to search published guides, public people by handle prefix and, when signed in, repositories you can access by name prefix. This is not global code or issue search; use a repository's search tools for those. A failed search source does not hide other results.

Guides, legal pages and supported resource pages can also be read as Markdown: send Accept: text/markdown or append ?format=markdown to the page URL. Keep existing query parameters and add &format=markdown when needed. A known page without the requested representation returns 406. A missing route returns 404; adding ?format=markdown does not make an unknown route available. Sign-in-required workflows return 401. Private resources may return 404 to conceal their existence. Authentication and private repository concealment apply equally to HTML and Markdown.

Root /llms.txt indexes every published guide and site page as Markdown, and /llms-full.txt contains all of them in one file. A repository's /<owner>/<repo>/llms.txt gives its metadata, a bounded default-branch root tree, the README's opening and where to go next. These are reading aids, not complete repository exports. The site sitemap contains public site pages, not private repositories.

Resource Markdown covers repository/profile summaries, source trees and files, commits/history, issues, pulls, stacks, branches and tags. Issue/pull lists default to open items, as the browser does. Detail pages include authored bodies; discussion, reviews and checks link to the browser rather than being copied. Pull-request commits and text patches have bounded Markdown documents. Lists are bounded: history 100 commits, issue/pull/stack 30 rows, owner repositories 20 rows and refs 100 rows; a tree document lists the whole directory. Follow the document's next-page link where it has one; a history document names the API cursor that continues it. Unsupported browser filter combinations do not advertise a Markdown alternate. Oversized or unsupported README previews show an explicit notice and snapshot link without hiding the repository overview.

Follow repository URLs

Start with /<owner>/<repo>/llms.txt and follow its resource links. They select Markdown explicitly, so no custom request headers are needed. Source URLs use /<owner>/<repo>/tree/<revision>/<path> for directories and /<owner>/<repo>/blob/<revision>/<path> for files. History uses /<owner>/<repo>/commits/<revision>; a commit uses /<owner>/<repo>/commit/<oid>. Omit <path> for the root tree.

A requested revision can name a branch, an encoded full ref such as refs%2Fheads%2Fmain, or a commit OID. Snapshot links use the resolved commit OID so their files remain tied to the document you read. Encode slashes within a ref as %2F; slashes between file path segments remain /. Relative links in an included README resolve inside that same snapshot. Supported relative images use the authorized image endpoint pinned to the snapshot commit; external destinations remain unchanged.

Use the advertised .md alternate for document routes, or append ?format=markdown. Source file paths are exact: .md inside a blob path is part of the filename and is never treated as a representation suffix.

Repositories

Collaboration

Account

Organizations

Integrations

Read as MarkdownGitCafe documentation
Documentation