New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Implementation

by warpdotdev-demos in warpdotdev-demos/cloud-factory-demo

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, verifying…

MITAuto-check passedProductivity & Automation

Install Implementation

skills CLI
$ npx skills add warpdotdev-demos/cloud-factory-demo --skill implementation -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install warpdotdev-demos/cloud-factory-demo implementation --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/warpdotdev-demos/cloud-factory-demo.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/implementation .claude/skills/implementation && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
implementation
GitHub stars
325
Token cost
~3.8k tokens
SKILL.md length
2,083 words
Files
1
Skills in repo
7
Repo updated
First seen
Licence
MIT

At a glance

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, verifying…

  • Works in 11 steps: Identify the issue and repository → Verify optional helper skills → Post an implementation-started status… → …
  • Tasks that involve Desktop control
  • SKILL.md covers Workflow and Guardrails
  • Calls gh; reaches oz.warp.dev and oz.staging.warp.dev

What it does

Implementation is an agent skill from warpdotdev-demos/cloud-factory-demo. 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, verifying visible UI behavior with the verify-behavior computer-use skill when applicable, opening a GitHub pull request, and reporting progress back to the original issue.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Productivity & Automation, covering Desktop control and Issue triage. It works with GitHub and Jira. The licence is MIT.

When your agent uses it

  • Tasks that involve Desktop control
  • Tasks that involve Issue triage

Example prompts

  • “/implementation”

Workflow steps

11 steps, taken from the step headings in SKILL.md.

  1. Identify the issue and repository
  2. Verify optional helper skills
  3. Post an implementation-started status comment
  4. Fetch tracker context
  5. Locate and read specs first
  6. Inspect the current codebase
  7. Implement the change
  8. Validate the implementation
  9. Verify visible behavior with verify-behavior
  10. Create a branch and pull request
  11. Post the PR link and final status to the issue

What it can do on your machine

Read from SKILL.md and the folder at commit ab21d0c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • oz.warp.dev
    • oz.staging.warp.dev

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Implementation loads about 3.8k tokens when it runs. Until then it costs about 93 tokens; SKILL.md has 2,083 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~93
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from warpdotdev-demos/cloud-factory-demo at commit ab21d0c, republished under its MIT licence (© warpdotdev-demos). 2,083 words, ~3,758 tokens.

