[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71P141SPMBME1QDEA5XBXMF":3,"skill-same:01M71P141SPMBME1QDEA5XBXMF":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":49,"updatedAt":50,"install":51,"resources":63},"01M71P141SPMBME1QDEA5XBXMF","catchup",null,"Catch the user up on what changed in this chat since their last message, in plain words and small visuals. List every item waiting on them with what they need to decide it from the reply alone. Use for \u002Fskill:catchup.","drsh4dow\u002Fpi-setup","drsh4dow","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F45247070?v=4","01M71P068NASGHSWS11VWW416N","Daniel Moretti","01M71P0698BH81N65NP04X9NVN",10,"MIT","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fcatchup\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"up","reply","user","it","plain","use","visuals","list","true","decide","for","waiting on them","message","catch","with","last","chat","2026-11-10 10:56:23",false,"---\nname: catchup\ndescription: \"Catch the user up on what changed in this chat since their last message, in plain words and small visuals. List every item waiting on them with what they need to decide it from the reply alone. Use for \u002Fskill:catchup.\"\ndisable-model-invocation: true\nuser-invokable: true\n---\n\n# Catchup\n\nCatch the user up on what changed in this chat since the last message they wrote before `\u002Fskill:catchup`, and help them understand each change, not only where it stands. Then lay out every call waiting on them so they can make it from your reply alone. Notifications and subagent results are not their messages. Assume the user remembers their last message and nothing after it.\n\nUse [`\u002Fbro`](..\u002F..\u002Fprompts\u002Fbro.md)'s voice, not its task: plain words, short sentences, no jargon, like one person catching up another. Say what changed for the user, not how you did it. Say \"the tests pass\", not \"CI is green\". Leave out hashes, file paths, commands, build numbers, and test counts unless the user needs one to act, apart from the artifact list at the end. Call each PR, branch, or agent by a name the user would know, not by a label you invented. If a fact needs context to make sense, give the context or leave the fact out.\n\n## Gather what changed\n\nKeep this turn read-only: read anything you need, but do not change code, start an app or a job, or post anything. Collect your own work since that message, reports from subagents, and messages from anyone else in this chat. Your memory of the chat is a summary; the record is what the work wrote down. When the work keeps a state folder, such as a run's, list the files it wrote or changed since that message and read them before you write a word: the decision log, the run report, unit and ledger status, the standing orders, the reviews, and the evidence, such as verdicts, traces, and before and after files. Check the current state of each PR, CI run, or agent this chat touched. Check each number and each claim you will show against the artifact it comes from, and say so when you correct one. When an artifact disagrees with the current state, go by the current state and say which artifact is stale.\n\nAn action item is a call or step only the user can take, such as a product choice, an approval, an irreversible action, or access you lack. Include any still waiting on the user, even one raised before their last message. A question someone in the chat asked that only the user can answer, such as a bot asking who owns a ticket, is a call, and so is a default you chose on the user's behalf that they may want changed, such as anything you told them you would do \"unless you want\" otherwise or left as it was \"unless you say\". So is a proposal or question in the run's report or decision log that needs the user and has no recorded answer, even if the chat never asked it. Work you can still do yourself is not an action item, unless a standing order blocks it, such as one past a stop time: then lifting that order is the call. Never make up a call to fill the reply. A step the user did not ask for and the work does not need is not an action item, unless it is irreversible and waiting on the user: give it one line and no visual.\n\nOne call can cover many items, such as each PR in a set awaiting merge. For each item, collect its link, what it changes for users, the evidence behind your pick, its risk, and your pick. Write \"unknown\" for a fact the call needs that you do not know. Leave out a link you do not have.\n\n## Write the reply\n\nSpend words on the calls, not on the story. Keep what happened under 100 words, not counting pictures, and shorter when less happened. Leave out work that changed nothing for the user. Give each item about 30 words. The reply grows with the number of items: two items need well under 150 words in all, not counting pictures, and thirty need far more. Never cut items or shrink them to stay under a word count: no count in place of a list, and no link in place of an item. A link can add depth, but the reply alone must be enough to decide.\n\nOpen with one short sentence that names what waits on the user, or says nothing does. The action items give the detail. If nothing happened and nothing waits on the user, say so and stop.\n\nThen show what happened, pictures first. Embed inline the screenshots and videos the work produced, then any diagram that explains a change. Then sum up in one short bullet per thing the user asked for: what came of it, and whether it is done, still running, failed, or not checked. Name the furthest stage its evidence shows, decided, built, verified, or live, so a recorded decision never reads as shipped behavior. Write each line the way you would say it out loud: \"Search was slow from a missing index\", not \"Search review: done\" or \"Slow search: missing index\". Name any bug found and fixed on the way. Each line must stay true when read alone. Never mark something done that still waits on the user, and leave out anything the action items say. Under the summary, give at most three short lines that change what the user knows or must do. Then name in one line any work left that you can do yourself.\n\nThen list the action items. Ask the call the user owns, such as merge, approve, or pick, and give your pick. A step you would take first goes in your pick. So does anything that must happen first, and anything that cannot be undone. Give the number or link of each PR, issue, or agent a call is about, also in a call between options.\n\nFit the shape to the call. A call about one item is one bullet: the call, your pick, what it changes for users, the evidence behind your pick, and its risk, with the item named once. When items share a call, write the call and your pick once, then give each item its own bullet, riskiest first: its link and name, what it changes for users, the evidence behind your pick, and its risk. An item that is also part of a call between options, such as a PR that can merge once the user picks, still gets its own full bullet in the shared call. Name an item's pick only where it differs from the call's. Give each item's risk even when it is low, such as \"Low risk: only the colors change.\" Say what waiting costs only when it is more than a delay, such as a deadline or lost data.\n\nFor a call between options, give every option the work weighed, each with what it gets the user and what it costs, and the current state when there is one. Those costs are the call's risk, so add no separate risk line, unless the user must also merge or approve the item: then give the item's own risk too, as for any merge. When the screenshots above show the options, write each option's gain and cost under its screenshot.\n\nEnd with the artifacts, so the user can check your story and reason about each call themselves. Give one bullet per artifact you read that bears on a call or a summary line, such as a decision-log entry, the run report, a review, a verdict, a trace, or a before and after file. Each bullet links the file, says in a few words what question it answers, gives when it was written, and flags any disagreement with the current state. Group them under the call or summary line they back. This list does not count toward the word limits, and it is the one place file paths belong. Leave it out only when the work kept no artifacts.\n\n## Visuals\n\nA visual is a picture: a screenshot, a video, a Mermaid diagram, a chart or diagram from `scripts\u002Fvisualize.ts`, or a generated image. A Markdown table is not a visual, even with before and after columns.\n\nWhen something is easier to grasp as a picture than as sentences, draw it: how a design or system works, a PR stack or dependency chain with each PR's state, a before and after of a fix, or options side by side. Never draw a status list, a list of action items, or boxes with nothing connecting them. Never give a fact twice, in text or across visuals.\n\nKeep each visual small enough to read at a glance: at most six boxes, with at most eight words in each. Write labels as plain words a person would say, not tags like \"Tests: pass\". A fact that needs a sentence belongs in the text, or nowhere.\n\nEmbed screenshots and videos inline when the change is visible, not only as links. If a visible change has none, mark its summary line \"No screenshot yet,\" and say there what changed on screen. Draw diagrams and charts from facts you have: a Mermaid diagram for how things connect and a `scripts\u002Fvisualize.ts` chart for numbers. Never invent a number, and never draw or generate a picture of a screen you did not capture. Link only artifacts that exist.\n\nTo embed a screenshot or chart in Pi, read its image file with the `read` tool, which shows the picture in the chat. A video cannot play in the chat, so link its file. Run `node \u003Cskill dir>\u002Fscripts\u002Fvisualize.ts --help` for how to draw a chart, and write its files in the state folder.\n","# Catchup\n\nCatch the user up on what changed in this chat since the last message they wrote before `\u002Fskill:catchup`, and help them understand each change, not only where it stands. Then lay out every call waiting on them so they can make it from your reply alone. Notifications and subagent results are not their messages. Assume the user remembers their last message and nothing after it.\n\nUse [`\u002Fbro`](..\u002F..\u002Fprompts\u002Fbro.md)'s voice, not its task: plain words, short sentences, no jargon, like one person catching up another. Say what changed for the user, not how you did it. Say \"the tests pass\", not \"CI is green\". Leave out hashes, file paths, commands, build numbers, and test counts unless the user needs one to act, apart from the artifact list at the end. Call each PR, branch, or agent by a name the user would know, not by a label you invented. If a fact needs context to make sense, give the context or leave the fact out.\n\n## Gather what changed\n\nKeep this turn read-only: read anything you need, but do not change code, start an app or a job, or post anything. Collect your own work since that message, reports from subagents, and messages from anyone else in this chat. Your memory of the chat is a summary; the record is what the work wrote down. When the work keeps a state folder, such as a run's, list the files it wrote or changed since that message and read them before you write a word: the decision log, the run report, unit and ledger status, the standing orders, the reviews, and the evidence, such as verdicts, traces, and before and after files. Check the current state of each PR, CI run, or agent this chat touched. Check each number and each claim you will show against the artifact it comes from, and say so when you correct one. When an artifact disagrees with the current state, go by the current state and say which artifact is stale.\n\nAn action item is a call or step only the user can take, such as a product choice, an approval, an irreversible action, or access you lack. Include any still waiting on the user, even one raised before their last message. A question someone in the chat asked that only the user can answer, such as a bot asking who owns a ticket, is a call, and so is a default you chose on the user's behalf that they may want changed, such as anything you told them you would do \"unless you want\" otherwise or left as it was \"unless you say\". So is a proposal or question in the run's report or decision log that needs the user and has no recorded answer, even if the chat never asked it. Work you can still do yourself is not an action item, unless a standing order blocks it, such as one past a stop time: then lifting that order is the call. Never make up a call to fill the reply. A step the user did not ask for and the work does not need is not an action item, unless it is irreversible and waiting on the user: give it one line and no visual.\n\nOne call can cover many items, such as each PR in a set awaiting merge. For each item, collect its link, what it changes for users, the evidence behind your pick, its risk, and your pick. Write \"unknown\" for a fact the call needs that you do not know. Leave out a link you do not have.\n\n## Write the reply\n\nSpend words on the calls, not on the story. Keep what happened under 100 words, not counting pictures, and shorter when less happened. Leave out work that changed nothing for the user. Give each item about 30 words. The reply grows with the number of items: two items need well under 150 words in all, not counting pictures, and thirty need far more. Never cut items or shrink them to stay under a word count: no count in place of a list, and no link in place of an item. A link can add depth, but the reply alone must be enough to decide.\n\nOpen with one short sentence that names what waits on the user, or says nothing does. The action items give the detail. If nothing happened and nothing waits on the user, say so and stop.\n\nThen show what happened, pictures first. Embed inline the screenshots and videos the work produced, then any diagram that explains a change. Then sum up in one short bullet per thing the user asked for: what came of it, and whether it is done, still running, failed, or not checked. Name the furthest stage its evidence shows, decided, built, verified, or live, so a recorded decision never reads as shipped behavior. Write each line the way you would say it out loud: \"Search was slow from a missing index\", not \"Search review: done\" or \"Slow search: missing index\". Name any bug found and fixed on the way. Each line must stay true when read alone. Never mark something done that still waits on the user, and leave out anything the action items say. Under the summary, give at most three short lines that change what the user knows or must do. Then name in one line any work left that you can do yourself.\n\nThen list the action items. Ask the call the user owns, such as merge, approve, or pick, and give your pick. A step you would take first goes in your pick. So does anything that must happen first, and anything that cannot be undone. Give the number or link of each PR, issue, or agent a call is about, also in a call between options.\n\nFit the shape to the call. A call about one item is one bullet: the call, your pick, what it changes for users, the evidence behind your pick, and its risk, with the item named once. When items share a call, write the call and your pick once, then give each item its own bullet, riskiest first: its link and name, what it changes for users, the evidence behind your pick, and its risk. An item that is also part of a call between options, such as a PR that can merge once the user picks, still gets its own full bullet in the shared call. Name an item's pick only where it differs from the call's. Give each item's risk even when it is low, such as \"Low risk: only the colors change.\" Say what waiting costs only when it is more than a delay, such as a deadline or lost data.\n\nFor a call between options, give every option the work weighed, each with what it gets the user and what it costs, and the current state when there is one. Those costs are the call's risk, so add no separate risk line, unless the user must also merge or approve the item: then give the item's own risk too, as for any merge. When the screenshots above show the options, write each option's gain and cost under its screenshot.\n\nEnd with the artifacts, so the user can check your story and reason about each call themselves. Give one bullet per artifact you read that bears on a call or a summary line, such as a decision-log entry, the run report, a review, a verdict, a trace, or a before and after file. Each bullet links the file, says in a few words what question it answers, gives when it was written, and flags any disagreement with the current state. Group them under the call or summary line they back. This list does not count toward the word limits, and it is the one place file paths belong. Leave it out only when the work kept no artifacts.\n\n## Visuals\n\nA visual is a picture: a screenshot, a video, a Mermaid diagram, a chart or diagram from `scripts\u002Fvisualize.ts`, or a generated image. A Markdown table is not a visual, even with before and after columns.\n\nWhen something is easier to grasp as a picture than as sentences, draw it: how a design or system works, a PR stack or dependency chain with each PR's state, a before and after of a fix, or options side by side. Never draw a status list, a list of action items, or boxes with nothing connecting them. Never give a fact twice, in text or across visuals.\n\nKeep each visual small enough to read at a glance: at most six boxes, with at most eight words in each. Write labels as plain words a person would say, not tags like \"Tests: pass\". A fact that needs a sentence belongs in the text, or nowhere.\n\nEmbed screenshots and videos inline when the change is visible, not only as links. If a visible change has none, mark its summary line \"No screenshot yet,\" and say there what changed on screen. Draw diagrams and charts from facts you have: a Mermaid diagram for how things connect and a `scripts\u002Fvisualize.ts` chart for numbers. Never invent a number, and never draw or generate a picture of a screen you did not capture. Link only artifacts that exist.\n\nTo embed a screenshot or chart in Pi, read its image file with the `read` tool, which shows the picture in the chat. A video cannot play in the chat, so link its file. Run `node \u003Cskill dir>\u002Fscripts\u002Fvisualize.ts --help` for how to draw a chart, and write its files in the state folder.\n",{"name":5,"description":7,"user-invokable":41,"disable-model-invocation":41},true,"main","f7936596c1ba2e1472dadccc3f111b9d517fa96c","agent\u002Fskills\u002Fcatchup",2,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup","https:\u002F\u002Fgithub.com\u002Fdrsh4dow","https:\u002F\u002Fdanielmoretti.com\u002F","Toss A Coin To Your Witcher :pirate_flag: ","2026-11-03 22:13:53",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":41},[53,56,59],{"tool":54,"command":55},"npx","npx skills add drsh4dow\u002Fpi-setup --skill catchup",{"tool":57,"command":58},"bunx","bunx skills add drsh4dow\u002Fpi-setup --skill catchup",{"tool":60,"command":61},"pnpm","pnpm dlx skills add drsh4dow\u002Fpi-setup --skill catchup","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fcatchup\u002FSKILL.md",[64,70,74],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"scripts\u002Ftest\u002Fvisualize.test.ts","SCRIPT","脚本",2355,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fcatchup\u002Fscripts\u002Ftest\u002Fvisualize.test.ts",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"scripts\u002Ftsconfig.json",447,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fcatchup\u002Fscripts\u002Ftsconfig.json",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"scripts\u002Fvisualize.ts",2001,"https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fcatchup\u002Fscripts\u002Fvisualize.ts",[79,100,132,149,168,179],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":36},"01M71P4GPJMBK21BTZBKY9T8EE","changelog","Write the changelog entry for a pull request. Use when a PR changes behavior that users, operators, or integrators can notice.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fevals\u002Fharness-lessons\u002Ffixtures\u002Fchangelog-skill\u002FSKILL.md",[],[81,86,87,88,89,90,91,92,29,93,94,95,96,24,97,98,99],"users","pull","notice","changes","operators","pr","pull request","request","behavior","entry","write","when","can","changelog entry",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":116,"publishedAt":36},"01M71P4E9AZM56JBY227P2G1SC","writing-good-tickets","Write, file, or update an issue or ticket that an agent or a developer can take to one PR. Use when filing a bug or feature, updating an issue, or breaking a plan into tickets.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-tickets\u002FSKILL.md",[106,111],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[117,118,119,120,91,121,122,123,24,124,97,125,126,98,127,128,96,129,130,131],"good","writing","tickets","writing good tickets","feature","filing","ticket","false","file","one","plan","update","bug","take","issue",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":140,"publishedAt":36},"01M71P4C0B0DXTRRSG9RA6Y687","writing-good-prs","Write or update a pull request title and body that a reviewer can trust and own. Use when opening a PR or editing its description.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-prs\u002FSKILL.md",[138,139],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[117,141,118,142,87,143,91,144,24,124,97,98,145,146,92,93,128,96,147,148],"prs","writing good prs","trust","editing","reviewer","title","opening a pr","body",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":157,"publishedAt":36},"01M71P49D1AG2MR6AYNPMMT34Z","writing-good-commits","Write or reword a git commit message and size the commit it describes. Use when committing, or when reshaping commits during a rebase.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-good-commits\u002FSKILL.md",[155,156],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[158,117,118,159,31,160,96,161,162,163,24,124,164,165,97,166,167,22],"commits","writing good commits","size","git commit message","git","git commit","rebase","commit message","committing","commit",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":172,"categories":173,"keywords":176,"publishedAt":36},"01M71P480BDE55JMPVVEBCFS7P","writing-for-agents","Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwriting-for-agents\u002FSKILL.md",[174,175],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},[177,29,118,144,24,124,178,97],"writing for agents","documents",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":36},"01M71P45SNCD7DDSA6FRVCPA17","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fdrsh4dow\u002Fpi-setup\u002Fblob\u002Fmain\u002Fagent\u002Fskills\u002Fwizard\u002FSKILL.md",[],[181,186,187,29,19,188,189,190,24,191,124,97,192,126,193,98,194,195,196,197],"running","setting","ci","provisioning infrastructure","only","invoke","Bash","interactive","credentials","dashboard","generate","human"]