[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79TENEH7ARE7ANB9M9DAHS4":3,"skill-same:01M79TENEH7ARE7ANB9M9DAHS4":126},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":18,"linkOnly":19,"markdownContent":20,"markdownBody":21,"frontMatter":22,"refName":23,"commitSha":24,"skillDirectory":25,"forksCount":26,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":29,"install":30,"resources":43},"01M79TENEH7ARE7ANB9M9DAHS4","thought-rig",null,"Build and refine task-specific apps for expressing and exploring intent when chat alone makes relationships, research directions, timing, perceptual choices, or coupled settings hard to communicate. Proactively offer an editable working surface, seed it from the conversation, and read the user's changes back into the work.","Mattie\u002Fmattie_skills","Mattie","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F566406?v=4","01M79TBXJN40A1D31YFHV26CY4","01M79TBXKXWGQ8X3YWDQZXDGQN",1,"MIT","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: thought-rig\ndescription: Build and refine task-specific apps for expressing and exploring intent when chat alone makes relationships, research directions, timing, perceptual choices, or coupled settings hard to communicate. Proactively offer an editable working surface, seed it from the conversation, and read the user's changes back into the work.\n---\n\n# Thought Rig\n\n**Build the interface the conversation needs.**\n\nSometimes the most useful next reply is a little working apparatus: a storyboard\nwith layered timing, a font comparison bench, a simulation with a few well-chosen\ncontrols. Give the user something they can point at, move, compare, tune, and\nannotate. Their actions become part of the conversation, alongside their words.\n\nThink of an assistant bringing a purpose-built simulator to the workbench. It\nalready contains a plausible first attempt. The user can try it, change it, and\ndiscover what they mean. Both of you can reshape the apparatus as you learn.\n\n## Notice when a rig would help\n\nLook for intent that is awkward to express precisely in prose: relative timing,\noverlapping layers, motion and easing, spatial placement, sound, visual taste,\ncoupled parameters, research branches and dependencies, or judgments that depend\non seeing alternatives together.\nRepeated corrections such as \"a little earlier,\" \"more like that one,\" or \"keep\nthis part but change that part\" are especially useful signals.\n\nWhen the task has these qualities, make a rig the normal recommendation. Don't\nwait for the user to invent the interface or ask for sliders. Say what it would\nlet them do: \"I'll seed a timeline so you can move the entrance against the\nvoiceover and adjust its easing while it plays.\"\n\nBuild a modest, reversible rig when it fits the authorized task and available\ntools. If building it would be a substantial detour, offer the concrete idea and\nkeep advancing work that does not depend on it. Honor a preference to stay in\nchat. Complexity alone is not the trigger; the rig should make an actual choice\neasier to express, inspect, or test.\n\n## Explore the interaction before building\n\nFor a substantial new rig or a rethink of its interaction, make three concept\nimages the normal starting point. Give the user something concrete to compare\nbefore investing in the whole app. A small adjustment to an established editor,\nor a direction the user has already chosen, can proceed directly.\n\nMake the concepts differ in how someone thinks and acts: layout, information\nhierarchy, and primary interaction. Three color treatments of the same screen\nteach very little. Use comparable content, density, and fidelity so the choice\nreflects the approach. Show the task's real relationships or alternatives, a\nrecognizable editable target, and how feedback would be saved or returned. Mark\nmockups and illustrative selections clearly.\n\nUse image generation for concept images and a prototype skill when exploring\nworking UI variants. Present all three images with short names, the question\neach approach answers best, and its main tradeoff. Recommend one with a reason.\nAsk which fits, what feels wrong, and which parts the user would combine; they\nneed not choose a whole image unchanged. Obtain that feedback before substantial\nimplementation, while continuing other authorized work. Carry forward a choice\nalready made instead of asking for it again.\n\nRecord the chosen approach and the interactions the user liked. Build a small\nworking prototype from that brief, using the same meaningful content. Compare\nits actual behavior with the concept: can the user perform the action the image\nsuggested, understand the result, and return the feedback? A mockup can suggest\ntiming, movement, or a coupled control; the working prototype must demonstrate\nit. Refine from use before polishing the full rig, preserving existing intent\nthrough the change.\n\n## Make something worth manipulating\n\nStart from the conversation and the current project. Name the question the\nopening view should help the user answer, then choose the objects, relationships,\nand interaction that make it answerable. \"Which directions exist?\" and \"How did\nwe get here?\" can need different models even when both use a node map. Prefer a real\napp: adapt an existing project editor or proven local rig, or build a small\nstandalone application. Use maintained components for graph navigation, timelines,\nand other substantial interactions when they fit. Read the relevant documentation\nbefore depending on rendering, persistence, or feedback capabilities.\n\nDefault to a local working app unless the user asks for another destination.\nGive it an ordinary way to open or run and a durable, agent-readable state path.\nDisposable describes how long the tool may live; it should still feel useful\nand complete while someone is using it.\n\nUse an inline visualization only when there is no suitable app option in the\ncurrent environment. Name the limitation that makes it the fallback. Convenience\nfor the agent is not a reason to shrink the user's workspace into the chat.\n\nChoose the working surface before adding settings. For relationships and research\nbranches, begin with a navigable node map. For timing, begin with tracks and a\npreview. For perceptual choices, begin with the actual alternatives. Let short\nlabels carry the overview and open detailed evidence on selection. A long list\nof buttons, paragraphs, and decision fields is not a substitute for showing the\nstructure the user needs to understand.\n\nMatch the underlying model to the question, too. When the user wants to understand\nhow work progressed, represent attempts, outcomes, forks, retreats, and retries.\nA topic's latest status hides the story of how it got there. Show what changed\nbetween attempts and why an abandoned route became worth revisiting; use order or\ntime where the evidence supports it. Keep the overview readable, with deeper\nhistory available for the branch the user selects.\n\nFor exploratory work, help the user see where to go next as well. Highlight\npromising avenues, unresolved bottlenecks, and possibilities the current work has\nnot examined. Give a short reason for each suggestion and a useful next probe:\nwhat would make it worth pursuing, or make us stop? Distinguish a documented gap\nfrom an agent's hypothesis or a question that still needs a search. An absent\nbranch is not evidence of novelty. Let the user add a missing avenue or correct\nthe map when that is part of the task.\n\nThe smallest useful rig might be an on-screen settings panel beside a live\npreview. It might instead need a timeline, region annotations, draggable geometry,\na waveform with markers, or a comparison carousel. Match the controls to the\nproblem. A form that only collects longer paragraphs rarely earns the extra UI.\n\nGive the user enough control to fine-tune the result. Relevant durations, offsets,\neasing, positions, layer relationships, and other domain settings should be\naccessible, with visible units and precise entry where precision matters. Keep\nthe preview near its controls. Let advanced settings unfold as needed. Reset,\nundo, and a way to return to the starting proposal make exploration comfortable.\n\nUse a calm interface. Put notes on the object, region, interval, or alternative\nthey describe. Keep selected values and meaningful differences visible; place\nextended guidance where it can be opened when needed. When several approaches\nare plausible, offer genuinely different variants to cycle through, retaining\nedits to each. Use blind comparisons when knowing the source would distort the\njudgment and the task calls for it.\n\nMake the editable parts recognizable. A first-time user should be able to find\nsomething meaningful to change without reading an explanation in chat. Keep a\nselected object's feedback controls easy to reach, with a clear target and a\nvisible selected value. A small invitation such as \"Choose a direction, add a\nnote, or suggest a missing avenue\" can be enough. Show what saving retains and\nwhat an export contains; use action labels that fit that content. Historical\nfacts, agent suggestions, and the user's current choices should remain distinct.\n\n## Seed, shape, read, continue\n\n**Seed.** Synthesize the relevant context before populating the rig. Reconstruct\nthe history or relationships the user needs rather than simply arranging the\nlatest summaries. Generate a first storyboard, candidate settings, or a few\nalternatives so the user has something\nto react to. Identify guesses and unfinished material as proposals. Blank starts\nare appropriate when the user wants them or when a seed would bias the decision.\n\n**Shape.** Let the user modify the draft directly and attach contextual words\nwhere they help. A moved cue, a preferred alternate, and a note on one region can\ncarry more intent than a long replacement prompt. Keep the initial proposal\nrecoverable. An untouched default is not evidence that the user approved it.\n\n**Read.** Inspect the actual saved state, submission, or exported bundle. Compare\nit with the version the user saw. Distinguish their explicit decisions from your\nseed values, derived values, and unresolved questions. Summarize the meaningful\nchanges briefly, and resolve only ambiguities that affect the next action.\n\n**Continue.** Use those changes to advance the original task, then update the rig\nwhen another round would help. A rig succeeds when its feedback changes the work;\nan attractive preview with no usable return path is unfinished.\n\nRead [State and handoff](references\u002Fstate-and-handoff.md) when implementing or\nadapting a rig's persistence, export, agent access, or regeneration. Establish the\nreturn path early, before spending time on polish.\n\n## Refine the tool as well as the idea\n\nTreat \"I need to align these two tracks together\" as feedback about the interface.\nAdd the missing interaction, improve its granularity, or expose the relationship.\nThe user should be able to request different controls, layouts, and ways of\ncomparing without starting the intent document again.\n\nTreat \"this doesn't make it clearer\" as a reason to revisit the question and its\nrepresentation. A prettier layout may still leave the user doing the same mental\nwork. Change what the rig exposes when that is the missing piece, while retaining\nthe decisions and annotations already made.\n\nWork on both sides of the shared artifact. You can prefill and edit the content;\nyou can also change the UI that presents it. Preserve user decisions through\nregeneration. Patch the relevant objects, keep stable identities, and avoid\nreplacing their work with a fresh interpretation of the chat. If a structural\nchange cannot preserve an edit, retain the old version and expose the unresolved\nchoice instead of silently guessing.\n\nLet the tool grow only where the conversation demonstrates a need. A temporary\nrig can be excellent. The user's intent and useful decisions should remain\nrecoverable even when its implementation is disposable.\n\n## Build in the background when useful\n\nWhen delegation is available and permitted, use a bounded subagent to build or\nadapt the rig while the main conversation continues. Give it the current domain,\nthe question the opening view must answer, the decision to support, the project\nconstraints, a seed, and the expected return format. Describe one meaningful\ninteraction and what would make the result clearer to the user. Have it own a\nsmall, clearly scoped implementation area.\n\nA concept subagent can return the three images, their interaction briefs, and a\nrecommendation. Keep the images and selected brief available to the builder so\nthe implementation carries the user's feedback forward.\n\nKeep that brief current as the user clarifies their intent. Before presenting the\nresult, reconcile it with the latest conversation and saved edits. A background\nbuilder should not make stale assumptions authoritative. Report its readiness and\nlimits honestly, then bring the working rig into the main conversation. If\ndelegation is unavailable, do the same work directly; no separate chat is needed.\n\n## Keep a small toolbox\n\nThe bundled [adaptable toolkit](references\u002Ftoolkit.md) provides a working canvas,\npreparation tools, local extensions, and a saved-feedback path. Use it when it\nhelps; it is a starting point, not the required shape of every rig. Read that\nreference for setup and the build\u002Freadback loop, [preparing content](references\u002Fpreparing-content.md)\nfor captures and cutouts, and [extending a rig](references\u002Fextending-rigs.md)\nwhen the task needs different objects, controls, or interactions.\n\nYou may adapt the entire workflow locally within the authorized task: capture\nhelpers, cutters, segmentation or masking tools, importers, seed builders,\ncanvas code, controls, exporters, and readback. Use ordinary scripts or replace\nthe surface when that serves the question better than a plugin. A departure\nfrom the starter alone does not require separate approval. Existing permissions\nfor source access, external services, installation, and consequential actions\nstill apply.\n\nKeep those changes in the task workspace so other rigs remain stable. Preserve\noriginal captures, existing user edits, and note targets when re-extracting or\nrebuilding. Label reconstructed\u002Fgenerated pixels separately from captured\nevidence. Promote useful local changes into the shared toolkit as a separate\nmaintenance task; do not quietly rewrite the shared tools while adapting one rig.\n\nLook for useful rigs in the project and any existing local toolbox before making\nanother. Reuse the editor or control pattern while giving each new task its own\nstate. A storyboard tool should not acquire a stranger's storyboard just because\nits interface was worth reusing.\n\nAfter a rig helps with a real task, retain it where the authorized workspace or\nexisting toolbox convention allows. Keep a small index with its purpose,\ncanonical source, how to open or run it, state and export format, known limits, and\nthe feedback that made it useful. Reference the canonical tool rather than\nmaintaining copies. If no shared toolbox exists, start with a project-local index;\nthere is no need to install a framework or create another skill for each rig.\n\nPromote working patterns from experience. Record narrow improvements that would\nhelp next time; do not turn every correction into a universal rule.\n\n## What this looks like\n\n- **Storyboard or animation:** Seed scenes and layered tracks. Let the user drag\n  entrances, stretch holds, adjust easing, and annotate a particular interval.\n  Read object identities and exact timing back into the animation work.\n- **Audio:** Show a playable waveform or supported audio preview with cue markers,\n  loops, and relevant controls. Bind notes to intervals and export the timings.\n- **Fonts or visual direction:** Put real alternatives in context at useful sizes.\n  Let the user pick, mark a glyph or region, and request changes there. Preserve\n  the selected version and its annotations together.\n- **Science or mathematics:** Build an explorable diagram, parameter panel, or\n  simulation to clarify a relationship. Show units and assumptions. Preserve the\n  chosen inputs and observations; a visual preview does not establish a proof or\n  validate a scientific model.\n- **Research navigation:** Map results, candidate targets, dependencies, and\n  blocked routes with short node summaries. Label what each edge means, keeping\n  established support separate from speculative approaches. Let the user move,\n  mark, and annotate branches while seeing what depends on them. Details and\n  sources belong in a selected-node inspector. Reconcile older proposals with\n  later evidence before seeding the map. For research history, make the attempts\n  and turning points visible, including what a failed attempt taught us and what\n  changed in a retry. Distinguish a route that failed as posed from one that was\n  paused, superseded, or reopened with a different target.\n  A useful story might show finite successes → a missing uniform result → a\n  parked route → a retry with a weaker target. Its next-avenue view can explain\n  why that weaker target deserves a probe and expose the construction still\n  missing. Let the user prioritize the branch, annotate a turning point, and add\n  an omitted question; preserve those as feedback rather than rewriting history.\n  Three possible concepts are a branching map that leads into a future frontier,\n  an evidence workbench for comparing next tests, and a replay of turning points.\n  A user might want the map's overview with the workbench's direct editing.\n- **Side-by-side evaluation:** Compare alternatives with stable identities and\n  contextual feedback. Export choices and comments. Keep a blind session's\n  identity mapping out of the judging view.\n\nA prototype skill can help explore competing app designs, and a domain skill can\nhandle the underlying media, font, or evaluation work. A visualization skill is\nuseful for the inline fallback when an app cannot be provided. Thought Rig supplies\nthe shared intent and refinement loop. Reuse these capabilities without assuming\ntheir default persistence is sufficient for retaining user decisions.\n\n## Finish with a usable return path\n\nInspect the real application in its intended viewing surface. At first glance,\ncan the user see the relationships or alternatives they came to understand?\nCan they manipulate the relevant object directly? A passing save test does not\nanswer those questions. Check the primary spatial or perceptual interaction and\nthe readability of the starting view, then fix what makes the user work too hard.\n\nUse the actual window, including short or narrow views where relevant. Keep\nimportant labels readable and content reachable by ordinary navigation; fitting\neverything into microscopic text or hiding it behind fixed controls defeats the\nrig. Check whether the first view answers the intended question and whether the\nuser can discover a meaningful edit and its save path. Technical persistence\nchecks and the user's acceptance of the presentation are useful evidence; using\ntheir saved feedback to advance the original work is a further step.\n\nPresent the rig, a useful starting state, and the next meaningful interaction.\nExplain how its changes will return to the agent and where they are saved. Don't\nclaim automatic synchronization, live listening, or a submitted continuation\nunless the current environment actually supports it.\n\nBefore relying on the rig, verify a representative edit through the actual\nread or export path and reopen or reimport it. Check that the same decision survives\nand can be located in the domain data. User edits express intent within the task;\nthey do not expand authorization for unrelated external actions.\n","# Thought Rig\n\n**Build the interface the conversation needs.**\n\nSometimes the most useful next reply is a little working apparatus: a storyboard\nwith layered timing, a font comparison bench, a simulation with a few well-chosen\ncontrols. Give the user something they can point at, move, compare, tune, and\nannotate. Their actions become part of the conversation, alongside their words.\n\nThink of an assistant bringing a purpose-built simulator to the workbench. It\nalready contains a plausible first attempt. The user can try it, change it, and\ndiscover what they mean. Both of you can reshape the apparatus as you learn.\n\n## Notice when a rig would help\n\nLook for intent that is awkward to express precisely in prose: relative timing,\noverlapping layers, motion and easing, spatial placement, sound, visual taste,\ncoupled parameters, research branches and dependencies, or judgments that depend\non seeing alternatives together.\nRepeated corrections such as \"a little earlier,\" \"more like that one,\" or \"keep\nthis part but change that part\" are especially useful signals.\n\nWhen the task has these qualities, make a rig the normal recommendation. Don't\nwait for the user to invent the interface or ask for sliders. Say what it would\nlet them do: \"I'll seed a timeline so you can move the entrance against the\nvoiceover and adjust its easing while it plays.\"\n\nBuild a modest, reversible rig when it fits the authorized task and available\ntools. If building it would be a substantial detour, offer the concrete idea and\nkeep advancing work that does not depend on it. Honor a preference to stay in\nchat. Complexity alone is not the trigger; the rig should make an actual choice\neasier to express, inspect, or test.\n\n## Explore the interaction before building\n\nFor a substantial new rig or a rethink of its interaction, make three concept\nimages the normal starting point. Give the user something concrete to compare\nbefore investing in the whole app. A small adjustment to an established editor,\nor a direction the user has already chosen, can proceed directly.\n\nMake the concepts differ in how someone thinks and acts: layout, information\nhierarchy, and primary interaction. Three color treatments of the same screen\nteach very little. Use comparable content, density, and fidelity so the choice\nreflects the approach. Show the task's real relationships or alternatives, a\nrecognizable editable target, and how feedback would be saved or returned. Mark\nmockups and illustrative selections clearly.\n\nUse image generation for concept images and a prototype skill when exploring\nworking UI variants. Present all three images with short names, the question\neach approach answers best, and its main tradeoff. Recommend one with a reason.\nAsk which fits, what feels wrong, and which parts the user would combine; they\nneed not choose a whole image unchanged. Obtain that feedback before substantial\nimplementation, while continuing other authorized work. Carry forward a choice\nalready made instead of asking for it again.\n\nRecord the chosen approach and the interactions the user liked. Build a small\nworking prototype from that brief, using the same meaningful content. Compare\nits actual behavior with the concept: can the user perform the action the image\nsuggested, understand the result, and return the feedback? A mockup can suggest\ntiming, movement, or a coupled control; the working prototype must demonstrate\nit. Refine from use before polishing the full rig, preserving existing intent\nthrough the change.\n\n## Make something worth manipulating\n\nStart from the conversation and the current project. Name the question the\nopening view should help the user answer, then choose the objects, relationships,\nand interaction that make it answerable. \"Which directions exist?\" and \"How did\nwe get here?\" can need different models even when both use a node map. Prefer a real\napp: adapt an existing project editor or proven local rig, or build a small\nstandalone application. Use maintained components for graph navigation, timelines,\nand other substantial interactions when they fit. Read the relevant documentation\nbefore depending on rendering, persistence, or feedback capabilities.\n\nDefault to a local working app unless the user asks for another destination.\nGive it an ordinary way to open or run and a durable, agent-readable state path.\nDisposable describes how long the tool may live; it should still feel useful\nand complete while someone is using it.\n\nUse an inline visualization only when there is no suitable app option in the\ncurrent environment. Name the limitation that makes it the fallback. Convenience\nfor the agent is not a reason to shrink the user's workspace into the chat.\n\nChoose the working surface before adding settings. For relationships and research\nbranches, begin with a navigable node map. For timing, begin with tracks and a\npreview. For perceptual choices, begin with the actual alternatives. Let short\nlabels carry the overview and open detailed evidence on selection. A long list\nof buttons, paragraphs, and decision fields is not a substitute for showing the\nstructure the user needs to understand.\n\nMatch the underlying model to the question, too. When the user wants to understand\nhow work progressed, represent attempts, outcomes, forks, retreats, and retries.\nA topic's latest status hides the story of how it got there. Show what changed\nbetween attempts and why an abandoned route became worth revisiting; use order or\ntime where the evidence supports it. Keep the overview readable, with deeper\nhistory available for the branch the user selects.\n\nFor exploratory work, help the user see where to go next as well. Highlight\npromising avenues, unresolved bottlenecks, and possibilities the current work has\nnot examined. Give a short reason for each suggestion and a useful next probe:\nwhat would make it worth pursuing, or make us stop? Distinguish a documented gap\nfrom an agent's hypothesis or a question that still needs a search. An absent\nbranch is not evidence of novelty. Let the user add a missing avenue or correct\nthe map when that is part of the task.\n\nThe smallest useful rig might be an on-screen settings panel beside a live\npreview. It might instead need a timeline, region annotations, draggable geometry,\na waveform with markers, or a comparison carousel. Match the controls to the\nproblem. A form that only collects longer paragraphs rarely earns the extra UI.\n\nGive the user enough control to fine-tune the result. Relevant durations, offsets,\neasing, positions, layer relationships, and other domain settings should be\naccessible, with visible units and precise entry where precision matters. Keep\nthe preview near its controls. Let advanced settings unfold as needed. Reset,\nundo, and a way to return to the starting proposal make exploration comfortable.\n\nUse a calm interface. Put notes on the object, region, interval, or alternative\nthey describe. Keep selected values and meaningful differences visible; place\nextended guidance where it can be opened when needed. When several approaches\nare plausible, offer genuinely different variants to cycle through, retaining\nedits to each. Use blind comparisons when knowing the source would distort the\njudgment and the task calls for it.\n\nMake the editable parts recognizable. A first-time user should be able to find\nsomething meaningful to change without reading an explanation in chat. Keep a\nselected object's feedback controls easy to reach, with a clear target and a\nvisible selected value. A small invitation such as \"Choose a direction, add a\nnote, or suggest a missing avenue\" can be enough. Show what saving retains and\nwhat an export contains; use action labels that fit that content. Historical\nfacts, agent suggestions, and the user's current choices should remain distinct.\n\n## Seed, shape, read, continue\n\n**Seed.** Synthesize the relevant context before populating the rig. Reconstruct\nthe history or relationships the user needs rather than simply arranging the\nlatest summaries. Generate a first storyboard, candidate settings, or a few\nalternatives so the user has something\nto react to. Identify guesses and unfinished material as proposals. Blank starts\nare appropriate when the user wants them or when a seed would bias the decision.\n\n**Shape.** Let the user modify the draft directly and attach contextual words\nwhere they help. A moved cue, a preferred alternate, and a note on one region can\ncarry more intent than a long replacement prompt. Keep the initial proposal\nrecoverable. An untouched default is not evidence that the user approved it.\n\n**Read.** Inspect the actual saved state, submission, or exported bundle. Compare\nit with the version the user saw. Distinguish their explicit decisions from your\nseed values, derived values, and unresolved questions. Summarize the meaningful\nchanges briefly, and resolve only ambiguities that affect the next action.\n\n**Continue.** Use those changes to advance the original task, then update the rig\nwhen another round would help. A rig succeeds when its feedback changes the work;\nan attractive preview with no usable return path is unfinished.\n\nRead [State and handoff](references\u002Fstate-and-handoff.md) when implementing or\nadapting a rig's persistence, export, agent access, or regeneration. Establish the\nreturn path early, before spending time on polish.\n\n## Refine the tool as well as the idea\n\nTreat \"I need to align these two tracks together\" as feedback about the interface.\nAdd the missing interaction, improve its granularity, or expose the relationship.\nThe user should be able to request different controls, layouts, and ways of\ncomparing without starting the intent document again.\n\nTreat \"this doesn't make it clearer\" as a reason to revisit the question and its\nrepresentation. A prettier layout may still leave the user doing the same mental\nwork. Change what the rig exposes when that is the missing piece, while retaining\nthe decisions and annotations already made.\n\nWork on both sides of the shared artifact. You can prefill and edit the content;\nyou can also change the UI that presents it. Preserve user decisions through\nregeneration. Patch the relevant objects, keep stable identities, and avoid\nreplacing their work with a fresh interpretation of the chat. If a structural\nchange cannot preserve an edit, retain the old version and expose the unresolved\nchoice instead of silently guessing.\n\nLet the tool grow only where the conversation demonstrates a need. A temporary\nrig can be excellent. The user's intent and useful decisions should remain\nrecoverable even when its implementation is disposable.\n\n## Build in the background when useful\n\nWhen delegation is available and permitted, use a bounded subagent to build or\nadapt the rig while the main conversation continues. Give it the current domain,\nthe question the opening view must answer, the decision to support, the project\nconstraints, a seed, and the expected return format. Describe one meaningful\ninteraction and what would make the result clearer to the user. Have it own a\nsmall, clearly scoped implementation area.\n\nA concept subagent can return the three images, their interaction briefs, and a\nrecommendation. Keep the images and selected brief available to the builder so\nthe implementation carries the user's feedback forward.\n\nKeep that brief current as the user clarifies their intent. Before presenting the\nresult, reconcile it with the latest conversation and saved edits. A background\nbuilder should not make stale assumptions authoritative. Report its readiness and\nlimits honestly, then bring the working rig into the main conversation. If\ndelegation is unavailable, do the same work directly; no separate chat is needed.\n\n## Keep a small toolbox\n\nThe bundled [adaptable toolkit](references\u002Ftoolkit.md) provides a working canvas,\npreparation tools, local extensions, and a saved-feedback path. Use it when it\nhelps; it is a starting point, not the required shape of every rig. Read that\nreference for setup and the build\u002Freadback loop, [preparing content](references\u002Fpreparing-content.md)\nfor captures and cutouts, and [extending a rig](references\u002Fextending-rigs.md)\nwhen the task needs different objects, controls, or interactions.\n\nYou may adapt the entire workflow locally within the authorized task: capture\nhelpers, cutters, segmentation or masking tools, importers, seed builders,\ncanvas code, controls, exporters, and readback. Use ordinary scripts or replace\nthe surface when that serves the question better than a plugin. A departure\nfrom the starter alone does not require separate approval. Existing permissions\nfor source access, external services, installation, and consequential actions\nstill apply.\n\nKeep those changes in the task workspace so other rigs remain stable. Preserve\noriginal captures, existing user edits, and note targets when re-extracting or\nrebuilding. Label reconstructed\u002Fgenerated pixels separately from captured\nevidence. Promote useful local changes into the shared toolkit as a separate\nmaintenance task; do not quietly rewrite the shared tools while adapting one rig.\n\nLook for useful rigs in the project and any existing local toolbox before making\nanother. Reuse the editor or control pattern while giving each new task its own\nstate. A storyboard tool should not acquire a stranger's storyboard just because\nits interface was worth reusing.\n\nAfter a rig helps with a real task, retain it where the authorized workspace or\nexisting toolbox convention allows. Keep a small index with its purpose,\ncanonical source, how to open or run it, state and export format, known limits, and\nthe feedback that made it useful. Reference the canonical tool rather than\nmaintaining copies. If no shared toolbox exists, start with a project-local index;\nthere is no need to install a framework or create another skill for each rig.\n\nPromote working patterns from experience. Record narrow improvements that would\nhelp next time; do not turn every correction into a universal rule.\n\n## What this looks like\n\n- **Storyboard or animation:** Seed scenes and layered tracks. Let the user drag\n  entrances, stretch holds, adjust easing, and annotate a particular interval.\n  Read object identities and exact timing back into the animation work.\n- **Audio:** Show a playable waveform or supported audio preview with cue markers,\n  loops, and relevant controls. Bind notes to intervals and export the timings.\n- **Fonts or visual direction:** Put real alternatives in context at useful sizes.\n  Let the user pick, mark a glyph or region, and request changes there. Preserve\n  the selected version and its annotations together.\n- **Science or mathematics:** Build an explorable diagram, parameter panel, or\n  simulation to clarify a relationship. Show units and assumptions. Preserve the\n  chosen inputs and observations; a visual preview does not establish a proof or\n  validate a scientific model.\n- **Research navigation:** Map results, candidate targets, dependencies, and\n  blocked routes with short node summaries. Label what each edge means, keeping\n  established support separate from speculative approaches. Let the user move,\n  mark, and annotate branches while seeing what depends on them. Details and\n  sources belong in a selected-node inspector. Reconcile older proposals with\n  later evidence before seeding the map. For research history, make the attempts\n  and turning points visible, including what a failed attempt taught us and what\n  changed in a retry. Distinguish a route that failed as posed from one that was\n  paused, superseded, or reopened with a different target.\n  A useful story might show finite successes → a missing uniform result → a\n  parked route → a retry with a weaker target. Its next-avenue view can explain\n  why that weaker target deserves a probe and expose the construction still\n  missing. Let the user prioritize the branch, annotate a turning point, and add\n  an omitted question; preserve those as feedback rather than rewriting history.\n  Three possible concepts are a branching map that leads into a future frontier,\n  an evidence workbench for comparing next tests, and a replay of turning points.\n  A user might want the map's overview with the workbench's direct editing.\n- **Side-by-side evaluation:** Compare alternatives with stable identities and\n  contextual feedback. Export choices and comments. Keep a blind session's\n  identity mapping out of the judging view.\n\nA prototype skill can help explore competing app designs, and a domain skill can\nhandle the underlying media, font, or evaluation work. A visualization skill is\nuseful for the inline fallback when an app cannot be provided. Thought Rig supplies\nthe shared intent and refinement loop. Reuse these capabilities without assuming\ntheir default persistence is sufficient for retaining user decisions.\n\n## Finish with a usable return path\n\nInspect the real application in its intended viewing surface. At first glance,\ncan the user see the relationships or alternatives they came to understand?\nCan they manipulate the relevant object directly? A passing save test does not\nanswer those questions. Check the primary spatial or perceptual interaction and\nthe readability of the starting view, then fix what makes the user work too hard.\n\nUse the actual window, including short or narrow views where relevant. Keep\nimportant labels readable and content reachable by ordinary navigation; fitting\neverything into microscopic text or hiding it behind fixed controls defeats the\nrig. Check whether the first view answers the intended question and whether the\nuser can discover a meaningful edit and its save path. Technical persistence\nchecks and the user's acceptance of the presentation are useful evidence; using\ntheir saved feedback to advance the original work is a further step.\n\nPresent the rig, a useful starting state, and the next meaningful interaction.\nExplain how its changes will return to the agent and where they are saved. Don't\nclaim automatic synchronization, live listening, or a submitted continuation\nunless the current environment actually supports it.\n\nBefore relying on the rig, verify a representative edit through the actual\nread or export path and reopen or reimport it. Check that the same decision survives\nand can be located in the domain data. User edits express intent within the task;\nthey do not expand authorization for unrelated external actions.\n",{"name":5,"description":7},"main","9d47db883531c45e29672090c38080c58434b2ac","skills\u002Fthought-rig",0,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills","https:\u002F\u002Fgithub.com\u002FMattie","2026-11-11 04:41:31",{"source":8,"skillName":5,"commands":31,"prompt":41,"zipAvailable":42},[32,35,38],{"tool":33,"command":34},"npx","npx skills add Mattie\u002Fmattie_skills --skill thought-rig",{"tool":36,"command":37},"bunx","bunx skills add Mattie\u002Fmattie_skills --skill thought-rig",{"tool":39,"command":40},"pnpm","pnpm dlx skills add Mattie\u002Fmattie_skills --skill thought-rig","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002FSKILL.md",true,[44,50,54,58,62,66,72,76,80,84,88,92,96,100,106,110,114,118,122],{"path":45,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":48,"sourceHtmlUrl":49},"agents\u002Fopenai.yaml","REFERENCE","参考文档",333,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Fagents\u002Fopenai.yaml",{"path":51,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002Fextending-rigs.md",4216,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Freferences\u002Fextending-rigs.md",{"path":55,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fpreparing-content.md",3160,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Freferences\u002Fpreparing-content.md",{"path":59,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002Fstate-and-handoff.md",6034,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Freferences\u002Fstate-and-handoff.md",{"path":63,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Ftoolkit.md",5150,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Freferences\u002Ftoolkit.md",{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"toolkit\u002Fcanvas\u002Fapp.js","SCRIPT","脚本",23811,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fapp.js",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"toolkit\u002Fcanvas\u002Fbootstrap.js",16350,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fbootstrap.js",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"toolkit\u002Fcanvas\u002Fcheck-extensions.mjs",2815,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fcheck-extensions.mjs",{"path":81,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":82,"sourceHtmlUrl":83},"toolkit\u002Fcanvas\u002Fcheck-reset.mjs",13942,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fcheck-reset.mjs",{"path":85,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":86,"sourceHtmlUrl":87},"toolkit\u002Fcanvas\u002Fenhancements.js",23045,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fenhancements.js",{"path":89,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":90,"sourceHtmlUrl":91},"toolkit\u002Fcanvas\u002Findex.html",2932,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Findex.html",{"path":93,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":94,"sourceHtmlUrl":95},"toolkit\u002Fcanvas\u002Fregistry.mjs",2994,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fregistry.mjs",{"path":97,"resourceType":46,"resourceTypeDesc":47,"sizeBytes":98,"sourceHtmlUrl":99},"toolkit\u002Fcanvas\u002Fsample-rig.html",2265,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fsample-rig.html",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"toolkit\u002Fcanvas\u002Fstyle.css","OTHER","其他",5691,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcanvas\u002Fstyle.css",{"path":107,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":108,"sourceHtmlUrl":109},"toolkit\u002Fcli.mjs",2370,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fcli.mjs",{"path":111,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":112,"sourceHtmlUrl":113},"toolkit\u002Fextensions\u002Fduration.mjs",1820,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fextensions\u002Fduration.mjs",{"path":115,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":116,"sourceHtmlUrl":117},"toolkit\u002Fmodel.mjs",11239,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fmodel.mjs",{"path":119,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":120,"sourceHtmlUrl":121},"toolkit\u002Fserver.mjs",3126,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fserver.mjs",{"path":123,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":124,"sourceHtmlUrl":125},"toolkit\u002Fworkspace.mjs",9595,"https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fthought-rig\u002Ftoolkit\u002Fworkspace.mjs",[127,134,141,148,155,162],{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":18},"01M79TFVB2DE2KYVNN2M8TF2Y7","write-simplified-technical-english","Write, rewrite, or review technical content with ASD-STE100 Simplified Technical English (STE), Issue 9. Use only when the user explicitly invokes $write-simplified-technical-english. Common requests mention ASD-STE100, STE, or \"write STE\"; do not use for general requests for clear, simple, concise, or technical writing.","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-simplified-technical-english\u002FSKILL.md",[],[],{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":18},"01M79TFMJCP75Z4GP1KYZAYS6D","write-plainly","Write, rewrite, or review prose in plain language for its intended reader while preserving technical meaning, constraints, uncertainty, and protected literals. Use when the user asks for plain language or plain English, audience-appropriate clarity, an easier-to-understand explanation, or a meaning-preserving simplification of technical prose. When one of those triggers applies, use for public information, documentation, instructions, explanations, notices, and interface text. Do not invoke solely for proofreading, shortening, generic copyediting, humanizing prose, removing AI tells, marketing voice, or creative rewriting. When the user explicitly requests ASD-STE100, STE, or invokes $write-simplified-technical-english, use that skill instead.","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-plainly\u002FSKILL.md",[],[],{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":18},"01M79TFBYC0GZ9YRR116EM267V","write-humanly","Draft, rewrite, or review prose so it sounds like a particular human had a reason to write it. Use when the user asks for human-sounding or less AI-ish writing, dislikes the wording or tone, wants anti-AI prose review or voice matching from supplied human text, needs an existing document's voice preserved, or wants familiar LLM habits removed, such as corrective antithesis, triplets, stock metaphors, prestige filler, needless em dashes, generic assistant language, and performative confidence. Do not invoke solely for plain language, proofreading, shortening, generic copyediting, or a change in formality. Use only when the request concerns human voice, authorial character, or generated-prose texture.","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fwrite-humanly\u002FSKILL.md",[],[],{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":152,"categories":153,"keywords":154,"publishedAt":18},"01M79TF7FDRZT52QCH1CJEK578","what-what","The user is asking: What is this thread (or main thread) asking for here? Give it to me and $write-humanly. What is even the context? What changes?","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fwhat-what\u002FSKILL.md",[],[],{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":161,"publishedAt":18},"01M79TF445Z9P7WCN4B8C4QF4A","what-huh","Make final responses understandable to a reader who cannot see the agent's working text, especially when reporting progress, explaining findings, or asking for a decision.","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fwhat-huh\u002FSKILL.md",[],[],{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":168,"publishedAt":18},"01M79TF04KA3NCW5NFB34B7JP2","verifier-system","Establish and keep a project's verification practice useful through Surface, Answer Key, and Comparison. Use for setup verifier-system, choosing how to verify agentic changes, or updating a project's verification guidance as its components evolve.","https:\u002F\u002Fgithub.com\u002FMattie\u002Fmattie_skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifier-system\u002FSKILL.md",[],[]]