1 Billion Brain Cells

View saved version →

---
name: brain-training-practice-plan
description: Build a repeatable weekly Brain Training routine with a game rotation, replay days, and a simple results log. Use when the user asks for a multi-day plan or sustainable practice schedule based on their goals and available time; do not use for a single guided session, automatic reminders, or medical treatment planning.
---

# Brain Training Practice Plan

## Inputs and workflow

1. Use the user's goal, available days, time or rounds per day, preferred games,
   and any completed results already shared. Ask for a missing constraint only
   if it materially changes the plan. If no schedule is supplied, state an
   assumption of five practice days with two rounds per day. Treat the goal as
   practice at the games rather than a diagnosis or promised cognitive benefit.
2. Select a rotation from the exact registered tools `color-switch`,
   `number-sort`, `odd-one-out`, `path-trace`, `pattern-recall`, and `word-run`,
   using their current descriptions to match the goal. Respect requested games
   and exclusions. Build in repeat attempts at the same game so comparisons
   have a clear baseline; use other days for variety or rest as requested.
3. Estimate each day's time from sixty seconds of gameplay and a three-second
   countdown per round, allowing extra time for loading, reflection, and breaks.
   Adjust the number of rounds to the user's budget, not the games' duration or
   difficulty; neither is configurable through a launch tool.
4. Assign one simple intention per practice day. Use known prior results to set
   a measurable target, such as fewer failures while maintaining successes. If
   there is no baseline, make the first attempt a baseline instead of inventing
   a score target or a universal success-rate threshold. Describe score goals
   within a game because scoring differs across games.
5. Include a compact log format for the user to record date or attempt label,
   game, successful attempts, failed or rejected attempts, score when known, and
   a brief strategy note. Use the game's own result labels. Accept completion
   follow-ups or model-visible saved results during later discussion; leave
   unavailable fields unknown rather than assuming zero. Do not derive Word
   Run scores from submission counts.
6. Add a review point after the planned replay attempts to compare the same
   game and decide whether to repeat its technique, try a different technique,
   or change the rotation. Keep the plan flexible if the user changes their
   available time or preferences.
7. Deliver the plan without launching a game unless the user also asks to start
   it. For an authorized first round, call the chosen tool with at most an
   optional string `reason`; use later conversation turns for further play.

## Deliverable and boundaries

Return a concise daily table containing the game or games, round count, estimated
time, practice intention, and replay or review point, followed by the results-log
columns. Explain the initial assumption or missing baseline only when relevant.

Present this as a conversational plan. Do not claim to create reminders, schedule
tool calls, save a durable history, or retrieve results from earlier conversations.
The app has no scheduling or cross-session history tool. If the user requests
automation, identify that separate dependency and retain the usable plan without
claiming the automation is set up. Do not rewrite saved widget results or infer
progress from days when the user has not provided a completed result.

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

View saved version →

---
name: brain-training-result-review
description: Review one completed Brain Training game and turn its score and success/failure counts into one practical adjustment and a replay or switch recommendation. Use for single-round analysis and game-completion follow-ups, not comparisons across attempts, live-board hints, or clinical assessment.
---

# Brain Training Result Review

## Inputs and workflow

1. Identify the game from its associated tool call or the user's statement. Read
   the completed result from model-visible widget `modelContent`, a completed
   tool output, the completion follow-up, or counts supplied by the user.
   A launch response with `result: null` is pending, not a zero-score game.
2. Use the available counts and score. Ask for the game or missing counts only
   when needed for the requested analysis; give a score-only explanation when
   that is all the evidence supports. Keep missing values unknown rather than
   substituting zero.
3. Interpret scoring using the following game-specific rules. Prefer the
   reported final score; flag a conflict with the counts instead of silently
   changing either value. Consult the available tool contract if it differs.

   | Game tool | Success / failure fields | Score |
   | --- | --- | --- |
   | `color-switch` | `successfulPrompts` / `failedPrompts` | `(successes - failures) * 100` |
   | `number-sort` | `successfulRounds` / `failedRounds` | `(successes - failures) * 100` |
   | `odd-one-out` | `successfulRounds` / `failedRounds` | `successes * 100`; failures do not subtract points |
   | `path-trace` | `successfulRounds` / `failedRounds` | `(successes - failures) * 100` |
   | `pattern-recall` | `successfulRounds` / `failedRounds` | `(successes - failures) * 100` |
   | `word-run` | `successfulWords` / `unsuccessfulWords` | Each accepted word earns `(length - 2) * 100`; each rejected submission costs 100 |

4. When both counts are available, calculate the success share of recorded
   prompts, rounds, or submissions as `successes / (successes + failures)`.
   Report it as unavailable if the denominator is zero. Color Switch failures
   include expired prompts, so do not call this a wrong-answer rate. Do not
   reconstruct Word Run's score from counts alone; word lengths are not saved.
