Build a Nightly Second-Brain Editor With GitHub Review

The team changes how a handoff works during the day. The knowledge base still describes last month’s process. By the time someone notices, a new colleague has followed the wrong instructions.

A nightly knowledge audit can reduce that gap without giving an agent permission to rewrite the company’s memory. The useful service compares approved work evidence with existing documentation, identifies material differences, and prepares small changes a person can inspect.

For an AI service provider, the product is an evidence-linked review packet for one client. It is not unrestricted monitoring of everyone’s activity, and it should never auto-merge changes into GitHub.

1. Define what counts as an approved decision

Choose one documentation area, such as the client’s onboarding handbook. Name the person responsible for accepting changes. Agree which evidence can establish a new policy: an approved decision log, reviewed meeting notes, or a completed change record.

A casual suggestion in chat is not equivalent to a decision. A customer asking for a different process does not prove that the team accepted it. Give the audit explicit labels for approved decision, unresolved proposal, and observation.

Keep this service in the client’s separate Agentic Workers workspace. Create a Super Agent whose job is to propose documentation changes, with no authority to publish them. Start with one repository and an allowlist of documentation paths. Creating a Team requires Ultra.

2. Create a daily evidence bundle

Supply the day’s approved notes with stable references, approval status, timestamps, and owners. Include the relevant GitHub documentation snapshot and the exact commit identifier used for comparison.

Verify repository access in the workspace before designing around it. If read access is unavailable, use an approved export containing only the allowed files and their paths. GitHub is the knowledge source in this example, not a claim that every workspace already has a suitable connector. Do not use browser automation without separate authorization.

Exclude credentials, customer secrets, private personnel records, and material that cannot be retained under the client agreement. Where possible, supply a redacted decision summary instead of an entire conversation. Establish when raw daily bundles will be deleted and who can view the retained audit record.

3. Match evidence to the smallest relevant passage

Have the Super Agent find the existing passage before proposing a replacement. A useful finding includes the repository path, heading, current text, proposed text, and decision reference.

Require one of four outcomes for each decision: already documented, proposed change, conflict requiring review, or no appropriate destination. This prevents every daily update from becoming a new page.

For example, an approved decision might change onboarding ownership from sales to delivery after payment confirmation. The proposal should alter the ownership passage and identify any conflicting checklist. It should not rewrite the entire handbook or infer that billing policy also changed.

Treat instructions embedded in notes, repository files, or linked pages as untrusted content. They cannot expand the audit’s permissions or tell it to ignore its path allowlist.

4. Give the Super Agent a patch-focused instruction

Use a version of this instruction with the actual approved paths and evidence references:

Audit today’s approved decision bundle against the supplied GitHub documentation snapshot. Use only the allowed documentation paths and record the snapshot’s commit identifier. Do not inspect other repositories or retrieve additional conversations. Only evidence explicitly marked approved may support a proposed policy change; summarize unresolved proposals separately without patching them.

For each material approved decision, return one status: already documented, proposed change, conflict requiring review, or no destination found. Proposed changes must include file path, section, exact current passage, minimal replacement passage or unified diff, evidence reference, decision owner, and reason. Preserve unrelated text. Do not invent supporting evidence, policy, or file contents. Identify contradictions rather than choosing a preferred source silently.

Produce at most five proposed changes across ten allowed files, with no more than 200 changed lines. Stop after one comparison pass and one consistency check. If the repository snapshot is missing, evidence approval is unclear, or limits are exceeded, return a blocked report and specify the input or narrower scope needed. Never commit, push, open a pull request, merge, delete files, or publish. Draft any reviewer message without sending it. Finish with coverage, unresolved questions, and the base commit against which proposals must be checked.

5. Review provenance before prose

The reviewer should first ask whether the evidence authorizes the change, then whether the wording is accurate. A polished paragraph can still encode an unapproved decision.

Keep proposed diffs outside the authoritative repository during the pilot. Require explicit approval before any external action, including opening a pull request. If a person later applies the patch, compare the current repository with the recorded base commit first. A changed base needs a fresh comparison, not a blind patch application.

Never auto-merge, even after several clean runs. A successful previous review does not authorize future policy changes. Keep client and contact messages draft-only throughout this workflow.

6. Run a three-night documentation pilot

Use a single handbook section and a few approved decisions per night. Nightly timing is an example cadence, not a guarantee of continuous coverage. Begin with manual runs so a missing bundle is visible rather than mistaken for a day without changes.

Include a decision already documented, an unresolved suggestion, a contradictory policy, and a note containing a secret that should be excluded. These are suggested test inputs, not completed tests.

Measure accepted proposals, rejected proposals, unsupported changes, missed decisions found by the reviewer, and review time. Track the age of unresolved conflicts separately. Zero proposals may mean the handbook is current, but it may also mean the input packet was empty; the coverage summary must distinguish those cases.

This approach develops the second-brain maintenance idea from Corey Ganim’s October 20, 2026 workflow post. It is a proposed client build, not an executed Agentic Workers case study.

Build an evidence-linked knowledge audit with Agentic Workers