TCFCAN

View saved version →

---
name: attempt-review
description: Review one or a small bounded set of the user's authorized TCFCAN attempts or current listening/reading wrong-book entries. Use when the user asks why an answer was wrong, requests evidence from a specific attempt, or wants a small wrong-answer review; do not use for general progress diagnosis alone.
---

Review only records that TCFCAN returns for the connected account, within one module. Use the selected attempt's module; otherwise ask the user to choose one module before an unspecified or all-module review.

1. If the user selected a recent record, obtain its `attemptRef` from `get_recent_attempts`. For the current listening or reading wrong book, call `get_wrong_book`; do not infer membership from recent attempts.
2. Call `get_attempt_detail` only for the selected reference or a small number needed for the requested review. With no requested quantity, read at most five details.
3. Report current total, list entries returned, details successfully read, and the actual analysis scope as different quantities. Fetch another wrong-book page only when the user asks to continue.
4. For listening and reading, treat only `verified_answer_evidence` as stored evidence supporting the correct answer. A distractor does not need and must not be given a fabricated locator sentence. Treat `question_context` as context, not answer evidence.
5. For writing and speaking, distinguish the user's response, stored TCFCAN feedback, and your new interpretation. Respect every coverage and truncation field; missing feedback or evidence does not prove there was no error.
6. Explain the selected attempts in text and label every new explanation as AI interpretation. Do not automatically request a whole-module diagnosis card after a review.

For a listening or reading error classification, use the same bounded taxonomy as `learning-diagnosis`. Text-visible signals may support a candidate such as number, negation, contrast, scope, relation, synonym, viewpoint, main idea, detail, or over-inference only when the exact relationship can be explained from returned context. The selected option and correct-answer evidence alone cannot establish whether the user knew a word, recognized it in audio, parsed a sentence, or found the source location. Ask one concise question for those distinctions or mark the cause as insufficient evidence. Never turn one classified item into a stable learner weakness.

`attemptRef` is only for attempt detail and `questionRef` is only for practice-question retrieval. Never interchange them. Stop on `RATE_LIMITED`, disclose unread scope, and do not loop, bulk-fetch, or claim a whole-book review from paginated results.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: learning-diagnosis
description: Diagnose a user's authorized TCFCAN learning activity and identify one evidence-bounded priority. Use whenever the user asks to diagnose, assess, summarize, or review recent practice, progress, weaknesses, score changes, or what to focus on next, including vague requests that name no module. For a vague diagnosis request, ask the user to choose listening, reading, writing, or speaking before any TCFCAN tool call. Do not use for reviewing one already-selected attempt or merely saving a plan.
---

Read one module's TCFCAN facts and display its server-generated card in the same call, then explain the diagnosis in text.

Respond in the language of the user's current request unless the user asks for another language.

1. Determine whether the user explicitly requested one module. For unspecified or all-module requests, ask the user to choose from all four: listening, reading, writing, and speaking, before reading TCFCAN facts. Use ChatGPT's native question UI only if it can show all four choices; otherwise ask in plain text with all four choices visible. Do not recommend or preselect a module, or guess from recent activity. Complete one module before starting another independent diagnosis.
2. Call `get_learning_context` once with the selected `module` and conversation `locale`. The single-module call automatically returns the facts and displays the diagnosis card from the same query; no enable flag is required. Never disable the card for a diagnosis. For interpretation, use `current30Days` for the overview and level/task statistics, the non-overlapping current and previous 7-day windows for the short-term comparison, and the 30-day comparison only when its display threshold is met. Use question-bank progress, level/set performance, dimension summaries, score standards, and coverage fields as deterministic facts only. Do not copy facts into another tool or call again merely to display the card.
3. Call `get_recent_attempts` only when recent records or a different supported window are necessary. Call it at most once per diagnosis, and reuse that first result for every later selection or comparison in the same diagnosis. Never call it again with the same or broader scope merely to choose detail candidates.
4. If a claim requires question-level evidence, obtain only the few relevant details through `get_attempt_detail`. For a listening or reading wrong-book request, use `get_wrong_book`; do not substitute recent attempts for the current wrong book.
5. Separate recorded facts, deterministic statistics, and AI interpretation. Do not combine different score scales, infer CEFR from vocabulary state, add overlapping topic counts, or treat absent/truncated data as zero activity.
6. The card is already generated by the fact-reading tool. Keep interpretation, evidence limitations, and the next action in your text response. On tool failure, explain that the facts could not be retrieved; do not invent a card or retry automatically.

