[ENG-875] GH-AW to generate concept and flow documentations

.claude/skills/care-concept-doc/SKILL.md

@@ -76,3 +76,7 @@ A `_clinical_data` split, role lists, and slug names differ between Care version
 ## Conventions (shared with reference docs)
 
 Read `references/conventions.md` before writing for: domains & slugs, the link rule (`.mdx` everywhere except the translated `patient`/`create-patient`), MDX safety (no `{#…}` heading ids; wrap `{ }` in backticks), 3.0≡3.1 mirroring, and the `npm run build` (all locales) gate. Then return here.
+
+## Language
+
+Write every sentence in **ASD-STE100 Simplified Technical English** — read `references/ste.md`. In short: active voice, present tense, one instruction per sentence, ≤25 words in prose, one term for one thing (taken from `care_fe/public/locale/en.json`), and never a codebase literal where a user-facing label exists ("In Progress", never `in_progress`). A concept is read by clinicians and operators, so this applies to the whole page.

.claude/skills/care-concept-doc/references/ste.md

@@ -0,0 +1,68 @@
+# Simplified Technical English (ASD-STE100)
+
+All authored prose in the Care docs follows ASD-STE100 Simplified Technical English.
+The goal is documentation that reads the same way every time, translates cleanly into
+Malayalam, and cannot be misread by a clinician in a hurry.
+
+## Where it applies
+
+| Layer | Applies to |
+| --- | --- |
+| Concept | Every sentence. Concepts are read by clinicians and operators. |
+| Flow | Every sentence. Steps are the strictest case. |
+| Reference | All prose, admonitions, and section intros. **Not** the field and enum tables — terse noun-phrase cells are correct there, and STE explicitly prefers tables to prose for structured data. |
+
+## Sentence rules
+
+- Maximum 20 words per sentence in procedures (flow steps).
+- Maximum 25 words per sentence in descriptive prose.
+- One instruction per sentence. Do not chain actions with "and then".
+- One topic per paragraph. Maximum 6 sentences per paragraph.
+
+## Voice and tense
+
+- Use active voice. Write "Care creates a patient record", not "A patient record is
+  created by Care".
+- Use present tense. Write "Care assigns an identifier", not "Care will assign an
+  identifier".
+- Use the command form for instructions: "Select **Patients**.", "Enter the phone number."
+
+## Words
+
+- **One term for one thing, everywhere.** Take the user-facing term from
+  `care_fe/public/locale/en.json` and never alternate with a synonym: pick "facility"
+  and never switch to "hospital"; pick "encounter" and never switch to "visit".
+- Use simple, common words: "use" not "utilize", "start" not "initiate", "show" not
+  "display" or "render", "end" not "terminate", "about" not "regarding".
+- No jargon, idioms, or Latin abbreviations (`i.e.`, `e.g.`, `etc.`, `via`). Write "for
+  example" and "such as".
+- No vague quantifiers ("some", "several", "various") where a number or a list works.
+- Spell out what a pronoun refers to whenever there is any ambiguity. Prefer repeating
+  the noun over writing "it".
+
+## Structure
+
+- Use a list for more than two items or steps.
+- Use a table for field, attribute, status, and permission descriptions.
+- Put the condition before the instruction, never after: "If the patient has no phone
+  number, enter the emergency contact number."
+- Put a note in a Docusaurus admonition (`:::note`, `:::info`, `:::warning`) rather
+  than inline prose.
+
+## Forbidden
+
+- Future tense ("will") and conditional hedging ("should be able to", "may want to").
+- Passive constructions: "can be configured" → "you can configure".
+- Nominalizations: "perform the registration of" → "register".
+- Marketing language: "powerful", "seamless", "simply", "easily".
+- Codebase literals in user-facing text: write "In Progress", never `in_progress`;
+  write "create an encounter", never `can_create_encounter`.
+- Data-model phrasing where a user situation fits: write "The patient is registered in
+  Care", not "The patient record exists in Care".
+
+## Why it matters here
+
+Only the patient docs are translated into Malayalam today, but the whole site is built
+for both locales. Long sentences, chained clauses, and synonym drift are what make a
+docs site expensive to translate and easy to misread. Writing to STE now keeps that
+cost down and keeps the English unambiguous in the meantime.

