Arez

View saved version →

---
name: authoring-mcp-servers
description: "Use when creating or extending a headless Noodle Seed MCP server, tool, resource, prompt, or typed model-facing capability."
---

<!-- noodle-skill version:0.62.1 hash:0b2fd8c7e43fc69f -->

# authoring-mcp-servers

Deliver focused model-facing MCP behavior through the configured TypeScript entrypoint.

## Use when

- Build a headless MCP server.
- Add a typed tool, resource, or prompt.

## Do not use when

- Do not use when the primary outcome is a widget.
- Do not use only to diagnose or deploy existing behavior.

## Required inputs

- Requested user intent.
- Expected typed result.
- External operation contract when applicable.

## Workflow

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.
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
Load `references/sdk-surface.md` at `../noodle-seed/references/sdk-surface.md` only when the playbook or observed evidence names that concern.

## Verification evidence

The TypeScript behavior validates and passes local smoke; connector reads also have real-output proof.

## Recovery paths

Resume at the first failing compile, smoke, credential, mapping, or live-read layer.

## Stop conditions

Stop at local delivery unless another requested outcome explicitly authorizes a handoff.

## Handoff contract

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.

View saved version →

---
name: building-mcp-apps
description: "Use when a Noodle Seed MCP App, widget, interactive card, visual interaction, or host-visible UI is the primary requested outcome."
---

<!-- noodle-skill version:0.62.1 hash:f7fa54992c8d7692 -->

# building-mcp-apps

Deliver an MCP App whose visual interaction earns its place and preserves useful model-visible fallback.

## Use when

- Build an MCP App or widget.
- Add a host-visible interactive workflow.

## Do not use when

- Do not use when concise text fully serves the user.
- Do not use for headless server work with no UI outcome.

## Required inputs

- Target user and explicit UI benefit.
- Primary interaction and states.
- Model-visible result and text fallback.

## Workflow

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.
Load `references/experience-design.md` at `../noodle-seed/references/experience-design.md` only when the playbook or observed evidence names that concern.
Load `references/widgets-and-apps.md` at `../noodle-seed/references/widgets-and-apps.md` only when the playbook or observed evidence names that concern.

## Verification evidence

The App passes validation, local smoke, app checks, and the requested preview or host evidence level.

## Recovery paths

Distinguish data-contract, widget-runtime, rendering, host, and deployment failures.

## Stop conditions

Stop before deployment or publication unless that distinct outcome was requested.

## Handoff contract

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.

View saved version →

---
name: connecting-apis-to-mcp
description: "Use when all four API-evidence inputs exist—and only then: API base URL, authentication scheme, representative safe read, and observed response."
---

<!-- noodle-skill version:0.62.1 hash:21bbd3ec441ffd30 -->

# connecting-apis-to-mcp

Connect a real API using managed credentials and mappings proven against observed output.

## Use when

- Connect this API after confirming its base URL, authentication scheme, safe read, and observed response.

## Do not use when

- Do not use for static local behavior.
- Do not use when all available API evidence is stale, inaccessible, undocumented-only, or otherwise unusable.

## Required inputs

- API base URL and authentication scheme.
- Representative safe read.
- User intent and observed response shape.

## Workflow

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.
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.

## Verification evidence

A safe live read returns populated intentionally mapped fields through the effective local target.

## Recovery paths

Separate authentication, transport, response-shape, mapping, and empty-result failures before editing.

## Stop conditions

Stop before live writes without explicit approval, known effect, and a safe target.

## Handoff contract

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.

View saved version →

---
name: debugging-mcp-delivery
description: "Use when an existing Noodle Seed MCP project has a concrete validation, runtime, connector, App, host, deployment, or production failure."
---

<!-- noodle-skill version:0.62.1 hash:aa715bae12041d7c -->

# debugging-mcp-delivery

Repair or isolate the first failing evidence layer while preserving everything already proven.

## Use when

- Diagnose this failing MCP project.
- Inspect a hosted failure from logs or status.

## Do not use when

- Do not use for a greenfield build with no failure evidence.
- Do not mutate hosted state during read-only inspection.

## Required inputs

- Exact failing command or symptom.
- Current target and evidence level.
- Most recent sanitized failure.

