Update to Field Service Cloud Workflows

{
  "description": "Prepare a client-facing monthly landscape service report from Field Service Cloud records, with service highlights, inspections, irrigation or enhancement work, relevant follow-up, and verified photo captions. Use for Word/PDF client reports; internal management reviews use Field Service Cloud Operations.",
  "included_files": [
    {
      "relative_path": "references/connector-guidance.md",
      "size_in_bytes": 13164
    }
  ],
  "name": "field-service-cloud-monthly-client-report",
  "skill_md_contents": "---\r\nname: \"field-service-cloud-monthly-client-report\"\r\ndescription: \"Prepare a client-facing monthly landscape service report from Field Service Cloud records, with service highlights, inspections, irrigation or enhancement work, relevant follow-up, and verified photo captions. Use for Word/PDF client reports; internal management reviews use Field Service Cloud Operations.\"\r\n---\r\n\r\n# Field Service Cloud monthly client report\r\n\r\nAn explicit per-item translation request follows the connector guidance's labelled Original/Translation exception and does not prepare or generate a report. Preserve source text and report selections, edited sections, office notes and captions. Ordinary reports use the requested output language without unsolicited bilingual output.\r\n\r\nBefore retrieving or interpreting records, read the bundled [connector guidance](references/connector-guidance.md). This Monthly skill owns the client audience, report routing, necessary follow-ups, photos and file-delivery requirements. Its bundled reference works in a standalone import; do not load Operations or inherit that skill's three-call ceiling.\r\n\r\nPrepare a customer-ready monthly service report for the landscape company's office to approve before sharing with a property manager or HOA. Use the client's requested template and branding when supplied. This skill defines the report audience and layout; it does not send the report, schedule work, or change Field Service Cloud records.\r\n\r\nThe account manager may use a short request such as `Please prepare the August 2026 monthly client report for Rose HOA.` Do not require the user to name connector operations, callbacks, attachment IDs, or document-production steps. Apply the evidence, writing, photo, and review rules below automatically.\r\n\r\nFor requests from the Field Service Cloud workspace, keep its selected property ID, month and selection key. Reuse matching workspace records; for missing context use the shared primitive reads with that exact property ID, including property recap, task/form pages, exact task details and selected photos as needed. Do not re-resolve the selected property through the name-based monthly workflow. When the user explicitly asks to review proposed content before generating files, apply this skill's factual and client-audience rules, then present the proposed sections, separate office notes, report style and selected photo/caption choices through `review_report_content`. Preserve office edits during refinement and verify captions against the associated work. This explicit review stage stops before file production. When the user selects Generate files, complete the existing production, final viewer checks and three-file delivery below using the reviewed content; the interface handoff alone does not establish readiness.\r\n\r\nUse the everyday language of a landscape maintenance company throughout the workflow and every generated artifact. Prefer familiar terms such as maintenance crew, crew leader, route, property or jobsite, scheduled service, maintenance visit, irrigation work, enhancement, inspection, customer request, recommendation, and follow-up. Translate internal database, API, analytics, billing, and status categories into the appropriate landscape-service meaning; do not make the account manager or customer interpret system labels. State what work was performed, what condition was found, what remains proposed or scheduled, and what decision or follow-up is needed. Do not sound like a data export or audit report merely because the source provides record counts.\r\n\r\n## Complete an ordinary short request\r\n\r\nFor a workspace request, copy its `selectedTaskNumbers` into the review render input and include issue prose only for those numbers. Empty selection means service/inspection content without issue narrative. Declared `sourceTaskNumbers` must belong to the selection, and the actual prose must also exclude unselected issues. Preserve choices and office wording through refinement; after a changed issue selection, produce updated content without discarding unrelated edits. Preserve independent `selectedPhotos`, including a chosen photo from an issue excluded from prose. Image captions use verified photo evidence, not an implied task completion. Ordinary chat reports keep their existing routing.\r\n\r\nA one-line account-manager request starts the whole report workflow. Complete these checks before saying the files are ready; do not stop at an evidence summary, unshared workspace files, or a request for routine production instructions.\r\n\r\n1. Resolve the jobsite and month. Read the monthly evidence, the completed- and updated-date task sets, and relevant form answers. Reconcile their coverage and keep service visits distinct from tasks.\r\n2. Decide the customer story from saved descriptions, dates, status, and findings. A request to prepare a proposal remains a request until a separate proposal or send record proves otherwise; a workflow label such as `Sent to Customer` is not that proof. A manager-category visit proves a recorded visit, not a walkthrough or inspection, and a closed task does not prove a site inspection, diagnosis, or repair outcome. Keep uncertain record relationships and office verification out of the client file.\r\n3. Select relevant, nonduplicative photo IDs from attachment metadata before requesting bytes. Include enough photos to explain the material work and site conditions and follow the requested template; there is no fixed photo count or report-wide maximum. Retrieve selected photos in batches within the tool limits. If a selected photo is unusable, choose a relevant replacement when available; stop when the report has sufficient verified coverage. Use only supported or neutral captions.\r\n4. Write roughly **300–600 words** of useful landscape-maintenance client narrative, excluding captions and a compact service-count table. Consolidate routine work and describe supported site conditions, completed work, customer decisions, and next steps in natural service language. Move source-reconciliation cautions, missing-record explanations, uncertain task relationships, and billing paperwork to the office note. State a pending customer request once; do not turn a workflow status into a sent proposal, a visit into a task-specific inspection, or task closure into customer-facing closure language (`wrapped up`, `resolved`, `addressed`, or equivalent) when no dated finding or work outcome records what was done. If the concern still matters, state only the supported concern and a neutral next step in the client report; keep the closure date and evidence gap in the office note. Do not promise unscheduled work or pad a sparse month.\r\n5. Build the editable Word report, matching PDF, and separate office note from the final checked content. Open the final downloadable Word and PDF files in the host viewers and inspect every page; a local conversion screenshot or earlier draft is not final-page proof. Read each viewer page count. Both must show the same count, readable type, real photos with adjacent captions, and no accidental blank pages, unintended sparse content pages, or stranded headings. Intentional cover and closing pages may follow the supplied template. If either final viewer cannot be inspected or the counts differ, correct and recheck before claiming success.\r\n6. Present **three visible downloadable files** in Word, PDF, office-note order. Only then use the exact success sentence specified below. If a required check cannot be completed, name the specific limitation instead of claiming the files are ready.\r\n\r\nFor modern workspace monthly reports, copy `reportType=monthly`, `selectedServiceActivityIds` and `selectedFormResponseIds` into the review tool along with issue and photo choices. If context selects operations, use the Operations skill and its internal editor/file workflow instead of client formatting. Use only selected service rows (`selectedServiceActivities` carries their authorized facts/stable IDs) and selected inspection findings in narrative. Retrieve missing selected inspection answers with exact form response IDs and the selected property/month. Empty arrays exclude that category; absent fields in legacy contexts keep prior all-returned-record behavior. Preserve these choices through refinement and generation. Distinguish selected counts from whole-period aggregates and returned-page coverage, and put intentional exclusions or incomplete coverage in the separate office notes. Do not claim a complete month of service from a partial selection. Photo inclusion is independent of all narrative categories.\r\n\r\n## Report purpose and audience\r\n\r\nThis is a client-ready monthly service update, prepared for the landscape company's office to review before sending to a property manager or HOA. It should answer three questions: what services were completed and what each visit or work item was for; what inspections, irrigation or enhancement work, and site observations matter; and what client-relevant work or decisions remain. Lead with a reconciled service count by supported category, then give purpose-led details and verified photos when available.\r\n\r\nFor recorded service visits, the returned crew category is the authoritative purpose signal. The current API does not directly associate a service visit with a task; never join them by property, date, or coincidence, and never claim that a visit performed a task merely because both appear in the same month. Keep visit evidence and task evidence separate.\r\n\r\nNever copy the internal Operations review format into this report. Do not include `Records needing review`, `Needs attention`, service-review rows, crew or labor analysis, billing queues, or office-only diagnostics in the client files. Put internal checks and evidence gaps only in `Office_Review_Notes.md`. Client-relevant open, proposed, or scheduled work belongs under `Follow-up and planned work` using customer wording.\r\n\r\nUse best professional judgment from the full returned task evidence to decide which work belongs in a customer-facing report. Consider the task subject and type, current `description`, dated `descriptionHistory`, location, form or inspection context, irrigation or enhancement context, attachments and captions, status, and completion evidence. Include a task when it explains a service delivered, site condition, customer request, recommendation, or decision the customer should understand; describe its actual status rather than treating every returned task as completed.\r\n\r\nExclude a task when its evidence clearly shows internal office or administrative work—such as billing or collections, payroll or labor administration, staff or crew coordination, route planning, duplicate or data cleanup, internal reminders, or wording marked internal, office-only, or do not send—and it has no customer-facing outcome. Do not exclude a customer-relevant issue, unfavorable finding, proposed work, or follow-up merely because its status or type is unfamiliar. If the task's audience remains ambiguous, leave it out of the client files, note the omission for office review, and never copy internal wording or details into customer-facing text. Use `descriptionHistory` as dated intent and context, not completion proof; when it conflicts with the current description, treat the current description as authoritative.\r\n\r\nSeparate task IDs do not establish separate projects or separate physical work. Preserve the records for evidence, but when descriptions or locations overlap, avoid a distinct-project total unless the evidence resolves that overlap. Describe the supported work without double-counting it and leave the unresolved relationship for office review. Give each work item one useful explanation; repeat it elsewhere only when adding a distinct finding or decision, not the same description again.\r\n\r\n## Make the report useful every month\r\n\r\nThe acceptance standard is a landscape maintenance account manager who would be proud to send this report to the customer after a brief factual review and would choose to run it every month because it saves meaningful preparation time. A technically correct report that needs a major rewrite, hides important unfavorable findings, or reads like an internal record inventory fails this standard. Use professional judgment to select useful content and a polished, readable layout; customers may customize these instructions for their repeatable reporting style.\r\n\r\nTreat this as recurring client communication, not a one-time evidence dump. Keep the same concise, customer-facing structure and decision rules from month to month while allowing the returned facts to change the content. A useful report lets a property manager quickly understand what services were delivered and why, which site conditions or findings matter, what work remains open or proposed, and which photos or form findings support those statements. When a prior report is supplied for comparison, preserve comparable headings and service-count phrasing without carrying forward facts, tasks, photos, or conclusions that are not returned for the current month. Do not manufacture trends from a single month, and do not claim customer acceptance, distribution, or workflow adoption merely because report files were generated.\r\n\r\n## Establish the evidence\r\n\r\nBefore deciding whether a task belongs, consider its issue type (returned as `typeName`), subject, description and dated description history, checklist item text/completion/notes, attachment descriptions and tags, and relevant form answers. Dated task lists and monthly evidence may show only preview estimate and Items Used lines; check the exact counts and `isTruncated` flags before treating a preview as complete. Retrieve full exact-task detail when omitted descriptions, locations, notes, checklist items, attachment metadata, or work-order lines could change the inclusion decision or materially explain the work. Call the discovered `get_task_data` operation with `mode=work_items`, the returned `taskId`, and the same authorized scope ID, without dates, `dateBasis`, `cursor`, or `includeWorkOrderLines`; exact-ID lookup automatically includes all saved child detail. The `get_named_task_operational_summary` alternative also selects the exact task independently of its context dates; supply its required scope/date context and use actual returned task dates to judge report relevance. Do not retrieve every task's lines when the existing context already answers the question.\r\n\r\nIrrigation history describes saved changes to irrigation-system records. A history update alone is not an irrigation service, site visit, repair, or completion record. Include only a substantive, supported change that helps the customer understand the system or a decision; omit mere record-update dates, configuration record counts, and database housekeeping. Never associate a history update with a service visit by matching property or date, or count it as a separate service.\r\n\r\nThis monthly-report skill controls audience, routing, and retrieval; the Operations skill's three-call ceiling does not apply to a monthly report. Make focused follow-ups for relevant form answers, selected task details, required pages, and selected photo bytes. Batch compatible requests, reuse returned evidence, and stop when the evidence is sufficient. Respect denials, rate limits, and unavailable capabilities; do not repeat an unchanged failed request.\r\n\r\nConfirm the jobsite and calendar month/year from the request or existing conversation. Ask only for missing or ambiguous information needed to select records. If the user supplies a partial month, label the exact period; never present it as a complete month. Preserve the Operations limit of 31 inclusive dates. Do not divide an overlong request into multiple periods.\r\n\r\nStart with the monthly report evidence workflow for the exact jobsite and month when available. Its `payload.tasks` items use the same task shape as `get_task_data` `work_items`, including bounded child previews; the list covers tasks created in that period and is not necessarily all work completed or updated during the month. Before selecting report content, retrieve tasks for the same property and month with `get_task_data` in `work_items` mode using `dateBasis=completed` and `dateBasis=updated`, following returned pages and deduplicating by task ID with the created set. If the initial response explicitly includes these complete sets already, reuse them. Use recorded dates and substantive evidence to decide what belongs in the reporting period; an administrative update alone is not customer-relevant work. Do not infer completion from the date used to retrieve a task. If the available connector cannot retrieve the required scope, identify the specific gap in the office note rather than claiming comprehensive coverage.\r\n\r\nFor relevant forms and inspections, retrieve `get_form_data` with the same property and reporting dates and `includeAnswers=true`; read the recorded answers/results before drafting. Follow returned pagination when needed for accurate coverage and category counts. For selected customer-relevant photos, call `get_attachments` with deduplicated IDs from task or form metadata. Skip unused follow-ups. A summary without answers or a truncated list is not proof that findings or additional work are absent.\r\n\r\nReuse evidence only when its jobsite, period, and requested content match this report. An aggregate spanning different dates cannot become the monthly total. Historical task context can explain current work, but must not be presented as work performed this month. If required evidence remains unavailable, describe the specific gap for the office and avoid unsupported claims in the client files.\r\n\r\n## Jobsite KPI forms, when available\r\n\r\nLook for `formTemplateContext.category` equal to `Jobsite KPI` on eligible form responses, ignoring case and surrounding whitespace. Classify from the returned category, not a form title containing \"KPI\" or an assumed form purpose. The category is form-definition context; the recorded answers/results provide the KPI evidence. Use the existing `get_form_data` property/month filters and pagination; the operation does not currently accept a category filter. Reuse matching retrieved responses rather than make a separate discovery call.\r\n\r\nWhen selected, submitted responses in that category provide reportable results for this jobsite/month, call out those recorded results in a **Jobsite KPIs** section of the client report. Read their answers when needed using `includeAnswers=true`; preserve returned indicator labels, values, units, scores/grades and applicable scale/context. Do not invent targets, units, performance conclusions or trends. Existing client-audience rules still apply. Respect workspace `selectedFormResponseIds`, including an explicit empty array; KPI classification does not override exclusions or justify adding other responses. Draft responses are not submitted KPI results.\r\n\r\nIf no eligible selected, submitted KPI responses exist, omit the KPI section and continue the normal report. This is an optional category: do not block the report, add an empty KPI heading or treat its absence as a problem, and do not create/seed a category or form. Keep unavailable/partially retrieved form data and intentionally excluded or draft responses distinct from confirmed absence in the separate office notes when relevant.\r\n\r\n## Write for the client\r\n\r\nWrite a recurring client communication, not a record inventory. Success means the landscape company's office would be comfortable sending it after a brief factual review, the property manager can understand the month's service and follow-up without decoding records, and the company would choose to produce it again next month. Correct facts are not enough when the reader must search a long list for the point. State each material fact once, consolidate routine work, and prioritize the site outcomes, conditions, decisions, and follow-up that matter to the client.\r\n\r\nKeep the standard client narrative to roughly 300–600 words, excluding photo captions and a compact service-count table. Exceed that range only to preserve distinct safety, property-condition, urgent customer, irrigation, enhancement, or decision items that would be misleading to omit. Routine visit or task volume never justifies a longer narrative. Consolidate the supporting records in `Office_Review_Notes.md`; the customer report should be readable in a few minutes.\r\n\r\nLead with the jobsite, reporting period, and a short **Month in review** conclusion: what regular service occurred, the most meaningful work or site condition, and any customer decision or follow-up that matters. Then use the following sections when relevant evidence is available, omitting empty sections and keeping the main report compact:\r\n\r\n- **Service completed:** Start with reconciled category counts only when the returned records directly support them (for example, `4 maintenance services, 2 manager reviews, and 1 irrigation service`). For recorded service visits, treat returned `serviceCategoryName` (the crew's effective category for that day) as the authoritative purpose signal, group by its exact value, and translate known values into customer language: `Maintenance` means a maintenance service, `Manager` or `Management` means a manager review, and `Irrigation` means an irrigation service. This is visit context, not proof of a task-specific activity or a link to a task. Do not derive a visit's purpose from a same-day task, a task description, a date match, or a property match. For task-backed work, explain what the work item was for using the returned service item/type, task subject/type, form title, irrigation service type, saved location, and the current `description`. When `descriptionHistory` is returned, use it only as dated context when the wording changed or clarifies the task's purpose; it is not completion proof. Keep recorded visits distinct from completed tasks, do not add one visit to a task count, and do not invent a category when purpose detail is absent. If `serviceCategoryName` is null and no other purpose detail is returned, say that the purpose of that visit was not identified and put the gap in the office notes. A saved status or photo label alone is not proof that a task was completed; keep incomplete or proposed work in follow-up rather than listing it as completed.\r\n- **Inspections and observations:** Saved inspection dates, scores, findings, and related tasks. Do not infer passing, compliance, or resolution from a score or missing answers.\r\n- **Irrigation and enhancements:** Supported work or recorded findings, grouped by task and location, with relevant verified photos. Preserve separate task evidence in the office note; in the client report count separate repairs only when independent evidence establishes distinct physical work. When an irrigation task is at Estimate and no independent completion evidence was returned, describe only the inspection, findings, and proposed or estimated work. Do not say or imply in the summary or task details that irrigation work was performed, repairs were made, or repairs were completed. Photos and before/after captions do not change that status.\r\n- **Follow-up and planned work:** Client-relevant open work, decisions needed, or explicitly recorded future dates. Use three to five concise grouped items by default, retaining every distinct material safety, property-condition, urgent customer, irrigation, enhancement, or decision item even when that requires more. Distinguish recommendations from approved or scheduled work. A task requesting a proposal does not establish that a proposal has been prepared, sent, approved, or scheduled; describe it as a request until separate proposal evidence confirms its status. Never add a generic `Records needing review` section or copy internal service-review rows into the client report. If no due date is returned, do not promise one or say no schedule exists.\r\n\r\nWithin each section, group related routine service and describe meaningful outcomes rather than listing every visit, task, form, or photo. Retain every material safety, property-condition, customer-request, irrigation, enhancement, or decision item. Use only the few examples needed to make the month's work concrete; additional internal verification and record-level detail belong in `Office_Review_Notes.md`, not in the client narrative. State each task or condition once; later sections may refer to the group but must not repeat the same description. Before rendering, ask whether a property manager can understand the month in a quick scan and whether the landscape company's office would willingly repeat this report next month. If it reads like a task export, audit, or long list of equally weighted items, rewrite it.\r\n\r\nUse plain, professional language grounded in the records. Use each task's descriptive subject and relevant location in client copy; never expose internal task IDs or other record identifiers. Treat `Ready to Invoice`, `Estimate`, `Closed`, `Reported`, and similar values as internal-only and never print them verbatim in either client artifact. Describe completed work only from independent completion evidence (a completion date, or a substantive completion description/history corroborated by a photo or form finding). A historical completion date does not override a reopened current status; distinguish work documented on that date from remaining open follow-up. Keep billing state and paperwork in the office note. If completion evidence is absent, do not present the work as completed; describe a customer-relevant pending request or proposed work under follow-up, and put uncertain completion timing in the office note. A workflow status such as `Estimate` does not prove a proposal exists or was sent. Do not turn review-only records into a missed-service claim. Unless the user explicitly asks for them in this client report, omit crew names, crew-leader names, account-manager or inspector names, employee names, role attribution (for example, “by Steve Walker”), labor hours, crew-hours, visit duration, labor analysis, and staffing detail from both client files. A manager-category visit may be described by its customer-facing purpose (for example, “management review”) but never by the employee who performed it. This rule overrides any staffing or labor fields present in the recap and any Operations guidance. Leave billing follow-up, margins, staff criticism, and office-only notes out of the client draft unless the user explicitly requests appropriate content for that audience.\r\n\r\nBefore rendering, run a client-terminology pass over the complete Word and PDF content. Replace or remove every raw internal status, `Records needing review`, `Needs attention`, tool/API term, ID/code, storage filename, or office-only diagnostic. A client artifact must contain the customer wording above or an evidence-based neutral phrase, never the internal label that produced it. The client title, headings, body, captions, and filenames must not say `Draft`, `This draft`, `For office review`, `Prepared for office review`, `Office Review`, or similar production-process language; keep approval checks and evidence limitations only in `Office_Review_Notes.md`.\r\n\r\nNever equate missing information with zero work, no issues, or disabled tracking. When evidence is missing, omit the unsupported claim. If omission would conceal a material site condition or customer decision, report only the supported condition or pending request and put the evidence gap and verification request in the office note. Put detailed verification requests and internal billing notes in a clearly separate office-review note after the files, not in the client document or the short file-delivery paragraph. Never expose tool names, API modes, operation or call counts, limits, budgets, retries, retrieval strategy, raw codes, account identifiers, internal attachment filenames, or phrases such as `per policy` in the client files, delivery text, or office note. Use judgment about status updates while retrieving records or creating documents. Keep those updates out of the finished file-delivery message, client files and office note; those outputs contain only the required delivery text, client-ready facts and specific office checks.\r\n\r\n## Photos and document production\r\n\r\nFor workspace generation, respect fileFormat: both produces Word plus matching PDF; word produces Word only; pdf produces PDF only. Missing legacy choice means both. Always create separate office review notes, inspect every requested report/viewer page and deliver the actual requested formats in Word/PDF/notes order. Copy fileFormat during draft/refinement rendering so a fresh panel retains the choice. Office review and generation do not imply approval or sending.\r\n\r\nUse explicit paragraph/line spacing and image dimensions, with enough space that small renderer differences do not strand a section on an extra page. Do not rely on one conversion engine's page count as proof of the Word viewer's pagination. Keep the layout compact by removing repetition, not by shrinking text below a comfortable reading size.\r\n\r\nIn the final file-presentation step, explicitly order the files Word, PDF, then office notes. Creation order alone may not determine the order of the displayed file cards.\r\n\r\nSelect the strongest customer-relevant photos before requesting bytes, including a useful before/after pair when supported. Let the material work, distinct site conditions, and supplied template determine the number of photos, rather than a fixed count. Do not fetch every attachment by default or repeat visually identical photos. Use the saved date and task context to establish that a photo is relevant to the reporting period; an attachment saved later is not automatically evidence of work during this month. Each included photo should explain relevant work or a site condition, or serve a clear purpose in the requested template.\r\n\r\nUse the host's available Word/PDF creation capabilities. For every monthly report, provide an editable Word client report, a matching PDF, and a separate internal `Office_Review_Notes.md`. If the required file-creation capabilities are unavailable, state the specific limitation instead of claiming completion or using the success response below. Do not claim an artifact exists until it was generated and checked.\r\n\r\nAttachment items return a machine `attachmentId`, saved description, date, and nullable `tag`; they do not return storage URLs or filenames. For selected document photos, call the separate authenticated `get_attachments` operation with the selected IDs. The image content contains the original photo bytes, plus a caption/status manifest. Copy the exact saved-file path exposed by the host for that fresh image response, or decode its directly accessible base64 image data, into the document workspace before creating Word/PDF. Use the manifest's actual image MIME type and verify that the saved file's byte length matches the returned `byteLength`. If a batch does not expose usable files or bytes, retry the affected selected photos once in smaller batches, such as a before/after pair; this is not a report-wide photo limit. Do not search session transcripts or logs, fetch storage URLs, reconstruct a photo from its visual appearance, reuse previous report files, or ask the account manager to upload or manually insert it. Embed only these returned photo bytes and verify actual images in both formats, not caption-only placeholders. If the host still does not expose usable bytes, state that specific limitation instead of claiming client-ready completion; do not use the success response below. Record affected saved descriptions and tags in `Office_Review_Notes.md`. Treat each manifest item as the source of its caption and association; custom tag inclusion/exclusion is not implemented. Never fabricate pictures, reuse unrelated photos, expose storage identifiers, or claim a photo was embedded when it was not.\r\n\r\nUse saved attachment descriptions as captions, preserving the task and relevant location. Label before/after only when supported by saved descriptions or explicit user-provided mapping. An attachment date, task association, or visual contrast alone does not establish before/after or that the pictured work was completed; if the saved description is empty, use a neutral caption limited to visible content, supported task context, and date. Group related photos without cropping away the work evidence. If visual inspection leaves a material doubt about a photo's caption or association, omit that photo from both client files and record the reason only in the office notes. Do not include a photo you have identified as questionable and ask the office to replace it later. Retain any written finding independently supported by the task or inspection; a photo that does not show the defect is not proof that the defect is absent. Omit internal filenames and storage identifiers from the report. Keep any necessary photo-source note factual and brief.\r\n\r\nFollow a supplied reference layout; otherwise use a compact property/date header, readable section headings, and photos with adjacent captions. Let content determine page count. Keep captions with images and task headings with their content. For ordinary content pages, use keep-with-next/keep-together and compact spacing to avoid stranded headings or unreadable blocks. Honor intentional cover pages, closing pages, and section breaks in a supplied template; their deliberate whitespace is not a layout defect. Accidental blank pages and unintended sparse content pages fail review: after rendering, verify the actual Word and PDF viewers independently, record each observed page count in the office note, and remove any trailing page break or empty paragraph. If the viewer counts differ, or any page is accidentally blank, unintentionally sparse, or strands a heading, the files are not matching or ready; correct the layout and rebuild both formats. Do not treat a footer, source render, or model assertion as page-count proof. Do not fabricate logos, signatures, approvals, totals, or future work promises. Do not print raw attachment URLs in the client report unless the intended audience explicitly needs one; the URL is retrieval plumbing, not client-facing copy.\r\n\r\nBefore delivery, inspect every page of each generated format for clipping, accidental blank pages, image quality, photo/caption pairing, grouping, spacing, and page breaks. Reconcile dates, task statuses, visit counts, form findings, and included photos against the actual evidence. The Word and PDF are customer-ready report files awaiting office approval: do not label either client file as a draft or put office-review/process language inside it. Create the outputs in this exact order: (1) the editable Word client report, (2) the matching PDF, and (3) `Office_Review_Notes.md`. Put all missing evidence and office checks in that third file; keep them out of the client files and assistant prose. The finished file-delivery text must be exactly `Client-ready files prepared for office approval.` with no heading, notes, caveats, process description, or offer before or after it. Present the three files as visible downloadable artifacts in the required Word, PDF, then Office-notes order; workspace creation or screenshots alone do not deliver them. Never send or publish the files on the user's behalf.\r\n"
}