---
name: forjal-local-delegation
description: Use when the user explicitly asks to use, delegate work to, connect, or troubleshoot Forjal, including requests in Portuguese such as "use a Forjal", "delegue para a Forjal", or "conecte a Forjal". Coordinates an existing desktop-managed Forjal MCP connection; it does not install or start the local runtime itself.
compatibility: Requires the Forjal desktop app and its managed local MCP connection.
---

# Delegate work through Forjal

Forjal is a local execution layer for an agent the user already uses. The current agent remains responsible for planning, any external tools, and the final review. Forjal never silently chooses or substitutes a model.

## Treat the live connection as authoritative

Use the instructions and tool schemas exposed by the connected Forjal MCP server as the source of truth for:

- available tool names and arguments;
- current model identifiers and lifecycle labels;
- workspace permission modes;
- asynchronous run handling;
- returned evidence, files, commands, warnings, and next actions.

This skill supplies coordination policy, not a duplicate of the server contract. If the live schema conflicts with an example here, follow the live schema.

## Pass the connection gate

Before delegating, confirm that the current client exposes the Forjal tools. Common tool names include `get_forjal_status`, `list_forjal_models`, `run_local_model`, `await_local_model_run`, `resume_local_model_run`, and `cancel_local_model_run`, but do not require every name or invent a missing tool.

If the connection is absent:

1. Do not fabricate a Forjal result or fall back to an unrelated model while calling it Forjal.
2. Explain that this package does not bundle the local runtime or a static MCP command.
3. Ask the user to install or open the Forjal desktop app, connect the current client from **Connections**, and restart or reload the client.
4. Use [references/connection-setup.md](references/connection-setup.md) for concise recovery guidance.

## Decide whether to delegate

Delegate only a bounded part of the user's task. Good candidates include a first-pass review, classification, extraction, summarization, test-case generation, or a draft that the supervising agent can verify.

Keep these responsibilities with the supervising agent:

- final judgment and user-facing answer;
- network access, URLs, accounts, credentials, and secrets;
- external tools the supervisor declared;
- actions outside directories and permissions explicitly granted to Forjal.

Do not pass credentials or unrelated sensitive material into a local-model prompt.

## Select a model explicitly

Inspect the live model list or tool schema when selection is needed. Choose a concrete `model_id` that fits the requested capability and is actually available.

Preserve the distinction between `candidate`, `compatible`, and `certified`. Never describe a model as "best" merely because of its size, hardcode one model for every task, or silently replace the selected model. If no suitable model is available, state the limitation.

## Grant the least workspace access

Start with no workspace access unless files are necessary. When they are:

- use `read` for analysis that must not change files;
- use `write` only when the user asked for file changes, and scope it to the declared directories;
- use `run` only when the task requires a command supported by Forjal's allowlist.

Name only relevant files. Do not broaden a directory scope for convenience. The live tool schema defines the exact request shape.

## Submit and follow one run

Write a self-contained prompt with the bounded objective, relevant context, constraints, expected output, and verification criteria. Then call the live execution tool once.

If the response returns a run identifier or a pending state, follow the server's `next_action` and resume or await that same run. A client timeout is not evidence that execution failed. Do not submit a duplicate run merely because the first call is still pending.

## Review before using the result

Treat local output as untrusted draft material. Check it against the user's request and the returned evidence. For workspace-enabled runs, account for every reported file read or written and every command executed. Use [references/review-checklist.md](references/review-checklist.md) when the run changes files, executes commands, or reports a shortfall.

If evidence is missing, narrow the claim, verify it with the supervisor's tools, or tell the user what remains uncertain. Never present an incomplete local answer as verified.

## Report clearly

Reply in the user's language. Briefly state:

- what was delegated;
- which explicit model was used, when the live result identifies it;
- what access was granted;
- what the supervising agent verified;
- any shortfall, warning, file change, or executed command that matters.

Do not make quantified savings, universal privacy, or universal offline claims unless the current evidence directly supports them.