Skill instructions
deliberate-sketch-practice3.21 KB
View saved version →
---
name: deliberate-sketch-practice
description: Coach a bounded Draw Guess practice session when the user asks to improve one drawing technique across several rounds, practice silhouettes or proportions, or receive feedback between games. Use random subjects and the existing 60-second rounds; do not promise custom subjects, timer changes, or durable progress tracking.
---
# Deliberate Sketch Practice
## Inputs
- Use the requested technique and positive whole-number round count. Clarify an invalid count before starting; default to silhouette practice over three rounds when unspecified.
- Use model-visible uploaded images and the corresponding `guess-subject` outputs.
- Keep a small practice record in the current conversation: round number, initial guess, `is_correct`, and one observation about the chosen technique.
## Workflow
1. State the technique, round count, and what to focus on. Give one brief, subject-independent instruction, such as drawing the overall shape before adding details.
2. Reuse an unfinished round as the first practice round when appropriate. If its status is unclear, ask the user whether they are still drawing; do not inspect private widget flags or replace it automatically.
3. When a new round is needed and the user is ready, call `play-round` with no arguments or optional `reason`. Let the server choose the subject; do not pass a technique, subject, category, difficulty, or timer argument.
4. Let the user draw in the widget. Preserve its normal finish/upload flow and explicit Ask ChatGPT to guess action; do not guess before the user requests it.
5. On that request, inspect the latest uploaded drawing from `modelContent.drawnImageId`, `modelContent.imageUrl`, or `imageIds`. If the image cannot be inspected, help restore access before guessing.
6. Call `guess-subject` once with a best visual guess from its registered subject enum and optional `reason`. Record the initial `guess` and `is_correct`; do not use repeated guesses as practice results.
7. Give one observation and one adjustment specific to the session's technique. Ground both in the image, and distinguish recognition success from skill improvement. Use `sketch-feedback` when available if the user requests a fuller critique.
8. Announce the focus for the next round and wait for the user's ready or Play again request. Complete each round before starting the next, and stop at the agreed count.
9. Summarize the completed rounds, recognizable successes, recurring visual pattern, and one suggested next practice focus. Report incomplete rounds separately.
## Output
Give a brief coaching note between rounds and a final table containing the round, guess, outcome, and technique observation. Calculate a recognition rate only from completed rounds with confirmed results.
## Boundaries
- Keep progress in the conversation; do not claim stored history, saved settings, or a permanent training program.
- Never inspect private state or decrypt the assigned subject. Ask for the intended subject only after an initial guess if comparison is needed.
- Do not assume random subjects get harder, remain unique, or match a chosen category.
- Review older rounds using their recorded results, not new scoring calls; `play-round` replaces the active conversation subject.
Referenced files: 1 — file references are metadata, not package contents.
explain-drawing-guess2.43 KB
View saved version →
---
name: explain-drawing-guess
description: Explain a recorded Draw Guess guess or confusing result when the user asks why ChatGPT chose that subject, what visual cues supported it, or why their sketch was misrecognized. Reinspect the matching uploaded image and use the existing result; do not submit another guess or claim access to the hidden answer or unrecorded reasoning.
---
# Explain Drawing Guess
## Inputs
- Use the requested round's recorded `guess` and `is_correct` from `guess-subject`.
- Use its uploaded image from model-visible widget state or an image already visible in the conversation.
- Use an intended subject supplied by the user only as comparison context.
## Workflow
1. Identify the recorded guess and match it to the requested image. If either is missing or belongs to an ambiguous round, ask for the missing context instead of inventing an explanation.
2. Inspect the image itself, using the visible `modelContent.imageUrl`, `drawnImageId`, or `imageIds` as available. If inspection fails, say that the result alone cannot establish which visual cues influenced recognition; guide the user to refresh access through the round widget.
3. Describe up to two visible features that resemble the recorded guess, such as the outline, relative size of parts, or a characteristic detail. Explain how those features could support the choice without claiming to reconstruct unrecorded reasoning.
4. Use `is_correct` to state whether that guess matched the assigned subject. If it was incorrect, identify a visual ambiguity when the image supports one.
5. If the user supplied the intended subject, compare one distinguishing feature with the recorded guess. Otherwise, do not name an actual answer; invite the user to share it only if they want that comparison.
## Output
Give a concise explanation containing the recorded outcome, the visible supporting cues, and any important uncertainty. Keep a full drawing critique separate; use `sketch-feedback` when available if the user asks how to improve.
## Boundaries
- Use an existing result only. Do not call `guess-subject` to rescore the image, try alternatives, or reveal the hidden subject.
- Do not start a new round merely to explain a previous result.
- Do not access private widget content, decrypt metadata, or infer an assigned subject from an incorrect result.
- Describe ambiguous features as possible explanations, not proof that the drawing or recognition process failed for a particular reason.
Referenced files: 1 — file references are metadata, not package contents.
minimal-strokes-challenge3.06 KB
View saved version →
---
name: minimal-strokes-challenge
description: Run a voluntary Draw Guess stroke-limit challenge when the user asks to draw with fewer marks, use ten strokes or fewer, or test how simply they can make an object recognizable. Use the normal round and a user-reported stroke count; do not claim automatic counting, enforcement, or access to stroke history.
---
# Minimal Strokes Challenge
## Inputs
- Use the requested positive whole-number stroke limit; default to ten when unspecified. Clarify an invalid limit before starting.
- Count one continuous drawing gesture, from contact to lift, as one stroke. Ask the user to count the strokes remaining in their submitted drawing, excluding strokes removed with Undo or Clear.
- Use the saved image, its confirmed initial `guess-subject` result, and the user's reported count.
## Workflow
1. State the limit, counting rule, and challenge goal: make the assigned object recognizable without exceeding the limit. Explain that the widget does not count or enforce strokes.
2. Give one brief strategy, such as prioritizing the outline and one distinctive feature. Keep it subject-independent so the assigned word remains hidden from the model.
3. Start a normal round with `play-round`, using only optional `reason`, when the user is ready. Apply the rule to an existing unfinished round if requested rather than restarting it automatically.
4. Preserve the 60-second drawing, finish/upload, and explicit Ask ChatGPT to guess flow. Do not request the assigned word or count in advance of the initial visual guess.
5. Inspect the latest uploaded drawing from model-visible state, then call `guess-subject` once with one exact subject enum value and optional `reason`. Restore image access before guessing if necessary.
6. Ask for the user's stroke count after the initial guess if it has not been supplied. Accept a nonnegative whole-number count; clarify invalid counts before evaluating compliance. Label the count as user-reported; never estimate it from overlapping marks in the PNG.
7. Report recognition and limit compliance separately. Mark the challenge met only when the guess was correct and the reported count is within the limit. Mark it unmet when either condition is known to fail; otherwise leave it unconfirmed.
8. Suggest one image-grounded simplification to try next time. Reuse the limit for another random round only if the user asks to continue; do not promise a repeat of the same subject.
## Output
Report the guess and correctness, the stroke limit, the user-reported count or its absence, the challenge outcome, and one concrete simplification suggestion.
## Boundaries
- Treat count compliance as self-reported. Do not claim stroke telemetry, undo history, automatic disqualification, or tool arguments that set a limit.
- Do not access private state, decrypt metadata, or probe for the hidden subject with repeated scoring calls.
- Keep the initial result as the recognition outcome even if the user later explains the drawing.
- Do not treat failed recognition as proof that a drawing used too few strokes; ground simplification advice in visible features.
Referenced files: 1 — file references are metadata, not package contents.
pass-and-play-session3.11 KB
View saved version →
---
name: pass-and-play-session
description: Host a sequential Draw Guess group session when the user asks to take turns with friends, run a shared-device party game, or track scores for named players. Coordinate turns and a conversational score table using confirmed results; do not promise remote multiplayer, separate player accounts, private screens, or persistent leaderboards.
---
# Pass and Play Session
## Inputs
- Obtain player names and turn order from the user. Ask for names if absent; default to the listed order and two rounds per player unless another positive whole-number count is requested. Clarify invalid counts before starting.
- Use one shared conversation and device, with one active round at a time.
- Keep player, turn number, image ID when visible, initial guess, and confirmed outcome in the conversation.
## Workflow
1. State the player order, rounds per player, and scoring rule: award the drawer one point when ChatGPT's initial guess returns `is_correct: true`; award zero for `false`. Leave unfinished rounds unscored.
2. Announce the current player before starting their timer. Wait until they are ready, then call `play-round` with no arguments or optional `reason`. Keep any existing unfinished round until the user decides who will complete it or requests a restart.
3. Explain that the assigned word appears in the widget. If the group wants secrecy between players, ask other players to look away; do not claim the app can conceal the word on separate screens.
4. Let the current player draw and use Finished or the timer. Wait for their explicit Ask ChatGPT to guess request.
5. Inspect that round's latest uploaded image from model-visible state. Call `guess-subject` once with one exact registered subject value and optional `reason`; do not guess if the image is unavailable.
6. Associate the returned `guess` and `is_correct` with the announced player and turn. Count only that turn's initial result, using the visible image ID when available to recognize repeats. Do not count a repeated card or message as another round.
7. Update the score table and announce the next player. Treat a ready or Play again request as the next scheduled turn, and finish the current turn before calling `play-round` again.
8. After all scheduled turns finish, show final scores and name all players tied for the highest score. Start extra or tiebreak rounds only when requested.
## Output
Show the current player and round before drawing, a compact score table after each confirmed result, and final standings. Describe the score as recognition success in this game, not an objective ranking of artistic ability.
## Boundaries
- Keep scores in the conversation. Do not claim accounts, stored statistics, invitations, remote synchronization, or a durable leaderboard.
- Keep the hidden subject out of assistant messages. Do not use private widget content or decrypt metadata.
- Do not let a supplied intended subject override `is_correct` for scoring, and do not give the model extra guesses to improve a player's score.
- Use recorded outcomes for earlier turns; each new `play-round` replaces the subject used by scoring in the same conversation.
Referenced files: 1 — file references are metadata, not package contents.
recover-drawing-round4.1 KB
View saved version →
---
name: recover-drawing-round
description: Guide recovery of an interrupted Draw Guess round when the user reports a save failure, failed guessing or replay request, loading error, inaccessible uploaded image, or missing strokes after reload. Use visible evidence and existing retry controls; do not replace a recoverable round, promise stroke recovery, or claim access to private widget state.
---
# Recover Drawing Round
## Inputs
- Use the user's visible error message, current buttons, and what happened immediately before the failure.
- Use model-visible `modelContent.drawnImageId`, `modelContent.imageUrl`, `imageIds`, and recorded tool results when present.
- Ask for the error text and whether the drawing was saved if the next action depends on those details. Do not inspect private finish flags, countdown state, or encrypted metadata.
## Workflow
1. Identify the stage from visible evidence or the user's report: loading, drawing, saving, awaiting a guess, or replay. Do not diagnose the stage from a file ID alone.
2. Choose the matching recovery path:
- **Loading round:** Allow incomplete hydration to settle. If the widget explicitly reports that it could not load the round, explain that a fresh round is needed. Call `play-round` only when the user requests that replacement.
- **Could not save the drawing:** Guide the user to retry Finished while the current canvas remains open. Explain that the failed save leaves the drawing available in that mounted widget; avoid recommending reload.
- **Saving succeeded, but no guessing button yet:** Explain the four-second post-upload delay and direct the user to the Drawing saved dialog when it appears. Do not call `guess-subject` before a guessing request.
- **Could not ask ChatGPT to guess yet:** Guide the user to retry Ask ChatGPT to guess. Reuse the saved drawing; do not ask them to redraw or restart.
- **Saved round reopened:** Direct the user to its Ask ChatGPT to guess action. The widget refreshes the file's download URL before sending the request; do not claim the assistant can invoke that host API itself.
- **Uploaded image cannot be inspected:** Guide the user to retry the round's guessing action if it remains available. If it has already been sent and access is still unavailable, ask the user to attach the saved image if they have it. Do not make a visual guess without seeing it or assume an old URL still works.
- **Could not ask ChatGPT to start a new round yet:** Guide the user to retry Play again. Do not launch a duplicate round while a request is pending.
- **Strokes missing after reload:** Explain that countdown and round flags restore, but unfinished strokes do not. A previously uploaded PNG may still be available; unsaved strokes cannot be recovered by this skill. Let the user choose whether to redraw in the remaining time or request a new round.
- **No active draw-guess subject was found for this session:** Explain that the server has no active subject for scoring in this conversation. Do not score an old image by creating a random replacement subject; start a fresh drawable round only when requested.
3. Resume the normal guess flow only after the user explicitly asks for a guess, the current image can be inspected, and its association with the active round is clear. Call `guess-subject` with one exact registered subject value and optional `reason`.
4. When a new round is requested, call `play-round` with no arguments or optional `reason`, and explain that it starts a new random subject rather than restoring the old drawing.
## Output
Give the next concrete action and a short explanation of what the available evidence shows was retained or lost. State uncertainty when the reported error does not match a supported recovery path.
## Boundaries
- Guide widget actions; do not claim to click buttons, refresh host download URLs, reupload files, or restore private state.
- Preserve recoverable rounds. Do not use `play-round` as a generic ret
Preview of the first 4,000 characters. Read full instructions →
Referenced files: 1 — file references are metadata, not package contents.
sketch-feedback2.88 KB
View saved version →
---
name: sketch-feedback
description: Give concrete feedback on a completed Draw Guess sketch when the user asks how to make it clearer, easier to recognize, or better next time. Ground the critique in the uploaded image and recorded result; do not reveal the hidden assigned subject or use this for unrelated artwork.
---
# Sketch Feedback
## Inputs
- Use the completed round image exposed through model-visible widget state: `modelContent.drawnImageId`, `modelContent.imageUrl`, or `imageIds`.
- Use the matching `guess-subject` result, if available, and any technique the user wants to improve.
- Treat an intended subject volunteered after the guess as user-provided context.
## Workflow
1. Match the image and result to the requested round using the visible conversation. If the association is unclear, ask which round to review.
2. Inspect the actual image. If it is unavailable, explain that visual feedback needs the drawing; guide the user to the saved round's Ask ChatGPT to guess action to refresh its URL. Do not infer image contents from a file ID or result alone.
3. Complete a pending guess only if the user has explicitly requested guessing for this active round. Choose one exact value from the registered `guess-subject` subject enum and call it once with `guess` and optional `reason`. Otherwise, use the existing result without submitting another guess.
4. Identify one visible feature that communicates the object effectively, such as silhouette, proportion, or a distinctive detail. If the image is blank or too sparse to support a strength, say so rather than inventing one.
5. Suggest two specific changes to recognizable features. Tie each change to something visible in the image and explain how it would reduce ambiguity.
6. If the guess was incorrect and a subject-specific critique needs the intended subject, ask the user what they were drawing. Until they answer, discuss only visible clarity and the recorded guess.
7. Finish with one technique to prioritize next time. Start another round only when the user asks to play again.
## Output
Give a short critique with one supported strength, up to two actionable changes, and one next-round focus. For a blank image, explain the lack of visual evidence and give one first step instead. Keep the tone constructive and scale the advice to a quick sketch made within the game's 60 seconds.
## Boundaries
- Treat `is_correct` as the recorded outcome, not as a measure of drawing quality. Describe possible causes of confusion as interpretations, not proven explanations.
- Keep the assigned subject hidden. Do not access `privateContent`, decrypt metadata, or probe `guess-subject` with alternatives to discover the answer.
- Do not claim to edit the drawing, observe stroke order, measure drawing time, or recover strokes from a PNG.
- Do not rescore an older image after another `play-round` call; the server stores only the latest subject for the conversation.
Referenced files: 1 — file references are metadata, not package contents.