Governance / Documentation Standards

CTX Repo Documentation Guide

Documentation standard for drafting, metadata-tagging, publishing, and maintaining formal Markdown documents for third-party vendor documentation context repositories used by human operators, AI agents, AI-assisted development tools, automation workers, and future MCP/RAG workflows.

Text size
Status: publishedCreated: 06/28/2026Last updated: 06/28/2026

Document Scope

The service uses formal CTX repository documents to preserve the operating instructions, metadata, refresh scripts, source locations, validation rules, and AI-agent usage guidance for each third-party vendor documentation context repository.

This document defines the documentation standard for individual CTX repository update documents. It covers frontmatter requirements, product-purpose statements, required sections, script placement, AI-agent instructions, human operator notes, validation checklists, internal admin document-library publication, and ongoing maintenance.

This document does not define the infrastructure process for creating and refreshing CTX repositories. That infrastructure process belongs in CTX Repository Infrastructure Standard.

1. Purpose

Every CTX repository must have a formal Markdown file in the internal admin document library.

The purpose of the Markdown file is to make the CTX repository's refresh process understandable and repeatable for human operators, AI agents, AI-assisted development tools, automation workers, and future MCP/RAG tooling.

The document must explain what the vendor product is used for, what official source material is copied, where the local repository lives, where temporary source folders are created, what remote Git repository is used, what PowerShell refresh script should be run, what successful output looks like, and how AI agents should use the local context material.

2. Internal Admin Document Library

CTX repository documents must be published to the private internal admin document library, not the public customer-facing documentation library.

The internal admin document library currently lives at:

http://127.0.0.1:42000/docs/

A Cloudflare Tunnel access URL may be added later. Do not delay creating or updating CTX documentation while waiting for the Cloudflare Tunnel URL. After tunnel access is configured, update the relevant document-library access section with the external/private-access URL.

3. File Naming Standard

Every individual CTX repository update document must use this file naming pattern:

ctx-<product>-repo-update.md

Examples:

ctx-better-auth-repo-update.md
ctx-brevo-repo-update.md
ctx-resend-repo-update.md

The product portion must match the lowercase kebab-case CTX repository slug, without the leading ctx-.

4. Title and Slug Standard

The title pattern is:

CTX <Product> Repo Update

Examples:

CTX Better Auth Repo Update
CTX Brevo Repo Update
CTX Resend Repo Update

The slug pattern is:

ctx-<product>-repo-update

Examples:

ctx-better-auth-repo-update
ctx-brevo-repo-update
ctx-resend-repo-update

5. Frontmatter Standard

Each individual CTX update document must use frontmatter with this structure:

---
title: CTX <Product> Repo Update
slug: ctx-<product>-repo-update
description: Instructions for refreshing the local and remote <Product> documentation context repository. <Product purpose statement for the service.>
category: Reference Operations
subcategory: External Content Sync
status: published
createdDate: MM/DD/YYYY
lastUpdated: MM/DD/YYYY
searchable: true
---

The description field must identify the product's purpose inside the service.

Do not write the description as only a generic repository description. The reader must be able to understand what the product is used for without already knowing the vendor.

Examples:

Instructions for refreshing the local and remote Better Auth documentation context repository. Better Auth as the authentication framework for user accounts, login, sessions, and account-access control.

Instructions for refreshing the local and remote Brevo documentation context repository. Brevo as an email delivery provider for transactional email, SMTP relay, and related email-sending infrastructure.

Instructions for refreshing the local and remote Resend documentation context repository. Resend as an email delivery provider for transactional email, SMTP relay, and related email-sending infrastructure.

6. Document Scope Standard

The first sentence under # Document Scope must identify the product's purpose inside the service.

Use this structure:

The service uses <Product> as <plain-language purpose statement>.

Examples:

The service uses Better Auth as the authentication framework for user accounts, login, sessions, and account-access control.

The service uses Brevo as an email delivery provider for transactional email, SMTP relay, and related email-sending infrastructure.

The service uses Resend as an email delivery provider for transactional email, SMTP relay, and related email-sending infrastructure.

After the product-purpose sentence, the document scope must explain that the document defines the repeatable process for updating the product's documentation context repository and preserving selected official reference material for local development, human review, AI-agent usage, AI-assisted development-tool usage, automation, and future MCP/RAG workflows.

7. Required Sections

Each individual CTX update document must include these sections:

# Document Scope
## 1. Purpose
## 2. Operational Use
## 3. Source and Destination
## 4. What This Script Does
## 5. PowerShell Refresh Script
## 6. Expected Result
## 7. AI Agent Instructions
## 8. Human Operator Notes
## 9. Validation Checklist
## 10. Related Repositories

