Content Editing Prompt

Context

Use this prompt when editing, reviewing, or improving documentation in the TechStackMain workspace. It covers tool docs, script READMEs, architecture notes, guides, and custom Docusaurus pages.

Before editing, you need to know which type of file you're working with - they have different source locations, different sync rules, and different frontmatter schemas.

Which File to Edit

What you want to update	Edit this file	Do NOT edit
A tool's description, cost, IDs, integrations	`tools/<name>.md`	`docusaurus/docs/tools/...` (generated)
A script folder's docs (Hetzner, GTM, etc.)	`scripts/resources/<tool>/README.md`	`docusaurus/docs/scripts/<tool>/index.md` (generated)
Architecture, tracking IDs, automation flows	`architecture.md`	-
A custom docs page (guide, feature, prompt)	`docusaurus/docs/<path>.md` directly	-
Webflow CMS collection docs	`scripts/resources/webflow/CMS Collections Documentation.md`	-
The llms.txt content structure	`docusaurus/scripts/generate-llms-txt.cjs`	`docusaurus/static/llms.txt` (generated)

⚠️ The most common mistake: editing docusaurus/docs/tools/ or docusaurus/docs/scripts/ files directly. These are overwritten on every build by sync-tools.cjs and sync-scripts.cjs. Always edit the source files listed above.

Prompt Template

I need to edit documentation in the Pacing Agency TechStackMain workspace.

**What I'm editing:**
[DESCRIBE what content needs changing - e.g. "Update the n8n tool doc with a new workflow", "Fix a broken link in the Hetzner scripts README", "Add a new section to the GTM guide"]

**File to edit:**
[FILE_PATH - e.g. tools/n8n.md, scripts/resources/hetzner/README.md, architecture.md]

**Current content (paste if relevant):**
[CURRENT_CONTENT or "see file"]

**What needs to change:**
[SPECIFIC_CHANGES - be explicit: new sections, corrected IDs, updated instructions, etc.]

**Context from architecture.md / related tool docs:**
[Any relevant IDs, URLs, or system details the edit should reference]

Please edit the file following the Pacing Agency content standards:

1. **Voice and tone**
   - British English spellings (organisation, behaviour, colour, licence, optimise)
   - No em dashes - use a comma or restructure the sentence instead
   - Conversational but precise: write for a technical team member, not a marketing audience
   - Problem/solution framing: state what something does before explaining how

2. **Structure**
   - Short paragraphs and bullets over long prose
   - Lead with the most important detail in each bullet
   - Use tables for IDs, mappings, comparisons; code fences for snippets and commands
   - Add `##` headings for major topics, `###` for sub-topics - don't go deeper than `####`

3. **Content rules**
   - Never include server IPs, Hetzner project IDs, or internal credentials in public-facing docs
   - Do include public identifiers: GTM container IDs, GA4 measurement IDs, Webflow site/collection IDs, pixel IDs
   - When referencing other tools, link to their docs page: [Tool Name](/docs/tools/category/name)
   - If updating a tool doc: keep the frontmatter fields intact; only edit the markdown body below the `---` block
   - If updating a script README: keep the frontmatter fields (`title:`, `description:`, `language:`, `download:`, `related_tool:`) intact

4. **Frontmatter safety**
   - Do not add or remove frontmatter keys unless explicitly asked
   - Do not change `accountId`, `category`, `monthlyCost`, or `accountType` values unless you have verified the correct value

After editing, confirm:
- [ ] File is the source file (not a generated copy)
- [ ] Frontmatter is intact and unchanged
- [ ] No server IPs or private credentials added
- [ ] British English throughout
- [ ] All internal links use relative paths or /docs/... format
- [ ] Code blocks have the correct language tag (bash, js, ts, python, yaml, etc.)

Variables to Customize

Variable	Description	Example
`[DESCRIBE what content needs changing]`	Plain-English summary of the edit	"Add the new Stalwart SMTP integration to the Notifuse tool doc"
`[FILE_PATH]`	Source file path relative to workspace root	`tools/notifuse.md`
`[CURRENT_CONTENT]`	Paste the section being changed	Paste a heading + a few bullets
`[SPECIFIC_CHANGES]`	Explicit list of what to add, fix, or remove	"Add a section under ## Integrations listing Stalwart as the SMTP relay"
`[Context from architecture.md]`	Any relevant IDs or system details	"Stalwart is at `email.pacing.agency`, used as SMTP relay for cold email"