.claude/skills/care-flow-doc/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: care-flow-doc
+description: >-
+  Use when creating or updating a FLOW doc (the "How do I…?" task layer) for the
+  Care docs site. Trigger when adding a walkthrough for a user task (register a
+  patient, close an encounter, dispense a medication), when a Care UI change alters
+  the steps of an existing task, or when the user says "write a flow for X",
+  "document how to do X", "the steps are out of date", or "this flow is missing".
+  Covers the quality bar (create-patient), the page structure, sourcing steps from
+  care_fe rather than guessing, the manual flow sidebar, link/MDX conventions,
+  3.0≡3.1 versioning, and build validation.
+---
+
+# Building Care flow docs
+
+A **flow** answers _"How do I…?"_ — it walks a user through one task in the product,
+start to finish. It is neither a concept (what a thing _is_) nor a reference (what
+fields it _has_). A reader arrives at a flow with a job to do.
+
+Flows live at `versioned_docs/version-3.0/flows/<domain>/<slug>.mdx`, mirrored to
+`version-3.1`. One task per page.
+
+## The quality bar
+
+The gold standard is `versioned_docs/version-3.0/flows/clinical/create-patient.mdx`.
+**Read it every time.** Study how a good flow:
+
+- Opens with one sentence naming the task and its end state ("the minimum path from
+  search to a saved record ready for an encounter").
+- Pulls the conceptual background out into a `:::info Prerequisite` admonition linking
+  the concept, so the steps stay uncluttered.
+- Separates **what you need before you start** from **the steps themselves**.
+- Numbers steps as `### 1. <imperative>` and keeps each one to a single decision.
+- Uses a table when a step has a set of fields, not a wall of prose.
+- Ends with what the user can do next, and the API equivalent for implementers.
+
+## Naming
+
+The slug is a kebab-case verb phrase: `create-patient`, `close-an-encounter`,
+`record-a-symptom`. The H1 matches it in sentence case: `# Close an encounter`.
+Use the same `<domain>` folders as concepts and references.
+
+## Page structure
+
+- Frontmatter: `sidebar_position: <n>`.
+- `# <Verb phrase>` then one or two sentences stating the task and its end state.
+- `:::info Prerequisite` — link the concept(s) a reader should understand first.
+- `## Before you start` — required permission in plain words, prior records the task
+  depends on (an encounter needs a patient), and any deployment configuration that
+  changes the task.
+- `## Steps` — `### 1. <imperative>`, one decision per step. Give the real navigation
+  path and the real button labels. Use a `| Field | Notes |` table for form fields.
+  Mention a keyboard shortcut only if `care_fe/src/config/keyboardShortcuts.json`
+  actually defines one for that action.
+- `## After <the task>` — what the user can do next, as a `| Next step | When |` table.
+- `## API equivalent` — the request an implementer would send, in an ```` ```http ````
+  fence. Take the path and payload from the code, not from memory.
+
+## Sources
+
+1. **`care_fe`** — the flow is a UI walkthrough, so the frontend is primary. Trace the
+   route in `src/Routers/routes/`, the page component, the form schema, and the
+   navigation labels. Take every user-visible string from `public/locale/en.json`;
+   enum display labels use keys shaped `PREFIX__value` (`encounter_status__in_progress`
+   → "In Progress"). Never print a raw codebase value in a flow.
+2. **`care`** — for the permission the task needs and the API equivalent. Trace the
+   viewset's `authorize_*` hook to the permission slug the way the concept skill
+   describes; state it in plain words ("a role with **patient create** permission"),
+   not as a slug.
+3. **The matching concept doc** — for the framing you link to, not to repeat.
+
+If the UI does not match what you expected, the flow is wrong or the product changed.
+Report the mismatch; do not write steps you have not verified.
+
+## The flow sidebar is manual
+
+This is the easiest thing to get wrong. Concepts and references are `autogenerated`
+from their folders, so a new file appears on its own. **Flows are not.** After adding a
+flow, append its doc id to the matching domain's `items` array in BOTH:
+
+- `versioned_sidebars/version-3.0-sidebars.json`
+- `versioned_sidebars/version-3.1-sidebars.json`
+
+```json
+{ "type": "category", "label": "Clinical", "key": "clinical-flows",
+  "items": ["flows/clinical/create-patient", "flows/clinical/close-an-encounter"] }
+```
+
+A flow that is not listed there builds cleanly and is invisible on the site.
+
+## Linking
+
+Follow the shared link rule, with one trap specific to flows: `create-patient` is one
+of the two translated docs, so links **to** it must be extensionless
+(`../../flows/clinical/create-patient`). Every other internal link keeps `.mdx`.
+
+## Workflow
+
+### Creating a new flow
+
+1. Read the `create-patient` gold standard.
+2. Trace the task through `care_fe`, and the permission and API through `care`.
+3. Write to `flows/<domain>/<slug>.mdx`.
+4. Add the doc id to both sidebar files.
+5. Mirror to 3.1, then build.
+
+### Updating for a product change
+
+1. Decide what changed: the steps (UI moved, labels changed), the prerequisites
+   (permission or configuration), or the outcome.
+2. Update only the affected sections; preserve the rest.
+3. Mirror to 3.1, build, and report what changed.
+
+## Conventions (shared with concept and reference docs)
+
+Read `../care-concept-doc/references/conventions.md` before writing for: domains &
+slugs, the link rule, MDX safety (no `{#…}` heading ids; wrap `{ }` in backticks),
+3.0≡3.1 mirroring, and the `npm run build` (all locales) gate. That file is the single
+copy — do not fork a third version of it here.
+
+## Language
+
+Write every sentence in **ASD-STE100 Simplified Technical English** — read
+`../care-concept-doc/references/ste.md`. Flows are the strictest case:
+
+- Steps are commands: "Select **Patients**.", not "The user should select Patients."
+- One instruction per sentence, ≤20 words. Never chain with "and then".
+- Condition first: "If the appointment has no linked encounter, select **Start
+  Consultation**."
+- One term for one thing, taken from `care_fe/public/locale/en.json`.
+- Write the user's situation, not the data model: "The patient is registered in Care",
+  not "The patient record exists".

.claude/skills/care-reference-doc/SKILL.md

@@ -85,3 +85,9 @@ Read `references/conventions.md` for the full detail on:
 - **Build validation** — `npm run build` (all locales) is the authoritative gate.
 
 Always read that file before writing, then return here.
+
+## Language
+
+Write prose in **ASD-STE100 Simplified Technical English** — read `../care-concept-doc/references/ste.md`. Active voice, present tense, ≤25 words per sentence, one term for one thing, no marketing language and no hedging.
+
+This applies to the page intro, section intros, admonitions, and any explanatory paragraph. It does **not** apply to the field, enum, and spec tables: terse noun-phrase cells are correct there, and STE itself prefers a table to prose for structured data. Keep the type notation (`CharField(100), nullable`) exactly as the code has it.

.github/aw/actions-lock.json

@@ -0,0 +1,14 @@
+{
+  "entries": {
+    "actions/checkout@v4": {
+      "repo": "actions/checkout",
+      "version": "v4",
+      "sha": "11d5960a326750d5838078e36cf38b85af677262"
+    },
+    "github/gh-aw-actions/setup@v0.85.4": {
+      "repo": "github/gh-aw-actions/setup",
+      "version": "v0.85.4",
+      "sha": "2709137ea6c5b0e19aa621454dc643ea8dc526b1"
+    }
+  }
+}