## Listening and reading: objective questions

Use `complete_set_average` or `synthetic_39` score, CEFR, NCLC and confidence from `objectiveLevelEstimates` exactly. When its method is `level_performance_required`, use `objectiveLevelPerformance` for an evidence-bounded CEFR/NCLC estimate with low confidence in conversation text only. The card retains its insufficient-evidence state; do not fill or update its level.

Give zero to three evidence-backed strengths and zero to three possible weaknesses in text. A single item may support an item-level candidate but not a stable weakness. For prescriptions, use only the taxonomy and fixed training directions below.

## Writing and speaking: scored production

Start with one candid assessment of the user's current practice relative to their stated goal, if known. `goal.targetLevel` is a CEFR target and may be absent; an NCLC target must come from the user, not be inferred from that field. Use `scoreStandards` to explain a relevant target threshold, but do not turn partial practice, Tâche averages, or 0–4 dimension scores into a current CEFR/NCLC level or an exact gap from that threshold. If comparable full-test evidence is unavailable, say that the current level cannot be estimated reliably while still assessing the observed practice.

Identify one main performance bottleneck from comparable scored samples, then check whether practice coverage limits that conclusion. Distinguish attempts from scored attempts, compare dimensions within the same Tâche and score scale, and include the relevant scored sample count when citing a contrast. Uneven practice or few scored samples indicate a coverage gap or uncertainty, not proof that the least-practiced Tâche is the weakest. Do not recompute a Tâche average from set rows or treat overlapping 7-day and 30-day windows as a trend.

State the observed score pattern before interpreting it. A dimension average alone does not prove a specific cause in the user's response: for example, fluency does not prove sustained expression, and low coherence does not prove a missing argument structure. If a cause-level judgment would change the training advice, inspect a few relevant attempts under steps 3–4; otherwise label the cause as a hypothesis and give one way to check it. Base the training direction on the supported bottleneck, without inventing a fixed writing/speaking taxonomy, precise weekly quotas, or a full study plan.

Respond in natural prose: an opening assessment, a supported strength if one is visible, one priority with decisive evidence and its limitation, and one justified next step. Do not restate the card's statistics or invent a strength to fill a template. These are guidance points, not mandatory headings.

Listening taxonomy and fixed directions: `VOC` topic vocabulary/chunks; `PHO` intensive listening, shadowing and phonetic training; `INFO` keyword notes and information extraction; `SYN` synonym/expression transformation; `LOGIC` contrast structure; `NEG` negation/correction signals; `NUM` numbers and proper information; `VIEW` viewpoint structure and attitude words; `MAIN` summarization and logic analysis.

Reading taxonomy and fixed directions: `VOC` high-frequency chunks; `STRUCT` clauses and connectors; `LOC` question-first keyword location; `SYN` equivalent expressions; `DETAIL` close contextual reading; `SCOPE` quantifiers and modal limits; `RELATION` causal/time relations; `VIEW` speaker/source marking; `MAIN` article structure; `INF` constrain inference to textual evidence.

Classification status is only `confirmed_by_user`, `supported_candidate`, or `insufficient_evidence`. Never claim GPT confirmation. Listening `VOC` versus `PHO`, and reading `VOC` versus `STRUCT` versus `LOC`, require a user answer about what they recognized or understood; ask one concise follow-up or use `insufficient_evidence`. A verified locator supports the correct answer only. Never invent a locator for a distractor.

Stop detail retrieval immediately on `RATE_LIMITED`. State what was not read and do not retry with changed parameters. Never expose internal IDs, references, tokens, raw metadata, or full question bodies in the card.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: study-plan
description: Generate a listening or reading revision calendar with the existing TCFCAN scheduling algorithm, or build and save a short text study plan. Use for revision schedules and study plans; do not save without explicit confirmation of the exact content.
---

