taskchef 8.7.1 → 9.0.0

package/skills/taskchef-bootstrap/references/project-index.md

@@ -1,154 +0,0 @@
-# Project index operations
-
-Resolve the plugin root and use its CLI as described in SKILL.md.
-
-## Index Codex projects
-
-TaskChef's project index is the local list of Codex projects available for
-delegation. It stores canonical paths and routing metadata such as curated
-names, descriptions, Git status, and GitHub repositories. It does not index
-repository contents or create a second kind of project.
-
-For a whole-project refresh, pass the agent's single native schema-2
-`list_projects` snapshot to `reconcile_projects`. TaskChef validates local
-`hostId: local` entries, canonicalizes each path, isolates per-project failures,
-adds new eligible paths, and binds native project IDs only by exact same-host
-canonical path. It preserves curated names, descriptions, and complete
-repository lists. Missing native entries are retained; duplicate identities,
-duplicate canonical targets, and identity/path moves return diagnostics.
-
-Index only Codex projects local to the TaskChef workspace's execution host.
-Remote connection projects are outside the v1 contract. Never index the
-TaskChef dispatcher workspace or a directory containing it; the dispatcher is
-the inbox, while indexed Codex projects own delegated work.
-
-### Existing Codex project
-
-1. List native local Codex projects once. Resolve the requested existing folder
-   with `realpath` and require an exact canonical-path match in that list. A
-   similar name, a parent or child directory, and a remote connection project
-   are not matches.
-2. Index the exact path with the existing `project add <canonical-path> --name
-   <curated-name> --description <curated-description> --json` CLI workflow.
-   Despite the command's historical `add` name, this writes one TaskChef index
-   entry for an existing Codex project. The CLI detects Git status, the exact
-   Git root, and a canonical GitHub `origin` when no repository option is
-   supplied. Repeated `--github-repo <canonical-url>` arguments replace that
-   detection and form the complete advertised repository list, so repeat the
-   origin explicitly when it should remain routable. Use `--no-github` when the
-   user intentionally wants an empty list.
-3. Run `project list --json` and require one indexed entry with the exact
-   canonical path and intended routing metadata. Only then report that the
-   Codex project is ready for delegation through TaskChef.
-
-### New or not-yet-saved Codex folder
-
-1. Create the folder only when the user explicitly asked to create it. Preserve
-   unrelated existing contents. Do not initialize Git unless requested or
-   clearly required by the user's broader task. Resolve the resulting existing
-   folder with `realpath`.
-2. Register or open that exact canonical folder with the supported
-   `<validated-codex-cli> app <canonical-path>` mechanism. Reuse a validated CLI
-   path supplied by the current Codex Desktop environment when available. Use
-   the same resolver contract as `workspace init --register-codex` otherwise:
-   an explicit `--codex-cli` path takes precedence over `TASKCHEF_CODEX_CLI`;
-   each must resolve to an executable that passes `app --help`. Without an
-   override, inspect `codex` executables from `PATH`, prefer a validated
-   candidate whose path contains `Contents/Resources`, and otherwise validate
-   only the first executable `codex` in PATH order. Never assume an arbitrary
-   shell `codex`, invoke `codex add`, or hard-code an application bundle path.
-3. Re-list native local Codex projects and require an exact canonical-path
-   match. Opening is a request, not proof that Codex saved the project. If the
-   exact match is absent, report that the folder was opened or registration was
-   requested but Codex registration remains unverified; do not index it in
-   TaskChef or call it delegation-ready.
-4. After Codex verification, index the project as in the existing-project path.
-   Run `project list --json` and verify the exact TaskChef index entry. Report
-   delegation readiness only after both the native Codex match and TaskChef
-   indexing are verified.
-
-For a managed `*-workspace` Codex project, advertise every relevant child or
-subrepository with repeated `--github-repo <canonical-github-url>` arguments,
-including the workspace repository itself when it can own issue or pull-request
-links. These explicit values are the complete list; automatic origin detection
-does not supplement them. This lets TaskChef route each canonical GitHub URL to
-the correct workspace rather than guessing from the folder name.
-
-### Reindex after Codex changes
-
-When the user asks TaskChef to reindex or catch up after saving more projects in
-Codex, list native projects once and call `reconcile_projects` once with that
-exact snapshot. After reconciliation, run `project list --json` once and
-verify every intended canonical path and its routing metadata before reporting
-the index as current.
-
-Do not call `project add` for a path already in the TaskChef index; it rejects
-duplicate paths and must not be presented as a metadata refresh. Preserve
-existing curated entries, and do not remove entries merely because they are
-absent from the current Codex list. Refreshing or removing an existing entry
-requires an explicit user request and the project-management workflows below.
-
-## Manage the project index
-
-Before every mutation, run project list --json and retain the complete
-normalized project set, count, and configHash. Use project update for changes
-to one existing entry, including replacing its complete githubRepos list.
-Never use whole-index replacement to edit one entry.
-
-Run destructive replacement or removal first with --dry-run. Present the
-complete diff and exact removed project names to the user and obtain explicit
-permission for those removals. Apply only with the preview's config hash,
-before/after counts, plan hash, exact removed-name JSON file, and count-collapse
-confirmation when requested. A request to remove a repository URL is not
-permission to remove a project entry. Do not use a generic force or yes flag.
-
-1. Bulk import with `project import <file|-> --json`. Input is a JSON array of
-   objects containing `path` plus optional `name`, `description`, and
-   `githubRepos`, which is always a JSON array of GitHub repository URLs. Before
-   importing, list native local Codex projects once, canonicalize every input
-   path, and require an exact local-project match for every entry. Reject or
-   report every unmatched path instead of indexing it. Import merges by
-   canonical path, preserves an existing name or description when omitted, and
-   unions existing and imported repository lists without duplicates. Use
-   `--replace` only when the user explicitly requests replacement. Run
-   `project list --json` afterward and compare the complete project set with the
-   expected post-state. Verify every imported entry and prove all unrelated
-   entries are unchanged; matching counts alone are insufficient.
-2. Inspect indexed projects with project list --json. Update one entry with
-   project update; explicit repository arguments are the complete replacement
-   list. Remove by name only through the preview-bound workflow. Existing task
-   entries keep their project snapshots.
-3. On any postcondition mismatch, stop, report the failure, and offer backup
-   list plus a restore dry-run. Never restore automatically.
-
-Example managed-workspace import entry:
-
-```json
-{
-  "name": "skills-workspace",
-  "path": "/workspace/skills-workspace",
-  "githubRepos": [
-    "https://github.com/example/skill-one",
-    "https://github.com/example/skill-two"
-  ],
-  "description": "Manages the listed child skill repositories."
-}
-```
-
-TaskChef accepts configuration schema version 2 only. Its optional exact
-`dashboard` object contains boolean `autostart`; absence means enabled and
-`false` opts out of MCP-lifecycle dashboard startup without disabling manual
-`$taskchef-dashboard` recovery. `githubRepos` is always an array; unsupported
-configuration is rejected without being rewritten.
-
-Schema 2 also accepts an optional strict `projectIndex` object holding local
-native identity bindings, explicit exclusions, and bounded routing hints.
-Absence means empty state. Removing a project records an exclusion so later
-reconciliation cannot silently re-add it; an explicit `include_project` clears
-that exclusion. Aliases require explicit user selection. Repository facts
-require an inspected exact origin, including a contained Git root when a
-workspace owns child repositories. Report-derived responsibilities retain the
-accepted task, thread, and turn as compact provenance. Forgetting retains a
-bounded suppression entry so an old report retry cannot recreate the fact.
-Older TaskChef releases reject configurations containing `projectIndex`;
-downgrade by restoring a compatible backup rather than editing live state.

