Process to generate or update a doc page — from research to published markdown.
Mode A — Feature Name (default): input is a feature name (e.g. "Flows", "HSM Templates", "Speed Send").
Mode B — PR Number: input matches #\d+, a GitHub PR URL for glific/glific-frontend, or a commit range.
Read what's needed for the task:
sections.md— to determine which of the 8 sections the content belongs instyle-writing.md,style-page.md— for writing conventions and templatesstyle-images.md,screenshots.md— for image handling and screenshot recipes
Mode A — Feature Name:
- Find the container:
../glific-frontend/src/containers/{FeatureName}/ - Read the main list and form components (e.g.
FlowList.tsx,Flow.tsx) to understand what the UI shows and does - Read
../glific-frontend/src/routes/AuthenticatedRoute/AuthenticatedRoute.tsxto find the URL route - Check existing docs in
docs/for the feature (search for the feature name in file names and content) - Optionally read
../glific-frontend/src/graphql/queries/{Feature}.tsto understand what data the feature displays - If user-observable behavior is unclear from the UI alone (defaults, validation rules, limits, why an action is blocked/allowed), read the backend:
../glific/lib/glific/{feature}/and../glific/lib/glific/{feature}.exfor domain logic,../glific/lib/glific_web/resolvers/{feature}.exand../glific/lib/glific_web/schema/{feature}_types.exfor what each query/mutation exposes. Translate findings into plain user-facing language — never document internal architecture.
Mode B — PR Number:
gh pr diff #PR_NUMBER --repo glific/glific-frontendto see what changed- Identify affected containers from the changed file paths
- Read the changed files in full to understand new behavior
- Check existing docs for the affected area
- If the PR is in the backend repo (
glific/glific) or the frontend change depends on backend behavior, rungh pr diff #PR_NUMBER --repo glific/glificand/or read the relevant../glific/lib/...files (see the backend paths above) to understand the user-observable change
Use sections.md to map the feature to the right section. For Product Features, check the existing numbered file list to determine the next number.
Print the placement plan and ask the user to confirm before writing anything:
Placement plan:
- Doc: docs/{section}/{filename}.md
- Images: static/img/{feature}/
- Action: {new page | update existing | add sub-page to existing dir}
- Recipe: scripts/recipes/{feature-slug}.yaml ({exists | needs creating})
Check for an existing recipe at scripts/recipes/{feature-slug}.yaml.
Recipe missing → create it. Read screenshots.md for the exact format. Find data-testid values in the relevant container files.
Recipe exists → review it against what you read in step 3. Add or update flows for any user path the doc will reference. Fix selectors if the UI has changed.
Then run:
node scripts/screenshot.js {feature-slug}Verify all expected files land in static/img/{feature}/. Iterate on any selector that misses — never ship a doc that references a non-existent image.
Use :::info Screenshot coming soon only when the feature requires backend data that cannot be seeded (e.g., live WhatsApp delivery receipts, billing pages).
Choose the correct template from style-page.md based on the section. Save to the confirmed path from step 4.
Follow style-writing.md for voice and format. The most common mistake: writing for a technical audience. Imagine explaining this to an NGO field worker on their first day.
- All images referenced in the doc exist in
static/img/{feature}/ - Image paths use
/img/prefix (Docusaurus convention), notstatic/img/ - No new GitHub CDN image URLs (only old untouched pages keep those)
- Page header has the read-time badge and difficulty level
- Page matches the correct section template from
style-page.md - Numbered file prefix is correct and doesn't conflict with existing files
Documentation generated:
- Doc: docs/{section}/{filename}.md
- Images: static/img/{feature}/ ({N} screenshots captured)
- Recipe: scripts/recipes/{feature-slug}.yaml
Next:
1. Preview: yarn start (in this repo)
2. Review at http://localhost:3000/docs/{slug}
3. Commit doc + recipe + screenshots together, then open a PR