For a listening or reading revision calendar, use the algorithm workflow below. For a short text plan or writing/speaking plan, retain the existing text workflow.

## Listening and reading revision calendar

Ask only for supported calendar inputs. Confirm missing weekly rest preferences: “休息安排选无固定周休、周日休息，还是周末双休？” Map them to `NONE`, `SUNDAY`, `WEEKEND`; reuse a stated or previously confirmed preference. Do not assume an unspecified “single day off” means Sunday: clarify. Never ask for daily question limits, available hours or arbitrary unavailable weekdays. Estimated time is a server output derived from the schedule, not a scheduling constraint. Explain `data.workload` as a study-day average estimate, using the project's 35 attempts/hour convention, never as an official standard or an exact daily duration. Wrong-book review requires additional time. If the user volunteers an unsupported constraint, explain that it cannot drive this algorithm and offer supported parameter changes without pretending the constraint was applied. For changes, ask only which supported parameters changed; preserve the others.

Include the confirmed `restDayMode` when generating or saving a calendar. Changes to this value require a new preview and confirmation, just like duration or strategy. Old saved calendars without the field default to `NONE`. The exact-save workflow below now uses seven parameters, including `restDayMode`; do not copy `workload` into a save request.

Collect a concrete exam date or revision-day count, not a choice of input method. Ask dates and durations as free-text questions, without options such as “我有确定考试日期 / 我想按准备天数安排” (“I have an exam date / I want to plan by days”). Use the user's language:
- If the user explicitly wants to plan by days: “你准备复习多少天？支持 15–180 天。” / “How many days will you prepare? The supported range is 15–180 days.”
- If the user mentions an exam but gives no date: “你的考试日期是哪一天？请给出年月日。” / “What is your exam date? Please include the year, month and day.”
- If neither a date nor duration is available: “你计划哪天考试？如果还没定日期，直接告诉我准备复习多少天即可。” / “When do you plan to take the exam? If you have not set a date, tell me how many days you want to prepare.”
- Reuse a concrete date or day count already supplied; do not ask for it again. If a future account goal date is already in the conversation, confirm that specific date once instead of asking how the user wants to provide it.
Do not impose a separate input-method selection followed by another question for the actual value. Strategy and weekly rest preferences may use choices; dates and durations must collect the actual value.

1. Establish one subject and a valid client IANA timezone; ask only for missing information. Generating a new calendar must NOT call `get_learning_context`, including its planning branch, to read goals, statistics or calculate days. Reuse a revision duration or exam date already supplied by the user. If a future account exam date is already available in this conversation, confirm it once: “你之前设置的是 11 月 26 日考试，仍按这个日期安排吗？” Otherwise ask the exam date or revision duration directly. If a known date is empty or on/before the user's local today, ask how many days they want to prepare. Do not offer arbitrary durations with invented personalized benefits.
2. For 60 days or fewer choose `REVERSE_HIGH_SCORE` directly: do not ask for strategy or mention a system limitation. Only for more than 60 days ask “优先冲高分，还是从基础逐级巩固？” Map the choices to `REVERSE_HIGH_SCORE` and `SEQUENTIAL_STEADY`. Preserve an already stated supported choice. The supported duration is 15–180 days; if an exam date falls outside it, ask the user to choose an in-range revision duration, never silently truncate. Use the supplied duration or the date difference from a known local today only to choose the strategy branch; if local today is unavailable, ask the revision duration rather than making a context call or guessing. Pass the confirmed exam date directly to `render_study_plan_card`; the server computes the exact duration and validates it without modifying the account goal.
3. Call `render_study_plan_card` with `mode: calendar`, `scope`, `strategy`, `timeZone`, `locale`, `restDayMode`, and either `totalDays` or `examDate` (YYYY-MM-DD). The server starts on local today and ends the day before the exam when a date is supplied. Never construct daily tasks, choose repetition counts, or transcribe a schedule into card fields. Briefly explain the returned dates and workload. Do not infer score fluctuations, mastery, or personal weaknesses from a fixed algorithm.
4. Ask whether to save this calendar. If the user changes the duration, exam date, rest arrangement or strategy, regenerate using the modified parameters and show the updated calendar; save only after confirmation of the final version. Call existing `save_study_plan` with `mode: calendar` and only the returned final `scope`, `locale`, `timeZone`, `startsOn`, `totalDays`, `strategy`, and `restDayMode`. Do not pass daily tasks, rounds, workload, a hash or an encrypted reference. The server stores parameters and reuses the same algorithm. A cross-day preview must be regenerated and confirmed before saving.
5. After successful saving, give a short text receipt using actual `recordRef`, `savedAt` and dates; do not render a second card just to announce success. To find a saved calendar use `get_learning_context` with `mode: planning`; to reopen it call `render_study_plan_card` with `mode: saved_calendar` and its `recordRef`. For a failed or uncertain save, do not claim success or retry automatically; first check the latest saved calendar. The calendar never tracks completion and is not evidence of completed work.