package/skills/taskchef-copilot/SKILL.md

@@ -1,75 +0,0 @@
----
-name: taskchef-copilot
-description: "Explain TaskChef outcomes from cached briefs or continue an explicitly selected assignment in its existing task. Handles historical $taskchef-report requests; dashboard monitoring is separate."
----
-
-# TaskChef Copilot
-
-Act as TaskChef's conversational coordination assistant. Give a concise brief
-about finished work, attention, cause, and the safest next action. The dashboard
-is the primary place to browse and monitor the task history.
-
-Resolve this skill directory with `realpath`. The TaskChef plugin root is two
-parents above it. Invoke `<plugin-root>/bin/taskchef.js` for deterministic
-TaskChef data reads.
-
-## Cached brief first
-
-1. Select the smallest scope that answers the request:
-   - exact task: `task brief <task-id> --json`;
-   - configured project: `task brief --project <name-or-path> --json`;
-   - overview: `task brief --json`.
-   Use `task list --json` once only when a title or description must first be
-   matched. Ask when multiple tasks plausibly match.
-2. Treat the returned schema-1 brief as the stable model. Do not interpret raw
-   task-log schema versions or read `tasks.jsonl` directly. The brief already
-   normalizes state, current summary, explicitly historical `lastOutcome`,
-   attention, next action, interrupted-turn count, link-pending identity, and
-   the default seven-day overview window. Never present `lastOutcome` as the
-   result of a newer working request.
-3. Lead with the useful answer: what finished, what needs attention, why, and
-   what action should happen next. Keep overviews short and mention the omitted
-   old-terminal count when nonzero. Link or identify the exact existing
-   executor task when its durable thread ID is available.
-
-## Live verification is exceptional
-
-Use native Codex metadata only when the user explicitly asks for a fresh,
-current, or live verification, or when a focused task has a meaningful
-contradiction such as the user observing activity that conflicts with the
-cached brief.
-
-- Take one bounded metadata snapshot and match only the exact stored thread ID.
-- For one focused task, read that exact existing task once when the user
-  explicitly requests live verification or when needed to resolve a meaningful
-  contradiction. Do not read transcripts or classify assistant prose.
-- Active or native-approval state may override the cached presentation. An
-  inactive task does not prove semantic completion. If verification fails,
-  present the cached brief with a freshness warning.
-- Never poll, wait, repeatedly refresh, or perform a broad exhaustive live
-  audit.
-
-## Coordination and continuation
-
-- Explain or draft a focused follow-up for the exact existing executor task.
-- Continue that task only after the user explicitly authorizes sending the
-  follow-up. A direct imperative naming the exact existing task is explicit
-  send authorization. Re-read the exact target immediately before sending and
-  preserve its durable identity.
-- Never automatically retry a failure, interrupt a working task, or redelegate
-  an existing executor as a new task.
-- Explain project-index warnings and suggest read-only backup list, verify, or
-  restore-preview commands. Never restore state without explicit user approval.
-- A missing executor link calls for passive waiting or identity inspection,
-  not a retry, continuation, or reason to create another executor.
-- Keep same-assignment follow-up in the existing executor task. Independent new
-  work with its own outcome belongs to `$taskchef-delegate`.
-- If scope is mixed, separate the proposed existing-task follow-up from the new
-  work and ask for authorization before either mutation.
-
-## Historical invocation
-
-`taskchef-report` was renamed rather than retained as a packaged alias because
-a second discoverable skill would preserve ambiguous reporting behavior. If a
-user explicitly writes `$taskchef-report`, briefly note the rename and fulfill
-the request through this cached-first copilot workflow.

