@noodleseed/agent-kit 0.39.0 → 0.41.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -5
- package/manifest.json +904 -191
- package/package.json +1 -1
- package/skills/claude-code/SKILL.md +16 -14
- package/skills/claude-code/authoring-mcp-servers/SKILL.md +48 -0
- package/skills/claude-code/building-mcp-apps/SKILL.md +48 -0
- package/skills/claude-code/connecting-apis-to-mcp/SKILL.md +47 -0
- package/skills/claude-code/debugging-mcp-delivery/SKILL.md +48 -0
- package/skills/claude-code/deploying-mcp-services/SKILL.md +47 -0
- package/skills/claude-code/designing-mcp-products/SKILL.md +47 -0
- package/skills/claude-code/embedding-mcp-assistants/SKILL.md +47 -0
- package/skills/claude-code/examples/customer-auth/README.md +143 -1
- package/skills/claude-code/publishing-mcp-integrations/SKILL.md +47 -0
- package/skills/claude-code/references/embedded-assistant.md +142 -15
- package/skills/claude-code/reporting-noodle-feedback/SKILL.md +46 -0
- package/skills/claude-code/verifying-mcp-delivery/SKILL.md +47 -0
- package/skills/codex/SKILL.md +16 -14
- package/skills/codex/authoring-mcp-servers/SKILL.md +48 -0
- package/skills/codex/building-mcp-apps/SKILL.md +48 -0
- package/skills/codex/connecting-apis-to-mcp/SKILL.md +47 -0
- package/skills/codex/debugging-mcp-delivery/SKILL.md +48 -0
- package/skills/codex/deploying-mcp-services/SKILL.md +47 -0
- package/skills/codex/designing-mcp-products/SKILL.md +47 -0
- package/skills/codex/embedding-mcp-assistants/SKILL.md +47 -0
- package/skills/codex/examples/customer-auth/README.md +143 -1
- package/skills/codex/publishing-mcp-integrations/SKILL.md +47 -0
- package/skills/codex/references/embedded-assistant.md +142 -15
- package/skills/codex/reporting-noodle-feedback/SKILL.md +46 -0
- package/skills/codex/verifying-mcp-delivery/SKILL.md +47 -0
|
@@ -248,7 +248,125 @@ Or import the package root once and mount `<noodle-assistant session-endpoint="/
|
|
|
248
248
|
|
|
249
249
|
The component renders a custom element and must mount client-side. In a Next.js App Router tree, put the mount in a `"use client"` component; from a server component or the Pages Router, load it with `next/dynamic` and `ssr: false`.
|
|
250
250
|
|
|
251
|
-
For a customer-owned renderer, use the
|
|
251
|
+
For a customer-owned React renderer, use the renderer-free hook. It owns client lifetime and React subscription while `client` remains the one command surface:
|
|
252
|
+
|
|
253
|
+
```tsx
|
|
254
|
+
"use client";
|
|
255
|
+
|
|
256
|
+
import { useState } from "react";
|
|
257
|
+
import { useNoodleAssistant } from "@noodleseed/assistant/react/client";
|
|
258
|
+
|
|
259
|
+
export function CustomAssistant({ principalKey }: { principalKey: string }) {
|
|
260
|
+
const [draft, setDraft] = useState("");
|
|
261
|
+
const { client, messages, status, error } = useNoodleAssistant({
|
|
262
|
+
sessionEndpoint: "/api/assistant/session",
|
|
263
|
+
principalKey,
|
|
264
|
+
clientContext: () => ({
|
|
265
|
+
locale: navigator.language,
|
|
266
|
+
timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone,
|
|
267
|
+
}),
|
|
268
|
+
});
|
|
269
|
+
const busy = status === "submitted" || status === "streaming";
|
|
270
|
+
const settle = (operation: Promise<void>) => {
|
|
271
|
+
void operation.catch(() => {
|
|
272
|
+
// The hook exposes this same structured failure through `error`.
|
|
273
|
+
});
|
|
274
|
+
};
|
|
275
|
+
|
|
276
|
+
return (
|
|
277
|
+
<section aria-label="Assistant" aria-busy={busy}>
|
|
278
|
+
{messages.map((message) => (
|
|
279
|
+
<article key={message.id} data-role={message.role}>
|
|
280
|
+
{message.parts.map((part, index) => {
|
|
281
|
+
if (part.type === "text") return <p key={index}>{part.text}</p>;
|
|
282
|
+
if (part.type === "data-confirmation") {
|
|
283
|
+
const review = part.data;
|
|
284
|
+
return (
|
|
285
|
+
<section key={review.id} aria-label="Review proposed action">
|
|
286
|
+
<h3>{review.title ?? "Review proposed action"}</h3>
|
|
287
|
+
{review.description ? <p>{review.description}</p> : null}
|
|
288
|
+
<pre aria-label="Proposed action arguments">
|
|
289
|
+
{JSON.stringify(review.arguments ?? {}, null, 2)}
|
|
290
|
+
</pre>
|
|
291
|
+
<button
|
|
292
|
+
disabled={busy || review.status !== "pending"}
|
|
293
|
+
onClick={() => settle(client.respond(review.id, { action: "accept" }))}
|
|
294
|
+
>
|
|
295
|
+
Confirm
|
|
296
|
+
</button>
|
|
297
|
+
<button
|
|
298
|
+
disabled={busy || review.status !== "pending"}
|
|
299
|
+
onClick={() => settle(client.respond(review.id, { action: "decline" }))}
|
|
300
|
+
>
|
|
301
|
+
Don't proceed
|
|
302
|
+
</button>
|
|
303
|
+
</section>
|
|
304
|
+
);
|
|
305
|
+
}
|
|
306
|
+
if (part.type === "data-input-request") {
|
|
307
|
+
const request = part.data;
|
|
308
|
+
return (
|
|
309
|
+
<section key={request.id} aria-label="Assistant needs input">
|
|
310
|
+
<p>{request.message}</p>
|
|
311
|
+
<p>This renderer has not implemented the requested form.</p>
|
|
312
|
+
<button
|
|
313
|
+
disabled={busy || request.status !== "pending"}
|
|
314
|
+
onClick={() => settle(client.respond(request.id, { action: "decline" }))}
|
|
315
|
+
>
|
|
316
|
+
Cancel request
|
|
317
|
+
</button>
|
|
318
|
+
</section>
|
|
319
|
+
);
|
|
320
|
+
}
|
|
321
|
+
if (part.type === "data-tool-result") {
|
|
322
|
+
return (
|
|
323
|
+
<pre key={part.data.id} aria-label={`${part.data.tool} result`}>
|
|
324
|
+
{JSON.stringify(part.data.result, null, 2)}
|
|
325
|
+
</pre>
|
|
326
|
+
);
|
|
327
|
+
}
|
|
328
|
+
if (part.type === "data-view") {
|
|
329
|
+
return (
|
|
330
|
+
<p key={part.data.id}>
|
|
331
|
+
Trusted app view available: {part.data.title ?? part.data.resourceUri}
|
|
332
|
+
</p>
|
|
333
|
+
);
|
|
334
|
+
}
|
|
335
|
+
return <p key={index}>Unsupported assistant content.</p>;
|
|
336
|
+
})}
|
|
337
|
+
</article>
|
|
338
|
+
))}
|
|
339
|
+
{error ? <p role="alert">{error.message}</p> : null}
|
|
340
|
+
<form
|
|
341
|
+
onSubmit={(event) => {
|
|
342
|
+
event.preventDefault();
|
|
343
|
+
const message = draft.trim();
|
|
344
|
+
if (!message) return;
|
|
345
|
+
setDraft("");
|
|
346
|
+
settle(client.sendMessage(message));
|
|
347
|
+
}}
|
|
348
|
+
>
|
|
349
|
+
<input
|
|
350
|
+
aria-label="Message"
|
|
351
|
+
value={draft}
|
|
352
|
+
onChange={(event) => setDraft(event.currentTarget.value)}
|
|
353
|
+
/>
|
|
354
|
+
{busy ? (
|
|
355
|
+
<button type="button" onClick={() => client.abort()}>Stop</button>
|
|
356
|
+
) : (
|
|
357
|
+
<button type="submit">Send</button>
|
|
358
|
+
)}
|
|
359
|
+
</form>
|
|
360
|
+
</section>
|
|
361
|
+
);
|
|
362
|
+
}
|
|
363
|
+
```
|
|
364
|
+
|
|
365
|
+
`principalKey` is a browser-local identity for the authenticated user/tenant and is never sent to Noodle. Change it whenever that principal changes; the hook then aborts and clears the previous session and transcript. The hook does not register `<noodle-assistant>` or render Noodle markup.
|
|
366
|
+
|
|
367
|
+
The sample fails closed on input requests until you replace that branch with a form generated from `requestedSchema`. A custom renderer must show the complete confirmation review and both decisions, handle every part it supports, and surface an explicit unsupported state for the rest. For `data-view`, map `resourceUri` or `tool` plus the bounded/redacted `result` to a component already trusted by the application. Never inject `part.data.html`, assign it to `srcdoc`, or fetch a `ui://` URI; the managed element alone supplies Noodle’s sandbox host. Do not wrap this client in another chat transport or invent user messages for interaction continuations.
|
|
368
|
+
|
|
369
|
+
Outside React, use the same DOM-free client directly. It keeps the session token in memory, exposes a React-free `UIMessage` transcript with typed parts, and never registers a custom element:
|
|
252
370
|
|
|
253
371
|
```ts
|
|
254
372
|
import { createAssistantClient } from "@noodleseed/assistant/client";
|
|
@@ -266,30 +384,39 @@ assistant.updateModelContext({
|
|
|
266
384
|
structuredContent: { widget: { name: 'time-off', lifecycle: 'mounted' } },
|
|
267
385
|
});
|
|
268
386
|
|
|
269
|
-
let
|
|
270
|
-
|
|
271
|
-
|
|
272
|
-
|
|
273
|
-
|
|
274
|
-
|
|
275
|
-
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
|
|
387
|
+
let pending: { id: string; requestedSchema?: Readonly<Record<string, unknown>> } | undefined;
|
|
388
|
+
assistant.subscribeChat((state) => {
|
|
389
|
+
renderUIMessageState(state);
|
|
390
|
+
pending = undefined;
|
|
391
|
+
for (const message of state.messages) {
|
|
392
|
+
for (const part of message.parts) {
|
|
393
|
+
if (part.type === 'data-confirmation' && part.data.status === 'pending') {
|
|
394
|
+
pending = { id: part.data.id };
|
|
395
|
+
}
|
|
396
|
+
if (part.type === 'data-input-request' && part.data.status === 'pending') {
|
|
397
|
+
pending = { id: part.data.id, requestedSchema: part.data.requestedSchema };
|
|
398
|
+
}
|
|
399
|
+
if (part.type === 'data-view') {
|
|
400
|
+
renderRegisteredView(part.data.resourceUri, part.data.result);
|
|
401
|
+
}
|
|
402
|
+
}
|
|
279
403
|
}
|
|
280
404
|
});
|
|
281
405
|
|
|
282
406
|
await assistant.sendMessage("Book next Thursday and Friday off");
|
|
283
|
-
if (
|
|
407
|
+
if (pending) {
|
|
408
|
+
const requestedSchema = pending.requestedSchema;
|
|
284
409
|
const resolution = requestedSchema
|
|
285
410
|
? { action: 'accept' as const, content: await renderPortableForm(requestedSchema) }
|
|
286
411
|
: { action: 'accept' as const };
|
|
287
|
-
await assistant.respond(
|
|
412
|
+
await assistant.respond(pending.id, resolution);
|
|
288
413
|
}
|
|
289
414
|
// The same pending id also accepts { action: 'decline' } or { action: 'cancel' }.
|
|
290
415
|
```
|
|
291
416
|
|
|
292
|
-
`
|
|
417
|
+
`subscribeChat` immediately emits a detached `{ messages, status, error? }` snapshot and then emits as `UIMessage.parts` change. Text uses `text`; Noodle confirmations, input requests, tool results, and linked views use `data-confirmation`, `data-input-request`, `data-tool-result`, and `data-view`. Interaction data moves through pending/submitting/accepted/declined/cancelled. Use raw `subscribe(...)` only for transport/session lifecycle events that are not transcript content.
|
|
418
|
+
|
|
419
|
+
`data-view` means a completed tool has a linked MCP App view. It carries the call/interaction id, tool, `ui://` identity, optional title, bounded/redacted public result, and—on current services—the self-contained bridged document. The standard element is an MCP Apps host and mounts that document behind a double iframe; a customer renderer ignores it and maps the identity/result to an application-trusted component. The standard element supports lifecycle, app tool/resource calls, ui/message, ui/update-model-context, links, resize, and inline/fullscreen; sampling, tasks, downloads, and remote DOM are not advertised. It also dispatches `assistant-view-available` for a customer-owned renderer.
|
|
293
420
|
|
|
294
421
|
`clientContext` and typed `pageContext` are recomputed for each turn. `updateContext(...)` remains the legacy session-exchange context; `updatePageContext(...)` replaces the fresh per-turn application hint. `updateModelContext({ content, structuredContent })` publishes one cohesive renderer snapshot for later message turns without starting a turn; every call replaces the prior snapshot rather than merging fields. These are untrusted data, not conversation history or authorization input, and the boundaries reject credential-shaped or unbounded updates. A message may re-exchange once after a pre-execution `401`; the client never auto-retries interaction decisions. `tool_proposed.arguments` is a complete schema-aware review projection and, for connector-backed tools, names the sole exact connector version/operation/resolved arguments. Sensitive/write-only fields are redacted; truncating or omitting any non-sensitive action field fails closed. Accept is bound to the server-held action and claims at most one execution attempt—clients cannot replace it. Normal terminal outcomes scrub private arguments and continuations immediately; only an accepted action still executing retains them for the one-hour unknown-outcome recovery window, after which it records `interaction_outcome_unknown` and scrubs. Without downstream idempotency this is not an exactly-once business-effect guarantee. To reconcile a lost response, explicitly repeat the same id and decision: the service returns its durable stored outcome without re-execution.
|
|
295
422
|
|
|
@@ -297,7 +424,7 @@ if (pendingId) {
|
|
|
297
424
|
|
|
298
425
|
- Node.js 20+ for `@noodleseed/assistant/server`.
|
|
299
426
|
- The package ships ESM and CommonJS with full export conditions; no bundler aliases, `transpilePackages`, or ambient type shims are needed. If resolution fails, the installed package version is outdated: update `@noodleseed/assistant` instead of adding workarounds.
|
|
300
|
-
- TypeScript `moduleResolution` `bundler` or `node16` recommended; classic `node` also resolves the `/client`, `/react`, and `/server` subpaths.
|
|
427
|
+
- TypeScript `moduleResolution` `bundler` or `node16` recommended; classic `node` also resolves the `/client`, `/react`, `/react/client`, and `/server` subpaths.
|
|
301
428
|
|
|
302
429
|
## Verify the boundary
|
|
303
430
|
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: reporting-noodle-feedback
|
|
3
|
+
description: "Use when a Noodle Seed bug, misleading instruction, missing capability, or concrete product improvement should be proposed to the user."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:1e23938b39956ef8 -->
|
|
7
|
+
|
|
8
|
+
# reporting-noodle-feedback
|
|
9
|
+
|
|
10
|
+
Offer one sanitized feedback command and submit it only after informed explicit approval.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Report a Noodle Seed bug or documentation gap.
|
|
15
|
+
- Propose a concrete Noodle product improvement.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use for generic project bugs.
|
|
20
|
+
- Do not send customer code, identifiers, logs, or secrets.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- One distinct finding.
|
|
25
|
+
- Sanitized observed and expected behavior.
|
|
26
|
+
- User approval for the exact command.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/feedback.md` at `../noodle-seed/references/feedback.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
|
|
32
|
+
## Verification evidence
|
|
33
|
+
|
|
34
|
+
The user saw the exact sanitized command; only a returned reference proves submission.
|
|
35
|
+
|
|
36
|
+
## Recovery paths
|
|
37
|
+
|
|
38
|
+
If login or rate limits block submission, report that nothing was sent and do not retry-loop.
|
|
39
|
+
|
|
40
|
+
## Stop conditions
|
|
41
|
+
|
|
42
|
+
Stop before running the command until the user explicitly approves it.
|
|
43
|
+
|
|
44
|
+
## Handoff contract
|
|
45
|
+
|
|
46
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: verifying-mcp-delivery
|
|
3
|
+
description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:6ef6ef551e26b78e -->
|
|
7
|
+
|
|
8
|
+
# verifying-mcp-delivery
|
|
9
|
+
|
|
10
|
+
Report the highest evidence level actually rerun without upgrading weaker proof.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Verify this MCP delivery before handoff.
|
|
15
|
+
- Prove which delivery layers currently pass.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use as a substitute for fixing a known failure.
|
|
20
|
+
- Do not infer hosted health from local success.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Requested evidence level.
|
|
25
|
+
- Current target.
|
|
26
|
+
- Existing evidence and its freshness.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/verify-and-recover.md` at `../noodle-seed/references/verify-and-recover.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/test-in-hosts.md` at `../noodle-seed/references/test-in-hosts.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
|
|
33
|
+
## Verification evidence
|
|
34
|
+
|
|
35
|
+
Every dependency below the requested level passes now, or the first unproven layer is explicit.
|
|
36
|
+
|
|
37
|
+
## Recovery paths
|
|
38
|
+
|
|
39
|
+
Hand a concrete failing layer to debugging-mcp-delivery with all passing evidence preserved.
|
|
40
|
+
|
|
41
|
+
## Stop conditions
|
|
42
|
+
|
|
43
|
+
Stop after the requested level passes or the first bounded failure is isolated.
|
|
44
|
+
|
|
45
|
+
## Handoff contract
|
|
46
|
+
|
|
47
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
package/skills/codex/SKILL.md
CHANGED
|
@@ -1,9 +1,9 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: noodle-seed
|
|
3
|
-
description: Use when building, validating, testing, deploying, or operating a local or hosted Noodle Seed MCP server or app authored in TypeScript with the noodle CLI.
|
|
3
|
+
description: "Use when building, validating, testing, deploying, or operating a local or hosted Noodle Seed MCP server or app authored in TypeScript with the noodle CLI."
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
<!-- noodle-skill version:0.
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:2ea7d6dcc8358b35 -->
|
|
7
7
|
|
|
8
8
|
# Noodle Seed
|
|
9
9
|
|
|
@@ -17,23 +17,25 @@ If the request is unrelated to the Noodle MCP surface, stop here: follow the pro
|
|
|
17
17
|
|
|
18
18
|
## Route the request
|
|
19
19
|
|
|
20
|
-
Choose exactly one primary route from the user outcome below. Read that primary reference in full
|
|
20
|
+
Choose exactly one primary route from the user outcome below, then load the selected sibling skill and hand off the request. Read that primary reference in full; read supporting references only when the sibling or observed evidence requires them. Do not reread the corpus or restart discovery after the handoff.
|
|
21
21
|
|
|
22
|
-
Apply this precedence when wording overlaps:
|
|
22
|
+
Apply this precedence when wording overlaps: concrete failure evidence takes the debugging route; an MCP App/UI outcome takes the App route; external API integration from credentials, a URL, or an API specification takes precedence over generic server building; hosted inspection is debugging read-only; hosted mutation requires the explicitly requested deployment route.
|
|
23
23
|
|
|
24
24
|
Negative routing examples: “Inspect hosted logs/status” → `inspect-hosted` (read-only). “Prepare for deployment” → the applicable build or verification route and stop with a handoff; preparation does not authorize `link`, hosted config, deployment, rollback, host writes, or submission. “Keep this local” → a build or verification route, never a hosted route.
|
|
25
25
|
|
|
26
|
-
| User outcome |
|
|
26
|
+
| User outcome | Load sibling skill | Canonical playbook | Done when |
|
|
27
27
|
| :--- | :--- | :--- | :--- |
|
|
28
|
-
|
|
|
29
|
-
|
|
|
30
|
-
|
|
|
31
|
-
|
|
|
32
|
-
|
|
|
33
|
-
|
|
|
34
|
-
|
|
|
35
|
-
|
|
|
36
|
-
|
|
|
28
|
+
| Turn a vague MCP product idea into a bounded design before implementation | `designing-mcp-products` | `references/experience-design.md` (`references/authoring-workflow.md`) | The product contract identifies the user benefit, model boundary, evidence, and next implementation skill. |
|
|
29
|
+
| Create or extend a headless MCP server whose external API contract is already modeled | `authoring-mcp-servers` | `references/build-an-mcp-server.md` (`references/authoring-workflow.md`, `references/sdk-surface.md`) | The requested server behavior is locally validated and tested; connector reads have real-output evidence. |
|
|
30
|
+
| Connect a real API when credentials or an API specification are available | `connecting-apis-to-mcp` | `references/connect-an-api.md` (`references/authoring-workflow.md`) | A representative live read returns populated, intentionally mapped fields without exposing credentials. |
|
|
31
|
+
| Build or change an MCP App, widget, or host-visible UI | `building-mcp-apps` | `references/build-an-mcp-app.md` (`references/experience-design.md`, `references/widgets-and-apps.md`) | The UI has a stated user benefit, passes the requested checks, and degrades to useful text. |
|
|
32
|
+
| Validate, test, or prove a project at a named delivery evidence level | `verifying-mcp-delivery` | `references/verify-and-recover.md` (`references/test-in-hosts.md`) | The failing evidence layer is repaired and rerun, or the remaining blocker and exact next action are reported. |
|
|
33
|
+
| Diagnose or recover an existing project with concrete local or hosted failure evidence | `debugging-mcp-delivery` | `references/verify-and-recover.md` (`references/troubleshooting.md`, `references/inspect-hosted.md`) | The failing layer is repaired and rerun, or the stable blocker and exact next action are reported. |
|
|
34
|
+
| Inspect or diagnose hosted status, logs, metrics, events, or deployment metadata read-only | `debugging-mcp-delivery` | `references/verify-and-recover.md` (`references/troubleshooting.md`, `references/inspect-hosted.md`) | The requested hosted evidence is reported without changing target, configuration, access, or deployment state. |
|
|
35
|
+
| Deploy, configure, connect with writes, change access, or roll back a hosted MCP service when explicitly requested | `deploying-mcp-services` | `references/deploy-and-ops.md` (`references/cli-commands.md`) | The requested hosted state is evidenced without claiming unperformed host or production checks. |
|
|
36
|
+
| Embed a Noodle assistant in an existing SaaS or web application | `embedding-mcp-assistants` | `references/embedded-assistant.md` (`references/authoring-workflow.md`) | The requested embed boundary works with verified identity and credential separation at the tested level. |
|
|
37
|
+
| Prepare or submit an integration to a host directory | `publishing-mcp-integrations` | `references/publishing.md` (`references/app-directory-compliance.md`) | The requested submission evidence is complete and any host-review uncertainty is explicit. |
|
|
38
|
+
| Report a Noodle Seed bug, documentation gap, or product improvement | `reporting-noodle-feedback` | `references/feedback.md` (None) | A sanitized command is shown to the user and is submitted only after explicit approval. |
|
|
37
39
|
|
|
38
40
|
## Common machine loop
|
|
39
41
|
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: authoring-mcp-servers
|
|
3
|
+
description: "Use when creating or extending a headless Noodle Seed MCP server, tool, resource, prompt, or typed model-facing capability."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:0b2fd8c7e43fc69f -->
|
|
7
|
+
|
|
8
|
+
# authoring-mcp-servers
|
|
9
|
+
|
|
10
|
+
Deliver focused model-facing MCP behavior through the configured TypeScript entrypoint.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Build a headless MCP server.
|
|
15
|
+
- Add a typed tool, resource, or prompt.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use when the primary outcome is a widget.
|
|
20
|
+
- Do not use only to diagnose or deploy existing behavior.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Requested user intent.
|
|
25
|
+
- Expected typed result.
|
|
26
|
+
- External operation contract when applicable.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/build-an-mcp-server.md` at `../noodle-seed/references/build-an-mcp-server.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
Load `references/sdk-surface.md` at `../noodle-seed/references/sdk-surface.md` only when the playbook or observed evidence names that concern.
|
|
33
|
+
|
|
34
|
+
## Verification evidence
|
|
35
|
+
|
|
36
|
+
The TypeScript behavior validates and passes local smoke; connector reads also have real-output proof.
|
|
37
|
+
|
|
38
|
+
## Recovery paths
|
|
39
|
+
|
|
40
|
+
Resume at the first failing compile, smoke, credential, mapping, or live-read layer.
|
|
41
|
+
|
|
42
|
+
## Stop conditions
|
|
43
|
+
|
|
44
|
+
Stop at local delivery unless another requested outcome explicitly authorizes a handoff.
|
|
45
|
+
|
|
46
|
+
## Handoff contract
|
|
47
|
+
|
|
48
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: building-mcp-apps
|
|
3
|
+
description: "Use when a Noodle Seed MCP App, widget, interactive card, visual interaction, or host-visible UI is the primary requested outcome."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:f7fa54992c8d7692 -->
|
|
7
|
+
|
|
8
|
+
# building-mcp-apps
|
|
9
|
+
|
|
10
|
+
Deliver an MCP App whose visual interaction earns its place and preserves useful model-visible fallback.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Build an MCP App or widget.
|
|
15
|
+
- Add a host-visible interactive workflow.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use when concise text fully serves the user.
|
|
20
|
+
- Do not use for headless server work with no UI outcome.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Target user and explicit UI benefit.
|
|
25
|
+
- Primary interaction and states.
|
|
26
|
+
- Model-visible result and text fallback.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/build-an-mcp-app.md` at `../noodle-seed/references/build-an-mcp-app.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/experience-design.md` at `../noodle-seed/references/experience-design.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
Load `references/widgets-and-apps.md` at `../noodle-seed/references/widgets-and-apps.md` only when the playbook or observed evidence names that concern.
|
|
33
|
+
|
|
34
|
+
## Verification evidence
|
|
35
|
+
|
|
36
|
+
The App passes validation, local smoke, app checks, and the requested preview or host evidence level.
|
|
37
|
+
|
|
38
|
+
## Recovery paths
|
|
39
|
+
|
|
40
|
+
Distinguish data-contract, widget-runtime, rendering, host, and deployment failures.
|
|
41
|
+
|
|
42
|
+
## Stop conditions
|
|
43
|
+
|
|
44
|
+
Stop before deployment or publication unless that distinct outcome was requested.
|
|
45
|
+
|
|
46
|
+
## Handoff contract
|
|
47
|
+
|
|
48
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: connecting-apis-to-mcp
|
|
3
|
+
description: "Use when credentials, an API URL, an OpenAPI document, or an observed response must become real Noodle Seed MCP behavior."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:1e86b8704f407bd3 -->
|
|
7
|
+
|
|
8
|
+
# connecting-apis-to-mcp
|
|
9
|
+
|
|
10
|
+
Connect a real API using managed credentials and mappings proven against observed output.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Connect this OpenAPI URL to MCP.
|
|
15
|
+
- Use these API credentials for a real connector.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use for static local behavior.
|
|
20
|
+
- Do not use when credentials or a representative safe read are unavailable.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- API base URL and authentication scheme.
|
|
25
|
+
- Representative safe read.
|
|
26
|
+
- User intent and observed response shape.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/connect-an-api.md` at `../noodle-seed/references/connect-an-api.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
|
|
33
|
+
## Verification evidence
|
|
34
|
+
|
|
35
|
+
A safe live read returns populated intentionally mapped fields through the effective local target.
|
|
36
|
+
|
|
37
|
+
## Recovery paths
|
|
38
|
+
|
|
39
|
+
Separate authentication, transport, response-shape, mapping, and empty-result failures before editing.
|
|
40
|
+
|
|
41
|
+
## Stop conditions
|
|
42
|
+
|
|
43
|
+
Stop before live writes without explicit approval, known effect, and a safe target.
|
|
44
|
+
|
|
45
|
+
## Handoff contract
|
|
46
|
+
|
|
47
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: debugging-mcp-delivery
|
|
3
|
+
description: "Use when an existing Noodle Seed MCP project has a concrete validation, runtime, connector, App, host, deployment, or production failure."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:aa715bae12041d7c -->
|
|
7
|
+
|
|
8
|
+
# debugging-mcp-delivery
|
|
9
|
+
|
|
10
|
+
Repair or isolate the first failing evidence layer while preserving everything already proven.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Diagnose this failing MCP project.
|
|
15
|
+
- Inspect a hosted failure from logs or status.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use for a greenfield build with no failure evidence.
|
|
20
|
+
- Do not mutate hosted state during read-only inspection.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Exact failing command or symptom.
|
|
25
|
+
- Current target and evidence level.
|
|
26
|
+
- Most recent sanitized failure.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/verify-and-recover.md` at `../noodle-seed/references/verify-and-recover.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/troubleshooting.md` at `../noodle-seed/references/troubleshooting.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
Load `references/inspect-hosted.md` at `../noodle-seed/references/inspect-hosted.md` only when the playbook or observed evidence names that concern.
|
|
33
|
+
|
|
34
|
+
## Verification evidence
|
|
35
|
+
|
|
36
|
+
The failed layer is rerun successfully, or the stable blocker and exact next action are reported.
|
|
37
|
+
|
|
38
|
+
## Recovery paths
|
|
39
|
+
|
|
40
|
+
After two attempts with the same signature, stop editing and preserve the repro and passing layers.
|
|
41
|
+
|
|
42
|
+
## Stop conditions
|
|
43
|
+
|
|
44
|
+
Stop before hosted mutation unless the user separately requests deploying-mcp-services.
|
|
45
|
+
|
|
46
|
+
## Handoff contract
|
|
47
|
+
|
|
48
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: deploying-mcp-services
|
|
3
|
+
description: "Use when the user explicitly requests a Noodle Seed hosted link, configuration write, deployment, access change, rollback, or connection write."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:93e735b7ffb45df1 -->
|
|
7
|
+
|
|
8
|
+
# deploying-mcp-services
|
|
9
|
+
|
|
10
|
+
Apply only the explicitly authorized hosted mutation to the explicit org, app, and environment.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Deploy this MCP service to an explicit environment.
|
|
15
|
+
- Roll back or change hosted access.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use for preparation, inspection, or local-only work.
|
|
20
|
+
- Do not select or default a mutation target implicitly.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Explicit org, app, and environment.
|
|
25
|
+
- Authorized mutation.
|
|
26
|
+
- Pre-deploy verification evidence.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/deploy-and-ops.md` at `../noodle-seed/references/deploy-and-ops.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/cli-commands.md` at `../noodle-seed/references/cli-commands.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
|
|
33
|
+
## Verification evidence
|
|
34
|
+
|
|
35
|
+
The requested hosted state is confirmed without claiming unperformed host or production checks.
|
|
36
|
+
|
|
37
|
+
## Recovery paths
|
|
38
|
+
|
|
39
|
+
Preserve local evidence and isolate authentication, target, build, rollout, health, or rollback failures.
|
|
40
|
+
|
|
41
|
+
## Stop conditions
|
|
42
|
+
|
|
43
|
+
Stop and ask when target, authority, or effect is ambiguous.
|
|
44
|
+
|
|
45
|
+
## Handoff contract
|
|
46
|
+
|
|
47
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: designing-mcp-products
|
|
3
|
+
description: "Use when a Noodle Seed MCP product idea needs conversational fit, user benefit, scope, interaction, or evidence design before implementation."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
<!-- noodle-skill version:0.41.0 hash:76cce86729cffbee -->
|
|
7
|
+
|
|
8
|
+
# designing-mcp-products
|
|
9
|
+
|
|
10
|
+
Produce the smallest decision-ready MCP product design before code or hosted mutation.
|
|
11
|
+
|
|
12
|
+
## Use when
|
|
13
|
+
|
|
14
|
+
- Turn a vague product idea into an MCP product.
|
|
15
|
+
- Decide whether this job needs an MCP App.
|
|
16
|
+
|
|
17
|
+
## Do not use when
|
|
18
|
+
|
|
19
|
+
- Do not use for an already specified implementation.
|
|
20
|
+
- Do not use for generic product or UI design outside MCP.
|
|
21
|
+
|
|
22
|
+
## Required inputs
|
|
23
|
+
|
|
24
|
+
- Target user and job.
|
|
25
|
+
- System data or action the model cannot supply.
|
|
26
|
+
- Requested stopping point.
|
|
27
|
+
|
|
28
|
+
## Workflow
|
|
29
|
+
|
|
30
|
+
Read and follow the canonical playbook `references/experience-design.md` at `../noodle-seed/references/experience-design.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
|
|
31
|
+
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
|
|
32
|
+
|
|
33
|
+
## Verification evidence
|
|
34
|
+
|
|
35
|
+
A bounded product contract states user benefit, model boundary, interaction, fallback, risks, and next implementation skill.
|
|
36
|
+
|
|
37
|
+
## Recovery paths
|
|
38
|
+
|
|
39
|
+
If the idea is broad, reduce it to one conversational job and one representative success path.
|
|
40
|
+
|
|
41
|
+
## Stop conditions
|
|
42
|
+
|
|
43
|
+
Stop before implementation when the design inputs or product fit are unresolved.
|
|
44
|
+
|
|
45
|
+
## Handoff contract
|
|
46
|
+
|
|
47
|
+
Pass the selected outcome, explicit target, changed files, commands run, passing evidence, first unproven evidence layer, sanitized failure, remaining authority, and exact next action. The receiving skill continues from that layer; do not restart discovery or discard prior proof.
|