{"owner":"different-ai","repo":"openwork","hasSkills":true,"totalSkillsCount":4,"totalTokensCount":1959,"categories":["root-instruction","mcp-config","marketplace","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"openwork":{"command":"npx","args":["-y","@modelcontextprotocol/server-openwork"]}}},"found":["AGENTS.md",".cursor/mcp.json",".claude-plugin/marketplace.json",".claude-plugin/plugin.json"],"skills":{"AGENTS.md":"# AGENTS.md\n\nOpenWork helps users run agents, skills, and MCP. It is an open-source alternative to Claude Cowork/Codex as a desktop app.\n\n## What OpenWork Is\n\nOpenWork is a practical control surface for agentic work:\n\n* Run local and remote agent workflows from one place.\n* Use OpenCode capabilities directly through OpenWork.\n* Compose desktop app, server, and messaging connectors without lock-in.\n* Treat the OpenWork app as a client of the OpenWork server API surface.\n* Connect to hosted workers through a simple user flow: `Add a worker` -> `Connect remote`.\n\n## Core Philosophy\n\n* **Local-first, cloud-ready**: OpenWork runs on your machine in one click and can connect to cloud workflows when needed.\n* **Server-consumption first**: the app should consume OpenWork server surfaces (self-hosted or hosted), not invent parallel behavior.\n* **Composable**: use the desktop app, WhatsApp/Slack/Telegram connectors, or server mode based on the task.\n* **Ejectable**: OpenWork is powered by OpenCode, so anything OpenCode can do is available in OpenWork, even before a dedicated UI exists.\n* **Sharing is caring**: start solo, then share quickly; one CLI or desktop command can spin up an instantly shareable instance.\n\n\n## Pull Request Expectations (Fast Merge)\n\nIf you open a PR, you must run tests and report what you ran (commands + result).\n\nTo maximize merge speed, include evidence of the end-to-end flow:\n\n* Ideally: attach a short video/screen recording showing the flow running successfully.\n* Otherwise: screenshots are acceptable, but video is preferred.\n\nIf you cannot run tests or capture the video, say so explicitly and explain why, and include the exact commands/steps for the reviewer to reproduce.\n\n## Validate Every Experience\n\nAlmost everything we change has an effect on the outside world — the\nfilesystem, the runtime DB, server API responses, provisioning, sessions,\nor config. So the default is not \"write code and hope\"; it is **propose a\nflow, then drive it as the end user and validate it against reality until\nit actually holds.**\n\nA change is an *experience*: it might be a persistent feature, a single new\nbutton, or an entirely new screen. Every experience gets validated the same\nway — by producing **fraimz**, the frame-by-frame proof\n(`evals/results/<run-id>/fraimz.html`) where each frame binds a claim, the user\naction, an observable assertion, and a validated screenshot.\n\nThe deliverable and the full loop (frame → coded flow → drive the real app via\nCDP → validate/repair → verdict) live in the **`fraimz` skill** — load it\nwhenever a task asks you to \"create a fraimz\" / \"prove it works\", or whenever a\nchange touches anything observable outside the process. Run it via the\n`/fraimz` command or `pnpm fraimz --flow <id>`.\n\nReport `Passed` only when `fraimz.html` exists and every claim is backed by an\nobservable assertion; otherwise `Incomplete` / `Failed`, stated honestly with\nrepro steps. Pure docs/comments and types-only changes with no runtime path may\nskip — but say so explicitly. For changes you expect to be inert, the `fraimz`\nskill's canonical core flow proves the core experience is unchanged.\n\n## Demo-Driven Development (the paved path)\n\nFeature work starts with the demo, not a PRD:\n\n1. `/voiceover <feature>` — align on the demo script; **no code until it is approved** (`voiceover` skill).\n2. Build on a fresh worktree/branch (`git worktree add ...`), never on the user's checkout.\n3. Prove it with fraimz until every frame holds (`fraimz` skill).\n4. Open a PR against `dev` and post the proof on it: `pnpm fraimz --flow <id> --pr`.\n\n## Coding Guidelines\n\n### TypeScript\n\n- Never use `any`, typecasts, or `as`, unless 100% necessary or specifically instructed.\n\n### Package Managers\n\n- Use pnpm.\n- Never use npm or yarn.\n\n### UI and UX\n\n- Use components from @/components when possible.\n- When creating new components, we prefer using shadcn/ui with (Base UI).\n- Assume most end users of OpenWork are non-technical.\n\n### Tech Stack Preferences\n\nWhen uncertain, prefer: Tailwind, TypeScript, React, shadcn/ui (Base UI), TanStack Query, Zustand, Zod, Drizzle, Better-Auth.\n\n### Code Style\n\n- Always strive for concise, simple solutions.\n- If a problem can be solved in a simpler way, propose it.\n- Use the smallest possible diff to make a change. Then think of how to make it smaller and do that again.\n- Avoid fallback expressions when types or control flow already guarantee a value.\n\n### Workflow\n\n- If asked to do too much work at once, stop and state that clearly.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/plugin.json)"},"files":{"AGENTS.md":"# AGENTS.md\n\nOpenWork helps users run agents, skills, and MCP. It is an open-source alternative to Claude Cowork/Codex as a desktop app.\n\n## What OpenWork Is\n\nOpenWork is a practical control surface for agentic work:\n\n* Run local and remote agent workflows from one place.\n* Use OpenCode capabilities directly through OpenWork.\n* Compose desktop app, server, and messaging connectors without lock-in.\n* Treat the OpenWork app as a client of the OpenWork server API surface.\n* Connect to hosted workers through a simple user flow: `Add a worker` -> `Connect remote`.\n\n## Core Philosophy\n\n* **Local-first, cloud-ready**: OpenWork runs on your machine in one click and can connect to cloud workflows when needed.\n* **Server-consumption first**: the app should consume OpenWork server surfaces (self-hosted or hosted), not invent parallel behavior.\n* **Composable**: use the desktop app, WhatsApp/Slack/Telegram connectors, or server mode based on the task.\n* **Ejectable**: OpenWork is powered by OpenCode, so anything OpenCode can do is available in OpenWork, even before a dedicated UI exists.\n* **Sharing is caring**: start solo, then share quickly; one CLI or desktop command can spin up an instantly shareable instance.\n\n\n## Pull Request Expectations (Fast Merge)\n\nIf you open a PR, you must run tests and report what you ran (commands + result).\n\nTo maximize merge speed, include evidence of the end-to-end flow:\n\n* Ideally: attach a short video/screen recording showing the flow running successfully.\n* Otherwise: screenshots are acceptable, but video is preferred.\n\nIf you cannot run tests or capture the video, say so explicitly and explain why, and include the exact commands/steps for the reviewer to reproduce.\n\n## Validate Every Experience\n\nAlmost everything we change has an effect on the outside world — the\nfilesystem, the runtime DB, server API responses, provisioning, sessions,\nor config. So the default is not \"write code and hope\"; it is **propose a\nflow, then drive it as the end user and validate it against reality until\nit actually holds.**\n\nA change is an *experience*: it might be a persistent feature, a single new\nbutton, or an entirely new screen. Every experience gets validated the same\nway — by producing **fraimz**, the frame-by-frame proof\n(`evals/results/<run-id>/fraimz.html`) where each frame binds a claim, the user\naction, an observable assertion, and a validated screenshot.\n\nThe deliverable and the full loop (frame → coded flow → drive the real app via\nCDP → validate/repair → verdict) live in the **`fraimz` skill** — load it\nwhenever a task asks you to \"create a fraimz\" / \"prove it works\", or whenever a\nchange touches anything observable outside the process. Run it via the\n`/fraimz` command or `pnpm fraimz --flow <id>`.\n\nReport `Passed` only when `fraimz.html` exists and every claim is backed by an\nobservable assertion; otherwise `Incomplete` / `Failed`, stated honestly with\nrepro steps. Pure docs/comments and types-only changes with no runtime path may\nskip — but say so explicitly. For changes you expect to be inert, the `fraimz`\nskill's canonical core flow proves the core experience is unchanged.\n\n## Demo-Driven Development (the paved path)\n\nFeature work starts with the demo, not a PRD:\n\n1. `/voiceover <feature>` — align on the demo script; **no code until it is approved** (`voiceover` skill).\n2. Build on a fresh worktree/branch (`git worktree add ...`), never on the user's checkout.\n3. Prove it with fraimz until every frame holds (`fraimz` skill).\n4. Open a PR against `dev` and post the proof on it: `pnpm fraimz --flow <id> --pr`.\n\n## Coding Guidelines\n\n### TypeScript\n\n- Never use `any`, typecasts, or `as`, unless 100% necessary or specifically instructed.\n\n### Package Managers\n\n- Use pnpm.\n- Never use npm or yarn.\n\n### UI and UX\n\n- Use components from @/components when possible.\n- When creating new components, we prefer using shadcn/ui with (Base UI).\n- Assume most end users of OpenWork are non-technical.\n\n### Tech Stack Preferences\n\nWhen uncertain, prefer: Tailwind, TypeScript, React, shadcn/ui (Base UI), TanStack Query, Zustand, Zod, Drizzle, Better-Auth.\n\n### Code Style\n\n- Always strive for concise, simple solutions.\n- If a problem can be solved in a simpler way, propose it.\n- Use the smallest possible diff to make a change. Then think of how to make it smaller and do that again.\n- Avoid fallback expressions when types or control flow already guarantee a value.\n\n### Workflow\n\n- If asked to do too much work at once, stop and state that clearly.\n",".cursor/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.cursor/mcp.json)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/marketplace.json)",".claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/plugin.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/different-ai/openwork/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nOpenWork helps users run agents, skills, and MCP. It is an open-source alternative to Claude Cowork/Codex as a desktop app.\n\n## What OpenWork Is\n\nOpenWork is a practical control surface for agentic work:\n\n* Run local and remote agent workflows from one place.\n* Use OpenCode capabilities directly through OpenWork.\n* Compose desktop app, server, and messaging connectors without lock-in.\n* Treat the OpenWork app as a client of the OpenWork server API surface.\n* Connect to hosted workers through a simple user flow: `Add a worker` -> `Connect remote`.\n\n## Core Philosophy\n\n* **Local-first, cloud-ready**: OpenWork runs on your machine in one click and can connect to cloud workflows when needed.\n* **Server-consumption first**: the app should consume OpenWork server surfaces (self-hosted or hosted), not invent parallel behavior.\n* **Composable**: use the desktop app, WhatsApp/Slack/Telegram connectors, or server mode based on the task.\n* **Ejectable**: OpenWork is powered by OpenCode, so anything OpenCode can do is available in OpenWork, even before a dedicated UI exists.\n* **Sharing is caring**: start solo, then share quickly; one CLI or desktop command can spin up an instantly shareable instance.\n\n\n## Pull Request Expectations (Fast Merge)\n\nIf you open a PR, you must run tests and report what you ran (commands + result).\n\nTo maximize merge speed, include evidence of the end-to-end flow:\n\n* Ideally: attach a short video/screen recording showing the flow running successfully.\n* Otherwise: screenshots are acceptable, but video is preferred.\n\nIf you cannot run tests or capture the video, say so explicitly and explain why, and include the exact commands/steps for the reviewer to reproduce.\n\n## Validate Every Experience\n\nAlmost everything we change has an effect on the outside world — the\nfilesystem, the runtime DB, server API responses, provisioning, sessions,\nor config. So the default is not \"write code and hope\"; it is **propose a\nflow, then drive it as the end user and validate it against reality until\nit actually holds.**\n\nA change is an *experience*: it might be a persistent feature, a single new\nbutton, or an entirely new screen. Every experience gets validated the same\nway — by producing **fraimz**, the frame-by-frame proof\n(`evals/results/<run-id>/fraimz.html`) where each frame binds a claim, the user\naction, an observable assertion, and a validated screenshot.\n\nThe deliverable and the full loop (frame → coded flow → drive the real app via\nCDP → validate/repair → verdict) live in the **`fraimz` skill** — load it\nwhenever a task asks you to \"create a fraimz\" / \"prove it works\", or whenever a\nchange touches anything observable outside the process. Run it via the\n`/fraimz` command or `pnpm fraimz --flow <id>`.\n\nReport `Passed` only when `fraimz.html` exists and every claim is backed by an\nobservable assertion; otherwise `Incomplete` / `Failed`, stated honestly with\nrepro steps. Pure docs/comments and types-only changes with no runtime path may\nskip — but say so explicitly. For changes you expect to be inert, the `fraimz`\nskill's canonical core flow proves the core experience is unchanged.\n\n## Demo-Driven Development (the paved path)\n\nFeature work starts with the demo, not a PRD:\n\n1. `/voiceover <feature>` — align on the demo script; **no code until it is approved** (`voiceover` skill).\n2. Build on a fresh worktree/branch (`git worktree add ...`), never on the user's checkout.\n3. Prove it with fraimz until every frame holds (`fraimz` skill).\n4. Open a PR against `dev` and post the proof on it: `pnpm fraimz --flow <id> --pr`.\n\n## Coding Guidelines\n\n### TypeScript\n\n- Never use `any`, typecasts, or `as`, unless 100% necessary or specifically instructed.\n\n### Package Managers\n\n- Use pnpm.\n- Never use npm or yarn.\n\n### UI and UX\n\n- Use components from @/components when possible.\n- When creating new components, we prefer using shadcn/ui with (Base UI).\n- Assume most end users of OpenWork are non-technical.\n\n### Tech Stack Preferences\n\nWhen uncertain, prefer: Tailwind, TypeScript, React, shadcn/ui (Base UI), TanStack Query, Zustand, Zod, Drizzle, Better-Auth.\n\n### Code Style\n\n- Always strive for concise, simple solutions.\n- If a problem can be solved in a simpler way, propose it.\n- Use the smallest possible diff to make a change. Then think of how to make it smaller and do that again.\n- Avoid fallback expressions when types or control flow already guarantee a value.\n\n### Workflow\n\n- If asked to do too much work at once, stop and state that clearly.\n","isInternal":false,"tokens":1059,"sizeBytes":4549},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":200},{"name":"plugin.json","path":".claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":186},{"name":"mcp.json","path":".cursor/mcp.json","rawUrl":"https://raw.githubusercontent.com/different-ai/openwork/HEAD/.cursor/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.cursor/mcp.json)","tokens":300,"sizeBytes":179}],"systemPromptSnippet":"<yakaai_skills repo=\"different-ai/openwork\">\n<!-- File: AGENTS.md (Tokens: ~1059 | Category: root-instruction) -->\n# AGENTS.md\n\nOpenWork helps users run agents, skills, and MCP. It is an open-source alternative to Claude Cowork/Codex as a desktop app.\n\n## What OpenWork Is\n\nOpenWork is a practical control surface for agentic work:\n\n* Run local and remote agent workflows from one place.\n* Use OpenCode capabilities directly through OpenWork.\n* Compose desktop app, server, and messaging connectors without lock-in.\n* Treat the OpenWork app as a client of the OpenWork server API surface.\n* Connect to hosted workers through a simple user flow: `Add a worker` -> `Connect remote`.\n\n## Core Philosophy\n\n* **Local-first, cloud-ready**: OpenWork runs on your machine in one click and can connect to cloud workflows when needed.\n* **Server-consumption first**: the app should consume OpenWork server surfaces (self-hosted or hosted), not invent parallel behavior.\n* **Composable**: use the desktop app, WhatsApp/Slack/Telegram connectors, or server mode based on the task.\n* **Ejectable**: OpenWork is powered by OpenCode, so anything OpenCode can do is available in OpenWork, even before a dedicated UI exists.\n* **Sharing is caring**: start solo, then share quickly; one CLI or desktop command can spin up an instantly shareable instance.\n\n\n## Pull Request Expectations (Fast Merge)\n\nIf you open a PR, you must run tests and report what you ran (commands + result).\n\nTo maximize merge speed, include evidence of the end-to-end flow:\n\n* Ideally: attach a short video/screen recording showing the flow running successfully.\n* Otherwise: screenshots are acceptable, but video is preferred.\n\nIf you cannot run tests or capture the video, say so explicitly and explain why, and include the exact commands/steps for the reviewer to reproduce.\n\n## Validate Every Experience\n\nAlmost everything we change has an effect on the outside world — the\nfilesystem, the runtime DB, server API responses, provisioning, sessions,\nor config. So the default is not \"write code and hope\"; it is **propose a\nflow, then drive it as the end user and validate it against reality until\nit actually holds.**\n\nA change is an *experience*: it might be a persistent feature, a single new\nbutton, or an entirely new screen. Every experience gets validated the same\nway — by producing **fraimz**, the frame-by-frame proof\n(`evals/results/<run-id>/fraimz.html`) where each frame binds a claim, the user\naction, an observable assertion, and a validated screenshot.\n\nThe deliverable and the full loop (frame → coded flow → drive the real app via\nCDP → validate/repair → verdict) live in the **`fraimz` skill** — load it\nwhenever a task asks you to \"create a fraimz\" / \"prove it works\", or whenever a\nchange touches anything observable outside the process. Run it via the\n`/fraimz` command or `pnpm fraimz --flow <id>`.\n\nReport `Passed` only when `fraimz.html` exists and every claim is backed by an\nobservable assertion; otherwise `Incomplete` / `Failed`, stated honestly with\nrepro steps. Pure docs/comments and types-only changes with no runtime path may\nskip — but say so explicitly. For changes you expect to be inert, the `fraimz`\nskill's canonical core flow proves the core experience is unchanged.\n\n## Demo-Driven Development (the paved path)\n\nFeature work starts with the demo, not a PRD:\n\n1. `/voiceover <feature>` — align on the demo script; **no code until it is approved** (`voiceover` skill).\n2. Build on a fresh worktree/branch (`git worktree add ...`), never on the user's checkout.\n3. Prove it with fraimz until every frame holds (`fraimz` skill).\n4. Open a PR against `dev` and post the proof on it: `pnpm fraimz --flow <id> --pr`.\n\n## Coding Guidelines\n\n### TypeScript\n\n- Never use `any`, typecasts, or `as`, unless 100% necessary or specifically instructed.\n\n### Package Managers\n\n- Use pnpm.\n- Never use npm or yarn.\n\n### UI and UX\n\n- Use components from @/components when possible.\n- When creating new components, we prefer using shadcn/ui with (Base UI).\n- Assume most end users of OpenWork are non-technical.\n\n### Tech Stack Preferences\n\nWhen uncertain, prefer: Tailwind, TypeScript, React, shadcn/ui (Base UI), TanStack Query, Zustand, Zod, Drizzle, Better-Auth.\n\n### Code Style\n\n- Always strive for concise, simple solutions.\n- If a problem can be solved in a simpler way, propose it.\n- Use the smallest possible diff to make a change. Then think of how to make it smaller and do that again.\n- Avoid fallback expressions when types or control flow already guarantee a value.\n\n### Workflow\n\n- If asked to do too much work at once, stop and state that clearly.\n\n<!-- File: .claude-plugin/marketplace.json (Tokens: ~300 | Category: marketplace) -->\n# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/marketplace.json)\n\n<!-- File: .claude-plugin/plugin.json (Tokens: ~300 | Category: plugin-manifest) -->\n# claude-plugin Plugin Manifest\n\nPath: `.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.claude-plugin/plugin.json)\n\n<!-- File: .cursor/mcp.json (Tokens: ~300 | Category: mcp-config) -->\n# Model Context Protocol (MCP) Configuration\n\nPath: `.cursor/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/different-ai/openwork/HEAD/.cursor/mcp.json)\n</yakaai_skills>"}