[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CP97MEN4RXSGR6CVH8T3JN":3,"skill-same:01M6CP97MEN4RXSGR6CVH8T3JN":68},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":53,"updatedAt":54,"install":55,"resources":67},"01M6CP97MEN4RXSGR6CVH8T3JN","implementation",null,"Implement a fix or feature from a GitHub, Jira, Linear, or other issue-tracker issue by fetching issue context, inspecting the current codebase, making code changes, validating them, opening a GitHub pull request, and reporting progress back to the original issue.","bholmesdev\u002Fhubble.md","bholmesdev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F51384119?v=4","01M6CP8SJ3N9W8FYVCGV41QT3G","Ben Holmes","01M6CP8SP3A84K1TFMVS8BEBDW",1523,"MIT","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplementation\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"request","github","codebase","changes","true","progress","feature","back","tracker","issue","fix","context","reporting","pull","linear","code","jira","pull request","implement","2026-11-10 10:12:30",false,"---\nname: implementation\ndescription: Implement a fix or feature from a GitHub, Jira, Linear, or other issue-tracker issue by fetching issue context, inspecting the current codebase, making code changes, validating them, opening a GitHub pull request, and reporting progress back to the original issue.\nmetadata:\n  internal: true\n---\n\n# Implementation\n\nImplement the issue passed in the user's prompt and open a GitHub pull request with the fix or feature.\n\nExpect the prompt to contain a link, key, or number for exactly one issue in an issue tracker. Use tracker context and the current checkout to understand the requested behavior before changing code.\n\n## Workflow\n\n### 1. Identify the issue and repository\n\nExtract the issue URL, key, or number from the prompt. Determine whether it belongs to GitHub Issues, Jira, Linear, or another tracker.\n\nConfirm the current checkout is the repository where the implementation should happen. If the prompt does not identify one issue unambiguously, ask for clarification before making changes.\n\n### 2. Post an implementation-started status comment\n\nFor GitHub Issues, post a short status comment before doing implementation work so issue subscribers know an agent has started.\n\nUse the authenticated `gh` CLI when available. Include:\n\n- That automated implementation by a [Warp Factory agent](https:\u002F\u002Fwww.warp.dev\u002Foz) has started.\n- The issue identifier being implemented.\n- A follow-along link to the Oz run or Oz session.\n\nUse an Oz run URL or Oz session URL from the agent runtime, action output, environment, or logs. Do not use a GitHub Actions workflow URL as the follow-along link. If no Oz run or session link is available yet, say that the Oz follow-along link is not available yet rather than substituting another URL, and continue implementation.\n\nKeep this comment concise.\n\n### 3. Fetch tracker context\n\nUse the best available integration in this order:\n\n1. A relevant MCP server or native tracker tool\n2. The tracker's authenticated CLI, such as `gh`\n3. The tracker's API or web page\n\nFetch:\n\n- Full issue title and description\n- Comments and discussion\n- Existing labels, status, assignee, project, and linked issues\n- Attachments, screenshots, logs, reproduction steps, and acceptance criteria\n- Related open issues, likely duplicates, dependencies, and nearby product work\n\nDo not implement solely from the issue title. Do not expose credentials or secrets while fetching tracker data.\n\nIf tracker context is missing critical implementation details, post a concise blocker comment with the specific missing information and stop instead of guessing.\n\n### 4. Inspect the current codebase\n\nSearch and read the codebase to understand the affected feature, behavior, terminology, and likely implementation area.\n\nAssess:\n\n- Whether the described behavior exists today\n- Likely files, services, UI components, APIs, tests, and data flows involved\n- Existing patterns and abstractions to follow\n- Edge cases, migrations, platform differences, or compatibility risks\n- Validation commands used by the repository\n\nPost a brief progress comment if this investigation reveals a materially useful implementation area, for example: \"I found the relevant editor state flow in `src\u002F...` and am implementing the change there.\" Do not post internal reasoning, speculative details, secrets, or raw command output. Do not describe the implementation as complete until a pull request has been opened and you can include the PR URL.\n\n### 5. Implement the change\n\nMake the smallest cohesive change that satisfies the issue.\n\nFollow existing code style and architecture. Update tests, fixtures, docs, or configuration when they are part of the expected behavior. Do not bundle unrelated refactors, formatting churn, dependency upgrades, or opportunistic cleanup into the PR.\n\nIf the issue turns out to be much larger or more ambiguous than expected, stop and comment with a concise recommendation rather than producing a risky partial implementation.\n\n### 6. Validate the implementation\n\nRun the most relevant validation commands for the repository. Prefer commands documented in README, package scripts, CI config, Makefiles, or existing workflow files.\n\nAt minimum, attempt:\n\n- Targeted tests for the changed behavior, if available\n- Linting or typechecking, if available\n- A build or equivalent compile check, if appropriate\n\nThen verify the change end-to-end with the repo's verification skills. Passing typechecks and unit tests is not sufficient for user-facing changes:\n\n- For changes that affect the desktop app, follow `.agents\u002Fskills\u002Ftest-desktop-app\u002FSKILL.md`: run the app with CDP enabled, drive the changed flow in the real renderer (click controls, type, inspect DOM state), and confirm the issue's expected behavior visibly works. Capture a screenshot of the working flow when practical and include it in the PR.\n- For changes that affect the web app, use the dev server with `?test=1` as described in `AGENTS.md` and drive the changed flow the same way.\n- Before opening the PR, apply `.agents\u002Fskills\u002Fsimplify\u002FSKILL.md`.\n\nIf end-to-end verification is not possible in the current environment (for example the app cannot launch), say so explicitly in the PR with what was attempted; do not imply the flow was exercised.\n\nIf a validation command fails, investigate and fix failures caused by your changes. If failures appear unrelated or require external services, report them clearly in the PR and issue comment with enough detail for a reviewer to reproduce.\n\n### 7. Create a branch and pull request\n\nCreate a descriptive branch for the implementation, such as `fix\u002Fissue-123-short-title` or `feature\u002Fissue-123-short-title`.\n\nCommit only the intended changes. Use a clear commit message. When committing, include:\n\n`Co-Authored-By: Warp Factory Agent \u003Coz-agent@warp.dev>`\n\nPush the branch and open a GitHub pull request against the repository's default branch using the authenticated `gh` CLI. Capture the PR URL returned by `gh pr create`; this URL is required before posting final success back to the issue.\n\nThe PR description should include:\n\n- A direct link to the original issue\n- Summary of the change\n- Validation commands run and their results\n- Known limitations, follow-up work, or validation gaps\n\nAssociate the PR with the issue in GitHub:\n\n- If the implementation fully resolves the issue, include a closing keyword in the PR body, such as `Closes #123` or `Fixes #123`.\n- If the implementation only partially addresses the issue, include a non-closing reference, such as `Related to #123`, and explain the remaining work.\n\nAfter creating the PR, verify that you have a real PR URL. If `gh pr create` fails, do not post a success comment. Instead, fix the failure if possible, or post a blocker comment explaining that the implementation branch exists but PR creation failed.\n\n### 8. Post the PR link and final status to the issue\n\nOnly after opening the PR, post a final comment on the original issue with:\n\n- Link to the PR\n- Brief summary of what was implemented\n- Validation performed\n- Any known limitations or reviewer notes\n\nThe final issue comment must include the PR URL. A comment that says implementation is complete or that a PR will be opened later is not acceptable.\n\nIf no PR was created, post why implementation did not proceed and what concrete next step is needed. Do not describe this as a successful implementation.\n\n## Guardrails\n\n- Do not implement without fetching tracker context and inspecting the codebase.\n- Do not expose secrets, tokens, private environment variables, raw logs containing credentials, or internal reasoning in issue comments or PR descriptions.\n- Do not close, assign, reprioritize, or relabel the issue unless explicitly requested.\n- Do not overwrite unrelated labels or metadata.\n- Do not make unrelated code changes.\n- Do not claim validation passed if it was not run or failed.\n- Do not post a final success comment unless a pull request has already been opened and the comment includes the PR URL.\n- Post progress sparingly: always post the implementation-started comment, then post at most two additional progress comments before the final PR link unless blocked or explicitly asked for more updates.\n","# Implementation\n\nImplement the issue passed in the user's prompt and open a GitHub pull request with the fix or feature.\n\nExpect the prompt to contain a link, key, or number for exactly one issue in an issue tracker. Use tracker context and the current checkout to understand the requested behavior before changing code.\n\n## Workflow\n\n### 1. Identify the issue and repository\n\nExtract the issue URL, key, or number from the prompt. Determine whether it belongs to GitHub Issues, Jira, Linear, or another tracker.\n\nConfirm the current checkout is the repository where the implementation should happen. If the prompt does not identify one issue unambiguously, ask for clarification before making changes.\n\n### 2. Post an implementation-started status comment\n\nFor GitHub Issues, post a short status comment before doing implementation work so issue subscribers know an agent has started.\n\nUse the authenticated `gh` CLI when available. Include:\n\n- That automated implementation by a [Warp Factory agent](https:\u002F\u002Fwww.warp.dev\u002Foz) has started.\n- The issue identifier being implemented.\n- A follow-along link to the Oz run or Oz session.\n\nUse an Oz run URL or Oz session URL from the agent runtime, action output, environment, or logs. Do not use a GitHub Actions workflow URL as the follow-along link. If no Oz run or session link is available yet, say that the Oz follow-along link is not available yet rather than substituting another URL, and continue implementation.\n\nKeep this comment concise.\n\n### 3. Fetch tracker context\n\nUse the best available integration in this order:\n\n1. A relevant MCP server or native tracker tool\n2. The tracker's authenticated CLI, such as `gh`\n3. The tracker's API or web page\n\nFetch:\n\n- Full issue title and description\n- Comments and discussion\n- Existing labels, status, assignee, project, and linked issues\n- Attachments, screenshots, logs, reproduction steps, and acceptance criteria\n- Related open issues, likely duplicates, dependencies, and nearby product work\n\nDo not implement solely from the issue title. Do not expose credentials or secrets while fetching tracker data.\n\nIf tracker context is missing critical implementation details, post a concise blocker comment with the specific missing information and stop instead of guessing.\n\n### 4. Inspect the current codebase\n\nSearch and read the codebase to understand the affected feature, behavior, terminology, and likely implementation area.\n\nAssess:\n\n- Whether the described behavior exists today\n- Likely files, services, UI components, APIs, tests, and data flows involved\n- Existing patterns and abstractions to follow\n- Edge cases, migrations, platform differences, or compatibility risks\n- Validation commands used by the repository\n\nPost a brief progress comment if this investigation reveals a materially useful implementation area, for example: \"I found the relevant editor state flow in `src\u002F...` and am implementing the change there.\" Do not post internal reasoning, speculative details, secrets, or raw command output. Do not describe the implementation as complete until a pull request has been opened and you can include the PR URL.\n\n### 5. Implement the change\n\nMake the smallest cohesive change that satisfies the issue.\n\nFollow existing code style and architecture. Update tests, fixtures, docs, or configuration when they are part of the expected behavior. Do not bundle unrelated refactors, formatting churn, dependency upgrades, or opportunistic cleanup into the PR.\n\nIf the issue turns out to be much larger or more ambiguous than expected, stop and comment with a concise recommendation rather than producing a risky partial implementation.\n\n### 6. Validate the implementation\n\nRun the most relevant validation commands for the repository. Prefer commands documented in README, package scripts, CI config, Makefiles, or existing workflow files.\n\nAt minimum, attempt:\n\n- Targeted tests for the changed behavior, if available\n- Linting or typechecking, if available\n- A build or equivalent compile check, if appropriate\n\nThen verify the change end-to-end with the repo's verification skills. Passing typechecks and unit tests is not sufficient for user-facing changes:\n\n- For changes that affect the desktop app, follow `.agents\u002Fskills\u002Ftest-desktop-app\u002FSKILL.md`: run the app with CDP enabled, drive the changed flow in the real renderer (click controls, type, inspect DOM state), and confirm the issue's expected behavior visibly works. Capture a screenshot of the working flow when practical and include it in the PR.\n- For changes that affect the web app, use the dev server with `?test=1` as described in `AGENTS.md` and drive the changed flow the same way.\n- Before opening the PR, apply `.agents\u002Fskills\u002Fsimplify\u002FSKILL.md`.\n\nIf end-to-end verification is not possible in the current environment (for example the app cannot launch), say so explicitly in the PR with what was attempted; do not imply the flow was exercised.\n\nIf a validation command fails, investigate and fix failures caused by your changes. If failures appear unrelated or require external services, report them clearly in the PR and issue comment with enough detail for a reviewer to reproduce.\n\n### 7. Create a branch and pull request\n\nCreate a descriptive branch for the implementation, such as `fix\u002Fissue-123-short-title` or `feature\u002Fissue-123-short-title`.\n\nCommit only the intended changes. Use a clear commit message. When committing, include:\n\n`Co-Authored-By: Warp Factory Agent \u003Coz-agent@warp.dev>`\n\nPush the branch and open a GitHub pull request against the repository's default branch using the authenticated `gh` CLI. Capture the PR URL returned by `gh pr create`; this URL is required before posting final success back to the issue.\n\nThe PR description should include:\n\n- A direct link to the original issue\n- Summary of the change\n- Validation commands run and their results\n- Known limitations, follow-up work, or validation gaps\n\nAssociate the PR with the issue in GitHub:\n\n- If the implementation fully resolves the issue, include a closing keyword in the PR body, such as `Closes #123` or `Fixes #123`.\n- If the implementation only partially addresses the issue, include a non-closing reference, such as `Related to #123`, and explain the remaining work.\n\nAfter creating the PR, verify that you have a real PR URL. If `gh pr create` fails, do not post a success comment. Instead, fix the failure if possible, or post a blocker comment explaining that the implementation branch exists but PR creation failed.\n\n### 8. Post the PR link and final status to the issue\n\nOnly after opening the PR, post a final comment on the original issue with:\n\n- Link to the PR\n- Brief summary of what was implemented\n- Validation performed\n- Any known limitations or reviewer notes\n\nThe final issue comment must include the PR URL. A comment that says implementation is complete or that a PR will be opened later is not acceptable.\n\nIf no PR was created, post why implementation did not proceed and what concrete next step is needed. Do not describe this as a successful implementation.\n\n## Guardrails\n\n- Do not implement without fetching tracker context and inspecting the codebase.\n- Do not expose secrets, tokens, private environment variables, raw logs containing credentials, or internal reasoning in issue comments or PR descriptions.\n- Do not close, assign, reprioritize, or relabel the issue unless explicitly requested.\n- Do not overwrite unrelated labels or metadata.\n- Do not make unrelated code changes.\n- Do not claim validation passed if it was not run or failed.\n- Do not post a final success comment unless a pull request has already been opened and the comment includes the PR URL.\n- Post progress sparingly: always post the implementation-started comment, then post at most two additional progress comments before the final PR link unless blocked or explicitly asked for more updates.\n",{"name":5,"metadata":43,"description":7},{"internal":44},true,"main","cf633b3221b9572f22604168ac77c1ffa921debe",".agents\u002Fskills\u002Fimplementation",99,"https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md","https:\u002F\u002Fhubble.md","https:\u002F\u002Fgithub.com\u002Fbholmesdev","https:\u002F\u002Fbholmes.dev","Web developer, teacher, whiteboardist. Building the next terminal @warpdotdev ","2026-11-06 02:02:39",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":44},[57,60,63],{"tool":58,"command":59},"npx","npx skills add bholmesdev\u002Fhubble.md --skill implementation",{"tool":61,"command":62},"bunx","bunx skills add bholmesdev\u002Fhubble.md --skill implementation",{"tool":64,"command":65},"pnpm","pnpm dlx skills add bholmesdev\u002Fhubble.md --skill implementation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fimplementation\u002FSKILL.md",[],[69,89,104,123,143,168],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":38},"01M6PQAVS5DTTVEV9VA313YSYM","review-markdown-comments","Reply to, resolve, or reopen Hubble review comments stored as CriticMarkup in Markdown files. Use when asked to address a Hubble review comment.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Freview-markdown-comments\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",[81,82,83,84,85,86,87,88],"review markdown comments","comments","review","markdown","as","files","reply","use",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":38},"01M6PQAH29FCQB6921Y94CA8F4","merge-risk","Use when assessing the risk of merging a PR","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fmerge-risk\u002FSKILL.md",[],[96,97,98,20,99,100,101,102,23,103,88,45],"merge","risk","merge risk","blob","pr","https","engineering","matt pocock",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":114,"publishedAt":38},"01M6PQA0ADFHMANPW4KRAV7EA6","embed-html-app","Embed a Hubble HTML App inline inside a Markdown File using an iframe block. Use when an app should be viewed in the context of a document.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fembed-html-app\u002FSKILL.md",[110,111],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},{"categoryNo":112,"categoryName":113,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000009","前端开发",[115,116,117,118,119,120,84,30,88,121,122],"html","app","embed","embed html app","inline","file","document","block",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":129,"publishedAt":38},"01M6PQ9WQM5HF4QQ1J750346NY","edit-diagram","Create or edit a Hubble diagram: a .tldr file Hubble opens in its built-in tldraw canvas. With this skill installed, any diagram, canvas, whiteboard, or .tldr file is a Hubble diagram: use this skill instead of tldraw-offline, unless the user names the tldraw offline app or the file is a .tldraw archive.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fedit-diagram\u002FSKILL.md",[],[130,131,132,88,133,134,135,136,120,137,138,139,140,116,141,142],"edit diagram","edit","diagram","whiteboard","canvas","create","offline","tldraw offline","archive","tldr","user","tldraw","with",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":153,"publishedAt":38},"01M6PQ9JKMF9ZDQWNVSA38VCTT","create-html-app","Create or update a Hubble HTML App: a folder-local .html file Hubble runs as a self-contained interactive UI, with Alpine, Tailwind, Hubble theme tokens, and the injected hubble runtime API.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcreate-html-app\u002FSKILL.md",[149,150],{"categoryNo":112,"categoryName":113,"taxonomyType":78,"taxonomyTypeDesc":79},{"categoryNo":151,"categoryName":152,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000010","后端与接口",[154,116,115,135,155,156,157,158,159,160,161,162,163,164,120,165,85,166,142,167],"create html app","ui","theme tokens","runtime","tokens","local","self","interactive","Tailwind","api","alpine","update","theme","folder",{"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":174,"publishedAt":38},"01M6CPAR6ECFN9P9H1S4XWDCB1","convex","Routes general Convex requests to the right project skill. Use when the user asks which Convex skill to use or gives an underspecified Convex app task.","https:\u002F\u002Fgithub.com\u002Fbholmesdev\u002Fhubble.md\u002Fblob\u002Fmain\u002Fpackages\u002Fsync-backend\u002F.agents\u002Fskills\u002Fconvex\u002FSKILL.md",[],[170,175,176,177,88,140],"task","general","project skill"]