Arez

View saved version →

---
name: arez-help-mcp
description: Use Arez Help for grounded public product guidance and, for authorised users, the correct FieldIQ or Operate workflow from operational triage through confirmed actions.
---

# Arez Help

<!-- noodle-app-package source:716019b97772c97744ae5d83305a5912498a80951fe5b757d1fc3fcc26fa6cce surface:f4c1c735858771f2221912fea11e24dd50363b854b4882bf51d0405a052e9a05 -->

## When to use this product
- The user asks how Arez works or asks an Arez product capability question.
- A signed-in Arez user asks about operational attention, jobs, visits, notes, assets, reports, RFQs, suppliers, quotes or quotations, or Operate rotas.

## Workflows

### Answer a documented Arez product question

1. `tool:search_arez_knowledge` — Use for how-to or capability questions, not a request to perform an action on a specific record. Search the original question with a focused phrase; use at most three materially different searches. (read-only; idempotent)
2. `tool:get_arez_knowledge` — Retrieve selected results once and answer only from returned official content with source URLs. (read-only; idempotent)

### Check the signed-in account product

1. `tool:get_workspace_capabilities` — Use first when private account access is not established. If the requested product is unavailable, state its returned message and stop. (read-only; idempotent)

### Show FieldIQ operational attention

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:get_action_required` — Use for a general actionable backlog. For “this morning” use get_morning_risk_brief; for overall health use get_operational_overview; for SLA-only questions use show_sla_risks. (read-only; idempotent)

### Show FieldIQ operational health

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:get_operational_overview` — Use for overall operational health, company status, or a management snapshot; do not use it as an actionable task list. (read-only; idempotent)

### Show FieldIQ SLA risks

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:show_sla_risks` — Use for approaching or missed SLA deadlines and late attendance, not a general overdue-job list. (read-only; idempotent)

### Show overdue FieldIQ jobs

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:show_overdue_jobs` — Use for an overdue-job list; pass YYYY-MM only for a requested past calendar month. (read-only; idempotent)

### Find a FieldIQ job and show its summary

1. `tool:get_workspace_capabilities` — Always call first and stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:search_sites` — Use only when resolving a named site for a job list. (read-only; idempotent)
3. `tool:search_jobs` — Use only for a list or when the exact job number is unknown; skip for a known exact job number. (read-only; idempotent)
4. `tool:get_job_summary` — Call directly for a known exact job number, or after the user selects one returned job. (read-only; idempotent)

### Explain one job status

1. `tool:explain_job_status` — Use the exact job number and only recorded blockers, stage durations, and SLA trace; do not infer a cause. (read-only; idempotent)

### Create a FieldIQ job

1. `tool:start_job_creation` — Open the review form for a create, add, raise, log, or open-job request; a blank form is valid and writes nothing. (read-only; idempotent)
2. `tool:create_job` — Create only after the user reviews and confirms the form; report the action result. (write; confirmation required)

### Edit a FieldIQ job

1. `tool:start_job_editing` — Open the prefilled form for one exact job; this writes nothing. (read-only; idempotent)
2. `tool:update_job` — Send only reviewed title, description, category, or priority changes after confirmation; use add_note separately for notes. (write; destructive; confirmation required)

### Review one FieldIQ site

1. `tool:search_sites` — Resolve one unambiguous site from the user wording; ask the user to choose if multiple match. (read-only; idempotent)
2. `tool:get_site_summary` — Show only the selected site’s recorded work, visits, risks, and compliance alerts. (read-only; idempotent)

### Show job notes

1. `tool:get_notes` — Use for notes, comments, or recorded updates on one exact job number. This read does not add a note. (read-only; idempotent)

### Add a job note

1. `tool:add_note` — Append only after the user reviews the exact job number and note text and confirms. (write; confirmation required)

### Show job visits

1. `tool:get_visits` — Use for scheduled, planned, or recorded visits on one exact job number. This read does not schedule a visit. (read-only; idempotent)

### Schedule a job visit

1. `tool:start_visit_creation` — Use only for an explicit add, create, book, or schedule visit request; it opens a form and writes nothing. (read-only; idempotent)
2. `tool:add_visit` — Create only after the user reviews the visit details and confirms. (write; confirmation required)

### Review asset evidence and reporting

1. `tool:search_assets` — Resolve the asset first; for a named site, resolve the site before its assets. (read-only; idempotent)
2. `tool:get_asset_failure_history` — Use for repeat failures, breakdowns, reactive history, or cost trends. (read-only; idempotent)
3. `tool:get_engineer_reports` — Use for engineer, technician, or service findings. Treat symptoms as evidence, not diagnoses. (read-only; idempotent)

### Review asset status and risk

1. `tool:search_assets` — Resolve the asset first; resolve a named site with search_sites before searching its assets. (read-only; idempotent)
2. `tool:get_asset_summary` — Use for current status, safety, risk, compliance, and next maintenance. (read-only; idempotent)
3. `tool:get_asset_history` — Use only when the user asks for recorded status or risk changes over time. (read-only; idempotent)

### Find a worker or engineer

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:search_workers` — Use to resolve a worker, engineer, staff member, or operative for a later job or visit request; it does not assign work or change a rota. (read-only; idempotent)