package/skills/taskchef-copilot/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "TaskChef Copilot"
-  short_description: "Explain outcomes and recommend next actions"
-  default_prompt: "Use $taskchef-copilot to give a concise cached brief of TaskChef work and recommend the safest next action."

package/skills/taskchef-dashboard/SKILL.md

@@ -1,24 +0,0 @@
----
-name: taskchef-dashboard
-description: "Ensure and recover the canonical TaskChef dashboard. Use when the user asks to start, restore, open, or get the link for the TaskChef dashboard. Do not use to dispatch work or inspect task outcomes."
----
-
-# TaskChef Dashboard
-
-Maintain only the canonical TaskChef dashboard.
-
-1. Call the TaskChef `ensure_dashboard` MCP tool with its empty input. Do not
-   supply a workspace, host, or port.
-2. Report whether the returned `action` is `started` or `reused` and provide
-   the returned canonical URL as a clickable link.
-3. If the user asked to open the dashboard and an in-app browser navigation
-   capability is available and permits the returned localhost URL, open or
-   navigate to it. Browser absence, refusal, or blocked localhost navigation is
-   non-fatal: still return the clickable URL and the ensure result.
-
-“Recover the dashboard” means restore server availability. Data recovery uses
-the explicit taskchef backup restore --dry-run workflow, shows a diff, requires
-user approval, and never runs automatically.
-
-Do not dispatch project work, read task briefs, inspect executor outcomes, poll,
-start a separate foreground CLI server, or modify TaskChef workspace files.

