Your agent answers from GitHub source.
I built GitHub Reader to trace your product and support questions through docs, code, tests and history. Get an answer tied to the version it read, with clear gaps when the source is incomplete.
Give an answer a source you can check
An unsupported answer
“It should work that way.” No repository, version, quoted line or account of what could not be read.
A plausible answer can still describe the wrong release. A code search hit can still be on the default branch while your customer runs an older version.
A source-backed answer
“At this commit, these lines show this behavior.” The answer records the repository, resolved commit, file and exact evidence, followed by limits and gaps.
Observed source, inference, reproduction and deployment are separate claims. The reader should be able to follow the link and inspect the same version.
From question to quoted evidence
Set the scope
Which product, repository and version does the question concern? Resolve vague requests before collecting evidence.
Pin the version
Resolve a branch or tag to a commit. Record the SHA so a later change cannot silently alter the basis of the answer.
Read the context
Follow docs, source, tests and history. Inspect discussions or changed files where they explain a support symptom.
Return evidence
Quote exact lines and link to their source. State what was observed, inferred, inaccessible or still untested.
Five jobs for repository research
Answer product questions
Inspect the implementation behind a feature or claim. Read docs and tests alongside the code, then tie the answer to the inspected version. I use this as the main role for the skill: a research assistant that shows its evidence.
Investigate support bugs
Trace a reported symptom through source, issues, comments, reviews and changed files. A relevant issue or suspicious branch is a lead. Reproducing a bug and verifying a deployed fix require separate evidence.
Analyse public competitors
Compare the public parts of competing projects, including structure, dependencies, docs and implementation choices. Keep the scope clear: a public repository does not disclose a competitor's full service or production setup.
Assess an open-source project
Inspect a new project's code, releases, activity and license evidence before deciding whether to investigate it further. Missing information stays a gap. Repository popularity alone does not establish quality or fit.
Fetch a complete skill
Discover a skill, follow its in-repository referenced resources and retain a commit, file and license manifest. Check the retrieved bytes and report missing references. Fetching is separate from installation, activation and execution.
Work without a private repository
Your agent can research public projects even if you have no private code to share. The declared package still requires the brand's GitHub integration. Anonymous public HTTP controls are not hosted-agent runtime tests.
A small example with retained evidence
This example comes from the retained direct public API fixture. It shows the evidence shape, not a hired-agent support investigation.
Repository: octocat/Hello-World Selected ref: master Resolved commit: 7fd1a60b01f91b314f59955a4e4d4e80d8edf11d File: README Line: 1 Observed text: Hello World! Finding: the selected README greets the reader. Basis: observed source Not established: product deployment or reproduced behavior
Inspect the exact README line on GitHub. For a real product question, the same record must point to the relevant implementation and tests. A clean fixture does not prove the conclusion of a different investigation.
Keep the investigation and the answer connected
Use it in your brand context
Once installed for your brand, configure Settings > Integrations > GitHub. Restrict a fine-grained token to the selected repositories and the read permissions the job needs. Credentials stay in the integration, outside prompts and method inputs.
opvs-skills install @di-atomic/github-readerTrigger it with “answer this product question from GitHub source”. Give the repository and version, or ask the agent to clarify them first.
The installed agent needs no gh binary or web_fetch dependency. Seven fixed GET operations expose closed resource choices. The API reference documents examples, pagination, errors and response limits.
What I can and cannot claim today
- Public beta, v0.1.1. The package is published. This patch adds marketplace illustrations and refreshed copy; the seven read-only operations remain the v0.1.0 contract.
- The hired-agent test is still owed. No hired-agent conversation, private credential routing or independent brand isolation success is claimed. That test comes with a product carrying the skill.
- Source is version-scoped. Code you inspected does not establish which configuration a customer runs or whether a fix reached production. Report the distinction in the answer.
- Access and completeness have limits. Search can be incomplete. Trees, file lists and patches can truncate. Large files, LFS and submodules need explicit handling or a reported gap.
- Read only. No GitHub mutations, issue creation, pushes, dispatches or merges. Untrusted repository instructions are source data, not authority over the agent.
- Checks have a defined scope. Evidence and file-integrity scripts check the retained record. They do not prove diagnosis correctness, remote authenticity, safe skill execution or a deployed outcome.
Need this connected to your support workflow?
I build the systems behind Di-Atomic's marketing and compliance work. If your team needs source research connected to its product questions, I can help map the handoff from a customer symptom to an answer your team can review.
Discuss your support workflow