GitHub

Sharely.ai for GitHub watches the repositories where your product is built and tells you what each change means for the content that describes it: the pages it just made wrong, with a proposed edit, and the things that shipped with nothing written about them.

Nothing is published automatically. Every report waits for a person.

What is it?

Sharely.ai for GitHub is a GitHub App you install on an organization or a personal account. When a pull request is merged, a release is tagged or a commit lands on a watched branch, Sharely reads the change through GitHub's API and asks two questions:

• What did this change do, in product terms? Not "which files changed", but what a customer can now do that they could not before.
• What does the content in your workspace say about that? Every page, document and resource already synced into Sharely is checked against it.

The answer becomes a change report: the page that is now wrong, the sentence that contradicts the code, a proposed edit, and the lines of code the proposal is cited to. If no content mentions the change at all, it becomes a gap with the nearest page and a draft paragraph.

Sharely reads your repository through GitHub's API and keeps no copy of your code.

What problems does it solve?

The source of truth for what your product does is the code. The people maintaining the website, the help centre and the sales material do not read it, so the two drift apart — usually discovered by a customer, or by a prospect quoting a pricing page that stopped being true three releases ago.

Keeping them aligned is done today by hand: someone remembers to tell marketing, or nobody does.

• A feature changes and the page still promises the old behaviour. The change report names the page and the sentence, and proposes the new wording.
• Something ships and nothing describes it. The gap gives you the nearest page and a first draft.
• A refactor changes nothing a customer can see. It is recorded as internal and notifies nobody, so the queue stays worth reading.

What you get

Eight screens under Product in the Knowledge app, and the Slack settings beside them:

A merged pull request becomes a report within minutes.

What builds up as changes arrive

The first five screens are about one change at a time. The last three are what those changes add up to, and they fill in on their own — there is nothing to configure.

Capabilities

Every change the agent reads names the capabilities it touches, each with a one-sentence definition in product language. Those names accumulate into your product's vocabulary, and it is the vocabulary that gaps and reports are matched against: "bulk export" is what a marketing page says, where the code says POST /api/export.

Each row shows the definition, how many changes have named it, and whether it has been written into your workspace knowledge for the Ask tab and your agents to retrieve. Open a row to see the changes that taught it.

What is not here yet: which code implements a capability, whether it is behind a flag or a plan, and which release it became generally available in. Those need the full code map, which is a later step.

Coverage

The same capabilities, from the content's side: for each one, the pages that mention it and one of five statuses.

Three counts sit above the table — how many capabilities are covered, how many are uncovered, and how many are partial, stale or contradicted — and each row opens to the pages concerned, with a link to the report that made the finding.

A status clears when someone deals with it. Accepting the edit, editing it, marking the content correct or dismissing it all settle that finding, and the capability returns to covered once nothing is left outstanding against it — a capability with three wrong pages stays flagged until the third is dealt with. Assigning a finding to someone does not settle it, because naming who will fix the page is a statement that it is still wrong.

Two things to know about what Coverage can see today. It knows about pages a change report has looked at, so a page that mentions a capability but has never come up in any change's search is not counted — uncovered means "no report has found content for it" rather than "nothing anywhere mentions it". And it is recomputed when your code changes, not when your content does: rewriting a page moves nothing here until the next change touches the same capability.

Releases

Every release and tag on the repositories you watch, newest first, with the changes that shipped in each — worked out by comparing the tag against the previous one, so nothing has to be tagged by hand.

Each one leads with what is outstanding before you announce it, in the order that matters: blockers first, then pages to fix and gaps, then changes still being read, and finally Ready to announce when there is nothing left. Open a release to see every change in it with its verdict.

This screen needs tags and releases watched on at least one repository (see How to set it up → Repositories). A few releases read differently, and say so rather than looking empty: the first one has no previous tag to compare against, a tag that was deleted or moved cannot be compared any more, and GitHub stops a comparison at 250 commits, so a very large release is marked as partial.

Requirements

• A Sharely.ai workspace, with the content you want checked already synced into it. Sharely compares changes against what is in the workspace, so an empty workspace produces only gaps.
• Owner or admin of that workspace. The connection decides what the whole workspace reads.
• Permission to install a GitHub App on the account — on an organization, usually an owner. If you are not one, GitHub turns your install into a request for an owner to approve, and Sharely waits.
• For Slack notifications, permission to add an app to your Slack workspace. Optional: everything else works without Slack.

Note: Pick the workspace in the sidebar before you start. A GitHub connection belongs to one workspace.

How to connect it

1. In the Knowledge app, go to Product → Connect.
2. Press Connect a GitHub account. The dialog lists exactly what is requested:
   • Read access to code, metadata, pull requests and issues
   • No write access of any kind
   • Webhook events on pushes, pull requests, releases and tags