### Find a named supplier or contractor

1. `tool:get_workspace_capabilities` — Stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:search_suppliers` — Use only when the user names a specific supplier. For a general request to send an RFQ to suppliers, open start_rfq_creation instead so the user selects them in the form. (read-only; idempotent)

### Show the signed-in user’s Operate rota

1. `tool:get_workspace_capabilities` — Always call first and stop if Operate is unavailable. (read-only; idempotent)
2. `tool:get_today_rota_summary` — Use for today’s rota or rota-stat questions. Preserve returned counts and attendance states; do not infer coverage or availability. (read-only; idempotent)

### Show the signed-in user’s morning priorities

1. `tool:get_workspace_capabilities` — Always call first and stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:get_morning_risk_brief` — Preserve the live returned counts and site names; do not invent a fixed total. (read-only; idempotent)

### Review RFQ supplier responses

1. `tool:search_rfqs` — Resolve the exact RFQ first. A best-quote, submitted-cost, supplier-response, or comparison request cannot end here. (read-only; idempotent)
2. `tool:review_rfq_responses` — Always call after search_rfqs for response comparison. With no submitted cost lines, state that no best value exists and present Open RFQ in Arez. This review does not accept a response. (read-only; idempotent)

### Show RFQ details

1. `tool:search_rfqs` — Resolve the exact RFQ first; for best-quote or response comparison instead follow rfq_response_review. (read-only; idempotent)
2. `tool:get_rfq_details` — Show the selected RFQ’s returned scope, invitations, deadline, and response state without accepting a response. (read-only; idempotent)

### Accept a reviewed RFQ response

1. `tool:search_rfqs` — Resolve the exact RFQ unless its ID is already known from a prior lookup. (read-only; idempotent)
2. `tool:review_rfq_responses` — Show the submitted responses before a decision. (read-only; idempotent)
3. `tool:accept_rfq_response` — Use only when the user explicitly asks to accept one response and confirms the reviewed choice. Acceptance does not create a FieldJob. (write; destructive; confirmation required)

### Create a FieldJob from a reviewed RFQ response

1. `tool:search_rfqs` — Resolve the exact RFQ unless its ID is already known from a prior lookup. (read-only; idempotent)
2. `tool:review_rfq_responses` — Review the selected submitted response and any existing acceptance or conversion. (read-only; idempotent)
3. `tool:accept_rfq_response` — Use only if a response is not yet accepted and the user confirms the selected response; skip if it is already accepted. (write; destructive; confirmation required)
4. `tool:create_field_job_from_rfq` — If the discussed quote came from this RFQ, use this tool, not search_logquotes. Convert only after acceptance and a separate user confirmation; never duplicate a conversion. (write; destructive; confirmation required)

### Prepare and send an RFQ

1. `tool:get_workspace_capabilities` — Always call first and stop if FieldIQ is unavailable. (read-only; idempotent)
2. `tool:start_rfq_creation` — Open the supplier-selection form for one exact source job; it creates nothing. (read-only; idempotent)
3. `tool:create_rfq` — Create and send only after the user confirms the reviewed supplier selection. (write; destructive; open-world; confirmation required)

### Review a standalone quote or quotation

1. `tool:search_logquotes` — Use for a standalone LogQuote, not the discussed RFQ response. Resolve its exact ID unless already known. (read-only; idempotent)
2. `tool:get_logquote_details` — Show the amount, lines, status, and any existing FieldJob. A review request does not accept or convert the quote. (read-only; idempotent)

### Create a FieldJob from a standalone quote or quotation

1. `tool:search_logquotes` — Use only for a standalone LogQuote, not the discussed RFQ response. Resolve its exact ID unless already known. (read-only; idempotent)
2. `tool:get_logquote_details` — Review amount, lines, status, and decision before any write. (read-only; idempotent)
3. `tool:accept_logquote` — Use only when the quote is outstanding and the user confirms acceptance; skip when it is already accepted. (write; destructive; confirmation required)
4. `tool:start_logquote_job_creation` — Open the FieldJob review form only after the quote is accepted. (read-only; idempotent)
5. `tool:create_field_job_from_logquote` — Create only after the user confirms the reviewed FieldJob details. (write; destructive; confirmation required)

