RIPDPI: Skill for Claude Code

RIPDPI policy: use only the local repository planning home. OpenSpec stores, global configuration changes, direct archive, and telemetry are out of scope; ./taskctl enforces the pinned tool and disables telemetry.

Implement tasks from an OpenSpec change.

Repository root: Work only in the current RIPDPI checkout. Do not select or register OpenSpec stores. Run every CLI lookup through ./taskctl openspec cli from the repository root.

Input: Optionally specify a change name (e.g., $openspec-apply-change (Codex) or /openspec-apply-change (other agents) add-auth). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

Steps

1. Select the change

   If a name is provided, use it. Otherwise:

   • Infer from conversation context if the user mentioned a change
   • Auto-select if only one active change exists
   • If ambiguous, run ./taskctl openspec cli list --json to get available changes and ask the user to select one

   Always announce: "Using change: " and how to override (e.g., $openspec-apply-change (Codex) or /openspec-apply-change (other agents) <other>).

2. Check status to understand the schema

   ./taskctl openspec cli status --change "<name>" --json
   

   Parse the JSON to understand:

   • schemaName: The workflow being used (e.g., "spec-driven")
   • planningHome, changeRoot, and actionContext: planning scope and edit constraints
   • Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)

3. Get apply instructions

   ./taskctl openspec cli instructions apply --change "<name>" --json
   

   This returns:

   • contextFiles: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
   • Progress (total, complete, remaining)
   • Task list with status
   • Dynamic instruction based on current state
   • Optional context: current required project instruction input from the selected root
   • Optional operationGuidance: current advisory guidance for apply

   Handle states:

   • If state: "blocked" (missing artifacts): show message, suggest using $openspec-continue-change (Codex) or /openspec-continue-change (other agents) (if it is not installed, run ./taskctl openspec cli status --change "<name>" --json to see the next artifact and ./taskctl openspec cli instructions <artifact-id> --change "<name>" --json for how to create it)
   • If state: "all_done": congratulate, suggest archive
   • Otherwise: proceed to implementation

   Treat context as a required prompt-level input. Read and consider it, and apply relevant project facts, conventions, and constraints while implementing. Treat operationGuidance as optional additive advice. Read and consider every entry, and follow entries that are applicable and compatible with the built-in workflow.

   Keep both fields separate from CLI-returned state, missing artifacts, tasks, progress, contextFiles, and the built-in instruction. They are not evidence of task completion, do not replace the built-in instruction, and do not permit bypassing a blocked state. If context conflicts with the built-in instruction, an explicit user choice, or a CLI-controlled value, report the conflict and preserve the controlling value. If guidance is inapplicable or conflicts with those controlling inputs, do not follow it and explain why. These are prompt-level behavior contracts, not enforceable checks.

4. Read context files

   Read every file path listed under contextFiles from the apply instructions output. The files depend on the schema being used:

   • spec-driven: proposal, specs, design, tasks
   • Other schemas: follow the contextFiles from CLI output

   Do not copy context or operationGuidance verbatim into implementation files or planning artifacts unless the user separately asks for that content.