3. Press Continue to GitHub, and choose where to install the App and which repositories it may read. Only select repositories is the usual answer — pick the ones whose changes affect your public content. All repositories also covers repositories created later.
4. GitHub sends you back and the connection appears, with the last 30 days of merged pull requests and releases already being read.

To watch a second organization or a personal account, press Add another organization or account and repeat. Each connection is kept separate, including its roles. Slack is connected once for the whole workspace, and a connection may choose its own channel.

If the App is already installed on the organization but the connection is not in Sharely, use Already installed — connect it to this workspace in the same dialog.

How to set it up

Open the connection from Product → Connect, or the Settings link on its card.

Repositories

Every repository the installation can read is listed. Each one can be watched on its default branch, on tags and releases, on release/* branches, and on pull requests when they open.

A repository with nothing watched is marked paused, and every event for it is dropped.

Visibility

The roles that may see what this connection produces. Changes, reports, gaps and code excerpts are all tagged with them, and a person holding none of these roles sees none of it.

Start with Product truth, and add Marketing deliberately. Visitors to your public sites never hold these roles, so nothing derived from your code can reach them.

Backfill

The last 30 days of merged pull requests and releases are read when you connect, so the view is not empty. Run it again over a longer window to pick up older history.

Workspace knowledge

The reports and the capability vocabulary are written back into the workspace's knowledge, under the roles above, so the Ask tab and your workspace agents can retrieve them.

Slack notifications

Connect Slack once for the whole workspace — Product → Connect → Set up Slack — choose the channel everything posts to, and you are done. A GitHub account or a repository added later posts there without anyone opening its settings.

Three kinds of message, previewed beside the settings with sample content, laid out by the same code that posts the real thing:

Turning Notify on blocker off hides nothing: the blocker still waits in Changes, it just does not interrupt the channel.

This connection may post somewhere other than the workspace default — Channel, on its Slack panel — and a single repository may override it again, under Posts to in the repository list. The roll-up is the exception: it covers the whole account and follows the connection's channel.

See Slack for connecting it, the full channel rules, and what Sharely does and does not read.

Data and privacy

Sharely keeps no copy of your code

The App has read-only access, and the client Sharely uses cannot express a write even if it were granted one. Your repository is read through GitHub's API when a change arrives. There is no clone, no mirror and no snapshot of a branch.

What is stored for a change is its metadata — repository, author, message, the paths that changed and their line counts — plus short excerpts of the changed lines, within the caps below.

Excerpt caps

A summary only change keeps its paths and messages and no code at all — the excerpts are dropped rather than stored and ignored.

Sensitive mode

Set per repository, in the repository list. A repository in sensitive mode stores file paths and line ranges only — never a line of code, in a report, in a citation, or in what the agent is given to read. Use it for anything you would not want quoted back in a Slack message.

Secrets

Every diff is scanned before anything reads it. Matches are redacted and counted on the repository, and the count is shown in the Repositories view. The scan covers commit messages, pull-request bodies and release notes too, because a token pasted into one is as exposed as a token in a diff.

This is always on. It is not a setting.

Roles

Everything a connection produces — changes, reports, gaps, code excerpts and the capability vocabulary — carries the roles set in Visibility. A person who holds none of them sees none of it, and reports written back into workspace knowledge carry the same roles, so widening who may read them is a change to the connection, not a hunt for copies.

Where the text goes

Understanding a change and comparing it with your content is done by a language model. The change's metadata and excerpts, and excerpts of the content being checked, are sent to the same model deployment the rest of your Sharely.ai instance uses — no other third party — and the usage is recorded against your workspace like every other agent in the product.

Retention

Changes, reports and gaps stay in your workspace until the workspace is deleted. Disconnecting does not delete them, and uninstalling the App in GitHub stops new events without removing what has already been written.

When something does not appear

Disconnect and uninstall

Settings → Disconnect stops Sharely reading the account. The changes, reports and gaps already produced stay in your workspace, and the App stays installed in GitHub — remove it there too if you want the installation gone. Reconnecting later starts from the install as if it were new.

Product → Slack → Disconnect stops the posting. It forgets Sharely's copy of the Slack credential, so nothing can be posted; the app stays installed in Slack until you remove it there. Your channel choices are kept, and connecting again restores them.

Learn more

• Product — how connections, changes, reports and gaps fit together.
• Asana and Jira — the tasks and issues behind the code, so a report says what was meant to ship as well as what did.
• Slack — where these findings get posted.
• Integrations overview — the other ways to connect Sharely.ai.
• Knowledge Synchronization — getting the content that GitHub changes are checked against into your workspace.