## Workflow

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.
Load `references/troubleshooting.md` at `../noodle-seed/references/troubleshooting.md` only when the playbook or observed evidence names that concern.
Load `references/inspect-hosted.md` at `../noodle-seed/references/inspect-hosted.md` only when the playbook or observed evidence names that concern.

## Verification evidence

The failed layer is rerun successfully, or the stable blocker and exact next action are reported.

## Recovery paths

After two attempts with the same signature, stop editing and preserve the repro and passing layers.

## Stop conditions

Stop before hosted mutation unless the user separately requests deploying-mcp-services.

## Handoff contract

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.

View saved version →

---
name: deploying-mcp-services
description: "Use when the user explicitly requests a Noodle Seed hosted link, configuration write, deployment, access change, rollback, or connection write."
---

<!-- noodle-skill version:0.62.1 hash:93e735b7ffb45df1 -->

# deploying-mcp-services

Apply only the explicitly authorized hosted mutation to the explicit org, app, and environment.

## Use when

- Deploy this MCP service to an explicit environment.
- Roll back or change hosted access.

## Do not use when

- Do not use for preparation, inspection, or local-only work.
- Do not select or default a mutation target implicitly.

## Required inputs

- Explicit org, app, and environment.
- Authorized mutation.
- Pre-deploy verification evidence.

## Workflow

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.
Load `references/cli-commands.md` at `../noodle-seed/references/cli-commands.md` only when the playbook or observed evidence names that concern.

## Verification evidence

The requested hosted state is confirmed without claiming unperformed host or production checks.

## Recovery paths

Preserve local evidence and isolate authentication, target, build, rollout, health, or rollback failures.

## Stop conditions

Stop and ask when target, authority, or effect is ambiguous.

## Handoff contract

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.

View saved version →

---
name: designing-mcp-products
description: "Use when a Noodle Seed MCP product idea needs conversational fit, user benefit, scope, interaction, or evidence design before implementation."
---

<!-- noodle-skill version:0.62.1 hash:76cce86729cffbee -->

# designing-mcp-products

Produce the smallest decision-ready MCP product design before code or hosted mutation.

## Use when

- Turn a vague product idea into an MCP product.
- Decide whether this job needs an MCP App.

## Do not use when

- Do not use for an already specified implementation.
- Do not use for generic product or UI design outside MCP.

## Required inputs

- Target user and job.
- System data or action the model cannot supply.
- Requested stopping point.

## Workflow

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.
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.

## Verification evidence

A bounded product contract states user benefit, model boundary, interaction, fallback, risks, and next implementation skill.

## Recovery paths

If the idea is broad, reduce it to one conversational job and one representative success path.

## Stop conditions

Stop before implementation when the design inputs or product fit are unresolved.

## Handoff contract

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.

View saved version →

---
name: embedding-mcp-assistants
description: "Use when embedding a Noodle assistant into an existing SaaS or web application with browser, identity, session, and credential boundaries."
---

<!-- noodle-skill version:0.62.1 hash:cc54a67f21c0ecdb -->

# embedding-mcp-assistants

Deliver the requested assistant embed with identity and credential separation proven at the tested level.

## Use when

- Embed the Noodle assistant in an existing web app.
- Wire browser mounting and session exchange.

## Do not use when

- Do not use to build a standalone MCP App.
- Do not use when the request is only server authoring or deployment.

## Required inputs

- Application origin and mounting point.
- Desired built-in or custom browser experience.
- Identity/session boundary.
- Requested local or hosted evidence level.

## Workflow