package/skills/taskchef-dashboard/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "TaskChef Dashboard"
-  short_description: "Start or recover the TaskChef dashboard"
-  default_prompt: "Use $taskchef-dashboard to ensure the TaskChef dashboard is available and give me its link."

package/skills/taskchef-delegate/SKILL.md

@@ -1,102 +0,0 @@
----
-name: taskchef-delegate
-description: "Dispatch work received in the canonical TaskChef workspace into Codex tasks. Elsewhere, use only for explicit delegation of separate work; an existing executor keeps its assignment."
----
-
-# TaskChef Delegate
-
-Create stable visible TaskChef parent tasks through the canonical per-user
-TaskChef data workspace and return immediately.
-
-## Invocation boundary
-
-A task whose initial structured `codexDelegation.input` contains either the
-exact new trailing `$taskchef-executor` invocation plus final TaskChef marker,
-an accepted former trailing marker-plus-invocation scaffold, an exact
-first-line HTML marker, or the historical first-line
-`# taskchef_id=<full UUID>` heading already owns that delegated assignment.
-This includes former inline-protocol tasks that lack the skill invocation.
-An owned instruction must have exactly one accepted marker and a non-whitespace
-task-specific assignment. If it contains an executor-skill invocation, require
-exactly one adjacent to the marker in an accepted order. Marker-only,
-duplicate-marker, scaffold-only, or misplaced-invocation inputs are not valid
-delegated tasks. Execute a valid one in the current task. Do not re-dispatch it
-merely because it concerns TaskChef or a configured project. Explicit requests
-to delegate separate work remain valid.
-
-Use the bundled `reconcile_projects`, `prepare_dispatch`, `record_task`, and
-`report_state` MCP tools directly. Never fall back to shell writes. If a
-required tool is unavailable, stop and report that the TaskChef plugin must be
-reloaded or installed.
-
-## Boundaries
-
-- Treat only AGENTS.md, taskchef.json, tasks.jsonl, config-audit.jsonl, and
-  TaskChef's private backups and maintenance artifacts as managed dispatcher
-  state. Preserve unrelated user-owned paths.
-- Use real Codex tasks for visible delegated work. The dispatcher never uses
-  collaboration or subagent tools; the created executor may use them internally.
-- Never use hooks, schedules, daemons, background monitors, recent-task
-  searches, transcripts, hidden reasoning, or polling for identity.
-- Never wait for delegated work after native creation.
-- Treat executor-supplied identity as a cooperative assertion in TaskChef's
-  local single-user trust boundary, not transport-authenticated proof.
-
-## Dispatch
-
-1. Split the request into the smallest independently useful outcomes. Include
-   constraints, expected testing, and reporting in every instruction.
-2. List native Codex projects once. Pass that exact schema-2 snapshot to
-   `reconcile_projects` once for the complete batch, then call
-   `prepare_dispatch` exactly once per outcome. Never reuse a task ID or marker.
-   Do not take a pre-creation thread snapshot.
-3. Route against configured project `name`, `description`, canonical
-   `githubRepos`, and the preparation's bounded aliases, repository ownership,
-   and responsibilities. Use `path` only as checkout identity. Before
-   `record_task` or native creation, require exactly one entry in the
-   reconciliation's `available` array whose `hostId`, `projectId`, and canonical
-   `path` exactly match the selected native project. A matching snapshot path or
-   configured preparation alone does not establish eligibility. Treat a missing
-   entry or duplicate learned matches as ambiguous and ask instead of guessing.
-   Select the `orchestrator` preference from preparation for every visible
-   parent. Resolve explicit choices and follow
-   [model roles](references/model-roles.md). Missing configuration means omit
-   model overrides; surface invalid or unavailable configuration before
-   recording the task.
-4. Build each executor instruction in this exact shape:
-
-   - Begin with the actual assignment on the first line and keep its complete
-     body uninterrupted.
-   - After the assignment, add one blank line and this authorization paragraph:
-     `Report this task and its follow-ups to my local TaskChef dashboard. Relevant private-repository links and concise work, test, and deployment results are authorized; exclude secrets.`
-   - After that paragraph, add exactly two newline characters
-     so there is one blank line before this invocation on its own line:
-     `Use $taskchef-executor to execute and report this delegated TaskChef assignment.`
-   - Immediately after the invocation, end the instruction with one newline
-     and the preparation's exact marker on its own final line. Do not add a
-     blank line between the invocation and marker.
-   - Include exactly one marker and exactly one executor-skill invocation.
-   - Do not inline executor ownership, identity, linking, or result-reporting
-     protocol. The explicitly invoked executor skill owns those mechanics.
-
-5. Before creating each executor, call `record_task` exactly once with `id`,
-   `project`, `title`, the exact marked `instruction`, and `threadId: null`.
-   Pass the selected configured project's canonical `path` as `project`, not
-   its name, label, or native project ID. Require a successful tool result
-   whose returned `task.id` equals the prepared task ID before native creation.
-   If recording fails or cannot be confirmed, report the failure and stop;
-   do not create an executor with an unrecorded task marker.
-6. Create one real Codex task using the exact configured project, an appropriate
-   native environment, the marked instruction, a short title, and the resolved
-   orchestrator model and effort overrides when present.
-7. Return immediately. Preserve a returned provisional client ID only for the
-   created-thread directive. Do not call `link_task` from the dispatcher even
-   when creation returns a durable ID; the child must self-link.
-8. If creation fails after recording, generate a fresh UUID and call
-   `report_state` with it as `turnRef`, `failed`, null thread and Codex turn IDs,
-   and a bounded summary before returning the failure. Retain that UUID for an
-   exact retry.
-
-When the user explicitly selects or corrects a project name or alias, call
-`update_project_hint` with explicit-user evidence after routing. A guessed
-route, generic keywords, or ordinary task wording is never learning evidence.

