Skill: daniel-refahi-ikara/dr-api-execution-bootstrap (version 1.1.1)

--- name: dr-api-execution-bootstrap description: "Bootstrap and enforce fast direct API execution in a workspace. Use when you want an agent to run API calls directly in-session, avoid unnecessary subagents, use one upfront preflight followed by a continuous execution chain, keep outputs concise, and handle bulk API workflows with reliable approval and resume behavior. Especially useful for agents doing repeated CRUD, integration, service-compliance, or other multi-call API operations." --- # DR API Execution Bootstrap Use this as an installer and execution-enforcer skill. When the user asks to apply this skill, apply it immediately. Do not ask whether to enforce the policy. ## Apply to this workspace 1. Inspect workspace startup/default files. 2. Persist the execution policy in workspace bootstrap files (`AGENTS.md`, `MEMORY.md`, or equivalent). 3. Patch surgically and preserve unrelated instructions. 4. Validate with the strongest safe real test available. 5. Report either `Configured and validated` or `Configured, but blocked by: <reason>`. For the concrete application checklist, read `references/APPLY.md`. ## Enforcement contract ### 1) Execution policy Set and enforce these defaults for future sessions: - prefer direct in-session API execution - do not spawn subagents unless the user explicitly asks - default to fast mode single-run chain - do one upfront preflight only: - auth/token availability - app code / function key / required secret availability - one sanity endpoint check - after preflight passes, execute the full API chain continuously without unnecessary pauses ### 2) Communication policy Set and enforce: - keep responses concise - do not narrate every API call unless the user asks - for blocked execution, report the blocker briefly and precisely - for write operations, show one concise batch preview and wait for approval before executing ### 3) Operational execution rules Read `references/EXECUTION-PLAYBOOK.md` and follow it for: - bulk reads - bulk writes - failure handling - resume behavior - verification strategy ### 4) API-specific guidance If the workflow involves Ikara-style CRUD/integration/service-compliance APIs, also read `references/IKARA-PATTERNS.md` before executing. ### 5) Validation requirements After applying the rules, immediately validate them. If safe and permitted, run one small real dev test and confirm: - direct API call path works - no subagent was spawned - preflight + full-chain behavior is active If real execution is not possible, run the strongest safe validation available and state exactly what prevented full validation. ### 6) Limits If permissions, secrets, or tool access are missing: - do not pretend they were enabled - do not claim success - report exactly what is missing - keep the enforced policy in startup files anyway, unless file-write access is blocked ## Reuse on other agents If the user wants to replicate this behavior elsewhere, read `references/INSTALL.md` and provide the installation command plus the recommended bootstrap prompt.

path: _meta.json
content: ownerId: kn75qhdfr3qnbx390tbrjgz48981y6e4
slug: dr-api-execution-bootstrap
version: 1.0.0
publishedAt: 1774080800145

path: references/APPLY.md
content: # Apply checklist — dr-api-execution-bootstrap

Use this when the user says things like:
- Apply dr-api-execution-bootstrap to this workspace
- Enable direct API execution by default
- Bootstrap this workspace for fast API chaining

## Goal
Make direct in-session API execution the default workflow for the workspace.

## Steps
1) Inspect existing startup/default files:
- `AGENTS.md`
- `MEMORY.md`
- any workspace bootstrap/instruction files

2) Persist these rules:
- direct execution first
- no subagents unless explicitly requested
- one upfront preflight only
- fast mode single-run chain
- concise responses
- blocker-only reporting when execution is impossible

3) Patch existing files surgically.
- Do not erase unrelated user instructions.
- Do not duplicate sections if already applied.

4) Validate.
- Prefer a small real dev test if safe.
- Otherwise do the strongest safe validation available.

5) Final response:
- `Configured and validated`
- or `Configured, but blocked by: <reason>`


path: references/EXECUTION-PLAYBOOK.md
content: # Execution playbook

## Goal
Run API work fast, directly, and with minimal user friction.

## Direct-first runtime
- Execute API calls in the current session by default.
- Do not spawn subagents for normal API workflows unless the user explicitly asks.
- Keep the chain inside one run whenever tools and auth are already available.

