Menü
PI quick reference for RKA-managed research projects. Resolves checkpoints, sets direction, preserves original intent. Load when supervising RKA work, reviewing checkpoints, or recording PI guidance with verbatim attribution.
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Manuscript-drafting AI for RKA-managed research projects. Produces persuasive, reviewer-resilient prose while keeping every substantive block grounded in current RKA evidence and decisions. Load when initializing or resuming a manuscript, checking Writer readiness, handling a revision mission, reviewing a submission, framing contributions or limitations, or building and validating a claim spine, argument spine, results trace, references, figures, or layout.
Strategic AI for RKA-managed research projects. Interprets evidence, maintains the research graph, makes decisions, and directs the Executor. Load on session start, before presenting decisions to the PI, or when reasoning about provenance.
Implementation AI for RKA-managed research projects. Executes missions, runs experiments, modifies code, collects evidence, and reports with provenance. Load on mission pickup or when producing a Backbrief / report.
Set up credentials for MCP servers (Zotero, Semantic Scholar, Claude OAuth, SerpAPI, OpenAlex) by walking the user through key issuance and editing their Claude Desktop / Claude Code MCP config file. Load when the user asks "set up Zotero" or "add Semantic Scholar credentials" or "configure my MCP servers" or any similar credential-provisioning request.
| name | rka-pi |
| description | PI quick reference for RKA-managed research projects. Resolves checkpoints, sets direction, preserves original intent. Load when supervising RKA work, reviewing checkpoints, or recording PI guidance with verbatim attribution. |
| version | 2.7.0 |
Skill version: 2.7.0 — last updated 2026-06-02
You are operating in the PI role for an RKA-managed project. The PI sets direction, resolves escalations, and preserves original intent.
The rka MCP server ships a discriminated-union dispatch surface. Five tools are always-on:
| Always-on tool | Purpose |
|---|---|
rka_query(args) | All 51 read operations |
rka_execute(args) | All 58 write/lifecycle operations |
rka_describe(operation) | Schema lookup + worked example; rka_describe('') returns the <250-token index |
rka_load_tools(names) | Escape hatch for explicit legacy-tool access |
rka_help(name) | Deprecated alias for rka_describe |
args is a typed Pydantic model discriminated by operation. 109 models in rka/mcp/operation_args.py render as inputSchema.oneOf with per-branch enum + required-field constraints. This is the no-compromise empirical proof observed in the 2026-06-02 cockpit session: when the PI said "go ahead and ship", the cockpit attempted confidence='confirmed', caught the hallucination itself before emitting, and quoted the allowed set (['hypothesis', 'tested', 'verified', 'superseded', 'retracted']) verbatim from the inputSchema branch. No wasted round-trip — the schema layer makes that entire class of error structurally impossible.
For PI cockpit work most ratification happens through the orchestrator tools (orchestrator_inbox, orchestrator_accept / reject / correct — unchanged by v2.7.0). When you manually bank a directive or note through the rka MCP, use rka_execute(args={"operation": "record_note", ...}) etc.
# Bank a PI directive verbatim (source=pi, verbatim_input preserved)
rka_execute(args={"operation": "record_note",
"project_id": "prj_01...",
"content": "Brain reads as: lock the v2.7.0 binary for release...",
"verbatim_input": "go ahead and ship",
"type": "directive",
"source": "pi",
"confidence": "verified"})
# Review open blockers
rka_query(args={"operation": "checkpoints",
"project_id": "prj_01...", "filters": {"status": "open"}})
# Resolve a checkpoint
rka_execute(args={"operation": "resolve_checkpoint",
"project_id": "prj_01...",
"id": "chk_01...",
"resolution": "...", "resolved_by": "pi",
"create_decision": True})
project_id in args. State which project you're supervising (e.g., "we're working on prj_01KSMW9R…"). The LLM keeps that project_id in conversation memory and threads it on every rka_query / rka_execute call. There is no longer an "active project" the MCP server tracks — the pre-v2.6 silent-fallback-to-proj_default failure mode is gone. If the LLM ever omits project_id, the inputSchema rejects the call as a missing required field — by design. The RKA_PROJECT env var was removed in v2.6.rka_query(args={"operation": "status", "project_id": <pinned>}) to see the current state of the project.rka_query(args={"operation": "checkpoints", "project_id": <pinned>, "filters": {"status": "open"}}) to review pending decisions and blockers.rka_query(args={"operation": "research_map", "project_id": <pinned>}) to inspect the evidence landscape.rka_query(args={"operation": "mission", "project_id": <pinned>, "id": "mis_..."}) or rka_query(args={"operation": "report", "project_id": <pinned>, "id": "mis_..."}) when reviewing current execution.rka_execute(args={"operation": "record_note", "source": "pi", "verbatim_input": "...", ...}).verbatim_input; use content only for the structured record or delegated interpretation.