docnify-automation
作成者 ComposioHQdocnify-automation は、ライブのツールスキーマ検出、Docnify 接続の確認、検証済みワークフローの実行を通じて、エージェントが Composio Rube MCP 経由で Docnify タスクを扱えるようにします。
このスキルの評価は64/100で、ディレクトリ掲載としては許容範囲ですが機能は限定的です。Rube MCP を通じて Docnify を利用するためのトリガー条件とセットアップ案内はエージェントに十分提供されていますが、ディレクトリ利用者は本格的な Docnify ワークフローパックではなく、軽量な連携ラッパーとして捉えるのがよいでしょう。
- 有効な frontmatter により、Rube MCP 経由の Docnify automation スキルであることと、必要な MCP 依存関係が明確に示されています。
- 前提条件とセットアップ手順では、RUBE_SEARCH_TOOLS の確認、Docnify 接続の管理、実行前の ACTIVE ステータス確認が案内されています。
- まずツールを検索して最新のスキーマを確認する方針が強調されており、スキーマのずれを減らし、利用可能な Docnify ツールをより安全に起動しやすくしています。
- 単一の SKILL.md 以外にサポートファイル、スクリプト、参考資料、README、インストールコマンドが用意されていないため、導入時の手がかりは少なめです。
- ワークフローは主に汎用的な Rube MCP の検出・接続パターンで構成されており、Docnify 固有のタスク手順や具体例は多くありません。
docnify-automation skill の概要
docnify-automation ができること
docnify-automation は、Composio の Rube MCP server 経由で Docnify のアクションを実行するための Claude skill です。価値の中心は、固定された Docnify 手順を提供することではありません。まず現在の Docnify tool schema を検出し、Docnify connection を確認したうえで、検証済みの入力を使って適切な Rube tool を実行する、という進め方をエージェントに徹底させる点にあります。
向いているユーザーと用途
docnify-automation skill は、すでに Docnify を使っていて、Composio toolkit 経由で Docnify 関連の作成、更新、取得、管理を AI エージェントに手伝わせたい場合に適しています。手作業でダッシュボードを操作するよりも MCP ベースの自動化を好むチーム、とくに tool schema が変わる可能性があり、実行前にエージェントが現在の機能を確認する必要がある環境に向いています。
重要な違い: 先に tool discovery を行う
この skill の最も重要な運用ルールは、実行前に RUBE_SEARCH_TOOLS を呼び出すことです。Rube は現在の tool slug、input schema、execution plan、既知の落とし穴を返すため、これは実務上大きな意味があります。エージェントがフィールド名を推測したり、古い例をもとに操作したりするリスクを下げられます。
導入条件と制限
これは薄いオーケストレーション用の skill であり、単体で動作する Docnify SDK ではありません。Rube MCP が利用できること、RUBE_MANAGE_CONNECTIONS で管理される Docnify connection があること、MCP tools を呼び出せる AI client が必要です。リポジトリパスには SKILL.md だけが含まれているため、helper scripts、templates、ローカル自動化コードではなく、運用ガイドとして理解するのが適切です。
docnify-automation skill の使い方
インストールと connection の前提
利用している skill client が一般的な skills CLI に対応している場合は、次のコマンドでインストールします。
npx skills add ComposioHQ/awesome-claude-skills --skill docnify-automation
次に、client configuration に Rube MCP を server として追加します。
https://rube.app/mcp
Docnify の操作を依頼する前に、RUBE_SEARCH_TOOLS が利用可能であることを確認してください。そのうえで、toolkit に docnify を指定して RUBE_MANAGE_CONNECTIONS を呼び出します。status が ACTIVE でない場合は、返された認可フローを完了します。
安定した実行に必要な入力
弱い依頼の例は「Update my Docnify docs.」です。より実用的な docnify-automation の依頼では、Docnify で達成したい具体的な目的、対象の object または workspace、希望する変更内容、制約、そしてエージェントが実行してよいのか計画だけに留めるべきかを明示します。
例:
“Use docnify-automation for Workflow Automation. First discover the current Docnify tools with RUBE_SEARCH_TOOLS. Check that my docnify connection is active. Then find the tool for updating a document title. If the schema supports it, update document DOC-123 title to Q1 onboarding checklist. Show the tool slug and inputs before executing.”
このように書くと、エージェントに discover-check-execute の順序を与えられ、意図しない書き込みを減らせます。
実務で使いやすいワークフローパターン
安全に docnify-automation を使う流れは次のとおりです。
- 特定の Docnify タスクについて
RUBE_SEARCH_TOOLSで tools を検索する。 - 後続の discovery では、返された session ID を再利用する。
RUBE_MANAGE_CONNECTIONSで connection status を確認する。- 自分のタスクを、返された tool slug と schema に照合する。
- 書き込み操作の前に、予定している inputs の要約をエージェントに提示させる。
- 必要な identifiers、fields、permissions が明確になってから実行する。
読み取り専用タスクでは、より素早い実行を許可しても構いません。create、update、delete、publish 系の操作では、事前確認を必須にするのが安全です。
最初に読むべきリポジトリファイル
まず composio-skills/docnify-automation/SKILL.md を確認してください。ここには、前提条件、セットアップ、tool discovery、connection checking、基本ワークフローという運用上の契約がすべて含まれています。提供されている構成には個別の README.md、rules/、resources/、scripts/ フォルダはないため、別の場所に隠れた実装詳細があるとは考えないでください。
docnify-automation skill FAQ
docnify-automation はインストール可能な Docnify integration ですか？
それ単体では違います。docnify-automation skill は、MCP 対応エージェントのための指示レイヤーです。実際の integration は、Rube MCP 経由の Composio の Docnify toolkit によって行われます。skill はエージェントを正しく動かすためにインストールし、実運用するには Rube と Docnify を接続します。
通常の prompt より何が優れていますか？
通常の prompt では、Docnify API の形をエージェントが推測してしまう可能性があります。この skill は、まず tools を検出し、現在の schema を確認し、connection state をチェックし、返された execution guidance を使うよう明示します。そのため、古いフィールド名による失敗が問題になりやすい、本番に近いワークフロー自動化に向いています。
初心者にも向いていますか？
MCP server の接続と OAuth 形式の connection flow に抵抗がなければ、初心者にも扱いやすい skill です。一方で、ワンクリックで使える Docnify app、ローカル CLI、事前に用意された scripts を期待している場合には向きません。初心者が特に意識すべきなのは、書き込み操作の前に、検出された tool schema をエージェントに表示させることです。
この skill を使わないほうがよい場合は？
タスクが Docnify と関係ない場合、client が MCP tools を使えない場合、または live tool discovery なしで決定論的なオフライン自動化が必要な場合は避けてください。また、「clean up everything」のような広すぎる依頼も、正確な scope、identifiers、approval rules を指定できない限り避けるべきです。
docnify-automation skill を改善する方法
実行範囲を追加して prompt を改善する
docnify-automation の結果を改善する最も早い方法は、エージェントが「してよいこと」と「してはいけないこと」を明確にすることです。たとえば “read-only”、“do not execute until I approve”、“only update this document ID”、“stop if the schema does not expose the required field” のような表現を加えます。Docnify のアクションは実際のコンテンツを変更する可能性があるため、こうした境界線は重要です。
よくある失敗を防ぐ
よくある失敗には、tool discovery の省略、非アクティブな Docnify connection、object IDs の不足、曖昧な target names、schema mismatch があります。対策として、エージェントに次の情報を報告させます。使用した RUBE_SEARCH_TOOLS query、選択した tool slug、required fields、optional fields、送信予定の正確な payload です。
最初の出力後に調整する
最初の plan や tool result が出たら、具体的な修正で絞り込みます。たとえば “Use the tool that supports document metadata, not document content”、“retry with the existing session ID”、“filter for documents created after this date.” のように指示します。Rube の session context を維持し、エージェントに代替案を作らせるのではなく、返された schemas を比較させると、反復の精度が上がります。
skill を拡張する前に確認すべきこと
リポジトリを fork する場合は、SKILL.md にタスク別の prompt examples、破壊的操作に対する approval rules、よく使う Docnify workflow 向けの RUBE_SEARCH_TOOLS query 例を追加するとよいでしょう。現在の skill には scripts や references がないため、最も効果が大きい改善は、文章量を増やすことではなく、判断ロジックをより明確にすることです。