Files
Crazywoola f06cf8d7ca docs: revamp develop-plugin section (#784)
* docs: revamp develop-plugin section

Fixes critical content bugs that broke setup paths (wrong Linux binary
name, conflicting `REMOTE_INSTALL_URL` env var, full duplicate of
release-overview where GitHub-publishing steps should be, broken Flomo
provider YAML, depot-only `runs-on` in the auto-publish workflow,
unverified imports in reverse-invocation examples, wrong
`TextEmbeddingModelConfig` type) and restructures the section around the
developer's mental model.

Sidebar reorg: Publishing now reads release-overview -> Standards ->
Marketplace (with auto-publish nested) -> GitHub Repository -> Local
File -> FAQ. A new choose-plugin-type decision page sits between the
landing page and the CLI in Getting Started.

Major rewrites: release-to-individual-github-repo (full),
remote-debug-a-plugin (50 -> 160 lines with troubleshooting),
multilingual-readme (added template), faq (2 -> 10 entries), Flomo
walkthrough YAML to canonical credentials_for_provider shape. Quick
Decision callouts on model-schema and model-designing-rules. Backfilled
missing frontmatter `description` on 7 pre-existing pages for
CLAUDE.md compliance.

All edits in en/ only; translation pipeline handles zh/ja.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: fix TOC, tighten Standards, move signature verification

TOC: promote leading h3 -> h2 (and h4 -> h3) on 17 pages whose
right-rail TOC had no top-level entries because every section started
at h3. Hierarchy is preserved; subsections that were h4 now sit
correctly as h3 under their parent h2.

Standards section: rewrite contributor-covenant-code-of-conduct
(now properly titled "Plugin Development Guidelines") and
privacy-protection-guidelines for tighter prose, scannable lists, and
correct heading levels. The privacy page used h4 manual numbering
which broke its TOC entirely; now uses h2/h3 with an Accordion FAQ.

Reclassify third-party-signature-verification: it is a Community
Edition install-time feature, not a Marketplace standard. Moved from
Publishing > Standards to Publishing > Local File (alongside the
release-by-file `.difypkg` flow).

Also strip a stray `# Endpoint` h1 from endpoint.mdx (the title is
already in frontmatter) and replace a self-referencing link.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: subgroup walkthroughs, shorten titles, widget-ize publishing

Walkthroughs sidebar: split the 12-page flat list into Cheatsheet +
'By Plugin Type' subgroup (tool/oauth/model/agent-strategy/datasource/
trigger/endpoint) + 'Full Walkthroughs' subgroup (flomo/slack-bot/
md-exporter/multimodal). Shortened the worst sidebar offenders:

- 'Build Tool Plugins for Multimodal Data Processing in Knowledge
  Pipelines' -> 'Multimodal Tool'
- '10-Minute Guide to Building Dify Plugins' -> 'Flomo Tool (10-min)'
- 'Dify Plugin Development Cheatsheet' -> 'Cheatsheet'
- 'Develop A Slack Bot Plugin' -> 'Slack Bot'
- 'Build a Markdown Exporter Plugin' -> 'Markdown Exporter'
- 'Add OAuth Support to Your Tool Plugin' -> 'Tool OAuth'
- 'Neko Cat Endpoint' -> 'Endpoint Plugin'

Publishing pages: rewrite around Mintlify widgets and bake in the
actual reviewer process from the pr-review-helper skill:

- release-to-dify-marketplace.mdx: full rewrite with a Tabs-based
  pre-submission checklist, the exact 12-check reviewer table the
  automated workflow runs, a Steps submit flow, AccordionGroup FAQ,
  CardGroup related resources, and a PR-lifecycle table.
- release-overview.mdx: replace prose with a CardGroup chooser and a
  comparison table (audience / review / install path / versioning /
  best for).
- release-by-file.mdx: Steps for both packaging and installing,
  CardGroup for next-step distribution methods.
- third-party-signature-verification.mdx: scenario CardGroup,
  three-Step generate/sign/verify flow, three-Step daemon-enable flow.
- faq.mdx: add 'Why was my Marketplace PR rejected?' entry covering
  the most common automated-check failures from the skill.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* docs: add free Mintlify components (mermaid, check, icon)

- release-to-dify-marketplace.mdx: replace the static PNG submission
  flowchart with a Mermaid diagram (renders dark-mode-friendly,
  diff-friendly, no CDN dependency). Add Check callout confirming
  auto-publish on merge.
- tool-oauth.mdx: add a Mermaid sequence diagram contrasting the
  admin-side OAuth client setup with the per-user authorization flow,
  matching the existing "two separate flows" narrative.
- release-overview.mdx: add inline `<Icon>` to the comparison table
  header so each column reads as Marketplace/GitHub/Local at a glance.
- remote-debug-a-plugin.mdx, release-by-file.mdx,
  release-to-individual-github-repo.mdx: add `<Check>` confirmations
  after the verify-install step on each install path, so the reader
  knows what "success" looks like and when they can stop following.

Snippets deferred — the translation pipeline operates on en/zh/ja
trees, so a root-level `snippets/` directory needs coordination with
tools/translate before adoption.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* fix: address correctness gaps in develop-plugin pages

* docs: align plugin type catalog and tighten heading case

* style: drop em dashes and tidy formatting in develop-plugin docs

* fix: address Copilot follow-up comments on develop-plugin docs

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: RiskeyL <7a8y@163.com>
2026-05-21 21:41:19 +08:00

162 lines
5.5 KiB
Plaintext

---
dimensions:
type:
primary: conceptual
detail: architecture
level: beginner
standard_title: CLI
language: en
title: CLI
description: Install the Dify CLI, scaffold a new plugin project, and run it against a Dify instance for local development
---
Set up and package your Dify plugins using the Command Line Interface (CLI). The CLI provides a streamlined way to manage your plugin development workflow, from initialization to packaging.
This guide will instruct you on how to use the CLI for Dify plugin development.
## Prerequisites
Before you begin, ensure you have the following installed:
- Python version 3.12
- Dify CLI
- Homebrew (for Mac users)
## Create a Dify Plugin Project
<Tabs>
<Tab title="Mac">
```bash
brew tap langgenius/dify
brew install dify
```
</Tab>
<Tab title="Linux">
Download the latest binary from the [Dify Plugin Daemon releases page](https://github.com/langgenius/dify-plugin-daemon/releases). Pick `dify-plugin-linux-amd64` for x86_64 hosts or `dify-plugin-linux-arm64` for ARM hosts.
```bash
chmod +x dify-plugin-linux-amd64
sudo mv dify-plugin-linux-amd64 /usr/local/bin/dify
```
</Tab>
<Tab title="Windows">
Download `dify-plugin-windows-amd64.exe` (or `dify-plugin-windows-arm64.exe`) from the [Dify Plugin Daemon releases page](https://github.com/langgenius/dify-plugin-daemon/releases), rename it to `dify.exe`, and add its folder to your `PATH`.
</Tab>
</Tabs>
Now you have successfully installed the Dify CLI. You can verify the installation by running:
```bash
dify version
```
You can create a new Dify plugin project using the following command:
```bash
dify plugin init
```
Fill in the required fields when prompted:
```bash
Edit profile of the plugin
Plugin name (press Enter to next step): hello-world
Author (press Enter to next step): langgenius
Description (press Enter to next step): hello world example
Repository URL (Optional) (press Enter to next step): Repository URL (Optional)
Enable multilingual README: [✔] English is required by default
Languages to generate:
English: [✔] (required)
→ 简体中文 (Simplified Chinese): [✔]
日本語 (Japanese): [✘]
Português (Portuguese - Brazil): [✘]
Controls:
↑/↓ Navigate • Space/Tab Toggle selection • Enter Next step
```
Choose `python` and hit Enter to proceed with the Python plugin template.
```bash
Select the type of plugin you want to create, and press `Enter` to continue
Before starting, here's some basic knowledge about Plugin types in Dify:
- Tool: Tool Providers like Google Search, Stable Diffusion, etc. Used to perform specific tasks.
- Model: Model Providers like OpenAI, Anthropic, etc. Use their models to enhance AI capabilities.
- Endpoint: Similar to Service API in Dify and Ingress in Kubernetes. Extend HTTP services as endpoints with custom logic.
- Trigger: Webhook-based providers that turn third-party platform events into workflow start signals.
- Agent Strategy: Implement your own agent strategies like Function Calling, ReAct, ToT, CoT, etc.
Based on the ability you want to extend, Plugins are divided into six types: Tool, Model, Extension, Agent Strategy, Datasource, and Trigger.
- Tool: A tool provider that can also implement endpoints. For example, building a Discord Bot requires both sending and receiving messages.
- Model: Strictly for model providers, no other extensions allowed.
- Extension: For simple HTTP services that extend functionality.
- Agent Strategy: Implement custom agent logic with a focused approach.
- Datasource: Provide datasource for Dify Knowledge Pipeline.
- Trigger: Build webhook integrations that emit events to kick off workflows.
We've provided templates to help you get started. Choose one of the options below:
-> tool
agent-strategy
llm
text-embedding
rerank
tts
speech2text
moderation
extension
datasource
trigger
```
Enter the default dify version, leave it blank to use the latest version:
```bash
Edit minimal Dify version requirement, leave it blank by default
Minimal Dify version (press Enter to next step):
```
Now you are ready to go! The CLI will create a new directory with the plugin name you provided, and set up the basic structure for your plugin.
```bash
cd hello-world
```
## Run the Plugin
Make sure you are in the hello-world directory
```bash
cp .env.example .env
```
Edit the `.env` file to set your plugin's environment variables, such as API keys or other configurations. You can find these variables in the Dify dashboard. Log in to your Dify environment, click the “Plugins” icon in the top right corner, then click the debug icon (or something that looks like a bug). In the pop-up window, copy the “API Key” and “Host Address”. (Please refer to your local corresponding screenshot, which shows the interface for obtaining the key and host address)
```bash
INSTALL_METHOD=remote
REMOTE_INSTALL_URL=debug-plugin.dify.dev:5003
REMOTE_INSTALL_KEY=********-****-****-****-************
```
<Note>
`REMOTE_INSTALL_URL` combines host and port in `host:port` form. The host and port are shown together in the **API Key** card on the Plugins page.
</Note>
Now you can run your plugin locally using the following command:
```bash
pip install -r requirements.txt
python -m main
```
{/*
Contributing Section
DO NOT edit this section!
It will be automatically generated by the script.
*/}
---
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/develop-plugin/getting-started/cli.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)