graft

安装量: 920
排名: #4456

安装

npx skills add https://github.com/schrepa/graft --skill graft

Graft Use this skill when the task is about creating or refining a Graft server, wrapping an existing API with Graft proxy mode, or updating contributor-facing docs and examples so they match the current graft package behavior. Product thesis Graft's core value has three parts: Define once — tools with a name, schema, and handler. Serve as HTTP and MCP — from the same server, through a single shared pipeline (same auth, validation, middleware). Discovery is automatic — agents find tools via agent.json , mcp.json , llms.txt . Humans get interactive docs ( /docs ) and an OpenAPI spec ( /openapi.json ). Zero configuration. When explaining Graft, lead with all three parts. When showing examples, demonstrate both access patterns (MCP and HTTP) and mention what the server auto-serves. This applies to both source-based apps and proxy mode. Workflow Identify the mode before proposing changes: App authoring: createApp(...) , tools, resources, prompts, HTTP routes, Node or fetch integration. Proxy/OpenAPI: graft serve --openapi ... or graft.proxy.yaml . Docs/release hygiene: README, install instructions, skills, examples, contributor checks. Ground in the current repo before using memory: If tool access is available, inspect the current source, public exports, CLI commands, scaffold templates, and tests. If tool access is not available, ask for the smallest set of files or examples needed to avoid guessing. Follow the current public contract in examples and reviews: Inline tool examples: prefer app.tool('name', config) . Modular tool examples: prefer defineTool(...) plus app.tool(definedTool) . Auth shapes: true , ['role'] , or { roles: [...] } . MCP Streamable HTTP endpoint: POST /mcp . Auto-served framework endpoints: /.well-known/agent.json , /.well-known/mcp.json , /openapi.json , /docs , /llms.txt , /llms-full.txt , /health . Full CLI: serve , dev , check , test , studio , install , add-tool . When showing tool examples, demonstrate both the MCP tools/call invocation and the equivalent HTTP request (e.g. GET /list-items?q=hello or POST /create-entry ). Use tools where they materially improve correctness, but stay portable: With repo or shell access, inspect files and run validation commands after making changes. Without repo or shell access, state assumptions explicitly and keep recommendations tied to visible source or user-provided snippets. Load only the reference you need: App authoring: references/app-authoring.md Proxy/OpenAPI wrapping: references/proxy-openapi.md Validation, docs, and release hygiene: references/validation-release.md Quick examples Inline tool — both access patterns import { createApp } from '@schrepa/graft' import { z } from 'zod' const app = createApp ( ) app . tool ( 'list_items' , { description : 'List items matching a query.' , params : z . object ( { q : z . string ( ) } ) , auth : true , handler : async ( { q } ) => ( { items : [ 'hello' , 'world' ] . filter ( ( item ) => item . includes ( q ) ) , } ) , } ) export default app MCP ( tools/call ): { "method" : "tools/call" , "params" : { "name" : "list_items" , "arguments" : { "q" : "hello" } } } HTTP equivalent: GET /list-items?q=hello Authorization: Bearer The same handler, auth middleware, and validation run for both. Proxy mode — graft.proxy.yaml target : https : //petstore3.swagger.io/api/v3 tools : - method : GET path : /pet/findByStatus name : find_pets_by_status description : Find pets by status. parameters : type : object properties : status : type : string - method : POST path : /pet name : create_pet description : Create a pet. parameters : type : object properties : name : type : string required : [ name ] Start the proxy server: graft serve --config graft.proxy.yaml Graft exposes each configured operation as both an HTTP endpoint and an MCP tool, and auto-generates /openapi.json , /docs , and discovery files. For the direct OpenAPI path, use: graft serve --openapi ./openapi.yaml --target https://api.example.com Guardrails Do not document unsupported behavior just because an older example mentioned it. Keep examples executable and small; prefer one correct pattern over many variants. Prefer current source and tests over stale notes, blog posts, or memory. Do not mention registry or publishing artifacts unless they actually exist in the repo being edited. When a docs claim is likely to drift, add or update an automated check.

返回排行榜