## Fast mode single-run chain
Use this default sequence:
1. Load required tenant, auth, and endpoint constants.
2. Run one preflight only:
   - token present or refreshable
   - app code / function key present
   - one sanity endpoint returns expected auth/result shape
3. If preflight passes, execute the remaining API calls continuously.
4. Verify final state with the minimum readback needed.

Do not repeat token checks, config checks, or sanity probes before every call unless the API actually starts failing.

## Bulk read strategy
- Prefer one broad list call over many per-item reads when the payload contains enough fields.
- Build local lookup maps by id, title, or external key before writes.
- Filter in memory when cheaper than extra network round-trips.

## Bulk write strategy
- For many similar writes, keep the payload template fixed and vary only the changing fields.
- Serialize writes unless the API is clearly safe for concurrency.
- Use small pauses only when the API shows rate or stability issues.
- After bulk writes, do one summary verification pass instead of many redundant reads when possible.

## Approval flow for writes
For PUT/POST/DELETE operations:
- show a concise change preview
- wait for approve/reject in chat
- after approval, execute the whole write batch continuously
- do not ask for approval item-by-item when one batch preview is enough

## Failure handling
- Stop and surface the blocker when auth, endpoint shape, or payload contract is wrong.
- For bulk jobs, continue past isolated per-item failures only when safe, then return a created/updated/failed summary.
- Preserve enough detail to resume from the failed subset.

## Resume pattern
When a batch partially succeeds, report:
- attempted
- succeeded
- failed
- identifiers for failed items

Then resume only the failed subset if the user asks.

## Progress style
- Default: no per-call chatter.
- Acceptable: one short progress note for long-running batches.
- Always keep the final report concise and numeric.

## Verification checklist
After execution, verify only what matters:
- target object exists or was updated
- changed fields match expectation
- summary counts are correct
- failures are enumerated if any


path: references/IKARA-PATTERNS.md
content: # Ikara API patterns

## Base pattern
`{BaseUrl}/tenants/{tenantId}/...`

## Common auth pattern
- `Authorization: Bearer <access_token>`
- function/app key usually passed as `?code=<key>`

## Practical rules
- Confirm the active endpoint family before chaining calls (`/CRUD/...` versus non-CRUD refactor paths).
- Do one sanity call first to confirm the right path and auth shape.
- Reuse the same bearer token and app code for the whole chain.
- Prefer list endpoints when you can derive titles, ids, and created dates from one response.

## Common bulk workflows
- fetch all integrations once, then match by title/id locally
- create/update titles in a continuous loop after one approval
- create service compliances first, then one root group, then all criteria under that group
- for manual assessments, use the exact endpoint/method/content type the API expects

## Manual assessment note
Some manual assessment endpoints require:
- specific route shape
- PUT instead of POST
- multipart/form-data instead of JSON or urlencoded form data

Do not assume the write contract. Probe one working example first when the route is unfamiliar.


path: references/INSTALL.md
content: # Installation and activation

## Install from ClawHub
```bash
clawhub install dr-api-execution-bootstrap --workdir /home/Echo/.openclaw/workspace --force
```

## Apply in a workspace
Tell the agent:

```text
Apply dr-api-execution-bootstrap to this workspace.
```

## Recommended bootstrap prompt for another agent
```text
You are my API execution agent.
Apply dr-api-execution-bootstrap to this workspace and persist its rules in startup memory.
Use direct in-session API execution by default.
Do not spawn subagents unless I explicitly ask.
Use fast mode single-run chain.
Do one upfront preflight only: token, app code/function key, and one sanity endpoint.
After preflight, execute the full API chain continuously.
Keep responses concise and do not narrate every API call unless I ask.
For write operations, show one concise batch preview and wait for approval.
Then validate with a minimal real test and report either:
Configured and validated
or
Configured, but blocked by: <reason>
```

## What success looks like
- agent runs API calls directly in the current session
- no subagent fallback by default
- one preflight only, then continuous execution
- concise outputs
- predictable approval behavior for writes


Security scan verdicts — ClawScan: suspicious | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)