Read and follow the canonical playbook `references/embedded-assistant.md` at `../noodle-seed/references/embedded-assistant.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.

## Verification evidence

The embed works at the requested boundary without forwarding inbound credentials to business backends.

## Recovery paths

Localize failures to origin, session exchange, browser mount, MCP surface, or hosted configuration.

## Stop conditions

Stop when unavailable identity, origin, or hosted authority blocks the next evidence layer.

## Handoff contract

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.

View saved version →

---
name: executing-noodle-plans
description: "Use when the user asks to execute an approved, decision-complete implementation plan for a Noodle Seed project task by task with test-first changes, review, recovery, and final verification."
---

<!-- noodle-skill version:0.62.1 hash:6a9f132ddb79352e -->

# Execute a Noodle Seed implementation plan

Execute an approved plan without reopening settled design decisions. Keep implementation, review, and evidence scoped to the current repository and the authority the user granted.

## Preconditions

- Read the plan, repository instructions, current branch status, and the files named by the first incomplete task.
- Confirm the plan is decision-complete, test-first, compatible with the current code, and explicit about public contracts and required verification.
- Work in the repository-required isolated branch or worktree and preserve unrelated changes.
- If current code invalidates the plan or two requirements conflict, stop before editing and ask which requirement governs.

## Task loop

Execute one task at a time in plan order:

1. Restate the task boundary, expected behavior, focused failing test, and files in scope.
2. Add or update the focused test first and run it to confirm the expected failure when practical.
3. Implement only the behavior required to make that test pass. Do not add compatibility paths, abstractions, or adjacent cleanup the plan did not require.
4. Run the focused test, then the package-level checks named by the plan.
5. Review the task diff for plan compliance, correctness, security, type safety, and unnecessary surface area.
6. Record completion in the plan checkbox when it is writable and in a focused conventional commit.

When the active host provides isolated task workers and user authorization permits delegation, use a fresh implementer for an independent task and a separate reviewer after it. Give each worker only the task requirements, binding global constraints, file paths, and required evidence. Never run workers in parallel when their files or contracts overlap. Execute inline when workers are unavailable, tasks are tightly coupled, or delegation is not authorized.

## Review and recovery

- Independent review must compare the task requirements with the exact task diff and test evidence; implementer self-review does not replace it when a reviewer is available.
- Return concrete findings to the implementer, rerun the tests that cover each correction, and review the correction diff again.
- Allow at most three correction rounds for the same finding. Then stop with the unresolved requirement, attempted fixes, and current evidence instead of silently accepting drift.
- On context loss or interruption, resume from the plan checkboxes, git status, and git log; verify the last completed task before starting the first incomplete one.

## Completion

- Review the complete branch diff against the plan and all accepted design constraints.
- Run the focused tests, affected package checks, generated-surface checks, and the repository readiness gate.
- For Noodle application behavior, also run the validation, test, check, preview, or hosted evidence level selected by the owning Noodle Seed build or verification skill.
- Report commits, evidence, residual risk, and the first unproven layer. Do not claim deployment, publication, merge, or production behavior that was not performed.
- Hand delivery to the repository workflow; executing a plan does not itself authorize merge, deploy, publication, or other external mutation.

## Stop conditions

- Stop before implementation when the plan is incomplete or stale in a way that changes behavior, architecture, security, or public contracts.
- Stop after three unsuccessful correction rounds on the same load-bearing finding.
- Stop before any external mutation or destructive action outside the user-authorized task boundary.

View saved version →

---
name: publishing-mcp-integrations
description: "Use when preparing, reviewing, or submitting a Noodle Seed MCP integration to a host or app directory."
---

<!-- noodle-skill version:0.62.1 hash:efffbf82007f935d -->

# publishing-mcp-integrations

Produce complete submission evidence with host-review uncertainty stated explicitly.

## Use when

- Prepare this MCP integration for a directory.
- Review or submit the host listing.

## Do not use when

- Do not use for ordinary deployment.
- Do not submit when the user requested preparation or review only.

## Required inputs

- Target directory.
- Current deployment and verification evidence.
- Requested review, preparation, or submission boundary.

## Workflow

Read and follow the canonical playbook `references/publishing.md` at `../noodle-seed/references/publishing.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
Load `references/app-directory-compliance.md` at `../noodle-seed/references/app-directory-compliance.md` only when the playbook or observed evidence names that concern.

## Verification evidence

Required product, policy, deployment, media, and test evidence is present or explicitly missing.

## Recovery paths

Return missing implementation or evidence to its owning skill without restarting discovery.

## Stop conditions

Stop before external submission without explicit user authorization.

## Handoff contract

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.

View saved version →

---
name: reporting-noodle-feedback
description: "Use when a Noodle Seed bug, misleading instruction, missing capability, or concrete product improvement should be proposed to the user."
---

<!-- noodle-skill version:0.62.1 hash:0f404109f4845683 -->