package/skills/taskchef-delegate/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "TaskChef Delegate"
-  short_description: "Dispatch work into visible Codex tasks"
-  default_prompt: "Use $taskchef-delegate to route this request into independently openable Codex tasks."

package/skills/taskchef-delegate/references/model-roles.md

@@ -1,29 +0,0 @@
-# Model roles
-
-TaskChef reads optional personal role preferences from native Codex agent TOML
-in `$CODEX_HOME/agents/` (default `~/.codex/agents/`). Only model and reasoning
-effort are adapted; TaskChef does not load the files' instructions, tools, or
-permissions.
-
-For a new visible task, select `orchestrator` from the `modelRoles` returned by
-`prepare_dispatch`. Pass its `taskOverrides` as the native task's `model` and
-`thinking` only after checking that the current creation interface supports
-them. Missing configuration means omit both overrides. Invalid or unavailable
-configuration must be reported rather than silently ignored.
-
-Explicit user choices take precedence. An explicit model without an explicit
-effort omits effort; do not combine it with a configured effort from another
-model. To resolve an explicit choice, run the packaged resolver before creating
-the task:
-
-```sh
-python3 <plugin-root>/scripts/roles/resolve_roles.py --role orchestrator --model <model> [--effort <effort>]
-```
-
-Resolve `<plugin-root>` from this skill's installed path. Omit flags the user
-did not specify. The local model catalog is advisory; the current native tool
-is authoritative about supported model and effort values.
-
-The visible executor resolves Planner, Implementer, and Reviewer preferences
-itself when it starts those subagents. The dispatcher does not create or wait
-for those children.