### Reject a standalone LogQuote

1. `tool:search_logquotes` — Resolve the exact standalone LogQuote, not an RFQ response. (read-only; idempotent)
2. `tool:get_logquote_details` — Show amount, lines, and status before a decision. (read-only; idempotent)
3. `tool:reject_logquote` — Reject only after the user confirms the reviewed decision; report the action result. (write; destructive; confirmation required)

### Review a client across sites

1. `tool:search_sites` — Resolve the selected site and its client; do not guess a client ID. (read-only; idempotent)
2. `tool:get_client_review_pack` — Pass the resolved client and explicit inclusive dates; report returned costs and current open items. (read-only; idempotent)

### Review contract performance

1. `tool:get_contract_performance` — Use only an ID supplied by the user or authoritative lookup and explicit inclusive dates; never guess either. (read-only; idempotent)

## Boundaries
- Public knowledge answers must be grounded in retrieved official content and include the source URLs used.
- Private FieldIQ and Operate data requires a signed-in, authorised account. State the capability message and stop when the requested product is unavailable.
- Never guess an internal ID, job number, supplier, site, asset, or quote. Present ambiguous matches and ask the user to choose.
- Persistent FieldIQ actions require explicit user confirmation; never claim success without the action result, and never duplicate a quote or RFQ conversion.
- Never expose raw internal identifiers, raw app URLs, or another user’s private data.

## Examples
- “How do I add a visit to a job in Arez?” — use `product_guidance`.
- “What needs attention across the business?” — use `fieldiq_operational_attention`.
- “What are the urgent issues we need to deal with?” — use `fieldiq_operational_attention`.
- “Which work is blocked or slipping?” — use `fieldiq_operational_attention`.
- “How are operations doing overall?” — use `fieldiq_operational_overview`.
- “Give me a management view of current operational health.” — use `fieldiq_operational_overview`.
- “Which jobs are close to missing SLA?” — use `fieldiq_sla_risks`.
- “What work is overdue?” — use `fieldiq_overdue_jobs`.
- “Find jobs at Victoria Street Offices.” — use `fieldiq_job_lookup`.
- “Show the notes on job J000242.” — use `fieldiq_job_notes`.
- “Add this note to job J000242.” — use `fieldiq_add_note`.
- “Show visits for job J000242.” — use `fieldiq_job_visits`.
- “Book an engineer visit for this job.” — use `fieldiq_schedule_visit`.
- “Find an engineer called Sam.” — use `worker_resolution`.
- “Find supplier Acme Electrical.” — use `supplier_resolution`.
- “Show the engineer reports for the pump at CORAL.” — use `asset_reporting`.
- “Why does this asset keep breaking down?” — use `asset_reporting`.
- “What rotas are there today?” — use `operate_rota_summary`.
- “Who is working today?” — use `operate_rota_summary`.
- “Which supplier gave the best quote for RFQ-000237?” — use `rfq_response_review`.
- “Have any suppliers responded to this RFQ?” — use `rfq_response_review`.
- “Accept the submitted quote for this RFQ.” — use `rfq_response_acceptance`.
- “Turn this accepted RFQ quote into a job.” — use `rfq_to_fieldjob`.
- “Raise an RFQ from job J000242.” — use `rfq_creation`.
- “I need quotes from contractors for this job.” — use `rfq_creation`.
- “Show me the price and status of quotation Q00042.” — use `quote_review`.
- “Accept quotation Q00042 and create the FieldJob.” — use `quote_to_fieldjob`.
- “Turn this approved LogQuote into a job.” — use `quote_to_fieldjob`.
- “Add a visit to job J000242.” — use `fieldiq_schedule_visit`.
- “Why is job J000242 on hold?” — use `fieldiq_job_status_explanation`.
- “Create a job for this site.” — use `fieldiq_job_creation`.
- “Change the priority of job J000242.” — use `fieldiq_job_editing`.
- “How is the CORAL site doing?” — use `fieldiq_site_review`.
- “What is the current status of this pump?” — use `asset_status_review`.
- “Show this asset’s recorded risk changes.” — use `asset_status_review`.
- “Show the scope and deadline for RFQ-000237.” — use `rfq_details`.
- “Reject this outstanding LogQuote.” — use `quote_rejection`.
- “Review this client’s sites for the selected period.” — use `client_review`.
- “Show performance for this contract over the selected period.” — use `contract_review`.

## MCP surface

[Read the MCP surface reference.](references/mcp-surface.md)

Referenced files: 1 — file references are metadata, not package contents.

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.