Do not omit these sections unless a later documentation standard explicitly replaces this structure.

8. Required Content by Section

The document must explain:

  1. What the product is used for inside the service.
  2. Why the CTX repository exists.
  3. What official sources are copied.
  4. Where the local repository lives.
  5. Where the temporary source checkout folders live.
  6. What remote Git repository is used.
  7. How to run the repeat-safe refresh script.
  8. What successful output looks like.
  9. How AI agents should use the repository.
  10. What the repository does not contain.
  11. What validation checks must be completed.
  12. Which application repository owns the production implementation.

The document must avoid unnecessary repetition of the company name or product brand. Use neutral references such as the company, the service, the application, the internal admin document library, or the applicable service application repository when the specific name is not needed.

9. PowerShell Script Documentation Standard

The PowerShell refresh script included in the formal Markdown file must match the cheat-sheet script for that CTX repository.

Every PowerShell script or code block must start with a cd line so the operator is placed in the correct working directory before the script runs.

Required opening pattern:

cd C:\dev

$ErrorActionPreference = "Stop"

The script section must be titled:

## 5. PowerShell Refresh Script

The text immediately above the script should say:

Run this block from a normal PowerShell window.

The script must be placed inside a fenced code block marked as PowerShell:

```powershell

The script must be repeat-safe and must commit only if content changed.

10. AI Agent Instructions Standard

The ## 7. AI Agent Instructions section must instruct AI agents to treat the local CTX repository as the first reference source for work involving that product.

The section must state that the official vendor website or public upstream source may still be used when the local context appears incomplete, stale, or insufficient for a specific implementation question.

The section must also state that a normal git pull inside the CTX repository does not refresh vendor content. A normal git pull only updates the local copy from the configured remote Git repository. To refresh current official vendor content, the repeat-safe PowerShell refresh script must be run.

11. Human Operator Notes Standard

The ## 8. Human Operator Notes section must state that the refresh script is safe to run repeatedly.

The section must state that the script does not store SSH keys, passphrases, API keys, SMTP credentials, vendor secrets, company secrets, service secrets, environment files, or application configuration secrets.

The section must state that Git authentication is handled by the existing local SSH configuration on the operator's computer.

12. Validation Checklist Standard

The ## 9. Validation Checklist section must include product-specific file and folder checks.

It must also include these general checks:

  1. The expected local context repository exists.
  2. The expected key content folders or files exist.
  3. The local context repository contains selected official vendor reference material.
  4. git status does not show unexpected staged changes.
  5. If changes were found, a commit was created.
  6. If a commit was created, it was pushed to the remote Git repository.
  7. Temporary source checkout folders were removed.

The validation checklist must be specific enough that a human operator or AI agent can verify whether the refresh process worked.

13. Related Repositories Standard

The ## 10. Related Repositories section must identify the CTX repository only.

It must also state that the CTX repository does not define the production implementation itself. Product implementation belongs in the applicable service application repository.

Example:

This document concerns the documentation context repository only:

C:\dev\ctx-resend

It does not define the service's email, SMTP, transactional email, notification, React Email, or template implementation itself. The implementation belongs in the applicable service application repository.

14. Existing Individual CTX Documents

Current individual CTX update documents include:

ctx-better-auth-repo-update.md
ctx-brevo-repo-update.md
ctx-resend-repo-update.md

These documents should be used as the model for future third-party vendor documentation context repository update documents, subject to this standard.

15. Relationship to Infrastructure Standard

This document controls the drafting and publication standard for CTX repository Markdown files.

The infrastructure setup and refresh process is controlled by:

CTX Repository Infrastructure Standard

When creating a new CTX repository, complete the infrastructure work first, then create the formal Markdown document using this documentation standard.

16. Publication Validation Checklist

A CTX repository documentation file is complete only after all of the following are true:

  1. The Markdown file name follows the ctx-<product>-repo-update.md pattern.
  2. The frontmatter uses the required fields.
  3. The frontmatter description identifies the product's purpose inside the service.
  4. The first sentence under # Document Scope identifies the product's purpose inside the service.
  5. The document includes all required sections.
  6. The PowerShell refresh script starts with a cd line.
  7. The PowerShell refresh script matches the cheat-sheet script.
  8. The AI Agent Instructions section tells agents to search the local CTX repository first.
  9. The Human Operator Notes section states that secrets are not stored.
  10. The Validation Checklist is product-specific.
  11. The Related Repositories section identifies the CTX repository and the implementation boundary.
  12. The Markdown file is placed in the internal admin document library.
  13. The document can be found through the admin document library search or category view.