Skip to content
Back to skills

Tedix Delegate

ASecurity

Delegate a user-requested task to Tedix Home or a named tedi and follow its durable run. Use for tedi help, handoff, or existing run progress; not for a direct tool read or local harness admission.

  • 2 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added October 9, 2026
ai-agentsgo

Works with

  • cursor
  • terminal
  • cli

Security analysis

A100/100

Scanned October 9, 2026

npx -y skills add tedix-hq/tedix --skill tedix-delegate --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Tedix Delegate?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Tedix Delegate
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/tedix-hq-tedix-delegate/badge)](https://www.skillsdirectory.com/skills/tedix-hq-tedix-delegate)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: tedix-delegate
description: Delegate a user-requested task to Tedix Home or a named tedi and follow its durable run. Use for tedi help, handoff, or existing run progress; not for a direct tool read or local harness admission.
---

# Ask a tedi and follow the result

Use the authenticated native Tedix plugin connection. No CLI is required.
Honor an explicit user surface or repository CLI policy; `tedix ask` is the
CLI entry to the same durable Home path. Authentication failures go through
`tedix-connect`.

Before dispatch, distinguish an available callable from actual permission to
submit it. If the connection is read-only or the dispatch capability is denied,
do not submit or silently broaden consent. Offer a bounded read of an existing
run the user identified, or prepare handoff text in this chat. Name the missing
capability from the returned access check and explain the normal owner consent
step when the user wants dispatch. A handoff draft is not a queued run.

1. Keep the intended organization and the user's requested outcome. Discover
   the exact callable with a compact `discover.search` in that organization
   namespace, then load only its schema with `discover.describe(callable)`.
   The direct gateway calls it `home.ask`; Connect can expose
   `enqueue_kernel_runtime_message` under the organization namespace. Use the
   returned callable and parameters, including a stable `idempotencyKey` when
   supported. Never assume a literal `home` namespace on Connect.
   Usually omit the delegate and let Home route. Resolve a requested tedi to
   its real ID through a bounded read, never from an email or display name.
2. Send only the authorized task and relevant context. State the expected
   result and any user limits in `content`. Preserve a selected conversation
   or an earlier dispatch receipt when continuing the same task. For a new
   task, use a stable task-scoped conversation ID when the discovered schema
   supports it; omission does not prove caller isolation. Do not reuse a shared
   conversation merely because another request returned it. Supply the exact
   verified `workspaceContext` when the task belongs to a Workspace; never
   inherit an unrelated Workspace as the destination. Use `home:main` only
   when explicitly requested. Reading status is not
   permission to dispatch, approve a plan, or send another message.
3. Record the returned run/conversation IDs and report queued/running status
   as such. Discover the run-status and event readers for that exact run;
   inspect their source/schema rather than guessing names from the router.
   The direct gateway uses `read_home_run` and `read_home_run_events`; Connect
   can expose `read_run` and `read_run_events`. Read bounded event pages and
   carry the returned
   cursor (`stream.nextOffset` on Home) into the next page; use supported
   bounded long polling when caught up. Do not replay the dispatch to poll or retry
   an ambiguous submission: inspect its receipt first.
4. Read the run's terminal status and result before reporting completion.
   A successful status read or completed transcript row does not prove a
   successful run. If the status reader is unavailable, discover the mapped
   `read_run_trace` reader: `trace.status` is the run outcome, while
   `trace.complete` describes trace assembly. Use transcript reads for the
   answer, not as a replacement for run status. An `observe_only` dispatch
   returns a routing observation; it does not prove an ordinary Home answer.
   Report the worker's result, evidence and remaining action. A dispatch
   receipt is not completion; a worker's success message is a claim. Read a
   named Work Item or Output revision when the outcome depends on it. A plan
   awaiting approval stays pending; use the discovered approval flow only
   when authorized and acting as its actual approver. Keep budget, provider,
   scope, and policy errors explicit rather than promising eventual success.

User OAuth lets the user request work from Tedix workers. It does not make
this chat that worker or grant an external coding harness an Attempt. Do not
create a local executor identity merely to delegate. For an existing local
Work execution request use `tedix-resume-work` instead.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.