# reporting-noodle-feedback

Preview one sanitized feedback proposal and submit it once only after informed explicit approval.

## Use when

- Report a Noodle Seed bug or documentation gap.
- Propose a concrete Noodle product improvement.

## Do not use when

- Do not use for generic project bugs.
- Do not send customer code, identifiers, logs, or secrets.

## Required inputs

- One distinct finding.
- Sanitized observed and expected behavior.
- User approval for the exact dry-run preview and live command.

## Workflow

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.

## Verification evidence

The user saw the exact sanitized preview, diagnostics, destination, and live command; only a returned reference proves submission.

## Recovery paths

If login or rate limits block the one live submission, report that nothing was sent. A recording failure has an unknown outcome: report no reference and never auto-login or retry-loop.

## Stop conditions

Stop after the local dry-run and before the live command until the user explicitly approves it.

## Handoff contract

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.

View saved version →

---
name: verifying-mcp-delivery
description: "Use when proving a Noodle Seed MCP project works at a named compile, local, connector, App, host, deployment, or production evidence level."
---

<!-- noodle-skill version:0.62.1 hash:6ef6ef551e26b78e -->

# verifying-mcp-delivery

Report the highest evidence level actually rerun without upgrading weaker proof.

## Use when

- Verify this MCP delivery before handoff.
- Prove which delivery layers currently pass.

## Do not use when

- Do not use as a substitute for fixing a known failure.
- Do not infer hosted health from local success.

## Required inputs

- Requested evidence level.
- Current target.
- Existing evidence and its freshness.

## Workflow

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.
Load `references/test-in-hosts.md` at `../noodle-seed/references/test-in-hosts.md` only when the playbook or observed evidence names that concern.

## Verification evidence

Every dependency below the requested level passes now, or the first unproven layer is explicit.

## Recovery paths

Hand a concrete failing layer to debugging-mcp-delivery with all passing evidence preserved.

## Stop conditions

Stop after the requested level passes or the first bounded failure is isolated.

## Handoff contract

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.

View saved version →

---
name: wrapping-existing-applications
description: "Use when an existing application has no stable usable API and needs a read-only, identity-first Noodle Seed integration plan before implementation."
---

<!-- noodle-skill version:0.62.1 hash:eccc3c158dcafba8 -->

# wrapping-existing-applications

Produce the smallest safe, repository-grounded existing-application integration plan before any mutation.

## Use when

- Plan how to wrap an existing application that has no usable public API.
- Map internal application capabilities into an approved Noodle Seed implementation plan.

## Do not use when

- Do not use when all four API-evidence inputs exist—an API base URL, authentication scheme, representative safe read, and observed response; use `connecting-apis-to-mcp`. Missing, stale, inaccessible, undocumented-only, or otherwise unusable API evidence remains in `wrapping-existing-applications`.
- Do not use to execute an approved plan, diagnose a concrete failure, or mutate hosted state.

## Required inputs

- Repository scope and requested stopping point.
- Target user jobs.
- End-user identity provider and caller population.
- One static preconfigured downstream origin, or a routing blocker and owning-workflow handoff.

## Workflow

Read and follow the canonical playbook `references/wrap-existing-app.md` at `../noodle-seed/references/wrap-existing-app.md`. It owns the workflow; do not recreate it here or load the command catalog speculatively.
Load `references/authoring-workflow.md` at `../noodle-seed/references/authoring-workflow.md` only when the playbook or observed evidence names that concern.
Load `references/tool-design.md` at `../noodle-seed/references/tool-design.md` only when the playbook or observed evidence names that concern.

## Verification evidence

A sanitized capability map and repository-scoped plan state identity, authorization, routing, application changes, tool budget, tests, blockers, and the first unproven layer.

## Recovery paths

With a stable origin but no safe stable HTTP boundary, plan the smallest application-owned stable HTTPS adapter over existing business functions. If a safe live verification input or working credential is missing, leave that evidence explicitly unproven and name the exact prerequisite. Only multi-origin routing or no stable HTTP origin blocks and hands off to the existing owning routing workflow.

## Stop conditions

Stop after presenting the draft plan and before any file or hosted mutation until the user explicitly authorizes the exact next action and target.

## Handoff contract

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.