package/skills/taskchef-executor/SKILL.md

@@ -1,154 +0,0 @@
----
-name: taskchef-executor
-description: "Execute and report a TaskChef assignment or follow-up when explicitly invoked or carrying an accepted TaskChef marker. Owns executor identity and per-turn lifecycle; not dispatch or reporting on other tasks."
----
-
-# TaskChef Executor
-
-Own and execute the delegated assignment in the current Codex task. Do not
-re-dispatch it merely because it concerns TaskChef or a configured project.
-Explicit requests to delegate separate work remain valid.
-
-New instructions present the complete assignment first, then the reporting
-authorization paragraph, followed by exactly two newline characters (one blank
-line), the explicit skill invocation, one newline, and the exact
-`<!-- taskchef_id=<full UUID> -->` marker on the final line.
-There is no blank line between the invocation and marker.
-Treat that UUID as the TaskChef task ID.
-The authorization, invocation, and marker are lifecycle scaffolding, not part
-of the deliverable. Require non-whitespace task-specific content beyond them.
-For historical first-line markers, marker-before-invocation forms, compact or
-pre-authorization prompts, former inline protocol, or an installation exposing only `report_result`, read
-[compatibility](references/compatibility.md) before interpreting the assignment.
-Require exactly one marker and do not infer an ID from similar prose.
-
-## Start every execution turn
-
-Complete this lifecycle setup before substantive assignment work:
-
-1. Read this task's own durable Codex thread ID from `CODEX_THREAD_ID`. Never
-   use `CODEX_SESSION_ID`, `sourceThreadId`, a parent or delegator ID,
-   inherited metadata, title matching, recent-task search, transcripts, or a
-   provisional client ID.
-2. On the initial turn, call TaskChef `link_task` with the marked task ID and
-   that exact thread ID as the first TaskChef action. An identical retry is
-   idempotent. On a follow-up, retry the same link only when the prior link
-   cannot be established from the task context.
-3. Establish this prompt's lifecycle identity before reporting. If this exact
-   Codex thread can be read natively and exposes the current turn ID, use that
-   exact value for both `turnRef` and `turnId`. Otherwise generate one fresh
-   UUID locally, retain it for this entire prompt, use it as `turnRef`, and use
-   `turnId: null`. Do not infer a native ID, reuse an earlier prompt's
-   `turnRef`, or let a retry generate a replacement UUID.
-4. Call TaskChef `report_state` with the marked task ID, self-linked thread ID,
-   this prompt's `turnRef` and optional Codex `turnId`, `status: working`, an
-   omitted or null result summary, and a concise `requestSummary` describing this turn's assignment or follow-up.
-   When the turn targets a known GitHub repository, include its canonical
-   `https://github.com/<owner>/<repository>` URL so multi-repository projects
-   retain the selected repository instead of leaving TaskChef to guess.
-
-If the preceding TaskChef turn is still unfinished because its terminal report
-was lost, this newer valid working report atomically records that predecessor
-as interrupted and starts the current turn. Continue the real assignment from
-the current request. Do not manufacture a semantic `failed` result for the old
-turn and do not retry an old terminal report.
-
-If `CODEX_THREAD_ID` or a required TaskChef tool is unavailable, or if linking
-or the working-state report fails, report the failure visibly and stop before
-substantive work. Native turn reading is optional because the retained fallback
-UUID is the lifecycle identity. Retry a possibly lost working callback with the
-same `turnRef`; never generate a replacement for the same prompt or bypass a
-link-pending state.
-
-## Coordinate the assignment
-
-Keep this visible task as the stable owner of the assignment and its follow-ups.
-For repository work, use these tight routes:
-
-- An explicit investigate-or-plan-and-implement request starts a fresh Planner,
-  then a fresh Implementer, then a fresh Reviewer.
-- A direct implementation request starts a fresh Implementer, then a fresh
-  Reviewer; skip the Planner.
-- A later request to implement prior investigation or planning stays in this
-  visible task and starts a fresh Implementer, then a fresh Reviewer.
-
-Make the Reviewer read-only and cover the complete change. Use the installed
-`$branch-review-subagent-loop` when available or required by repository policy.
-TaskChef tracks only this parent task's lifecycle; do not report child phases or
-identities to TaskChef.
-
-Immediately before starting a child, check the Codex agents directory. If it
-contains no TOML files, inherit the parent's model settings without invoking
-Python. Otherwise resolve that role with the packaged resolver and use its
-`subagentOverrides` when valid:
-
-```sh
-python3 <plugin-root>/scripts/roles/resolve_roles.py --role <planner|implementer|reviewer>
-```
-
-Resolve `<plugin-root>` from this skill's installed path. Missing configuration
-means inherit the parent's model settings. Surface invalid or unavailable
-configuration instead of silently ignoring it. Give each child only the goal,
-scope, repository or worktree, relevant instructions, and validation expected;
-ask it to return changed files, tests, and blockers. Keep at most one writing
-agent active, verify its result, and use a fresh writer before another review
-when review finds a valid issue.
-
-## Finish every execution turn
-
-Before ending, call `report_state` with the same `turnRef` and `turnId` values
-used by this prompt's working report, one semantic status, and a concise summary:
-
-- `completed` only when the assignment is genuinely complete.
-- `needs_input` only when a semantic decision or missing information must come
-  from the user.
-- `failed` when the requested outcome cannot be completed or safely resumed.
-
-A live native approval prompt is Codex state, not semantic `needs_input`; leave
-the approval live instead of storing it as a TaskChef result. Never invent or
-reuse a `turnRef` after a follow-up. If a final-report response is lost, an
-identical terminal retry is safe only while the same turn remains current. On
-a later prompt, run the start lifecycle with a new `turnRef`; TaskChef
-will preserve the predecessor as interrupted, and only the new turn may receive
-a semantic result.
-
-Claim TaskChef was updated only after verifying the terminal response accepted
-this task, turn, status, and summary. Report failures visibly. If the platform
-rejects an authorized report, describe it as a platform rejection of that
-report; quote only a rationale actually returned. Do not infer the reason,
-promise approval, retry around an explicit denial, or change approval settings.
-Ask the user once and wait for new authorization before retrying a denial.
-
-Request and result summaries must omit secrets, transcripts, raw command output, hidden reasoning,
-and unnecessary personal data. Identical lifecycle retries are safe; never
-replace a same-`turnRef` report with different content or let an older turn
-overwrite newer state.
-
-After an accepted terminal report, `update_project_hint` may optionally retain
-one concise responsibility when that report coherently establishes it. Supply
-the same task ID, self-linked thread ID, and current turn ref as provenance.
-Repository ownership may be retained only after inspecting the exact selected
-repository or a contained Git root and verifying that exact canonical origin;
-include that repository path with the same accepted task/turn provenance.
-Never learn aliases, scan the transcript, or derive generic keywords here. A
-learning failure is nonfatal to the accepted task result: report it separately
-and do not retry with weaker evidence.
-
-## Preserve delivery context
-
-Summaries are the durable TaskChef timeline; the dashboard does not scan the
-full Codex transcript later. Include the known repository's canonical
-`https://github.com/<owner>/<repository>` URL in the working `requestSummary`.
-Use full canonical issue or pull-request URLs and include every delivered PR
-in the terminal summary, including both child and workspace PRs when relevant.
-Derive links from established project or remote evidence; never invent links
-or copy unrelated links from earlier turns.
-
-## Ending actions
-
-Normal completion returns normally after accepted terminal reporting. Never
-archive, hand off, close, navigate away from, or terminate the executor merely
-because work completed. `finish`, `complete`, `done`, `ship`, and ordinary
-cleanup do not authorize archive. Only when the user explicitly requests
-archiving this exact task or another action that can make the executor
-unavailable, read [ending actions](references/ending-actions.md) first.