Download SKILL.mdSave it as .claude/skills/implementation/SKILL.md (or your agent's skills folder).
name
implementation
description
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, verifying visible UI behavior with the verify-behavior computer-use skill when applicable, opening a GitHub pull request, and reporting progress back to the original issue.

Implementation

Implement the issue passed in the user's prompt and open a GitHub pull request with the fix or feature.

Expect 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.

Workflow

1. Identify the issue and repository

Extract the issue URL, key, or number from the prompt. Determine whether it belongs to GitHub Issues, Jira, Linear, or another tracker.

Confirm 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.

2. Verify optional helper skills

If the checkout contains .agents/skills/validate-changes-match-specs/SKILL.md, use it after implementation whenever PRODUCT.md and TECH.md specs exist for the issue.

If specs exist but the validation skill is missing, continue only if you can still manually compare the implementation against the specs. Report that the common validation skill was unavailable in the PR description and issue comment.

If the checkout contains .agents/skills/verify-behavior/SKILL.md and the issue has visible UI, browser, desktop, mobile, or other interactive behavior, you must run that skill before claiming the implementation is complete. It delegates to Oz's dedicated computer_use capability on this computer-use-enabled run — do not drive the GUI yourself and do not substitute generic remote children. Do not skip verification because PR creation failed or because automated unit tests passed.

3. Post an implementation-started status comment

For GitHub Issues, post a short status comment before doing implementation work so issue subscribers know an agent has started.

Use the authenticated gh CLI when available. Include:

  • That automated Oz implementation has started.
  • The issue identifier being implemented.
  • A follow-along link to the Oz run (see Oz run URLs below).

Keep this comment concise.

Oz run URLs

When posting any follow-along, evidence, or status link to an Oz cloud run, use the Oz web app URL — never invent links from the API host.

Correct format:

text
https://oz.warp.dev/runs/<run-id>

On staging / WarpDev, use:

text
https://oz.staging.warp.dev/runs/<run-id>

Rules:

  • Path is /runs/ (plural), never /run/.
  • Host is oz.warp.dev (or oz.staging.warp.dev), never app.warp.dev or app.staging.warp.dev.
  • Prefer a full run URL already provided by the runtime, action output, dispatcher, or logs. If you only have a run id, build the URL with the format above.
  • If you see https://app.warp.dev/run/<id> or https://app.warp.dev/runs/<id>, rewrite it to https://oz.warp.dev/runs/<id> before posting.
  • Do not use a GitHub Actions workflow run URL as the Oz follow-along link.
  • If no Oz run id or link is available yet, say the Oz follow-along link is not available yet rather than substituting another URL, and continue implementation.
4. Fetch tracker context

Use the best available integration in this order:

  1. A relevant MCP server or native tracker tool
  2. The tracker's authenticated CLI, such as gh
  3. The tracker's API or web page

Fetch:

  • Full issue title and description
  • Comments and discussion
  • Links to spec pull requests or checked-in PRODUCT.md and TECH.md files
  • Existing labels, status, assignee, project, and linked issues
  • Attachments, screenshots, logs, reproduction steps, and acceptance criteria
  • Related open issues, likely duplicates, dependencies, and nearby product work

Do not implement solely from the issue title. Do not expose credentials or secrets while fetching tracker data.

If tracker context is missing critical implementation details, post a concise blocker comment with the specific missing information and stop instead of guessing.

5. Locate and read specs first

Before inspecting implementation areas, search for specs related to the issue.

Look for:

  • Links to spec pull requests in the issue description or comments
  • Checked-in files under specs/<issue-slug>/PRODUCT.md and specs/<issue-slug>/TECH.md
  • Nearby PRODUCT.md and TECH.md files whose path or contents reference the issue

If both PRODUCT.md and TECH.md exist:

  • Read both specs completely before making code changes.
  • Treat the specs as the primary source of product behavior, acceptance criteria, technical direction, non-goals, and validation requirements.
  • Check newer issue comments for corrections or decisions that supersede the specs.
  • If the specs conflict with the issue or with each other, stop and post a concise blocker comment instead of guessing.

If only one of PRODUCT.md or TECH.md exists, read the available spec and decide whether the missing spec is a blocker. For broad or risky work, stop and ask for the missing spec.

If no specs exist, continue from the issue context and codebase inspection.

6. Inspect the current codebase

Search and read the codebase to understand the affected feature, behavior, terminology, and likely implementation area.

Assess:

  • Whether the described behavior exists today
  • Whether the requested behavior is already captured in PRODUCT.md and TECH.md
  • Likely files, services, UI components, APIs, tests, and data flows involved
  • Existing patterns and abstractions to follow
  • Edge cases, migrations, platform differences, or compatibility risks
  • Validation commands used by the repository

Post a brief progress comment if this investigation reveals a materially useful implementation area, for example: "I found the relevant editor state flow in src/... 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.

7. Implement the change

Make the smallest cohesive change that satisfies the issue.

Follow 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.

If 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.

8. Validate the implementation

Run the most relevant validation commands for the repository. Prefer commands documented in README, package scripts, CI config, Makefiles, or existing workflow files.

At minimum, attempt:

  • Targeted tests for the changed behavior, if available
  • Linting or typechecking, if available
  • A build or equivalent compile check, if appropriate

If 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.

If PRODUCT.md and TECH.md specs exist for the issue, validate the completed implementation against them before opening the PR:

  1. Read .agents/skills/validate-changes-match-specs/SKILL.md.
  2. Follow that skill to compare the implementation diff against the relevant specs.
  3. Fix any material mismatch caused by your implementation.
  4. If a mismatch reflects stale or incorrect specs rather than implementation drift, report it clearly and do not claim full spec alignment.

Include the spec-alignment result in the PR description and final issue comment.

Show full SKILL.md (994 more words)Show less
9. Verify visible behavior with verify-behavior

Required when the change affects UI, browser, desktop, mobile, or other interactive behavior and .agents/skills/verify-behavior/SKILL.md is present. Issue text that mentions drag-and-drop, screenshots, video, computer use, browser use, or verify-behavior is always treated as interactive.

  1. Read that skill and follow its parent workflow in verify mode. This covers greenfield features and bug fixes alike.
  2. If PRODUCT.md exists for the issue, pass its path and treat it as the source of user stories and acceptance criteria verification must exercise.
  3. Confirm this Oz cloud run has computer use enabled (computer_use: true / --computer-use). Do not launch generic remote children as a substitute for the dedicated computer-use capability.
  4. For multi-story features, fan out bounded parallel computer_use delegations (one key independent story each), then aggregate results. Stay single-delegation when stories are sequential or credentials are scarce.
  5. Delegate each verification unit to the platform computer_use capability with a concrete task: branch/ref, setup, story/checks, and expected evidence (native Oz session video of the critical path + reported screenshots). Do not call request_computer_use, parent-level start_recording/stop_recording, or invent custom recorder plumbing — permission and recording are handled inside the computer-use subagent.
  6. Require a native Oz video artifact for meaningful UI flows, plus durable https://oz.warp.dev/runs/<id> links on the issue and PR. Screenshots are supplementary. Prefer platform PR artifact helpers (e.g. get_artifacts_for_pull_request_description) when available. Do not invent gh --attach uploads of Oz recordings.
  7. If verification fails because of your change, fix the implementation and re-run verification before opening the PR when practical.
  8. If verification is blocked (computer use not enabled, missing display/secrets, subagent reports recording failure), post an explicit verification-gap comment with the blocker. Quote recording failures from the subagent. Still do not claim behavioral verification passed.
  9. Do not skip this step because PR creation failed. Verification is independent of opening the PR.
  10. Do not claim the UI implementation is complete until verify-behavior has produced Oz video/screenshot artifacts (or an explicit blocker) and the write-up includes durable Oz links.

Skip this step only for non-visual changes, when the skill file is missing, or when the repository truly has no runnable UI. Do not claim end-to-end behavioral verification unless verify-behavior ran via computer_use or you captured equivalent platform computer-use evidence.

10. Create a branch and pull request

Create a descriptive branch for the implementation, such as fix/issue-123-short-title or feature/issue-123-short-title.

Commit only the intended changes. Use a clear commit message. When committing, include:

Co-Authored-By: Oz <oz-agent@warp.dev>

Push 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.

The PR description should include:

  • A direct link to the original issue
  • Links to PRODUCT.md and TECH.md, if used
  • Summary of the change
  • Validation commands run and their results
  • Spec-alignment validation results, if specs exist
  • Behavior verification results from verify-behavior when it ran, including status, durable Oz run link(s), native Oz video artifact references, and any reported screenshots (prefer platform PR artifact markdown when available)
  • Known limitations, follow-up work, or validation gaps

Associate the PR with the issue in GitHub:

  • If the implementation fully resolves the issue, include a closing keyword in the PR body, such as Closes #123 or Fixes #123.
  • If the implementation only partially addresses the issue, include a non-closing reference, such as Related to #123, and explain the remaining work.

After 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.

11. Post the PR link and final status to the issue

Only after opening the PR, post a final comment on the original issue with:

  • Link to the PR
  • Brief summary of what was implemented
  • Validation performed
  • Spec-alignment validation result, if specs exist
  • Behavior verification summary, durable Oz run links, and native video/screenshot artifact references, if verify-behavior ran
  • Any known limitations or reviewer notes

The 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.

If 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.

Guardrails

  • Do not implement without fetching tracker context and inspecting the codebase.
  • Do not expose secrets, tokens, private environment variables, raw logs containing credentials, or internal reasoning in issue comments or PR descriptions.
  • Do not close, assign, reprioritize, or relabel the issue unless explicitly requested.
  • Do not overwrite unrelated labels or metadata.
  • Do not make unrelated code changes.
  • Do not ignore PRODUCT.md or TECH.md when they exist for the issue.
  • Do not claim validation passed if it was not run or failed.
  • Do not claim spec alignment if validate-changes-match-specs was not run or an equivalent manual comparison was not performed.
  • Do not claim interactive behavior was verified unless verify-behavior delegated to the dedicated computer_use capability (or equivalent platform computer-use evidence was collected).
  • For interactive/UI issues, do not treat the implementation as complete until verify-behavior has been attempted (pass or explicit blocker), a native Oz video artifact exists for meaningful UI flows (or a quoted recording failure), and durable Oz run/artifact links are on the issue and PR write-ups.
  • Never instruct verification to use ffmpeg or any external screen recorder; never call request_computer_use or parent-level recording APIs; never invent gh --attach for Oz videos. Recording stays inside the computer-use subagent.
  • Do not post a final success comment unless a pull request has already been opened and the comment includes the PR URL. If PR creation is blocked, still report verification results on the issue.
  • 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.

© warpdotdev-demos, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/implementation of warpdotdev-demos/cloud-factory-demo.

Open the folder on GitHubat commit ab21d0c

Compare with similar skills

Implementation next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Implementation compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Implementation this skillwarpdotdev-demos/cloud-factory-demo325—~3.8kAutomated safety check: PassMIT
Connect Apps with ComposioComposioHQ/awesome-claude-skills77k3 repos~557Automated safety check: PassNone
Issue Triage Loopcobusgreyling/loop-engineering11k—~522Automated safety check: PassMIT
Triagebholmesdev/hubble.md1.5k—~1.5kAutomated safety check: PassMIT
Mfs Findzilliztech/mfs151—~4kAutomated safety check: PassApache-2.0
Implementationbholmesdev/hubble.md1.5k—~2kAutomated safety check: PassMIT

Similar skills

  • Connect Apps with Composio

    ComposioHQ/awesome-claude-skills

    Connects an agent to 1000+ external apps through the Composio Tool Router plugin, so it can actually send emails, create issues and post messages instead of only drafting them.

    77k GitHub starsUsed in 3 repos~557 tokens
    Productivity & AutomationAuto-check passed

  • Issue Triage Loop

    cobusgreyling/loop-engineering

    Scans open GitHub issues and discussions, flags duplicates, scores priority and proposes labels into issue-triage-state.md without ever labeling or closing.

    11k GitHub stars~522 tokensUpdated today
    DevelopmentAuto-check passed

  • Triage

    bholmesdev/hubble.md

    Triage an incoming GitHub, Jira, Linear, or other issue-tracker issue against the current codebase and related issues, then return a structured decision with exactly one triage state.

    1.5k GitHub stars~1.5k tokensUpdated 6 days ago
    DevelopmentAuto-check passed

  • Mfs Find

    zilliztech/mfs

    Search, grep, browse, and read across registered MFS data sources via the mfs CLI — codebases, docs, PDFs, web crawls, databases (postgres/mysql/mongo/snowflake/bigquery), issue trackers…

    151 GitHub stars~4k tokensUpdated 2 mo ago
    DatabasesAuto-check passed

  • Implementation

    bholmesdev/hubble.md

    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…

    1.5k GitHub stars~2k tokensUpdated 6 days ago
    DevelopmentAuto-check passed

  • Triage Finding

    vlinx-io/VelaTerm

    A skill your agent uses when the user supplies or imports existing security findings, vulnerability reports, or security/vulnerability Jira/Linear tickets from scanners, advisories, GitHub…

    270 GitHub stars~6.9k tokensUpdated yesterday
    DevelopmentAuto-check passed

More from warpdotdev-demos/cloud-factory-demo

  • Improve Review PR

    warpdotdev-demos/cloud-factory-demo

    Daily outer loop that reviews human reactions to automated review-pr comments, synthesizes durable organizational knowledge, and opens a PR to update the review-pr skill when the feedback is worth…

    325 GitHub stars~1.7k tokensUpdated 1 mo ago
    Auto-check passed

  • Review PR

    warpdotdev-demos/cloud-factory-demo

    Review a PR from local annotated-diff artifacts and write validated review.json for the workflow to publish.

    325 GitHub stars~1.5k tokensUpdated 1 mo ago
    Auto-check passed

  • Triage

    warpdotdev-demos/cloud-factory-demo

    Triage an incoming GitHub, Jira, Linear, or other issue-tracker issue against the current codebase and related open issues, then return a structured decision with exactly one…

    325 GitHub stars~2.2k tokensUpdated 1 mo ago
    Auto-check passed

  • Verify Behavior

    warpdotdev-demos/cloud-factory-demo

    Verify or reproduce visible product behavior by delegating to Oz's dedicated computer-use capability, requiring a native Oz video artifact for meaningful UI flows and durable Oz run/artifact links.

    325 GitHub stars~2.2k tokensUpdated 1 mo ago
    Auto-check passed

  • Oz Cloud Factory Demo

    warpdotdev-demos/cloud-factory-demo

    Sets up a beginner-friendly Oz cloud software factory that automatically triages new GitHub issues, specs issues labeled ready-to-spec, implements issues labeled ready-to-implement, reviews PRs, and…

    325 GitHub stars~6.8k tokensUpdated 1 mo ago
    Auto-check passed

  • Spec

    warpdotdev-demos/cloud-factory-demo

    Coordinate spec-driven development for a GitHub, Jira, Linear, or other issue-tracker issue marked ready-to-spec by using write-product-spec and write-tech-spec, creating PRODUCT.md and TECH.md…

    325 GitHub stars~2.1k tokensUpdated 1 mo ago
    Auto-check passed

Works with

Categories

Questions about Implementation

What does Implementation do?

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, verifying…. Implementation is an agent skill from warpdotdev-demos/cloud-factory-demo. 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, verifying visible UI behavior with the verify-behavior computer-use skill when applicable, opening a GitHub pull request, and reporting progress back to the original issue.

When should I use Implementation?

Implementation fits situations like: tasks that involve Desktop control; tasks that involve Issue triage.

How do I install Implementation in Claude Code?

Run `npx skills add warpdotdev-demos/cloud-factory-demo --skill implementation -a claude-code`. Or copy the skill folder (.agents/skills/implementation in warpdotdev-demos/cloud-factory-demo) into .claude/skills/implementation in your project. Claude Code loads it when a task matches its description.

How do I install Implementation in Codex?

Run `npx skills add warpdotdev-demos/cloud-factory-demo --skill implementation -a codex`. Or copy the skill folder (.agents/skills/implementation in warpdotdev-demos/cloud-factory-demo) into .agents/skills/implementation in your project. Codex loads it when a task matches its description.

Can I use Implementation in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add warpdotdev-demos/cloud-factory-demo --skill implementation -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/implementation, .gemini/skills/implementation, .github/skills/implementation and .opencode/skills/implementation in your project.

What does Implementation need to run?

Going by SKILL.md and its folder, Implementation needs the command-line tools its instructions call (gh).

Does Implementation access the network?

SKILL.md names 2 domains. In commands or code: oz.warp.dev and oz.staging.warp.dev; the agent is likely to contact these when it follows the instructions. This is read from the text; nothing was executed.

Is Implementation safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Implementation use?

Implementation is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Implementation use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Implementation?

Skills that share tags, products or a category with Implementation: Connect Apps with Composio (ComposioHQ/awesome-claude-skills, 77k stars), Issue Triage Loop (cobusgreyling/loop-engineering, 11k stars), Triage (bholmesdev/hubble.md, 1.5k stars) and Mfs Find (zilliztech/mfs, 151 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Implementation?

warpdotdev-demos (a GitHub organization) maintains it in warpdotdev-demos/cloud-factory-demo, which has 325 GitHub stars. The repository holds 7 skills in this directory. The repository was last updated on August 12, 2026.

Source: warpdotdev-demos/cloud-factory-demo on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.