Spheric Admin Ltd v3.0.0
From the marketplace listing
Play chess without leaving ChatGPT. Start a new game in seconds, make moves in normal chess language, and talk about every part of the game as you play. You can ask why a move is good, why a move is bad, what to do next, or how to get better. This app is made for people who want to play, learn, and have fun at the same time. The app is easy to use. Just begin a game and make your moves. You can use simple move names, standard chess notation, or ask questions in plain English. If you are not sure what to do, ask for help. The game keeps going while you chat, so learning feels natural instead of like reading a long lesson. If you are brand new to chess, this app is a friendly place to start. It explains ideas in small, simple steps. It tells you what each piece can do and why some moves are stronger than others. You never have to pretend you understand. Just ask another question. You can learn one move at a time. If you already know how to play, you can go deeper. Talk about openings, middle games, endgames, tactics, strategy, planning, and common mistakes. Ask why a position feels better for one side. Compare different moves. Explore new ideas. The conversation changes to fit your questions. Play at your own speed. Think for a long time or move quickly. Stop to ask about a position. Go back and look at an earlier move. Try a different idea and see what could happen. Chess is not only about finding the best move. It is also about understanding why that move works. The app can explain forks, pins, skewers, discovered attacks, double checks, sacrifices, passed pawns, king safety, piece activity, space, time, and many other chess ideas using clear language. Hard topics become easier because you can ask for another explanation whenever you need one. Want to improve? Review your games after they finish. Talk about turning points, missed chances, and strong moves. Ask where the game changed. Find patterns in your play. Learn from mistakes instead of simply seeing that they happened. Every game becomes a chance to get stronger. You can also practice specific parts of chess. Focus on openings you want to remember. Study endgames that appear often. Learn how to attack, defend, trade pieces, or make better plans. Ask for tips that match your current skill level instead of getting the same advice every player receives. The conversation is just as important as the game. Ask “What if I move here?” Ask “What was my best move?” Ask “Why did my attack fail?” Ask “Can you explain that in a simpler way?” The app is built for questions, so you are never limited to playing in silence. There is no need to switch between different tools just to play and learn. The chessboard and the conversation work together. You make a move, ask a question, get an answer, and keep playing. Everything happens in one place, making practice smooth and enjoyable. Whether you play one game a week or many games every day, the app is ready. Beginners can build confidence. Casual players can have fun. Club players can explore ideas. Anyone who enjoys chess can have interesting conversations while playing. Use the app to play complete games, test new ideas, understand difficult positions, review finished games, and discover better moves. Learn at your own pace. Stay curious. Ask as many questions as you like. Every move is another chance to think, learn, and enjoy the game. If you want a chess game that also talks with you, teaches you, and helps you improve inside ChatGPT, this app is ready to play.
Language: English · Automatically detected from descriptions.
Sep 30, 2026 · 7 saved observations
Newly listed paths: agents/openai.yaml. This compares saved file lists, not package contents; a different collection source can change the list.
Skill evidence →Skill evidence →Skill evidence →Skill evidence →Skill evidence →Skill evidence →Skill evidence →--- name: adaptive-chess-rematch description: Recommend an appropriate Stockfish difficulty for a rematch and start a fresh Chess app game after the user authorizes it. Use when the user wants to play again, make the next game easier or harder, or adjust the level based on how the previous game felt. Use only the registered start-game tool and integer levels from 0 through 20. --- # Adaptive Chess Rematch ## Inputs Use the current widget's model-visible `difficulty`, `moves`, `phase`, and `outcome` when available. Give the user's explicit assessment of the previous game's difficulty more weight than the result alone. ## Choose the Level 1. Honor an explicit requested level from 0 through 20. 2. For a relative request, start from the current difficulty and use a conservative adjustment: - Move by 1 level for a slightly easier or harder game. - Move by 2 levels when the user says the game was clearly overwhelming or far too easy. - Keep the same level when the game felt competitive. 3. Clamp the recommendation to the inclusive 0–20 range. 4. Do not infer a large adjustment from one win, loss, draw, or resignation. If the user has not described how the game felt, ask one concise calibration question or recommend staying close to the current level. ## Start the Rematch 1. State the proposed level and one short reason. 2. Treat a direct request such as “make it harder and play again” as authorization. Otherwise, ask for confirmation before starting. 3. Call `start-game` with: - `difficulty`: the chosen integer from 0 through 20 - `reason`: an optional concise explanation of the user's rematch request 4. After the call, briefly confirm the level. Let the returned widget provide the fresh game. ## Boundaries - Use the tool name `start-game` exactly. Do not invent tool arguments. - Expect the tool's structured content to contain only `difficulty`. - Do not claim to modify, resume, or unfreeze the previous widget; every call creates a new game. - Remember that the user is always White and moves first. - Do not promise that a level maps to a formal player rating.
Referenced files: 1
--- name: chess-hint-ladder description: Give progressive, Socratic hints for the current Chess app position without revealing the move too early. Use when the user asks for a chess hint, clue, nudge, or guided help and wants to think through the live position themselves. Do not use for direct best-move requests or completed-game reviews. --- # Chess Hint Ladder ## Inputs Use only the current game widget's model-visible `modelContent`: - `fen` and `moves` for the position and its context - `phase`, `turn`, and `inCheck` for timing and urgency Use the conversation to track which hint level the user has already received. ## Workflow 1. Confirm that the state describes an active game and that it is White's turn. - If Black is thinking, ask the user to wait for Black's move. - If the engine is loading or unavailable, explain that a live move hint is premature. - If the game is finished or restarting, offer to discuss the position or review the game instead. - If the state is missing, ask for the current FEN or move sequence. 2. Check immediate forcing concerns first: whether White is in check, direct threats, loose pieces, checks, captures, and tactical motifs. 3. Start at the first unrevealed level unless the user requests a stronger hint: 1. State the position's main problem or objective without naming a move. 2. Identify the relevant board area, piece, or tactical motif without giving the full move. 3. Narrow the search to one or two candidate ideas. 4. Reveal a concrete candidate move and explain its purpose. 4. Give only one new level per response. Pause so the user can calculate before offering the next level. ## Output Label the response `Hint 1`, `Hint 2`, `Hint 3`, or `Reveal`. Keep it brief, explain what the user should inspect, and end by inviting the next hint level when appropriate. ## Boundaries - Do not claim access to Stockfish analysis, evaluation scores, principal variations, or its internal reasoning. - Present a revealed move as a reasoned candidate, not a guaranteed best move. - Do not make a move, control the widget, or call `start-game`. - Do not reveal later hint levels unless the user requests them.
Referenced files: 1
--- name: explain-chess-result description: Explain why the current Chess app game ended and turn the result into one practical lesson. Use when the user asks why the game was checkmate, stalemate, a draw, a resignation loss, or otherwise finished. Use the model-visible outcome reason and final position as authority; do not infer an ending when no outcome is present. --- # Explain Chess Result ## Inputs Read the current widget's model-visible `outcome`, `fen`, `moves`, `turn`, `inCheck`, and `phase`. If `outcome` is null, state that the widget has not recorded a final result. Explain the difference between the current status and a completed game if helpful, but do not invent an ending. ## Workflow 1. State the result, winner when present, and recorded reason. 2. Explain the relevant rule in plain language: - **Checkmate:** the side to move is in check and has no legal escape. - **Stalemate:** the side to move is not in check but has no legal move. - **Threefold repetition:** the same position, including the same side to move, occurred three times. - **Fifty-move rule:** fifty moves by each side passed without a pawn move or capture. - **Insufficient material:** the remaining material cannot produce checkmate. - **Resignation:** White ended the game voluntarily, so Black received the win. 3. Connect the rule to the final position or the last relevant moves without fabricating unavailable details. 4. Give one recognition tip or practical lesson for future games. ## Output Use this compact structure: - **Result** - **Why it ended** - **How it appears here** - **Takeaway** ## Boundaries - Treat `outcome.reason` as authoritative. - Do not substitute another draw rule or claim an unrecorded adjudication. - Do not present a Stockfish evaluation or principal variation. - Do not call `start-game`; explain the recorded game only.
Referenced files: 1
--- name: explain-last-chess-move description: Explain the purpose and consequences of the latest move in the current Chess app game. Use when the user asks why Stockfish or White played that move, what changed, what the move threatens, or how to respond. Ground the answer in the latest model-visible SAN and coordinate move plus the current position, without claiming access to Stockfish's reasoning. --- # Explain Last Chess Move ## Inputs Use the current widget's model-visible `moves`, `fen`, `turn`, `inCheck`, and `phase`. Treat the final entry in `moves` as the latest move and use both its SAN and coordinate fields. If the history is empty, explain that no move has been played yet. If the state is missing, ask for the move or current position. ## Workflow 1. Name the latest move and identify which side played it. If the user's wording names the wrong side, clarify gently. 2. Explain its immediate board effects: - movement, capture, check, promotion, or castling - newly attacked, defended, opened, or blocked lines - material or king-safety changes visible from the position 3. Describe one or two likely tactical or strategic purposes. Use language such as “likely,” “appears to,” or “one point is” when explaining Stockfish's move. 4. Identify the most important threat or consequence for the side to move. 5. When it is White's turn, offer a practical response idea. Give a concrete move only when confident it is legal; otherwise describe the plan or candidate set. ## Output Use four short parts: - **Move** - **What changed** - **Likely idea** - **What to watch now** Adapt the depth to the user's level and question. ## Boundaries - Do not claim access to Stockfish evaluation scores, search lines, or internal intent. - Do not call a move best, forced, winning, or a blunder without evidence available in the position. - Do not invent prior moves or hidden analysis. - Do not control the board or call `start-game`.
Referenced files: 1
--- name: export-chess-game description: Export the current Chess app game as copy-ready PGN movetext with conservative metadata. Use when the user asks to export, copy, save, share, or convert the current game to PGN. Build from the model-visible SAN history and result, preserve unfinished games with an asterisk, and never treat the current final FEN as a starting-position FEN. --- # Export Chess Game ## Inputs Use the current widget's model-visible `moves`, `phase`, and `outcome`. Use each move's stored SAN exactly. Accept optional header values such as event, site, date, round, or White's name from the user. If no widget state is available, ask for the move list. An empty but valid game exports as `*`. ## Workflow 1. Set the result token to `outcome.result` only when the game is finished and an outcome exists. Otherwise use `*`. 2. Build PGN movetext by pairing SAN entries in order: - Prefix White's move with `1.`, `2.`, and so on. - Place Black's following move after White's move. - Preserve the stored SAN notation for captures, checks, mates, castling, and promotions. 3. Append the result token exactly once at the end of the movetext. 4. Include only known or user-supplied tag values. It is safe to identify Black as `Stockfish 18`; use `?` for an unknown White name rather than inventing one. 5. When the user requests the strict PGN Seven Tag Roster, include unknown values as `?` and an unknown date as `????.??.??`. 6. Return the PGN in a fenced `pgn` code block. Keep commentary outside the block minimal. ## Boundaries - Do not invent dates, player names, ratings, event names, move comments, or variations. - Do not add `SetUp` or `FEN` tags. Games start from the standard position, while the widget's `fen` is the current or final position. - Do not recalculate or normalize SAN when the authoritative move history already supplies it. - Do not call `start-game` or write the export to an external service.
Referenced files: 1
--- name: opening-debrief description: Identify the likely opening family from the current Chess app move history and explain its practical plans. Use when the user asks what opening was played, how the opening developed, where play left familiar theory, or what plans to remember next time. Treat names and ECO codes as heuristic because the app exposes no opening database. --- # Opening Debrief ## Inputs Use the early portion of the current widget's model-visible SAN and coordinate `moves`, plus the current `fen` when it helps explain the resulting pawn structure. Use the user's experience level to choose vocabulary and depth. If no moves have been played, explain that there is no opening sequence to classify. If only a few half-moves are available, identify broad opening principles or a family rather than forcing a precise name. ## Workflow 1. Quote the relevant opening sequence in SAN. 2. Identify the most likely opening family or named variation. - State confidence when the move order is short, unusual, or compatible with transpositions. - Mention at most one plausible alternative name when ambiguity materially helps. 3. Explain the defining pawn structure, development pattern, and king-safety choices. 4. Give the typical practical plans for White and Black in the resulting structure. 5. Identify the first instructive decision for White. Call it a departure from theory only when sufficiently confident; otherwise describe it as a practical choice. 6. Finish with two or three priorities the user can remember in a future game. ## Output Use this structure: - **Opening sequence** - **Likely opening** - **Position character** - **Plans for both sides** - **Remember next game** ## Boundaries - Do not imply access to an opening database, live theory, or Stockfish analysis. - Omit an ECO code unless the user requests one and the classification is highly confident; label any supplied code as tentative. - Do not invent missing moves or claim that a move is the first theoretical error without reliable evidence. - Do not call `start-game` or alter the current game.
Referenced files: 1
--- name: post-game-chess-review description: Review a Chess app game and turn its move history into focused, practical lessons. Use when the user asks for a post-game review, recap, mistake analysis, turning points, or advice after finishing or abandoning a game. Ground the review in model-visible game state and do not present model judgments as Stockfish analysis. --- # Post-Game Chess Review ## Inputs Read the current widget's model-visible `difficulty`, `fen`, `moves`, `phase`, `turn`, `inCheck`, and `outcome`. Use any user-supplied goal, such as opening play, tactics, or time-independent decision making, to focus the review. If no usable move history is available, ask the user to provide the game or reopen its widget. If the game is still active, clearly label the response as a review so far. ## Workflow 1. Establish the game context: difficulty, completion status, result, ending reason, and move count. 2. Reconstruct the game's story from the SAN and coordinate move history. Divide it into opening, middlegame, and endgame only when the moves support those phases. 3. Select two to four instructive decision points. Anchor each point to an exact move number and SAN move. 4. For each decision point: - Describe what changed. - Explain the practical danger or opportunity. - Offer a better plan or a concrete alternative only when confident it is legal. - Tie the moment to a reusable chess concept. 5. Identify at least one thing the user handled well. Avoid making the report a list of faults. 6. Finish with two or three prioritized lessons and one specific practice suggestion. ## Output Use this compact structure: 1. **Game at a glance** — result, difficulty, and one-sentence story. 2. **Key moments** — move-anchored explanations. 3. **What worked** — one or more strengths. 4. **Next-game priorities** — two or three actionable lessons. 5. **Practice** — one focused exercise or theme. ## Boundaries - Do not invent moves, positions, clock information, player ratings, or causes not present in the state. - Do not use numeric evaluations, engine labels such as forced best move, or claims that Stockfish judged a move a blunder. - Prefer positional plans over a concrete variation when legality is uncertain. - Do not call `start-game`; keep this skill focused on reviewing the available game.
Referenced files: 1
Publisher declarations from the archived package. These are separate from our research and the live service's terms.
Package observed Oct 2, 2026.
plugin_asdk_app_69c28d6aedac81919502a88c2179e20c
Download plugin data (JSON)