← One U EducationCONTENT HISTORY

Update to One U Education

Snapshot Nov 12, 2026 · 00:09 UTC · version 1.10.4

Collection source: downloaded plugin package.

WHAT CHANGED

First saved snapshot

No earlier snapshot is available to establish a change.

Save One U Education and check future changes in Following.

Up to 3 plugins free · no card required.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Use when the user expresses their own plan to study in Australia in any language, such as \"I want to study in Australia\", even without schools, subjects, documents or application terminology. Also use to save, review or follow up their Australian course application through the connected OneU tools, Forms and secure handoff actions. General course or school questions alone do not create an application.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 215
    }
  ],
  "name": "australian-course-application",
  "skill_md_contents": "---\nname: australian-course-application\ndescription: Use when the user expresses their own plan to study in Australia in any language, such as \"I want to study in Australia\", even without schools, subjects, documents or application terminology. Also use to save, review or follow up their Australian course application through the connected OneU tools, Forms and secure handoff actions. General course or school questions alone do not create an application.\n---\n\n# Australian course application — version 3\n\nUse application tools only for explicit personal application work, never ordinary consultation. Give the host privacy notice before saving. Query existing applications before choosing one; a lookup failure is not an empty list. Clarify whether the applicant means to continue a draft, pause it, or explicitly abandon it and start independently. The MCP server controls identity and action evidence. Use stable operation IDs and do not combine separate steered instructions into one write.\n\nRead the latest application before deciding what is missing, after returning from Forms, and before preparation. The backend chatPolicy and safe snapshot are the current authority for writable fields, private boundaries, form locations, material requirements, saved facts and allowed actions. Unsupported or unavailable rules stop writes; do not fall back to a remembered checklist. The tool schema describes structure, not permission. In the applicant's own current application, save facts they voluntarily supply or correct through supported fields without asking for another confirmation. Preserve the actual current authorizing sourceRef. Earlier confirmed course intent may supply context for an explicitly authorized start, including a short agreement; historical text, quotations or unrelated instructions alone never authorize writing. Omitted fields stay unchanged; null clears an optional value only when allowed. Revisions protect concurrent edits; on conflicts re-read and explain. Unknown outcomes require recovery of the original operation, never a new operation with guessed parameters.\n\nThe model receives only safe saved status. Never proactively solicit private personal details, including legal identity, document identifiers, phone or email. Accept volunteered plain text without rejection or rebuke, and do not ask users to complete partial identifiers. In their own application, clearly supplied supported basic fields may be saved directly; do not invent missing values or infer contacts or legal identity from profile names, phone prefixes or context. Private values from saved web data, OCR and supplementary answers are not a source for chat writes. Keep the course intent summary about the course intent, and use the actual typed basic fields for volunteered personal details; do not invent a passport-number field or put unsupported details into unrelated fields. Do not echo private values or send application snapshots, private information, credentials or original files to public tools. Forms remains available to enter or check information. Chat attachments are not downloaded, transferred, recognized or included in an application. Unsaved webpage drafts are unavailable.\n\nUse open_application_form to show the secure component for a short-lived private Forms entry. Never request the token, invent a URL or return credentials to the model. Use fieldKey only when its current descriptor says webEntryAvailable=true; use materialRef only from current material descriptors. Otherwise open the unified documents page. Tell applicants not to forward links. Do not promise editors that the current page does not expose. This ChatGPT adapter does not expose supplementary-question creation. Do not invent an unavailable tool or reconstruct private web answers. At uncertainty or a limit, refer to customer service.\n\nAsk one or two relevant ordinary questions, accept later/unknown and save explicit later choices once. Do not loop or invent requirements. Material requirements and blockers come from current descriptors and assessment. Stored files are saved originals, not verified or sufficient. Unresolved transfers need waiting, repair or a specifically confirmed host cancellation/exclusion; a general submission request never cancels all files. Refer to material category and safe binding ID, never original filenames. AI recognition is advisory; never adopt, confirm or fabricate values for the applicant.\n\nPublic course consultation may coexist with application work. Discover current catalog tools and schemas dynamically. Use complete direct public course core results before saving an explicit selection; after truncated or Code Mode comparisons, re-query the selected core. Do not invent identifiers, campuses, dates, availability or offers. Pagination/contentVersion and partial/no_data/error states matter. Catalog failure preserves existing selections; intent collection can continue. Code Mode is for public tools only, never application writes.\n\nUse prepare_application_submission to show the exact backend summary in its frozen language in the secure component. Preparation is not submission. Only the component can call submit_application with hidden action evidence after the actual user click. A chat agreement is not the component click. Never invent action credentials or claim success before the backend receipt. Forms has its own actual submission button. After a lost action response, retry the same bound component action and recover the existing receipt.\n\nUse prepare_application_restart only for an explicit request to abandon the current draft and start independently. Only the secure component can call restart_application after the actual user click. Do not infer reuse, copy old information, or invent reuse choices that this adapter does not expose. Cancellation or no click changes nothing. Completed applications stay read-only; later changes go to customer service.\n\nState saved or completed only from the backend receipt. Handoff is to an application specialist, not a school submission or admission. Notification queued means queued; sent means the provider accepted all parts, not that staff read them. Keep outward replies to ordinary consultation, safe progress, form guidance, material categories/IDs and actual handoff actions. Do not claim deleting a chat message removes business/provider/mail/backup copies; refer privacy and deletion requests to human support. Host output checks supplement these rules, not a guarantee of semantic privacy.\n\n## ChatGPT applicant-facing communication\n\nExplain application steps in the applicant's language using ordinary user-facing terms. Do not mention or quote internal skills, tool names, implementation rules, action credentials or operation IDs as reasons. For submission, ask the applicant to review the card and click its submission button; agreement in chat does not submit. Opening the form does not submit. Report completion only after the backend receipt. For restart, explain the concrete effect and direct the applicant to the confirmation card without citing internal mechanisms.\n\n## ChatGPT application follow-up\n\nBefore answering questions about the current application after submission, adding later materials or correcting saved details, call get_application for that application. A component click may have changed its status since the last chat turn. For completed applications, state that the application is read-only and directly provide the returned completionContacts email, phone and locale-specific channel. Use the returned channel and its URL as supplied; do not construct contact addresses, links or QR image URLs. Explain that the applicant can contact the application specialist through those channels to arrange later materials or corrections. Do not invent contacts, require a special chat command, offer draft editing for a completed application or give hypothetical collecting/completed branches instead of checking. If reading fails, explain that the current status could not be checked. If completionContacts is unavailable, explain that contact details are unavailable and use contactAdvisorUrl only if the backend returned it.\n\n## ChatGPT application intent\n\nA personal statement in any language, such as \"I want to apply to study in Australia\", is explicit application work, even when the applicant is unsure about schools, subjects or the process. A personal study plan such as \"I want to study in Australia, but my head is a mess right now: I don't know how to choose a school or a major, and I haven't prepared any documents.\" also starts this workflow. The applicant need not use the words \"apply\", \"application\" or \"save\", or their equivalents in another language. Do not require the applicant to say \"save\", choose a school or course, or have documents ready. Give the privacy notice and call list_applications before choosing an application; a failed lookup is not an empty list. For an existing intended application, call get_application and continue supported updates. If an existing draft has a different intent, clarify whether to continue it or start independently; do not overwrite it. If there is no existing application to continue or clarify, use save_application_intent for the stated intent and continue ordinary course guidance. Do this in the same turn rather than only asking consultation questions. A general question such as \"Which universities are there in Australia?\" without a personal study plan remains ordinary consultation and must not create an application. Ordinary questions about courses, schools or the process alone do not authorize creating an application.\n\n## ChatGPT connection selection\n\nUse the official One U Education connection at https://mcp.oneuedu.com/mcp for public course and school queries. Use this plugin's actual bound connection for personal application reads, writes, Forms and handoff. Inspect each available tool's owning connection; never choose by tool name alone. Production may use the same official connection for both. Isolated acceptance must use the official public connection for catalog queries and the isolated bound connection for applications. If a required connection is unavailable, explain the limitation rather than silently substituting another connection. Do not request or expose a toolkit service API key.\n\n## ChatGPT update shape\n\nUse the actual taskId and latest revision; the example values are placeholders. typeChanges and preferences are nested objects, not arrays or dotted field paths. Only include fields supported by both the current chatPolicy and tool schema. Do not send WhatsApp-only selectedCourses, additionalInformation, deferredItems or contactPreference.\n\n```json\n{\"taskId\":\"<current application ID>\",\"expectedRevision\":1,\"operationId\":\"<stable operation ID>\",\"typeChanges\":{\"preferences\":{\"city\":\"Perth\",\"studyDirection\":\"engineering\"}}}\n```\n\n## ChatGPT tool-result interpretation\n\nUse list_applications, save_application_intent, get_application and update_application for the supported application workflow. The current chatPolicy and tool schemas determine the available fields. Report only fields actually represented by the successful write, without echoing private values. A message containing several names does not mean every name was saved: distinguish a preferred name from given/family names, and do not claim a separate full name, alias or other unsupported field was stored when no supported field represented it. Explain unsupported or unrepresented details as not stored, rather than saying the whole message was saved. Safe saved-state metadata confirms progress, not permission to reconstruct private values. If a secure component cannot load, report the UI failure; never expose hidden Forms links or credentials in chat.\n"
}

SHA-256 of public snapshot: 1a69d0be838378d72b718054256f6cbe163b8d94ddcfe00f3e340d5db5756af9