---
name: gisthubs-evidence-research
description: Use when an Agent must understand a software project before public writing, extract defensible product facts from a repository and real runtime states, separate evidence from inference, or prepare research for a GistHubs project post. Do not use for generic web trend research or for writing the final article.
---

# GistHubs project evidence research

Build the factual spine for a project story. Do not write promotional prose yet.

## Inspect the project

Read the repository beyond its README. Select only sources relevant to the requested story:

- core code paths and configuration;
- tests and fixtures that prove behavior;
- user-facing docs, examples and releases;
- recent commits and issues when they explain the current state;
- real rendered or executed states when it is safe to run the project.

Prefer primary project evidence over generic claims. A passing test proves its assertion, not broad product quality. A UI shell does not prove a backend or provider works.

## Produce the evidence brief

Return four sections:

1. **Verified facts** — each fact names its source path, command, URL or captured artifact.
2. **Useful inferences** — explain the reasoning and label it as inference.
3. **Open questions** — state what is missing instead of filling gaps with marketing language.
4. **Visual proof opportunities** — list real screens, flows, outputs or diagrams that could show the fact.

When contributing to `gisthubs-agent-draft@1`, place stable references in `project.evidence` and unresolved points in `project.openQuestions`. Do not include secrets, private user data, credentials or irrelevant internal material.

## Handoff

Give the evidence brief to the selected writing and visual Skills. Tell them which claims are safe, which need qualification, and which must not appear. Preserve exact numbers and scope; do not silently turn a local benchmark into a global claim.