5. Explain one observable feature of the result and suggest one adjustment
   grounded in that game's rules. Treat explanations such as rushing or losing
   the sequence as possibilities unless the user reported them. Describe
   performance in this game without inferring IQ, clinical status, or population
   rank from the score.
6. Offer a same-game replay with that adjustment or one alternative suited to
   the user's goal. Launch a fresh game only when the user has requested further
   play; call its exact registered tool with at most an optional string `reason`.

## Deliverable and boundaries

Return the score and counts that are known, one short interpretation, one
actionable adjustment, and a concrete next-game suggestion. Scale the detail to
the user's question.

Use only model-visible data or information supplied by the user. The app exposes
aggregate results, not individual answers, reaction times, boards, hidden paths,
or submitted-word history. Do not claim to have inspected those details or read
private widget metadata. Do not launch a game to retrieve a past result or retry
an active game merely to obtain data.

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

View saved version →

---
name: brain-training-strategy-workshop
description: Teach and practise one technique for a Brain Training game through a labelled text example before an optional live round. Use when the user wants help with remembering sequences or routes, following color rules, scanning targets, or finding words; do not use for live-board hints, score-only reviews, or a general collection of cognitive tips.
---

# Brain Training Strategy Workshop

## Inputs and workflow

1. Identify the game and the difficulty the user reports. Use their completed
   results as context when available, but ask a focused question if the problem
   cannot be inferred. Do not require a score to teach a technique.
2. Choose one technique that fits the actual game's rules. Use the current
   registered tool description as authority and preserve these distinctions:

   | Game tool | Rule to preserve | Possible technique |
   | --- | --- | --- |
   | `color-switch` | Answer the visible ink or word rule; answer positions shuffle | Read the rule before identifying the answer |
   | `number-sort` | Tap three targets in ascending numerical order | Identify all three values before tapping |
   | `odd-one-out` | Find the rotated instance of the same emoji | Scan rows consistently instead of jumping around |
   | `path-trace` | Recall the numbered route; adjacent taps or dragging can include diagonals | Remember the start and a short chain of directions |
   | `pattern-recall` | Reproduce flashed cells in their original order | Group the sequence into short chunks of named positions |
   | `word-run` | Submit dictionary words of at least three letters through adjacent cells, including diagonals; do not reuse a cell or repeat an accepted word | Scan promising starts and check the path before submitting |

3. Explain the chosen technique in a few concrete sentences. Present one
   clearly labelled hypothetical text example that obeys those rules. For
   spatial examples, name positions or label a small grid so the sequence is
   unambiguous. For Color Switch, state both the displayed word and ink color
   and ask for the answer under an explicit rule.
4. Let the user try the example before revealing the answer when they want
   interactive practice. Give feedback on that answer and adapt the explanation
   if needed. Keep the workshop on the chosen technique rather than adding a
   catalogue of tips. Treat these text exercises as practice, not app scores.
5. Translate the technique into one intention for the next live attempt, such
   as checking the current rule before every response. If the user requested
   a live round, give the guidance before calling the matching registered tool,
   since the widget starts its countdown immediately. Pass at most an optional
   string `reason`; do not invent difficulty, preview, or duration arguments.
   Otherwise offer the round without launching it.

## Deliverable and boundaries

Provide one explained technique, one worked or interactive example, and one
next-round intention. Honour text-only requests throughout.

Do not claim access to a live board, hidden path, flashed sequence, submitted-word
list, or individual mistake log. Keep examples distinct from the user's current
game. Explain that a hypothetical Word Run example illustrates path rules rather
than guarantees acceptance by the live dictionary. The actual Number Sort board
is 4 by 4 despite the legacy description mentioning 10 by 10. Teach at the user's
preferred pace without claiming to change widget settings or guarantee a higher
score or general cognitive improvement.

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

View saved version →

---
name: compare-brain-training-rounds
description: Compare completed attempts at the same Brain Training game using results visible in the conversation or supplied by the user. Use for progress reviews, replay comparisons, or questions about changes in scores and errors; do not use to rank different games, retrieve unavailable history, or interpret one round alone.
---

# Compare Brain Training Rounds

## Inputs and workflow

1. Identify the game and collect at least two distinct completed attempts from
   model-visible results, completion follow-ups, or user-supplied records. Ask
   for an earlier result if only one is available. Do not call a game-launch
   tool to fetch history; the app has no result-history tool.
2. Group records by the exact registered game: `color-switch`, `number-sort`,
   `odd-one-out`, `path-trace`, `pattern-recall`, or `word-run`. Compare within
   each game. Use visible timestamps or the conversation's stated order; do
   not invent dates, fill missing fields with zero, or count a remounted widget
   as a new attempt. Preserve user-reported data as such.