package/skills/taskchef-executor/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "TaskChef Executor"
-  short_description: "Run and report a delegated TaskChef assignment."
-  default_prompt: "Use $taskchef-executor to execute and report this delegated TaskChef assignment."

package/skills/taskchef-executor/references/compatibility.md

@@ -1,22 +0,0 @@
-# Compatibility
-
-Pre-authorization prompts with the invocation before the final marker use the
-entrypoint lifecycle without requiring a new authorization paragraph.
-
-Existing delegated tasks may include the former inline ownership, linking, and
-`report_result` paragraphs. Continue executing those tasks here without
-re-dispatching. Prefer `report_state` when available. If an older installed
-TaskChef exposes only `report_result`, follow its inline protocol; after an
-upgrade, the deprecated `report_result` alias remains available for exact
-legacy retries. Also accept historical trailing instructions that place the
-marker before the invocation, with or without the former blank line before the
-marker; the former compact assignment-to-invocation boundary with the marker
-last; an exact HTML marker on the first line with or without the former blank
-line; or the older exact
-first-line `# taskchef_id=<full UUID>` heading. These compatibility forms do not
-change the identity or lifecycle rules in `SKILL.md`. For either first-line form, the
-assignment follows the marker. Ignore the final executor invocation and any
-recognizable former inline ownership, linking, working-state, or
-result-reporting paragraphs as lifecycle scaffolding; execute the remaining
-task-specific body. Require non-whitespace task-specific content and never
-treat an invocation by itself as an assignment.

