Skill instructions
action-room28.5 KB
View saved version →
---
name: action-room
description: Connect the current Codex conversation and project to a user-selected DXIR Action Room, perform its report-owned tasks in Codex, and synchronize progress and artifact evidence. Use when the user provides an Action Room link or asks to work on the already-bound Room.
---
Keep execution, questions, permission approvals, and interruption in the user's ordinary Codex conversation. Action Room displays the selected Room's work and evidence. Connecting does not authorize unrelated work or external actions.
## Connect the selected conversation
First use [connection and recovery](../research-strategy/SKILL.md#connect-and-recover-in-this-conversation) to read the connected account and handle native login prompts or missing tools in this same conversation. For a Room request, resume the selected Room's read after connecting; do not open research service selection or replay mutations. Preserve existing local work and bindings.
For a Room inherited from an approved research/strategy project, use the research-strategy skill's `dxir_handoff`/`dxir_room` route instead of steps 1–4 below. Use that route for every Room operation so project revocation remains enforced. It supports Codex and Work without host hooks; its executor_key is not a Codex session ID. Use that skill's native-file layout, checkpoint and upload instructions in place of ALL legacy action-room.mjs commands below and in references, including layout/task-dir, pending/ack, checkpoints and artifact/upload. Never pass an executor key as a fabricated host identity. The research, completion, goal and evidence requirements below still apply. Use host files/tools only where actually available.
In that inherited route, legacy hook/journal commands and Codex identity fields in the references do not apply. Use the host's normal document/file tools, save required deliverables in the selected project, and record research/execution/output evidence through the corresponding `dxir_room` operations. Preserve the server's task order and completion criteria. Do not call the legacy local bind helper with a fabricated host identity.
If this conversation has no selected project folder, use only [folder setup](../research-strategy/SKILL.md#when-codex-starts-without-a-project-folder) to offer creation under the user's home or selection of an existing folder, then verify host attachment. For a standalone Room, return to the steps below without creating a research context or opening service selection. Creating a folder does not supply the host identity required for binding.
Before using the legacy binding steps below, check whether this package contains `hooks/hooks.json`. The public directory package omits legacy hooks. In that package, read the selected Room and reuse its owned project link or project ID when returned, then follow the research-strategy skill's existing-project connection route. If no project is available, preserve the Room and explain that this earlier standalone Room requires the advanced manual package. Never request trust for missing hooks, fabricate host identity or replay completed work to migrate a Room.
1. Read the Room using `action_room_read` and its UUID from the user's DXIR Room link. Do not choose a Room from unrelated conversation history.
2. Run `node "<plugin-root>/scripts/action-room.mjs" identity` from the current project. Trusted plugin hooks attach `DXIR host identity` containing `codex_session_id`, `project_key`, and `data_dir` from the actual current hook input. Use only this invocation's identity. Without that context, ask the user to review this plugin in `/hooks`; do not scan transcripts, infer a session ID, edit trust settings, or silently switch to another session. Node.js 18 or newer is required.
3. Call `action_room_bind` with `room_id`, the host's `codex_session_id`, and a user-facing `project_label` that contains no absolute path. Use the returned Room tasks in their immutable order and preserve their output re
Preview of the first 4,000 characters. Read full instructions →
Referenced files: 4 — file references are metadata, not package contents.
research-strategy29 KB
View saved version →
---
name: research-strategy
description: Use DXIR research or strategy analysis from GPT app source folders, or help connect a project folder when Codex starts without one. Check DXIR readiness, start new analyses with the owner's service selection, prepare inputs, retrieve reports and optionally execute Action Room. Also supports existing DXIR project links.
---
# DXIR in the current GPT app project
Use the host's actual project/source folders. Preserve an already attached folder; when none is selected, follow the folder setup below. Do not ask the user to create a separate DXIR project, reselect an already connected folder, run a separate CLI agent, or start an app-server. Project creation alone never starts analysis or uploads files. Readiness checks may offer folder setup; start analysis only when requested.
Keep user-facing guidance centered on the requested outcome. The user need not understand MCP, hooks, execution contracts, routing IDs or helper commands. Perform supported preparation and checks yourself; show only input/source/cost disclosure, plain progress and results. Ask for material missing information once. On failure, give one actionable next step for the actual current client and retain the original request. Reuse existing authorization and avoid repeated setup or long procedural prompts. Respect confirmations required by the host; cancellation or declined authorization stops the dependent action. A desktop-app restart does not reload a VS Code extension: only when a metadata reload is necessary, preserve active work and guide the user to reload the client actually running this conversation. In VS Code use the documented Developer: Reload Window action; never automate the host UI or change its settings.
Check `action_room_account` first. Browser login does not switch the connector account. Never request an API key, export OAuth credentials, inspect host databases/transcripts for IDs, or fabricate a host session/project ID. Server IDs are routing values, not GPT project identities. No hooks are required.
## Connect and recover in this conversation
Use the tool names and schemas actually exposed by this host. The public directory exposes one tool per operation, such as `dxir_services_list`, `dxir_services_read`, `dxir_handoff_read`, `dxir_handoff_resume` and `dxir_room_research_save`. These names already fix the operation: supply their flat input fields without `action`, `operation` or a `payload` wrapper. References below use the earlier grouped names to describe those same operations. Use a grouped tool only when that exact tool is available. An inherited Room uses the available `dxir_room_*` operation tools; legacy execution tools need manual-package hooks.
For a readiness request, read `action_room_account`, then `dxir_services`. Neither requires a source folder, context creation, service selection or payment. Report the account and services actually returned; report folder availability separately. Keep the user's original request in this conversation throughout recovery.
Read execution_contract returned by action_room_account and compare it with the actual tool schemas in this conversation. The complete current metadata includes dxir_context.project_id and dxir_handoff resume, mutation_id and review_hash (or the corresponding dxir_handoff_resume tool with those fields); a tool count or installed ZIP version does not prove these features. Check capabilities for the requested operation: a new isolated context and analysis may use the existing context, selection, analysis and handoff bind schemas when available. Missing project_id blocks attaching an existing web project; missing resume/mutation_id/review_hash blocks deferred or revised-report recovery. Preserve those dependent requests and checkpoints and use the host's supported metadata refresh and a new conversation after plugin update. Continue independent supported work without claiming complete metadata readiness. The authenticated server admis
Preview of the first 4,000 characters. Read full instructions →
setup1.75 KB
View saved version →
---
name: setup
description: Connect DXIR after installing the plugin and show how to make the first request. Use for setup or connection checks; installation alone does not request analysis.
---
# Connect DXIR
Use [connection and recovery](../research-strategy/SKILL.md#connect-and-recover-in-this-conversation) to read `action_room_account`, then the available `dxir_services_list` or earlier `dxir_services` tool. Let the host present its native login action when required. Preserve the user's original request and continue its read-only checks after connection. Neither check needs a folder, creates a project, uploads materials or starts paid work.
After successful reads, briefly identify the connected DXIR account and the next useful action in the user's language. Reuse an attached project folder. If no folder is attached, explain how to select the folder containing the materials in this host; offer the existing skill's folder setup only when the user wants help creating or connecting it.
An example request is: “이 프로젝트의 자료를 분석하고 결과를 설명해 주세요. 보고서에 따른 작업도 해주세요. 필요한 서비스는 추천해 주세요.” Translate it to the user's language. Do not send that example, open service selection or start analysis during setup. If the user has already requested substantive work, finish connection checks and perform that original request through the research-strategy or action-room skill within its existing authorization.
Keep helper commands, routing IDs and connection diagnostics out of normal guidance. A successful installation or browser login is not a verified DXIR connection. Stop prompting after a declined connection; provide one supported next step if connection remains unavailable.