Frontmatter Schemas

Tool doc (`tools/<name>.md`)

---
accountId: 16d542af-ada4-4d1b-9ef5-2125be1ae598   # TwentyCRM account ID - do not change
title: Google Tag Manager
category: WEBSITE                                   # Must match: WEBSITE | SELF_HOSTING | OPERATIONAL_TOOLS
                                                    #   SOCIAL_MEDIA | MARKETING_TOOL | DESIGN_CONTENT
                                                    #   AD_SPEND | OFFICE_COWORKING | CRM
categoryDisplay: Website                            # Human-readable label shown in UI
monthlyCost: 0
monthlyCurrency: GBP
annualCost: 0
annualCurrency: GBP
renewalDate: null                                   # ISO date string or null
accountType:
  - CLIENT_ACCESS                                   # Options: CLIENT_OWNED | INTERNAL | CLIENT_ACCESS
  - INTERNAL
accessLink: https://tagmanager.google.com/...       # Direct link to tool dashboard
moreInfo: Used for Pacing internal and client...    # One-line note for TwentyCRM
---

Script README (`scripts/resources/<tool>/README.md`)

---
title: Hetzner Scripts                              # Shown as page title in docs
description: Shell scripts for checking...          # One-line summary; used in llms.txt
language: bash                                      # Primary language: bash | python | javascript | json
download: /downloads/hetzner-scripts.zip            # Path to downloadable zip (generated on build)
related_tool: hetzner                               # Slug of matching tool doc
---

Custom Docusaurus page

---
id: my-page                     # URL slug - keep lowercase with hyphens
title: My Page Title
sidebar_label: Short Label      # Shorter version if title is long
sidebar_position: 3             # Position in sidebar (lower = higher up)
last_verified: 2026-03-10       # ISO date - used by doc verification system
---

Common Mistakes to Avoid

1. Editing the generated file instead of the source

❌ Editing docusaurus/docs/tools/website/gtm.md
✅ Editing tools/gtm.md

❌ Editing docusaurus/docs/scripts/hetzner/index.md
✅ Editing scripts/resources/hetzner/README.md

The generated files are overwritten on every build. Changes made there will silently disappear.

2. American English spellings

❌ optimize, organization, behavior, color, license, customize
✅ optimise, organisation, behaviour, colour, licence, customise

Also watch for: analyze → analyse, recognize → recognise, center → centre

3. Em dashes

❌ The script checks Hetzner status - servers, firewalls, volumes
✅ The script checks Hetzner status: servers, firewalls, and volumes.
✅ The script checks Hetzner status (servers, firewalls, volumes).

4. Vague opening sentences

❌ This tool is used for a variety of purposes.
❌ Webflow is a powerful platform that enables users to...
✅ Webflow is the CMS and front-end for pacing.agency - all marketing pages, blog, and service collections live here.

Lead with what it does, not what it is.

5. Including private infrastructure details in public docs

❌ Adding server IPs (91.98.150.95), Hetzner project IDs (12332922), or internal service tokens to tool docs or architecture.md
✅ Reference the hosting provider, region, and server type (e.g. Hetzner Cloud, Falkenstein, CCX13) without the IP
✅ Include public identifiers (GTM IDs, GA4 IDs, Webflow collection IDs, pixel IDs) - these are intentional

6. Breaking frontmatter

❌ Adding a key that isn't in the schema (e.g. author: Ben)
❌ Changing category to a value not in the allowed list
❌ Removing accountId from a tool doc
✅ Only edit the markdown body below the closing ---; leave the frontmatter block alone unless explicitly changing it

7. Wrong link format

❌ See [GTM](../../../tools/website/gtm.md) - relative paths break across doc sections