package/skills/taskchef-executor/references/ending-actions.md

@@ -1,26 +0,0 @@
-# Keep terminal reporting ahead of executor-ending actions
-
-Normal completion ends with the semantic terminal `report_state` callback and
-then returns normally. Never archive, hand off, close, navigate away from, or
-otherwise terminate the Codex task merely because the work or turn completed.
-An archive is authorized only when the current assignment or follow-up
-explicitly requests archiving this exact Codex task. Words such as `finish`,
-`complete`, `done`, `ship`, and ordinary cleanup do not authorize archive.
-
-When archive is explicitly authorized, finish and verify the requested work,
-read the exact task identity required by this protocol, submit the terminal
-`report_state` callback for the current `turnRef`, and verify that TaskChef
-accepted the terminal state. Only then call the native Codex archive operation.
-Archive must be the final state-changing action, and native confirmation is
-required before claiming it succeeded.
-
-Apply the same terminal-callback-first rule when the user explicitly requests
-another action that can make this executor unavailable before it reports, such
-as handing off the task or terminating or restarting the process that owns the
-TaskChef MCP transport. This ordering rule does not authorize any such action.
-If terminal reporting fails, do not archive or perform the requested
-executor-ending action; leave the executor accessible and report the lifecycle
-failure visibly. If terminal reporting succeeds but the later action fails,
-preserve the accepted `completed`, `failed`, or `needs_input` state, report only
-the later action's failure, and do not reopen the lifecycle or report `working`
-again.