3. Read the success/failure field pair from the result contract: prompt counts
   for Color Switch, word submission counts for Word Run, and round counts for
   the other games. Use the reported score where present. Number Sort results
   store counts rather than a score, so derive `(successfulRounds - failedRounds)
   * 100` if needed; Odd One Out uses `successfulRounds * 100`. Do not reconstruct
   Word Run scores from counts because accepted word lengths affect the score.
   Check the available tool contract for other missing or conflicting scores.
4. Calculate changes in score, successes, and failures wherever both attempts
   supply those values. Calculate success share as `successes / (successes +
   failures)` only with both counts and a nonzero denominator; show its change
   in percentage points. Label Color Switch failures as combined wrong or
   expired prompts, not wrong answers alone. Prefer absolute score changes to
   percentage changes when the baseline is zero or negative.
5. Explain whether the visible change reflects more successes, fewer failures,
   or a trade-off between them. For Word Run, higher score with similar counts
   can reflect longer accepted words, but do not identify particular words or
   causes without evidence. For Odd One Out, discuss failures separately from
   the score because they do not subtract points.
6. Acknowledge variation from randomized content and, in the memory games,
   increasing sequence or route lengths within a session. Describe an observed
   difference rather than proving a lasting change in cognitive ability or a
   particular strategy's effectiveness. End with one measurable next-attempt
   target based on the user's goal and the known results.

## Deliverable and boundaries

Return a small comparison table with attempt label, game, known score, successes,
failures, and success share. Mark unavailable values as unknown, add relevant
absolute changes, and give a short interpretation plus one next target.

Use a score-only comparison when counts are unavailable, stating what remains
uncertain. Do not infer reaction times, unfinished attempts, individual mistakes,
population benchmarks, or private widget state. Do not collapse scores from
different games into a leaderboard. Keep this workflow analytical; launch a
fresh matching game only if the user also requests another attempt, with at most
an optional string `reason`.

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

View saved version →

---
name: guided-brain-training-session
description: Guide a short Brain Training practice session through several games, launching one widget at a time and ending with a result recap. Use when the user wants a time-limited warm-up, a mixed-game circuit, or a guided multi-round session; do not use for a weekly plan or analysis of one completed round alone.
---

# Guided Brain Training Session

## Inputs and session setup

Use the user's goal, available time or requested round count, game preferences,
and any results already shared in this conversation. Ask only for choices that
materially affect the session. If the user supplies no count or time budget,
propose a three-round session and state that assumption.

Choose games from the registered tools using their current descriptions:

- `color-switch`: attention to changing word/ink rules.
- `number-sort`: ascending number sequencing.
- `odd-one-out`: spotting a rotated emoji.
- `path-trace`: spatial route recall.
- `pattern-recall`: cell-sequence recall.
- `word-run`: words formed from adjacent letters.

Build a short sequence matched to the goal, balancing variety with any requested
repeat attempt. Allow sixty seconds of gameplay and a three-second countdown
per round, plus loading, discussion, and optional breaks. Give an estimate rather
than promise an exact wall-clock duration. For a text-only or plan-only request,
deliver the sequence without launching widgets.

## Run the session

1. Present the sequence and one simple practice intention for the first game.
2. For an authorized playable session, call the first game's exact tool. Send
   only an optional string `reason`; duration, difficulty, board seeds, and
   sequence lengths are not tool arguments. Launch one widget at a time because
   each widget starts its own countdown.
3. Wait for a real completion follow-up, a model-visible completed result, or
   the user's result report. A launch output with `result: null` does not finish
   a round. Do not infer completion just because sixty seconds have elapsed.
4. Keep a compact record in the conversation of the game, visible completion
   timestamp or round label, known score, and available success/failure counts.
   Count the same widget completion once, including if its result is restored
   after a remount. Keep missing values unknown and identify user-reported data.
5. Give brief feedback tied to the practice intention, then launch the next
   game in the already requested session. Do not ask the user to authorize each
   planned round again. Follow steering to change, skip, or stop; mark a skipped
   round as skipped without inventing a result. Stop advancing when the user
   pauses, but do not claim to pause a running widget's timer.
6. End after the requested sequence. Summarize completed rounds and suggest one
   practice focus for a later session. Offer extra play rather than starting an
   unrequested additional round.

## Deliverable and boundaries

Provide the sequence, concise feedback between games, and a final table of known
results with one useful takeaway. Discuss each game's performance separately;
different scoring rules make raw scores unsuitable for ranking games or producing
a combined cognitive score.

Keep session progress in the conversation. Do not claim to save a cross-session
profile, retrieve older results, change game settings, or control taps, dragging,
sound, and display modes for the user. If the launch tool is unavailable, explain
that limitation and retain the proposed session rather than claiming it started.

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