❌ See [GTM](https://docs.pacing.agency/docs/tools/website/gtm) - absolute URLs break in local dev
✅ See [GTM](/docs/tools/website/gtm) - root-relative paths work everywhere

For links within the same directory: [Sibling Page](./sibling) is fine.

8. Missing language tags on code blocks

❌ ``` (no language)
✅ ```bash, ```javascript, ```python, ```yaml, ```typescript

Language tags enable syntax highlighting and are required for the copy button to label correctly.

Markdown Quick Reference

# H1 - page title only (one per file)
## H2 - major section
### H3 - sub-section
#### H4 - use sparingly; don't go deeper

**bold** - key terms, UI labels, important warnings
`inline code` - file paths, commands, IDs, variable names, URLs in body text
*italic* - avoid; use bold instead for emphasis

- Bullet item (use for lists of 3+ items)
  - Nested bullet (maximum one level of nesting in most cases)

1. Numbered step
2. Second step

| Column A | Column B |
| --- | --- |
| Row 1 A | Row 1 B |

> Blockquote - use for important callouts or quoting

```bash
# Code fence - always add language tag
./script.sh --flag value

/docs/path/to/page # Internal link example Link text # External link

tip

Use Docusaurus admonitions (tip/note/info/warning/danger) for callouts. Not blockquotes.

--- # Horizontal rule - use sparingly, only to divide major topic areas

---

## Good Content Examples

### Good tool doc opening (from `tools/gtm.md`)

```markdown
Purpose: document current GTM setup, identity handling, event routing, and dependencies.

## Loader and hosting
- Custom loader served via Stape first-party domain `https://load.data.automates.tech/…`
- Web container ID: `GTM-PGPK24VR`. Server container ID: `GTM-NHVBMP3D` (sGTM).
- CMP: Termly; tags listen to `userPrefUpdate` and consent events.

What makes this good:

Opens with a one-line purpose statement, no fluff
Uses inline code for all IDs and URLs
Short bullets, each starting with what (not "This is used for...")
Specific, verifiable details

Good script README opening (from `scripts/resources/hetzner/README.md`)

---
title: Hetzner Scripts
description: Shell scripts for checking Hetzner Cloud project status - servers, firewalls, volumes, and traffic.
language: bash
download: /downloads/hetzner-scripts.zip
related_tool: hetzner
---

# Hetzner Scripts

Scripts for managing and checking Hetzner Cloud projects.

## Scripts

### check-hetzner-project.sh

Check the status and resources of a Hetzner Cloud project.

**Usage:**
```bash
export HCLOUD_TOKEN=your-api-key
./check-hetzner-project.sh

What makes this good:
- Frontmatter is complete and all keys are filled
- Description in frontmatter is a single sentence that works as a standalone summary
- H3 for each script, not H2
- Usage example comes immediately after the description

---

### Good table for IDs (from `architecture.md`)

```markdown
| Area | Details |
| --- | --- |
| Webflow site | `669e9035529a7f101e149eca` (pacing.agency) |
| GTM (web) | `GTM-PGPK24VR` via Stape loader `https://load.data.pacing.agency/...` |
| GA4 | Measurement ID `G-TPFS2Z0HNJ` (via sGTM) |

What makes this good:

All IDs are in backticks
Notes are in plain English, added in parentheses
Short enough to scan at a glance

Follow-up Actions

After making content edits:

If editing a tool doc or script README: run npm run build locally to verify sync generates the expected output, or just push - Cloudflare Pages will do it automatically
If editing a script README: check the download block appears correctly on the generated /docs/scripts/<tool>/ page
If editing architecture.md: confirm you haven't added any server IPs or private project IDs that should stay internal
If editing a custom Docusaurus page: update last_verified date in frontmatter
Commit and push to trigger the Cloudflare Pages build and live deployment

Repository Structure - where files live and how sync works
Tool Template - correct frontmatter schema for new tools
Feature Template - template for new Docusaurus pages
LLMs.txt Implementation - how content is exported for AI consumption
Algolia Search - how content is indexed for search

Success Criteria

✅ Edited the source file, not the generated copy
✅ Frontmatter is intact (no keys added, removed, or misspelled)
✅ British English throughout
✅ No em dashes
✅ No server IPs or private credentials
✅ All code blocks have a language tag
✅ Internal links use root-relative /docs/... format
✅ Build passes locally or on Cloudflare Pages after push

Context​

Which File to Edit​

Prompt Template​

Variables to Customize​

Frontmatter Schemas​

Tool doc (tools/<name>.md)​

Script README (scripts/resources/<tool>/README.md)​

Custom Docusaurus page​

Common Mistakes to Avoid​

1. Editing the generated file instead of the source​

2. American English spellings​

3. Em dashes​

4. Vague opening sentences​

5. Including private infrastructure details in public docs​

6. Breaking frontmatter​

7. Wrong link format​

8. Missing language tags on code blocks​

Markdown Quick Reference​

Good script README opening (from scripts/resources/hetzner/README.md)​

Follow-up Actions​

Related Documentation​

Success Criteria​