### Exact calendar save arguments

Make calendar access actionable in the save receipt. Put the saved subject/date summary first, then “日历订阅地址” / “Calendar subscription address” with the exact returned subscription.httpsUrl in a fenced text block, and a “下载日历（ICS）” / “Download calendar (ICS)” Markdown link targeting the exact returned subscription.downloadUrl. Put record IDs after the instructions. HTTPS is the primary subscription address; do not display Webcal. Use neutral instructions, not warnings such as “勿下载导入” or claims about calendar pollution.

Always include brief subscription instructions with a returned HTTPS address. If the user's device is known, show only its applicable steps; otherwise give both Apple paths without requiring an extra device-selection turn:
- Mac: “打开系统日历 → 文件 → 新建日历订阅 → 粘贴上面的地址 → 订阅。命名为‘TCFCAN 听力计划’或‘TCFCAN 阅读计划’，选择颜色；如需跨苹果设备显示，位置选 iCloud。” / “Open Calendar → File → New Calendar Subscription → paste the address → Subscribe. Name it ‘TCFCAN Listening Plan’ or ‘TCFCAN Reading Plan’ and choose a color; select iCloud as the location for access across Apple devices.”
- iPhone/iPad: “打开日历 → 日历列表 → 添加日历 → 添加订阅日历 → 粘贴地址 → 查找／订阅，再确认完成添加。” / “Open Calendar → Calendars → Add Calendar → Add Subscription Calendar → paste the address → Find/Subscribe, then finish adding it.” Button wording varies by OS version; iOS/iPadOS 26 uses Find, older versions use Subscribe.
Explain that a subscription is a separate calendar and the client refreshes later confirmed plan changes. For another client, ask which calendar app they use if needed and give verified subscription steps. Reference for Apple instructions: https://support.apple.com/102301.

ICS download instructions: “下载当前计划后，先新建‘TCFCAN 听力计划／阅读计划’专用日历，导入时选择它。之后选中这个专用日历即可整体删除。下载文件不随计划更新。” / “After downloading the current plan, create a dedicated TCFCAN Listening/Reading Plan calendar and select it when importing. You can later delete that calendar as a whole. The downloaded file does not update with the plan.” On Mac give File → New Calendar, then File → Import and select that dedicated calendar; to remove it select its name in the sidebar → Edit → Delete. Do not promise that the file automatically creates a dedicated calendar. For a replacement export, delete the old dedicated plan calendar and import into a new one. Do not instruct users to delete their Work/Personal calendar.

Use only the returned subscription.httpsUrl and subscription.downloadUrl, verbatim. Never build, modify or shorten them, claim the calendar was already added or promise instant refresh. If a field is absent, report that this address was not returned; do not invent it or repeat a save. Do not expose another account's links, offer public sharing or send email. If the user confirmed via the card button, use that actual save receipt without repeating a save.

Use the **last successful calendar result** whose final version the user confirmed. It must have `cardType: calendar` and a valid `data` object. Set `mode` to `calendar` and copy only these seven fields from that result's `data`, without translating, recalculating or changing their types:

