Skip to main content
U.S. Army Corps of Engineers
®
US Army Corps of EngineersInstitute for Water Resources, Risk Management Center
Developer Resources

Creating a New Document: Complete Walkthrough

This comprehensive guide walks you through the entire process of creating new documentation from start to finish, including folder setup, content creation, testing, and administrator coordination.

Quick Step Flow​

Click a step to jump to the detailed section.

  1. Pre-Flight ChecklistGo to checklist
  2. Step 1: Create a BranchGo to Step 1
  3. Step 2: Determine Folder LocationGo to Step 2
  4. Step 3: Create Folder StructureGo to Step 3
  5. Step 4: Add Supporting AssetsGo to Step 4
  6. Step 5: Create MDX FilesGo to Step 5
  7. Step 6: Register the DocumentGo to Step 6
  8. Step 7: Test LocallyGo to Step 7
  9. Step 8: Open a Pull RequestGo to Step 8

Overview​

This walkthrough applies to all new document creation, whether you're using the DOCX converter or creating MDX files manually.

Important

Even when using the DOCX converter (Chapter 05), you'll still need to follow most of these steps. The converter automates MDX file creation from Word documents, but you're still responsible for:

  • Creating the branch and folder structures
  • Adding bibliography files
  • Adding source documents for archiving
  • Handling videos/GIFs manually (converter doesn't extract these)
  • Registering the document and opening the pull request

When to use this guide:

  • Creating documentation for new software on a docs/new/ branch
  • Adding a new document type for existing software on a docs/new/ branch

For creating a new version of an existing document (v1.1, v2.0, etc.), see Versioning System instead.

The big picture. Author one new document on a docs/new/ branch. Its Content PR receives peer, Lead Civil, and AI-assisted technical editing, then merges and deploys as a draft. An administrator later starts a separate full-document Director Review PR; approval or waiver produces a Publication PR. See Review Classifications and Stages and Author Workflow.

Pre-Flight Checklist​

Before you begin, gather and prepare the following:

Required Information:

✓ Software name and type
✓ Document type (users-guide, validation-studies, applications-guide, etc.)
✓ Version number (always v1.0 for a brand-new document)
✓ Branch slug (e.g., docs/new/dam-analyzer-users-guide)

Source Materials:

✓ Source document gathered (Word doc, PDF, or other reference material if any)
✓ List of figures/images compiled
✓ Bibliography/references collected
✓ Videos/GIFs identified (if applicable)

Decision Point:

✓ Determined creation method:

  • Using DOCX converter (for Word documents) → See Chapter 05 for converter instructions
  • Manual MDX creation (for hand-authored documentation) → Follow all steps in this guide
Time Estimate

New document from scratch: 4-8 hours depending on complexity
New version from existing: 2-4 hours
Using DOCX converter: Reduces MDX creation time by 50-75%

Step 1: Create a Branch​

The main branch is protected. Author new documents on a feature branch and merge them through a pull request. Use docs/new/ to describe the intended classification. An administrator's controller command is authoritative.

Not creating a new document?

Documentation prefixes describe new documents, major revisions, minor revisions, editorial corrections, and developer documentation. See Review Classifications and Stages. This chapter covers a new document; for revisions, see Versioning System.

Branch naming: docs/new/<short-slug> where the slug describes the document. Use lowercase with hyphens.

Examples:

  • docs/new/dam-analyzer-users-guide
  • docs/new/totalrisk-applications-guide
  • docs/new/lifesim-validation-oroville

Using Git (command line)​

# Make sure your local main is up to date
git checkout main
git pull origin main

# Create and switch to the new branch
git checkout -b docs/new/dam-analyzer-users-guide

Using GitHub Desktop​

  1. Open GitHub Desktop and select the RMC-Software-Documentation repository.
  2. Click the Current Branch dropdown.
  3. Click New Branch.
  4. Name the branch docs/new/<your-slug>.
  5. Confirm the branch is being created from main.
  6. Click Create Branch.

GitHub Desktop will switch to the new branch automatically.

Branch name tip

Keep the slug short but specific. The branch name shows up in PR titles, commit history, and search — dam-analyzer-users-guide is more useful later than new-doc or dam-stuff.

Step 2: Determine Folder Location​

With the branch created, you need to determine exactly where your documentation belongs in the project structure.

Decision Process​

Question 1: What type of application/software is this?

  • Desktop software (exe/installer) → desktop-applications/
  • Web-based tool or application → web-applications/
  • Excel-based toolbox/calculator → toolbox-technical-manuals/

Question 2: What is the folder hierarchy for your application type?

Hierarchy Differences

The folder structure differs based on application type:

Desktop and Web Applications:

application type → software name → document type → version

Toolbox Technical Manuals:

application type → suite name → tool/document name → version

Toolbox manuals have a different structure because they document suites of related tools.

Examples​

Example 1: Desktop Application

Software: Dam Analyzer (new desktop application)
Document: Users Guide
Version: 1.0

Path: docs/desktop-applications/dam-analyzer/users-guide/v1.0/

Example 2: Web Application

Software: Risk Calculator (new web app)
Document: Users Guide
Version: 1.0

Path: docs/web-applications/risk-calculator/users-guide/v1.0/

Example 3: Toolbox Technical Manual

Suite: seismic-hazard-suite (existing)
Tool: peak-ground-acceleration (new tool in the suite)
Version: 1.0

Path: docs/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

Need help? Reference the decision tree in Chapter 03: Project Structure for more detailed guidance.

Step 3: Create Folder Structure​

You need to create folders in five different locations that all mirror each other.

Critical Requirement

All five folder structures must match exactly. The paths must be identical except for the root folder (docs/ vs. static/figures/ vs. static/videos/ vs. static/bibliographies/ vs. static/source-documents/).

For Desktop and Web Applications​

# Example: New desktop application "dam-analyzer" users guide v1.0

# 1. Create docs folder
docs/desktop-applications/dam-analyzer/users-guide/v1.0/

# 2. Create figures folder (mirrors docs structure)
static/figures/desktop-applications/dam-analyzer/users-guide/v1.0/

# 3. Create videos folder if needed (mirrors docs structure)
static/videos/desktop-applications/dam-analyzer/users-guide/v1.0/

# 4. Create bibliographies folder (mirrors docs structure)
static/bibliographies/desktop-applications/dam-analyzer/users-guide/v1.0/

# 5. Create source-documents folder (mirrors docs structure)
static/source-documents/desktop-applications/dam-analyzer/users-guide/v1.0/

For Toolbox Technical Manuals​

# Example: New tool "peak-ground-acceleration" in seismic-hazard-suite v1.0

# 1. Create docs folder
docs/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

# 2. Create figures folder
static/figures/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

# 3. Create videos folder if needed
static/videos/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

# 4. Create bibliographies folder
static/bibliographies/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

# 5. Create source-documents folder
static/source-documents/toolbox-technical-manuals/seismic-hazard-suite/peak-ground-acceleration/v1.0/

Key Points​

  • Naming convention: Use lowercase with hyphens (e.g., dam-analyzer, not Dam_Analyzer or DamAnalyzer)
  • Version format: Always v + major.minor (e.g., v1.0, v1.1, v2.0)
  • Videos folder: Only create if your document contains videos/GIFs
  • Source-documents folder: Optional but highly recommended for archiving original files
Folder Creation

You can create folders using your file explorer, IDE, or command line. All parent folders will be created automatically as needed.

Step 4: Add Supporting Assets​

This step can happen at different times depending on your workflow:

  • Before creating MDX (recommended for organization)
  • During MDX creation (as you reference assets in your writing)
  • After initial MDX creation (during revision and refinement)

Choose the timing that works best for you.

Add Figures and Images​

Copy images to the figures folder you created in Step 3.

Figure Naming Standards:

You must choose one of two approved naming conventions for your document:

Standard A: Sequential Generic (Typical for DOCX converter)

  • figKey: figure-1, figure-2, figure-3, etc.
  • Filename: figure1.png, figure2.png, figure3.png, etc.
  • When to use: Documents converted from Word, or when you prefer numbered organization
  • Inserting figures: Use letter suffixes (e.g., figure-24a between 24 and 25)

Standard B: Descriptive Semantic (Optional for hand-authored)

  • figKey: fig-menu-screenshot, fig-workflow-diagram, etc.
  • Filename: menu-screenshot.png, workflow-diagram.png, etc.
  • When to use: Hand-authored documentation where semantic names improve maintainability
  • Inserting figures: Just add new descriptive name, no renumbering needed
Consistency Required

Pick one standard and use it throughout your entire document. Do not mix conventions.

See Chapter 03: Project Structure - Figure Naming Standards for complete details.

Add Videos and GIFs​

Copy video files to the videos folder you created in Step 3.

  • Supported formats: .mp4, .webm, .gif
  • Name videos descriptively: workflow-demonstration.mp4, menu-navigation.gif
  • Important: Videos and GIFs must be added manually - the DOCX converter does not extract these

Create Bibliography File​

Create bib.json in the bibliographies folder you created in Step 3.

Do This Early

Create the bibliography file before writing MDX if possible. It's much easier to reference citations as you write than to go back and add them later.

Using AI to Speed Up Creation:

Creating bib.json files manually is time-consuming. AI can help:

  1. Find an example bib.json from an existing document in this project
  2. Copy your references from your source document
  3. Provide both to an AI (Claude, ChatGPT, etc.) with a prompt like:
I need to create a bib.json file for my documentation project. Here's an example
showing the required format:

[paste example bib.json]

Here are the references from my document:

[paste your bibliography]

Please create a bib.json file following the exact format, ensuring all citation
keys are unique and formatted correctly.
  1. Review the AI output carefully:
    • ✓ Citation keys are unique
    • ✓ Author names, years, titles are accurate
    • ✓ All required fields present
    • ✓ Valid JSON format (no trailing commas, proper quotes)
    • ✓ IEEE style compliance

Example bib.json locations to reference:

  • static/bibliographies/desktop-applications/rmc-totalrisk/users-guide/v1.0/bib.json
  • static/bibliographies/toolbox-technical-manuals/internal-erosion-suite/backward-erosion-piping-progression/v1.0/bib.json

See Chapter 03: Project Structure - Creating bib.json with AI for detailed instructions.

Add Source Documents​

Copy source files to the source-documents folder you created in Step 3.

  • Original Word documents (.docx)
  • PDFs
  • Spreadsheets or other reference materials

This step is optional but highly recommended for:

  • Archiving original materials
  • Future updates and revisions
  • QA verification
  • Historical reference

Step 5: Create MDX Files​

Now you're ready to create the actual documentation content.

If you have a Word document in the modern RMC Word Template format, use the DOCX converter to automatically generate MDX files.

See Chapter 05: DOCX Converter for complete instructions.

The converter will create:

  • 00-document-info.mdx
  • 00-version-history.mdx
  • 01-preface.mdx (automatically renames "Introduction" if needed)
  • All chapter files with proper numbering

After conversion:

✓ Verify all file names follow conventions
✓ Check that 01-preface.mdx has title "Preface"
✓ Review figure references for correctness
✓ Add any missing videos/GIFs manually

Option B: Manual MDX Creation​

If creating documentation from scratch without a Word document, create MDX files manually.

Required Files (in order):

1. 00-document-info.mdx

Basic template:

---
title: Document Info
reportDate: November 2023
reportType: Computer Program Document
reportTitle: RMC Backward Erosion Piping (Progression) Toolbox
reportSubTitle: RMC Internal Erosion Suite
reportAuthors: ["Tim O'Leary, Risk Management Center"]
reportAbstract: The spreadsheet tools contained in this toolbox deterministically and probabilistically assess the likelihood of backward erosion piping progression (hydraulic condition) using the adjusted Schmertmann (2000) method and the adjusted calculation rule of Sellmeijer et al. (2011) in addition to creep ratio methods of Bligh (1910) and Lane (1935).
reportSubjectTerms: ['Internal erosion', 'backward erosion piping', 'Schmertmann', 'Sellmeijer', 'Bligh', 'Lane', 'creep ratio']
responsiblePersonName: Tim O'Leary
responsiblePersonNumber: 502-315-6599
citationGuide: "T. M. O'Leary, <i>RMC Backward Erosion Piping (Progression) Toolbox Technical Manual</i>, Lakewood, CO: U.S. Army Corps of Engineers, Risk Management Center, 2025. Accessed on <i>{enter current date here}</i>."
---

import NavContainer from '@site/src/components/NavContainer';
import DocumentMetadata from '@site/src/components/DocumentMetadata';
import Link from '@docusaurus/Link';
import addBaseUrl from '@docusaurus/useBaseUrl';

<NavContainer
  link="/toolboxes/internal-erosion-suite"
  linkTitle="Internal Erosion Suite"
  document="toolbox-technical-manuals/internal-erosion-suite/backward-erosion-piping-progression"
></NavContainer>

# Document Information

<DocumentMetadata metadata={frontMatter} />

2. 00-version-history.mdx

Basic template:

import NavContainer from '@site/src/components/NavContainer';
import TableVersionHistory from '@site/src/components/TableVersionHistory';
import Link from '@docusaurus/Link';

<NavContainer
  link="/toolboxes/internal-erosion-suite"
  linkTitle="Internal Erosion Suite"
  document="toolbox-technical-manuals/internal-erosion-suite/backward-erosion-piping-progression"
></NavContainer>

# Version History

<TableVersionHistory
  versions={['1.0']}
  dates={['July 2025']}
  descriptions={['Initial release as an online document. Source is RMC CPD-2023-06.']}
  modifiedBy={['-']}
  reviewedBy={['Damon Amlung']}
  approvedBy={['Nathan Snorteland']}
/>

3. 01-preface.mdx

CRITICAL: Preface Requirement

File name: 01-preface.mdx Title in file: Preface

The first chapter of the main report must always be named 01-preface.mdx with the title "Preface" - even if your source document calls it "Introduction" or something else.

Why: Ensures consistency across all documents and is required for automatic sidebar generation.

Exception: If you absolutely need a different first chapter title, contact a site administrator before creating your document.

Basic template:

---
title: 'Preface'
---

# Preface

This document provides...

[Your preface content here]

4. Additional Chapter Files

Create files numbered 02-, 03-, 04-, etc.:

02-introduction.mdx
03-methodology.mdx
04-results.mdx
05-conclusions.mdx
06-appendix-acronyms.mdx
07-appendix-references.mdx

File naming pattern: ##-chapter-name.mdx

  • ## = Two-digit number (01, 02, 03, etc.)
  • chapter-name = Lowercase with hyphens

For MDX syntax and component usage: See Chapter 06: Creating and Editing Pages

Checkpoint: After Creating MDX Files​

Verify the following before proceeding:

✓ All three required files exist (00-document-info.mdx, 00-version-history.mdx, 01-preface.mdx)
✓ File names follow exact naming convention (lowercase, hyphens, no spaces)
✓ 01-preface.mdx has title "Preface" (no exceptions without admin approval)
✓ Chapter numbering is sequential with no gaps
✓ Front matter is complete in all files (title, proper YAML format)
✓ No typos in file paths or component imports

Step 6: Register the Document​

Every published document is registered in src/docConfig.js. This file is the single source of truth for which documents appear on the site and which carry the DRAFT watermark. Without an entry, your document won't appear on the appropriate landing page, won't be indexed by search, and won't be included in the production build.

Add a new entry to the docs array, grouped by category and software. Set draft: true. Choose active based on whether the draft should be available in production after the Content PR merges. Publication removes draft status after separate Director review.

Example entry for a new desktop application document:

{
  category: 'desktop-applications',
  software: 'dam-analyzer',
  doc_location: 'desktop-applications/dam-analyzer/users-guide',
  doc_name: 'Dam Analyzer Users Guide',
  active: false,
  draft: true,
},

Field reference:

FieldDescription
categoryOne of desktop-applications, toolboxes, or web-applications
softwareThe software identifier (lowercase, hyphenated)
doc_locationPath from docs/ to the document folder (no version, no leading slash)
doc_nameDisplay name shown on the landing-page tile
activetrue to publish; false while drafting
drafttrue to apply the DRAFT watermark on the latest version; false once finalized

See the existing entries in src/docConfig.js for examples across all categories.

Download-only documents

If your "document" is actually a direct PDF download rather than an MDX-built site, use a downloadUrl field instead of doc_location. See the LifeSim Technical Reference Manual entry in src/docConfig.js as an example.

Step 7: Test Locally​

Before opening the pull request, test everything locally.

Local Testing Steps​

# 1. Run the development server
npm start

This will:

  • Generate the sidebar automatically
  • Build counter files for figure/table/equation numbering
  • Start a local web server (usually at http://localhost:3000)

Wait for the build to complete (you'll see "Compiled successfully" message in the console).

What to Test​

2. Navigate to your new document

  • Open your browser to the local server URL
  • Find your document in the sidebar
  • Click to open it

Check:

✓ Sidebar appears and shows your document
✓ All chapters are listed in the sidebar
✓ Chapter order is correct
✓ Sidebar sections collapse/expand properly

3. Click through each chapter

Check:

✓ All pages load without errors
✓ Figures display correctly
✓ Figure numbers are sequential and correct
✓ Citations render properly (if applicable)
✓ Internal links work
✓ No missing images or broken references
✓ Videos/GIFs play correctly (if applicable)

Common Issues and Solutions​

Issue: Sidebar doesn't show my document

  • Solution: Check that folder structure matches exactly across docs/ and static/ folders
  • Verify version folder exists and is named correctly (v1.0, not v1.0.0 or 1.0)

Issue: Figures not displaying

  • Solution: Verify src paths in Figure components point to correct location
  • Check that image files actually exist in static/figures/ folder
  • Ensure file extensions match (.png vs .PNG)

Issue: Citations not rendering

  • Solution: Ensure bib.json exists in correct bibliographies folder
  • Validate JSON syntax (no trailing commas, proper quotes)
  • Check that citation keys match between MDX and bib.json

Issue: Wrong chapter order in sidebar

  • Solution: Check numeric prefixes on files - sidebar orders by number
  • Ensure all files have two-digit prefixes (01, 02, not 1, 2)

Issue: Build errors or warnings

  • Solution: Read the error message carefully
  • Check front matter YAML syntax
  • Verify all component imports are correct
  • Look for typos in file names or paths

Step 8: Open a Pull Request​

When local testing passes, commit your work and open a Content pull request. The docs/new/ prefix describes the intended classification. An administrator records /review classify new <doc_location>; the Content PR then requires peer, Lead Civil, and AI technical-edit stages.

Commit and push​

# Stage everything you've added
git add docs/ static/ src/docConfig.js

# Commit with a descriptive message
git commit -m "Add Dam Analyzer Users Guide v1.0"

# Push the branch to GitHub
git push -u origin docs/new/dam-analyzer-users-guide

GitHub Desktop users: stage and commit via the Changes panel, then click Publish branch.

Open the pull request​

After pushing, GitHub returns a URL like https://github.com/USACE-RMC/RMC-Software-Documentation/pull/new/<branch-name>. Click it to open the PR creation page (or use the Pull Requests tab on GitHub).

The repository ships a PR template that prefills a description structure. Fill in the sections:

  • Description — what document you're adding and why
  • Document scope — the one document and its doc_location
  • Related issues — any tracked issues this addresses
  • Validation — record the preview, checks, and version-history update

Click Create pull request.

What happens automatically​

After opening the PR, CI builds the site and the preview workflow reports its result. The administrator classifies the PR and assigns one named peer reviewer. The controller keeps one persistent summary with the classification, stage, reviewer, completed or waived stages, preview, and next action. Labels make purpose and status easy to scan; they do not control state.

What you do next​

Follow the Author Workflow. The administrator assigns every stage reviewer. Apply feedback and use /review ready if substantial revisions need renewed attention. Replies and resolved threads help the discussion but are not automated gates.

When something special is needed​

The PR comment thread is the place to coordinate anything unusual. Tag @usace-rmc/docs-admin in a comment if:

  • This is a completely new software product that needs homepage or navigation links added
  • The document needs an exception from the standard sidebar structure (e.g., the first chapter isn't a "Preface")
  • You need a new React component that doesn't exist yet
  • The document has a specific deployment-timing dependency (e.g., must go live alongside a software release)

The PR is the coordination point. After the Content PR merges, production builds automatically from main and publishes the document as a draft. An administrator later starts the separate Director review.

Complete Examples​

Example 1: New Desktop Application Users Guide​

Scenario: Creating a Users Guide for a new desktop application called "Dam Safety Tool," version 1.0.

1. Create a branch: docs/new/dam-safety-tool-users-guide off main.

2. Determine location:

  • Application type: Desktop → desktop-applications/
  • Full path: docs/desktop-applications/dam-safety-tool/users-guide/v1.0/

3. Create folders (docs, figures, videos, bibliographies, source-documents — all mirroring the same path).

4. Add assets: 45 screenshots, 3 demo videos, a bib.json with 12 references, and the source Word document.

5. Create MDX using the DOCX converter (Chapter 05) → 8 chapter files generated automatically.

6. Register in src/docConfig.js:

{
  category: 'desktop-applications',
  software: 'dam-safety-tool',
  doc_location: 'desktop-applications/dam-safety-tool/users-guide',
  doc_name: 'Dam Safety Tool Users Guide',
  active: false,
  draft: true,
},

7. Test locally with npm start. Verify all figures display, videos play, citations render, and there are no console errors.

8. Open the Content pull request: push the branch, fill in the template, and identify its doc_location. Because this is a brand-new software product, note the required homepage or navigation links in the PR.

Example 2: New Toolbox Technical Manual​

Scenario: Adding a new tool "Seepage Analysis" to the existing seismic-hazard-suite.

1. Create a branch: docs/new/seepage-analysis-toolbox off main.

2. Determine location:

  • Application type: Toolbox → toolbox-technical-manuals/
  • Full path: docs/toolbox-technical-manuals/seismic-hazard-suite/seepage-analysis/v1.0/

3. Create folders (docs, figures, bibliographies, source-documents — no videos needed for this document).

4. Add assets: 15 diagrams, a bib.json with 8 references, and the Excel tool as the source document.

5. Create MDX manually (no source Word document):

  • 00-document-info.mdx with <DocumentMetadata />
  • 00-version-history.mdx with the initial v1.0 entry
  • 01-preface.mdx
  • Four more chapters (02- through 05-)

6. Register in src/docConfig.js:

{
  category: 'toolboxes',
  software: 'seismic-hazard-suite',
  doc_location: 'toolbox-technical-manuals/seismic-hazard-suite/seepage-analysis',
  doc_name: 'Seepage Analysis Toolbox Technical Manual',
  active: false,
  draft: true,
},

7. Test locally — verify the new tool appears under the existing seismic-hazard-suite in the sidebar.

8. Open the Content pull request. Identify the document location and validation so an administrator can classify it and assign review.

Quick Reference Checklist​

Use this scannable checklist to confirm every step is complete:

Pre-Creation​

✓ Source materials gathered
✓ Folder location determined
✓ Document type selected
✓ Branch slug decided (e.g., docs/new/dam-analyzer-users-guide)
✓ Creation method chosen (DOCX converter vs. manual)

Branch​

✓ Created branch with docs/new/ prefix off main

Folder Structure​

✓ Created docs folder: docs/[application-type]/[software]/[document-type]/v1.0/
✓ Created figures folder: static/figures/[matching-path]/
✓ Created videos folder (if needed): static/videos/[matching-path]/
✓ Created bibliographies folder: static/bibliographies/[matching-path]/
✓ Created source-documents folder: static/source-documents/[matching-path]/

Supporting Assets​

✓ Copied images to figures folder
✓ Selected figure naming standard (A or B)
✓ Copied videos/GIFs to videos folder (if applicable)
✓ Created bib.json in bibliographies folder (if citations needed)
✓ Copied source files to source-documents folder

MDX Files​

✓ Created 00-document-info.mdx with DocumentMetadata
✓ Created 00-version-history.mdx with TableVersionHistory
✓ Created 01-preface.mdx with title "Preface"
✓ Created additional chapter files with proper numbering
✓ All file names use lowercase with hyphens
✓ Front matter complete in all files

Registration​

✓ Added an entry to src/docConfig.js for the new document
✓ Set active: false, draft: true for initial state

Testing​

✓ Ran npm start without errors
✓ Sidebar generates correctly
✓ All chapters appear in correct order
✓ Clicked through every chapter
✓ All figures display properly
✓ Videos/GIFs play correctly (if applicable)
✓ Citations render correctly (if applicable)
✓ No console errors in browser developer tools
✓ Internal links work

Pull Request​

✓ Pushed branch to remote
✓ Opened PR via GitHub web interface or IDE
✓ Filled in PR template description
✓ Identified the one document and its doc_location ✓ Verified the controller summary shows administrator classification and assignment ✓ Verified preview URL builds and displays the new document
✓ Recorded special navigation, component, or timing needs in the PR

Next Steps​

After completing this walkthrough:

Questions? Contact site administrators or refer to the other chapters in this documentation guide for detailed information on specific topics.

Last updated on