What Pythe can read: site, repo and files
Give Pythe a website, a public GitHub repo or a text document. It reads them, reports which sources worked, and asks about what it could not tell instead of guessing.
Updated 2026-10-13
During onboarding Pythe turns whatever you can hand over into one condensed block of context. The hard rule: it never presents something as read from your own site if it did not read it. A source that fails is reported as failed.
Sources
| Source | What Pythe reads | Notes |
|---|---|---|
| Your website | The page you give, plus up to 5 sub-pages it picks from the links. | Only http and https. A page with nothing readable is reported with the reason. |
| A public GitHub repo | Repo details (description, topics, stars, issues, dates, languages), the shape of the code (top folders, routes, schema files), the 15 latest commit subjects, the README, and a few key files: the package manifest and product docs such as CLAUDE.md, CONTRIBUTING.md, ARCHITECTURE.md, ROADMAP.md or PRD.md. | Its route list is effectively the feature list and its dependencies reveal the stack. A private repo needs your GitHub connection. |
| A document | Text-like files: .txt, .md, .markdown, .json, .csv, .html, .rtf. | Up to 512 KB of text. Binary formats are rejected up front. |
| Mentions elsewhere on the web | Third-party commentary about the company. | Kept as its own labelled source. It is never merged into your own words. |
What comes back
- Facts Pythe could confirm, which fill the fields on the next screen.
- Conflicts between sources, such as a site that says one thing and a repo another.
- Unknowns: up to four questions about what it could not work out. You answer those on the review screen.
- For each source, whether it worked and, if not, what to fix.
Only what you confirm on the next screen is used. See Onboarding.
Related
Previous: Onboarding: brief, review and dossier · Next: Market and competitor research