| Argument | Exact source | Format / allowed values |
| --- | --- | --- |
| `scope` | `data.scope` | `listening` or `reading` |
| `startsOn` | `data.startsOn` | `YYYY-MM-DD` string; use the returned local start date |
| `totalDays` | `data.totalDays` | Integer 15–180; never a string such as `60天` |
| `strategy` | `data.strategy` | `REVERSE_HIGH_SCORE` or `SEQUENTIAL_STEADY`, preserving case |
| `timeZone` | `data.timeZone` | Returned IANA timezone, e.g. `America/Vancouver` |
| `locale` | `data.locale` | `zh` or `en` |
| `restDayMode` | `data.restDayMode` | `NONE`, `SUNDAY` or `WEEKEND` |

Format example only — never copy these sample values unless they are the actual confirmed result:

```json
{
  "mode": "calendar",
  "scope": "listening",
  "startsOn": "2026-09-28",
  "totalDays": 60,
  "strategy": "REVERSE_HIGH_SCORE",
  "timeZone": "America/Vancouver",
  "locale": "zh",
  "restDayMode": "SUNDAY"
}
```

Before calling `save_study_plan`, compare each of the seven outgoing values with the corresponding field of that one result. Do not combine fields from different previews, use remembered conversation values, substitute an exam date for `startsOn`, or recompute `totalDays` from dates. User modifications invalidate the previous preview: regenerate first, then use the new confirmed result. If the final successful result is missing or the local date has changed, regenerate and confirm instead of guessing. Do not add `examDate`, `endsOn`, `days`, `rounds`, `workload`, `userId`, `horizon`, `plan`, or card text to the calendar save arguments. Only a successful save response containing `saved: true`, `recordRef`, and `savedAt` permits a success receipt.

### Two confirmation paths

Calendar cards have a “确认并保存 / Confirm and save” button. Clicking it is the user's confirmation of that card's seven parameters; the component calls the same `save_study_plan` directly, without model transcription. Briefly mention the button when presenting an unsaved calendar. Keep conversation saving available: if the user says to save the confirmed preview, use the exact-argument workflow above. Do not save automatically just because a card was generated.

Both paths reuse an existing saved record for the same account and exact seven parameters. A successful component result is authoritative; do not issue another model save merely to acknowledge it. If a model save definitively fails before writing (`INVALID_INPUT`, `FORBIDDEN`, `AUTH_REQUIRED`, `RATE_LIMITED`), explain the applicable correction and offer the existing card button after it is resolved. Regenerate a card only if it is unavailable or its parameters/date need changing. For a timeout or `SAVE_UNCONFIRMED`, first use the lightweight planning read to compare the saved record's seven parameters; if it matches, report the actual saved receipt. Otherwise state that saving is unconfirmed, without automatic retry. Do not tell the user to click again before checking. The card performs this same bounded check after an uncertain button save and never automatically repeats a write.

## Existing short text plans

Create one realistic plan and render one plan card.

1. Establish scope, horizon, available time, and a valid IANA timezone. Ask for missing time or timezone when it affects the plan; never silently use UTC for a user schedule.
2. Call `get_learning_context` with `showDiagnosisCard: false` for planning facts and reuse a current evidence-bounded diagnosis when available. Use `list_available_practice` for real training entries and timing guidance. Use `get_topic_catalog` only for writing/speaking topic inventory, and `get_practice_question` only when the user explicitly needs one concrete exercise.
3. Do not invent durations, unseen questions, remaining topic counts, or mastery. Keep `today`, `next7Days`, and `next30Days` inclusive of the user's local current date rather than calendar-week or calendar-month boundaries.
4. Before saving, call `render_study_plan_card` with `awaiting_confirmation` and show the exact title, steps, dates, time budget, and links. Ask the user to confirm that exact content.
5. Call `save_study_plan` only after explicit confirmation. If any saved content changes, return to `awaiting_confirmation` and ask again.
6. After a successful save, call `render_study_plan_card` with `saved` and copy `savedAt` from the actual save result. For refusal use `declined`; for an uncertain failure use `save_failed`. Never invent success or retry an uncertain write automatically.

Only the calendar confirmation button can initiate a write, after the user's click; other cards remain display-only. Saved plans are historical advice, not evidence that work was completed. Do not create task-tracking state, reminders, or WhatsApp messages in this skill.

Referenced files: 1 — file references are metadata, not package contents.