From c26a2cf23e2e81e08d795a1008adab15193adf4b Mon Sep 17 00:00:00 2001 From: CCLCK <84182037+CCLCK@users.noreply.github.com> Date: Sun, 12 Apr 2026 18:01:40 +0800 Subject: [PATCH] Add local machine context snapshots --- .gitignore | 5 + context/local-machine/admin-macos/README.md | 28 +++ .../codex_callrate_smoke/config.json | 19 ++ .../codex_callrate_smoke_noref/config.json | 19 ++ .../phase1_results.jsonl | 6 + .../skills_snapshot.json | 70 ++++++ .../config.json | 23 ++ .../phase1_results.jsonl | 2 + .../skills_snapshot.json | 232 ++++++++++++++++++ .../admin-macos/mcp/repo-local.mcp.json | 23 ++ gdpval_bench/run_benchmark.py | 11 + openspace/skill_engine/evolver.py | 107 +++++++- openspace/tool_layer.py | 4 + tests/test_evolver_captured_names.py | 79 ++++++ 14 files changed, 622 insertions(+), 6 deletions(-) create mode 100644 context/local-machine/admin-macos/README.md create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke/config.json create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/config.json create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/phase1_results.jsonl create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/skills_snapshot.json create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/config.json create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/phase1_results.jsonl create mode 100644 context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/skills_snapshot.json create mode 100644 context/local-machine/admin-macos/mcp/repo-local.mcp.json create mode 100644 tests/test_evolver_captured_names.py diff --git a/.gitignore b/.gitignore index 77dd181..50275e8 100644 --- a/.gitignore +++ b/.gitignore @@ -30,6 +30,7 @@ build/ # MCP files openspace/config/config_mcp.json +.mcp.json # Logs logs/ @@ -46,6 +47,7 @@ showcase/.openspace/* # GDPVal benchmark cache gdpval_bench/.openspace/* !gdpval_bench/.openspace/*.db +gdpval_bench/results/ # Embedding cache embedding_cache/ @@ -73,3 +75,6 @@ openspace/skills/* node_modules/ # Frontend local dependency link frontend/node_modules + +# Local scratch +tmp/ diff --git a/context/local-machine/admin-macos/README.md b/context/local-machine/admin-macos/README.md new file mode 100644 index 0000000..8e38241 --- /dev/null +++ b/context/local-machine/admin-macos/README.md @@ -0,0 +1,28 @@ +## Admin macOS Local Context + +This directory keeps machine-specific snapshots that are useful for future +deployment, migration, and debugging on other machines, while avoiding noise in +the repo root. + +Included here: + +- `mcp/repo-local.mcp.json` + - snapshot of the repo-local MCP wiring that was used during local debugging +- `gdpval_bench/...` + - selected benchmark result snapshots that were useful during local call-rate + and provider-path investigation + +Intentional choices: + +- absolute local paths are preserved because they are part of the context +- localhost API base values are preserved because they document the local stack +- secrets are not preserved + - any benchmark config copied here has API keys redacted + +Intentionally omitted from this snapshot: + +- SQLite/WAL benchmark databases +- raw recording directories +- ad hoc `tmp/` scratch files + +Those source locations remain local-only and are ignored via `.gitignore`. diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke/config.json b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke/config.json new file mode 100644 index 0000000..c8a5631 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke/config.json @@ -0,0 +1,19 @@ +{ + "clawwork_root": "/tmp/openspace-bench-mp4o3U", + "gdpval_path": null, + "model": "gpt-5.4", + "max_iterations": 20, + "backend_scope": [ + "shell" + ], + "use_clawwork_productivity": false, + "run_name": "codex_callrate_smoke", + "max_tasks": 3, + "per_occupation": null, + "sectors": null, + "occupations": null, + "task_ids": null, + "record_call_details": true, + "enable_evaluation": false, + "concurrency": 1 +} \ No newline at end of file diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/config.json b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/config.json new file mode 100644 index 0000000..2d190a5 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/config.json @@ -0,0 +1,19 @@ +{ + "clawwork_root": "/tmp/openspace-bench-noref-JwyV4l", + "gdpval_path": null, + "model": "gpt-5.4", + "max_iterations": 20, + "backend_scope": [ + "shell" + ], + "use_clawwork_productivity": false, + "run_name": "codex_callrate_smoke_noref", + "max_tasks": 3, + "per_occupation": null, + "sectors": null, + "occupations": null, + "task_ids": null, + "record_call_details": true, + "enable_evaluation": false, + "concurrency": 1 +} \ No newline at end of file diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/phase1_results.jsonl b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/phase1_results.jsonl new file mode 100644 index 0000000..933c773 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/phase1_results.jsonl @@ -0,0 +1,6 @@ +{"task_id": "0112fc9b-c3b2-4084-8993-5a4abb1f54f1", "phase": "phase1", "occupation": "Nurse Practitioners", "sector": "Health Care and Social Assistance", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.01, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.01}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:37:44.273256"} +{"task_id": "02314fc6-a24e-42f4-a8cd-362cae0f0ec1", "phase": "phase1", "occupation": "General and Operations Managers", "sector": "Retail Trade", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.0, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.0}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:37:44.278249"} +{"task_id": "02aa1805-c658-4069-8a6a-02dec146063a", "phase": "phase1", "occupation": "Project Management Specialists", "sector": "Professional, Scientific, and Technical Services", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.0, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.0}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:37:44.282846"} +{"task_id": "0112fc9b-c3b2-4084-8993-5a4abb1f54f1", "phase": "phase1", "occupation": "Nurse Practitioners", "sector": "Health Care and Social Assistance", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.0, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.0}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:38:19.523517"} +{"task_id": "02314fc6-a24e-42f4-a8cd-362cae0f0ec1", "phase": "phase1", "occupation": "General and Operations Managers", "sector": "Retail Trade", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.0, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.0}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:38:19.526964"} +{"task_id": "02aa1805-c658-4069-8a6a-02dec146063a", "phase": "phase1", "occupation": "Project Management Specialists", "sector": "Professional, Scientific, and Technical Services", "task_value_usd": 0.0, "status": "error", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 0.0, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 0, "tool_calls": 0, "time_sec": 0.0}, "skills": {"before": 2, "after": 2, "new_this_task": 0, "evolved": [], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:38:19.529894"} diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/skills_snapshot.json b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/skills_snapshot.json new file mode 100644 index 0000000..8c4d283 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref/skills_snapshot.json @@ -0,0 +1,70 @@ +[ + { + "skill_id": "single-retry-transient-failures__v0_cb599f5d", + "name": "single-retry-transient-failures", + "description": "Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/single-retry-transient-failures/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "imported", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": null, + "change_summary": "", + "content_diff": "--- a/.upload_meta.json\n+++ b/.upload_meta.json\n@@ -0,0 +1,7 @@\n+{\n+ \"origin\": \"captured\",\n+ \"parent_skill_ids\": [],\n+ \"change_summary\": \"Captured a workflow for handling likely transient upstream failures by doing one minimal retry first and explicitly recording whether the issue is intermittent or reproducible.\",\n+ \"created_by\": \"gpt-5.4\",\n+ \"tags\": []\n+}\n\n--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,228 @@\n+---\n+name: single-retry-transient-failures\n+description: Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.\n+---\n+\n+# Single Retry for Transient Failures\n+\n+## Purpose\n+\n+Use this workflow when a task fails with a likely transient infrastructure problem, such as:\n+\n+- HTTP 5xx from an upstream service\n+- gateway/proxy failures like 502, 503, 504\n+- temporary connection resets or timeouts\n+- rate-limit edge cases that may clear immediately\n+- brief platform instability not obviously caused by local changes\n+\n+The goal is to quickly distinguish:\n+\n+- transient platform instability, vs.\n+- a reproducible product or code issue\n+\n+This avoids wasting time debugging or changing code before confirming the problem persists.\n+\n+## When to use this\n+\n+Apply this skill when all of the following are true:\n+\n+1. The failure appears external or infrastructural.\n+2. There is no strong evidence yet that a recent code/config change caused it.\n+3. Retrying once is low-risk and does not create harmful side effects.\n+4. You can re-run the smallest possible failing step.\n+\n+Do not use this as an excuse for repeated blind retries.\n+\n+## Core rule\n+\n+Before deeper investigation, perform exactly one minimal retry of the failing operation.\n+\n+- Minimal retry = rerun only the smallest step needed to test whether the issue persists.\n+- One retry only = enough to test intermittency without masking a real defect.\n+\n+After the retry, explicitly record the outcome.\n+\n+## Procedure\n+\n+### 1) Confirm the error looks transient\n+\n+Treat the issue as potentially transient if signals include:\n+\n+- HTTP 502/503/504\n+- upstream service unavailable\n+- network timeout during dependency call\n+- temporary DNS/TLS/proxy/connectivity failure\n+- infrastructure-generated error page\n+- job failure with no local stack trace pointing to your code\n+\n+If the error clearly points to deterministic local logic, skip this skill and debug normally.\n+\n+### 2) Check retry safety\n+\n+Before retrying, verify:\n+\n+- rerunning will not duplicate destructive side effects\n+- rerunning will not create bad state\n+- if side effects exist, there is idempotency protection or safe rollback\n+- credentials, environment, and inputs remain unchanged\n+\n+If retry is unsafe, do not retry blindly. Instead document why and investigate more carefully.\n+\n+### 3) Perform one minimal retry\n+\n+Retry only the failing step, not the entire workflow unless necessary.\n+\n+Examples:\n+\n+- rerun one API request, not the whole deployment\n+- rerun one test shard, not the whole test suite\n+- rerun one build/download step, not all CI jobs\n+- repeat the same command with the same inputs\n+\n+Keep the retry minimal:\n+\n+- same inputs\n+- same environment\n+- no code changes\n+- no config changes\n+- no workaround added yet\n+\n+This preserves the diagnostic value of the retry.\n+\n+### 4) Record both attempts clearly\n+\n+Capture:\n+\n+- original failure timestamp\n+- original error summary\n+- whether the retry used identical inputs\n+- retry result: passed or failed\n+- if failed again, whether the error is materially the same\n+\n+Use short, explicit wording so future follow-up can tell what happened.\n+\n+Example status notes:\n+\n+- \"Initial run failed with upstream 502. Performed one identical retry; retry succeeded. Treat as transient platform issue unless it recurs.\"\n+- \"Initial run failed with 503. One minimal retry failed with same 503. Issue appears reproducible; continue investigation.\"\n+- \"Initial timeout retried once and succeeded. No code changes made; likely intermittent dependency instability.\"\n+\n+### 5) Branch based on the retry result\n+\n+#### If the retry succeeds\n+\n+Conclude that the failure was likely intermittent.\n+\n+Then:\n+\n+- avoid unnecessary code changes\n+- note that the issue is not currently reproducible\n+- proceed with the task if appropriate\n+- flag possible platform instability if relevant\n+- monitor for recurrence\n+\n+Do not over-investigate unless:\n+- the task requires high confidence in reliability, or\n+- the same transient pattern is recurring often\n+\n+#### If the retry fails again\n+\n+Treat the issue as likely reproducible.\n+\n+Then:\n+\n+- begin deeper investigation\n+- inspect logs, traces, and recent changes\n+- isolate the failing subsystem\n+- consider fixes, mitigations, or escalations\n+\n+The single retry has now served its purpose: it ruled out a one-off blip.\n+\n+## Decision table\n+\n+| Situation | Action |\n+|---|---|\n+| Likely upstream/infrastructure 5xx, safe to retry | Retry once minimally |\n+| Retry succeeds | Record as likely transient; avoid unnecessary changes |\n+| Retry fails similarly | Treat as reproducible; investigate deeply |\n+| Retry unsafe due to side effects | Do not retry blindly; document and investigate safely |\n+| Error clearly caused by deterministic local logic | Skip this workflow |\n+\n+## Recommended phrasing for reports\n+\n+Use concise language that preserves diagnostic value.\n+\n+### Success on retry\n+\n+- \"Observed likely transient upstream failure; one minimal retry succeeded with no changes.\"\n+- \"Issue appears intermittent rather than reproducible.\"\n+- \"No product/code change made because retry cleared the failure.\"\n+\n+### Failure on retry\n+\n+- \"Performed one minimal retry to test intermittency; failure reproduced.\"\n+- \"Issue is not a one-off transient; continuing root-cause investigation.\"\n+\n+### Retry not attempted\n+\n+- \"Likely transient error observed, but retry was not safe due to non-idempotent side effects.\"\n+\n+## Guardrails\n+\n+### Do\n+\n+- retry once\n+- retry the smallest possible unit\n+- keep inputs unchanged\n+- record what happened\n+- use the retry result to guide next steps\n+\n+### Do not\n+\n+- keep retrying until success\n+- modify code before confirming reproducibility\n+- rerun a large workflow when a smaller reproduction is available\n+- hide the fact that the first failure occurred\n+- assume success on retry means the system is healthy\n+\n+## Example workflow\n+\n+### Example 1: Upstream 502 during a task\n+\n+1. A command fails with HTTP 502 from a dependency.\n+2. No local code changes explain it.\n+3. Rerun the same command once with the same inputs.\n+4. If it succeeds, record:\n+ - \"Initial 502 appears transient; single retry succeeded.\"\n+5. Continue without code changes.\n+\n+### Example 2: Timeout during CI dependency fetch\n+\n+1. Dependency download times out.\n+2. Retry only the fetch step once.\n+3. If it times out again, record:\n+ - \"Single retry reproduced timeout; investigating network/dependency issue.\"\n+4. Move into deeper diagnosis.\n+\n+## Why this works\n+\n+A single minimal retry is a fast diagnostic tool:\n+\n+- low effort\n+- low risk when safe\n+- preserves signal\n+- prevents premature debugging\n+- separates intermittent infrastructure instability from true reproducible defects\n+\n+This is especially useful in automated environments, CI systems, remote execution, and tasks that depend on external services.\n+\n+## Completion checklist\n+\n+Before finishing, confirm:\n+\n+- [ ] The error was plausibly transient\n+- [ ] Retry was safe\n+- [ ] Only one minimal retry was performed\n+- [ ] No code/config changes were made before the retry\n+- [ ] The retry outcome was explicitly documented\n+- [ ] Next actions were chosen based on whether the issue reproduced", + "content_snapshot": { + ".upload_meta.json": "{\n \"origin\": \"captured\",\n \"parent_skill_ids\": [],\n \"change_summary\": \"Captured a workflow for handling likely transient upstream failures by doing one minimal retry first and explicitly recording whether the issue is intermittent or reproducible.\",\n \"created_by\": \"gpt-5.4\",\n \"tags\": []\n}\n", + "SKILL.md": "---\nname: single-retry-transient-failures\ndescription: Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.\n---\n\n# Single Retry for Transient Failures\n\n## Purpose\n\nUse this workflow when a task fails with a likely transient infrastructure problem, such as:\n\n- HTTP 5xx from an upstream service\n- gateway/proxy failures like 502, 503, 504\n- temporary connection resets or timeouts\n- rate-limit edge cases that may clear immediately\n- brief platform instability not obviously caused by local changes\n\nThe goal is to quickly distinguish:\n\n- transient platform instability, vs.\n- a reproducible product or code issue\n\nThis avoids wasting time debugging or changing code before confirming the problem persists.\n\n## When to use this\n\nApply this skill when all of the following are true:\n\n1. The failure appears external or infrastructural.\n2. There is no strong evidence yet that a recent code/config change caused it.\n3. Retrying once is low-risk and does not create harmful side effects.\n4. You can re-run the smallest possible failing step.\n\nDo not use this as an excuse for repeated blind retries.\n\n## Core rule\n\nBefore deeper investigation, perform exactly one minimal retry of the failing operation.\n\n- Minimal retry = rerun only the smallest step needed to test whether the issue persists.\n- One retry only = enough to test intermittency without masking a real defect.\n\nAfter the retry, explicitly record the outcome.\n\n## Procedure\n\n### 1) Confirm the error looks transient\n\nTreat the issue as potentially transient if signals include:\n\n- HTTP 502/503/504\n- upstream service unavailable\n- network timeout during dependency call\n- temporary DNS/TLS/proxy/connectivity failure\n- infrastructure-generated error page\n- job failure with no local stack trace pointing to your code\n\nIf the error clearly points to deterministic local logic, skip this skill and debug normally.\n\n### 2) Check retry safety\n\nBefore retrying, verify:\n\n- rerunning will not duplicate destructive side effects\n- rerunning will not create bad state\n- if side effects exist, there is idempotency protection or safe rollback\n- credentials, environment, and inputs remain unchanged\n\nIf retry is unsafe, do not retry blindly. Instead document why and investigate more carefully.\n\n### 3) Perform one minimal retry\n\nRetry only the failing step, not the entire workflow unless necessary.\n\nExamples:\n\n- rerun one API request, not the whole deployment\n- rerun one test shard, not the whole test suite\n- rerun one build/download step, not all CI jobs\n- repeat the same command with the same inputs\n\nKeep the retry minimal:\n\n- same inputs\n- same environment\n- no code changes\n- no config changes\n- no workaround added yet\n\nThis preserves the diagnostic value of the retry.\n\n### 4) Record both attempts clearly\n\nCapture:\n\n- original failure timestamp\n- original error summary\n- whether the retry used identical inputs\n- retry result: passed or failed\n- if failed again, whether the error is materially the same\n\nUse short, explicit wording so future follow-up can tell what happened.\n\nExample status notes:\n\n- \"Initial run failed with upstream 502. Performed one identical retry; retry succeeded. Treat as transient platform issue unless it recurs.\"\n- \"Initial run failed with 503. One minimal retry failed with same 503. Issue appears reproducible; continue investigation.\"\n- \"Initial timeout retried once and succeeded. No code changes made; likely intermittent dependency instability.\"\n\n### 5) Branch based on the retry result\n\n#### If the retry succeeds\n\nConclude that the failure was likely intermittent.\n\nThen:\n\n- avoid unnecessary code changes\n- note that the issue is not currently reproducible\n- proceed with the task if appropriate\n- flag possible platform instability if relevant\n- monitor for recurrence\n\nDo not over-investigate unless:\n- the task requires high confidence in reliability, or\n- the same transient pattern is recurring often\n\n#### If the retry fails again\n\nTreat the issue as likely reproducible.\n\nThen:\n\n- begin deeper investigation\n- inspect logs, traces, and recent changes\n- isolate the failing subsystem\n- consider fixes, mitigations, or escalations\n\nThe single retry has now served its purpose: it ruled out a one-off blip.\n\n## Decision table\n\n| Situation | Action |\n|---|---|\n| Likely upstream/infrastructure 5xx, safe to retry | Retry once minimally |\n| Retry succeeds | Record as likely transient; avoid unnecessary changes |\n| Retry fails similarly | Treat as reproducible; investigate deeply |\n| Retry unsafe due to side effects | Do not retry blindly; document and investigate safely |\n| Error clearly caused by deterministic local logic | Skip this workflow |\n\n## Recommended phrasing for reports\n\nUse concise language that preserves diagnostic value.\n\n### Success on retry\n\n- \"Observed likely transient upstream failure; one minimal retry succeeded with no changes.\"\n- \"Issue appears intermittent rather than reproducible.\"\n- \"No product/code change made because retry cleared the failure.\"\n\n### Failure on retry\n\n- \"Performed one minimal retry to test intermittency; failure reproduced.\"\n- \"Issue is not a one-off transient; continuing root-cause investigation.\"\n\n### Retry not attempted\n\n- \"Likely transient error observed, but retry was not safe due to non-idempotent side effects.\"\n\n## Guardrails\n\n### Do\n\n- retry once\n- retry the smallest possible unit\n- keep inputs unchanged\n- record what happened\n- use the retry result to guide next steps\n\n### Do not\n\n- keep retrying until success\n- modify code before confirming reproducibility\n- rerun a large workflow when a smaller reproduction is available\n- hide the fact that the first failure occurred\n- assume success on retry means the system is healthy\n\n## Example workflow\n\n### Example 1: Upstream 502 during a task\n\n1. A command fails with HTTP 502 from a dependency.\n2. No local code changes explain it.\n3. Rerun the same command once with the same inputs.\n4. If it succeeds, record:\n - \"Initial 502 appears transient; single retry succeeded.\"\n5. Continue without code changes.\n\n### Example 2: Timeout during CI dependency fetch\n\n1. Dependency download times out.\n2. Retry only the fetch step once.\n3. If it times out again, record:\n - \"Single retry reproduced timeout; investigating network/dependency issue.\"\n4. Move into deeper diagnosis.\n\n## Why this works\n\nA single minimal retry is a fast diagnostic tool:\n\n- low effort\n- low risk when safe\n- preserves signal\n- prevents premature debugging\n- separates intermittent infrastructure instability from true reproducible defects\n\nThis is especially useful in automated environments, CI systems, remote execution, and tasks that depend on external services.\n\n## Completion checklist\n\nBefore finishing, confirm:\n\n- [ ] The error was plausibly transient\n- [ ] Retry was safe\n- [ ] Only one minimal retry was performed\n- [ ] No code/config changes were made before the retry\n- [ ] The retry outcome was explicitly documented\n- [ ] Next actions were chosen based on whether the issue reproduced" + }, + "created_at": "2026-04-12T02:38:19.517472", + "created_by": "" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:38:19.517476", + "last_updated": "2026-04-12T02:38:19.517477" + }, + { + "skill_id": "verify-before-confirming__v1_acf0d1bc", + "name": "verify-before-confirming", + "description": "Require a minimal evidence check before asserting that a status or success condition is true.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/verify-before-confirming/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "imported", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": null, + "change_summary": "", + "content_diff": "--- a/.upload_meta.json\n+++ b/.upload_meta.json\n@@ -0,0 +1,9 @@\n+{\n+ \"origin\": \"fixed\",\n+ \"parent_skill_ids\": [\n+ \"verify-before-confirming__v0_109e009a\"\n+ ],\n+ \"change_summary\": \"Added claim-matching verification guidance so confirmations must validate the exact named tool or report the claim as unverified.\",\n+ \"created_by\": \"openspace\",\n+ \"tags\": []\n+}\n\n--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,126 @@\n+---\n+name: verify-before-confirming\n+description: Require a minimal evidence check before asserting that a status or success condition is true.\n+---\n+\n+# Verify Before Confirming\n+\n+Use this workflow when a task asks for status confirmation, success confirmation, or a short “is it working?” answer. Do not assert success based only on expectation, prior context, or a single unverified statement. First perform at least one lightweight verification step, then answer briefly with the verified result.\n+\n+## When to Use\n+\n+Apply this skill when the user asks you to confirm whether something is:\n+\n+- working\n+- complete\n+- running\n+- connected\n+- deployed\n+- fixed\n+- available\n+- healthy\n+- successful\n+\n+Examples:\n+\n+- “Confirm the relay is working.”\n+- “Is the service up?”\n+- “Check whether the job completed.”\n+- “Verify the recording was saved.”\n+- “Make sure the integration is active.”\n+\n+## Workflow\n+\n+1. Identify the claim being confirmed.\n+ - Example: “The relay is working.”\n+ - Example: “The build completed successfully.”\n+ - Example: “The recording exists.”\n+\n+2. Choose the smallest available verification method.\n+ Prefer the least invasive check that can provide real evidence, such as:\n+ - reading recent logs\n+ - checking a status endpoint\n+ - listing expected output files\n+ - inspecting a recording/artifact\n+ - running a diagnostic command\n+ - checking a process, job, or service status\n+ - verifying timestamps, exit codes, or health checks\n+ The verification must match the exact claim being confirmed. Do not substitute a nearby or weaker check that only shows general availability, routing, or partial system access.\n+\n+ - If the claim names a specific tool, service, artifact, integration, or endpoint, verify that named thing directly when possible.\n+ - Do not treat generic introspection, provider discovery, or session visibility as proof that a specific tool invocation works unless the claim is specifically about introspection or discovery.\n+ - For tool-availability or connectivity claims, prefer directly invoking or inspecting the named tool itself with a safe read-only or no-op check when available.\n+ - If the specific thing cannot be inspected or invoked, say the claim remains unverified rather than inferring success from related signals.\n+\n+3. Run or inspect the verification source before responding.\n+ Do not skip this step unless no verification source or tool access exists.\n+\n+4. Interpret the evidence conservatively.\n+ - If the check passes, say what was verified.\n+ - If the check is inconclusive, say it is inconclusive and mention what was checked.\n+ - If the check fails, state the failure rather than asserting success.\n+ - If the evidence only confirms a related capability but not the exact claim, explicitly say that the exact claim was not verified.\n+\n+5. Final answer: one short sentence when the user requested only confirmation.\n+ Include the verified evidence in compressed form.\n+\n+## Response Patterns\n+\n+Verified success:\n+\n+“Verified: the service health check returned OK.”\n+\n+“Confirmed: the latest log shows the relay connected successfully.”\n+\n+“Verified: the expected recording file exists and was updated today.”\n+\n+Inconclusive:\n+\n+“I couldn’t fully confirm it; the process is running, but no recent success log was available.”\n+\n+“Status is inconclusive: the endpoint responded, but the expected artifact was not present.”\n+\n+Failure:\n+\n+“Not confirmed: the diagnostic command failed with a connection timeout.”\n+\n+“Not working yet: the latest log shows authentication errors.”\n+\n+## Rules\n+\n+- Do not mark a status-confirmation task complete without checking at least one available evidence source.\n+- The evidence source must be relevant to the exact claim, not just to a neighboring capability or tool path.\n+- Do not claim success merely because no error is visible.\n+- Do not treat tool listing, backend/provider discovery, or session metadata as confirmation that a specific named tool executes successfully unless that exact execution claim was tested.\n+- When asked whether a particular tool is available, connected, or working, validate that specific tool directly when possible; otherwise report that the claim is unverified.\n+- Do not over-verify if the task only needs a simple confirmation; one relevant check is usually enough.\n+- Keep the final answer concise, especially when the user asked for a simple status confirmation.\n+- If tools are unavailable, say so explicitly and avoid pretending verification occurred.\n+\n+## Minimal Verification Examples\n+\n+For a service:\n+\n+1. Run a health/status command or check recent logs.\n+2. Reply: “Verified: the health check reports the service is running.”\n+\n+For a file or recording:\n+\n+1. List or inspect the expected artifact path.\n+2. Reply: “Verified: the recording file exists and has a recent timestamp.”\n+\n+For a relay, integration, or connection:\n+\n+1. Check logs, events, or a diagnostic command showing recent activity.\n+2. Reply: “Confirmed: recent logs show the relay connected and forwarded traffic.”\n+\n+For a background job:\n+\n+1. Check job status, exit code, or output artifact.\n+2. Reply: “Verified: the job completed successfully with exit code 0.”\n+\n+For a named tool or tool-connectivity claim:\n+\n+1. Verify the specifically named tool directly, ideally with a safe invocation or direct inspection of that tool's availability/status.\n+2. Do not rely only on provider listing, session lookup, or presence of other tools as a proxy.\n+3. Reply: “Verified: the named tool responded to a read-only check.” or “Unverified: I could inspect the provider, but I could not directly confirm the named tool.”\n", + "content_snapshot": { + ".upload_meta.json": "{\n \"origin\": \"fixed\",\n \"parent_skill_ids\": [\n \"verify-before-confirming__v0_109e009a\"\n ],\n \"change_summary\": \"Added claim-matching verification guidance so confirmations must validate the exact named tool or report the claim as unverified.\",\n \"created_by\": \"openspace\",\n \"tags\": []\n}\n", + "SKILL.md": "---\nname: verify-before-confirming\ndescription: Require a minimal evidence check before asserting that a status or success condition is true.\n---\n\n# Verify Before Confirming\n\nUse this workflow when a task asks for status confirmation, success confirmation, or a short “is it working?” answer. Do not assert success based only on expectation, prior context, or a single unverified statement. First perform at least one lightweight verification step, then answer briefly with the verified result.\n\n## When to Use\n\nApply this skill when the user asks you to confirm whether something is:\n\n- working\n- complete\n- running\n- connected\n- deployed\n- fixed\n- available\n- healthy\n- successful\n\nExamples:\n\n- “Confirm the relay is working.”\n- “Is the service up?”\n- “Check whether the job completed.”\n- “Verify the recording was saved.”\n- “Make sure the integration is active.”\n\n## Workflow\n\n1. Identify the claim being confirmed.\n - Example: “The relay is working.”\n - Example: “The build completed successfully.”\n - Example: “The recording exists.”\n\n2. Choose the smallest available verification method.\n Prefer the least invasive check that can provide real evidence, such as:\n - reading recent logs\n - checking a status endpoint\n - listing expected output files\n - inspecting a recording/artifact\n - running a diagnostic command\n - checking a process, job, or service status\n - verifying timestamps, exit codes, or health checks\n The verification must match the exact claim being confirmed. Do not substitute a nearby or weaker check that only shows general availability, routing, or partial system access.\n\n - If the claim names a specific tool, service, artifact, integration, or endpoint, verify that named thing directly when possible.\n - Do not treat generic introspection, provider discovery, or session visibility as proof that a specific tool invocation works unless the claim is specifically about introspection or discovery.\n - For tool-availability or connectivity claims, prefer directly invoking or inspecting the named tool itself with a safe read-only or no-op check when available.\n - If the specific thing cannot be inspected or invoked, say the claim remains unverified rather than inferring success from related signals.\n\n3. Run or inspect the verification source before responding.\n Do not skip this step unless no verification source or tool access exists.\n\n4. Interpret the evidence conservatively.\n - If the check passes, say what was verified.\n - If the check is inconclusive, say it is inconclusive and mention what was checked.\n - If the check fails, state the failure rather than asserting success.\n - If the evidence only confirms a related capability but not the exact claim, explicitly say that the exact claim was not verified.\n\n5. Final answer: one short sentence when the user requested only confirmation.\n Include the verified evidence in compressed form.\n\n## Response Patterns\n\nVerified success:\n\n“Verified: the service health check returned OK.”\n\n“Confirmed: the latest log shows the relay connected successfully.”\n\n“Verified: the expected recording file exists and was updated today.”\n\nInconclusive:\n\n“I couldn’t fully confirm it; the process is running, but no recent success log was available.”\n\n“Status is inconclusive: the endpoint responded, but the expected artifact was not present.”\n\nFailure:\n\n“Not confirmed: the diagnostic command failed with a connection timeout.”\n\n“Not working yet: the latest log shows authentication errors.”\n\n## Rules\n\n- Do not mark a status-confirmation task complete without checking at least one available evidence source.\n- The evidence source must be relevant to the exact claim, not just to a neighboring capability or tool path.\n- Do not claim success merely because no error is visible.\n- Do not treat tool listing, backend/provider discovery, or session metadata as confirmation that a specific named tool executes successfully unless that exact execution claim was tested.\n- When asked whether a particular tool is available, connected, or working, validate that specific tool directly when possible; otherwise report that the claim is unverified.\n- Do not over-verify if the task only needs a simple confirmation; one relevant check is usually enough.\n- Keep the final answer concise, especially when the user asked for a simple status confirmation.\n- If tools are unavailable, say so explicitly and avoid pretending verification occurred.\n\n## Minimal Verification Examples\n\nFor a service:\n\n1. Run a health/status command or check recent logs.\n2. Reply: “Verified: the health check reports the service is running.”\n\nFor a file or recording:\n\n1. List or inspect the expected artifact path.\n2. Reply: “Verified: the recording file exists and has a recent timestamp.”\n\nFor a relay, integration, or connection:\n\n1. Check logs, events, or a diagnostic command showing recent activity.\n2. Reply: “Confirmed: recent logs show the relay connected and forwarded traffic.”\n\nFor a background job:\n\n1. Check job status, exit code, or output artifact.\n2. Reply: “Verified: the job completed successfully with exit code 0.”\n\nFor a named tool or tool-connectivity claim:\n\n1. Verify the specifically named tool directly, ideally with a safe invocation or direct inspection of that tool's availability/status.\n2. Do not rely only on provider listing, session lookup, or presence of other tools as a proxy.\n3. Reply: “Verified: the named tool responded to a read-only check.” or “Unverified: I could inspect the provider, but I could not directly confirm the named tool.”\n" + }, + "created_at": "2026-04-12T02:38:19.518081", + "created_by": "" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:38:19.518083", + "last_updated": "2026-04-12T02:38:19.518084" + } +] \ No newline at end of file diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/config.json b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/config.json new file mode 100644 index 0000000..79e4c8f --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/config.json @@ -0,0 +1,23 @@ +{ + "clawwork_root": "/tmp/openspace-bench-noref-JwyV4l", + "gdpval_path": null, + "model": "gpt-5.4", + "max_iterations": 20, + "backend_scope": [ + "shell" + ], + "use_clawwork_productivity": false, + "run_name": "codex_callrate_smoke_noref_fix", + "max_tasks": 2, + "per_occupation": null, + "sectors": null, + "occupations": null, + "task_ids": null, + "record_call_details": true, + "llm_kwargs": { + "api_key": "REDACTED", + "api_base": "http://127.0.0.1:8080/v1" + }, + "enable_evaluation": false, + "concurrency": 1 +} diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/phase1_results.jsonl b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/phase1_results.jsonl new file mode 100644 index 0000000..2aa1076 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/phase1_results.jsonl @@ -0,0 +1,2 @@ +{"task_id": "0112fc9b-c3b2-4084-8993-5a4abb1f54f1", "phase": "phase1", "occupation": "Nurse Practitioners", "sector": "Health Care and Social Assistance", "task_value_usd": 0.0, "status": "success", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 93.54, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 1, "tool_calls": 0, "time_sec": 93.54}, "skills": {"before": 3, "after": 4, "new_this_task": 1, "evolved": [{"name": "clinical-soap-note-from-narrative-enhanced", "origin": "derived", "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/clinical-soap-note-from-narrative-enhanced/SKILL.md"}], "used": ["clinical-soap-note-from-narrative__v0_9ff620af"]}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:50:48.493407"} +{"task_id": "02314fc6-a24e-42f4-a8cd-362cae0f0ec1", "phase": "phase1", "occupation": "General and Operations Managers", "sector": "Retail Trade", "task_value_usd": 0.0, "status": "success", "tokens": {"prompt_tokens": 0, "completion_tokens": 0, "total_tokens": 0, "llm_calls": 0, "cost_usd": 0.0, "wall_time_sec": 269.94, "agent_prompt_tokens": 0, "agent_completion_tokens": 0, "agent_total_tokens": 0, "agent_llm_calls": 0, "call_details": []}, "execution": {"iterations": 10, "tool_calls": 10, "time_sec": 269.94}, "skills": {"before": 4, "after": 6, "new_this_task": 2, "evolved": [{"name": "adaptive-document-output", "origin": "captured", "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/adaptive-document-output/SKILL.md"}, {"name": "verify-build-artifacts", "origin": "captured", "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/verify-build-artifacts/SKILL.md"}], "used": []}, "evaluation": {"has_evaluation": false}, "timestamp": "2026-04-12T02:55:18.445041"} diff --git a/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/skills_snapshot.json b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/skills_snapshot.json new file mode 100644 index 0000000..a609ab2 --- /dev/null +++ b/context/local-machine/admin-macos/gdpval_bench/codex_callrate_smoke_noref_fix/skills_snapshot.json @@ -0,0 +1,232 @@ +[ + { + "skill_id": "clinical-soap-note-from-narrative__v0_9ff620af", + "name": "clinical-soap-note-from-narrative", + "description": "Convert a narrative clinical encounter into a structured SOAP note by separating subjective and objective data, generating a problem-focused assessment, and adding an appropriate safety-conscious plan when red flags or neurologic abnormalities are present.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/clinical-soap-note-from-narrative/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "imported", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": null, + "change_summary": "", + "content_diff": "--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,207 @@\n+---\n+name: clinical-soap-note-from-narrative\n+description: Convert a narrative clinical encounter into a structured SOAP note by separating subjective and objective data, generating a problem-focused assessment, and adding an appropriate safety-conscious plan when red flags or neurologic abnormalities are present.\n+---\n+\n+# Clinical SOAP Note From Narrative\n+\n+Use this skill when you are given a free-text clinical encounter, visit summary, or narrative case description and need to produce a structured SOAP note.\n+\n+This workflow is designed to:\n+- preserve the distinction between patient-reported history and clinician-observed findings\n+- avoid inventing exam findings, diagnostics, or treatment details\n+- produce a concise, problem-focused assessment\n+- add an appropriately cautious plan when red-flag symptoms or abnormal neurologic findings are described\n+\n+## Core principles\n+\n+1. Do not add facts that were not provided.\n+2. Keep subjective and objective information separated.\n+3. Preserve uncertainty when the source is uncertain.\n+4. Make the assessment clinically coherent but problem-focused.\n+5. Escalate the plan when the narrative includes red flags, worsening symptoms, or abnormal neurologic findings.\n+6. If the source lacks information, omit it or mark it as not provided rather than fabricating content.\n+\n+## Step-by-step workflow\n+\n+### 1) Read the encounter and extract source facts\n+\n+Identify and group all explicit facts from the narrative into:\n+- symptoms and history\n+- timing and progression\n+- relevant negatives\n+- exam findings\n+- prior treatments or self-care\n+- clinician impression or likely diagnosis if stated\n+- follow-up or return precautions if stated\n+\n+Before drafting, mentally separate:\n+- Subjective = what the patient reports, describes, denies, or experiences\n+- Objective = observed exam findings, measured values, test results, and clinician-documented physical findings\n+\n+### 2) Build the Subjective section\n+\n+Include only history elements supported by the narrative:\n+- chief concern\n+- onset, duration, course\n+- associated symptoms\n+- aggravating/alleviating factors\n+- pertinent negatives\n+- relevant prior history or attempted treatments, if provided\n+\n+Keep it concise and clinical. Rewrite into standard medical style without changing meaning.\n+\n+Example transformation:\n+- Narrative: \"He says the headache started 3 days ago, is getting worse, and now he has tingling in his left arm.\"\n+- Subjective: \"Reports 3 days of worsening headache with associated left arm tingling.\"\n+\n+### 3) Build the Objective section\n+\n+Include only documented objective data:\n+- vital signs, if given\n+- physical exam findings\n+- neurologic findings\n+- imaging/lab results, if given\n+\n+Important:\n+- Do not infer a normal exam if none was described.\n+- Do not add routine headings with normal findings unless explicitly provided.\n+- If the exam is sparse, keep the Objective sparse.\n+\n+Good:\n+- \"Neuro: Decreased sensation in left upper extremity.\"\n+Avoid:\n+- \"CN II-XII intact\" unless the narrative explicitly states this.\n+\n+### 4) Write a problem-focused Assessment\n+\n+Synthesize the likely clinical issue using only the available facts.\n+\n+The assessment should:\n+- summarize the main problem in 1-3 sentences\n+- mention key supporting features\n+- note important uncertainty when present\n+- avoid overcommitting to a diagnosis not established in the source\n+\n+Preferred style:\n+- \"Presentation is concerning for...\"\n+- \"Symptoms are most consistent with...\"\n+- \"Given X and Y, cannot exclude...\"\n+\n+If the narrative includes neurologic deficits, red-flag symptoms, or concerning progression, the assessment should explicitly reflect concern rather than minimizing it.\n+\n+Example:\n+- \"Worsening headache with unilateral sensory symptoms is concerning for a neurologic process and warrants urgent evaluation; benign primary headache cannot be assumed from the available information.\"\n+\n+### 5) Write the Plan with safety escalation when warranted\n+\n+Base the plan on what is provided, but structure it clearly.\n+\n+Possible plan components:\n+- symptomatic treatment already recommended or used\n+- monitoring or follow-up\n+- diagnostic evaluation if stated or clearly warranted by the narrative\n+- return precautions / emergency precautions\n+\n+When red flags are present, include a safety-conscious plan such as:\n+- urgent ED evaluation\n+- same-day in-person neurologic assessment\n+- immediate imaging/workup if the narrative supports that urgency\n+- explicit return precautions for worsening weakness, numbness, severe headache, speech changes, vision changes, gait instability, altered mental status, bowel/bladder dysfunction, fever, or other relevant warning signs\n+\n+Do not understate urgency if the input includes:\n+- focal neurologic deficits\n+- new weakness or numbness\n+- severe or worsening headache with neuro symptoms\n+- altered mental status\n+- seizure\n+- saddle anesthesia or bowel/bladder changes\n+- rapidly progressive symptoms\n+- other clearly dangerous features\n+\n+### 6) Final quality check\n+\n+Before finalizing, verify:\n+- no invented vitals, exam findings, or test results\n+- subjective and objective are not mixed\n+- assessment reflects the actual level of concern\n+- plan contains clear escalation when red flags are present\n+- note is concise and clinically readable\n+\n+## SOAP note template\n+\n+Use this structure:\n+\n+Subjective:\n+- [Chief concern and history in concise prose or bullets]\n+\n+Objective:\n+- [Only provided exam findings, vitals, tests]\n+\n+Assessment:\n+- [Focused synthesis of the main clinical issue, including uncertainty or concern]\n+\n+Plan:\n+- [Treatment / next steps / follow-up / precautions]\n+\n+## Safety trigger guide\n+\n+Escalate the plan when the narrative includes any of the following:\n+- focal neurologic deficit\n+- progressive neurologic symptoms\n+- new unilateral weakness or numbness\n+- severe or worsening headache with neurologic symptoms\n+- syncope, seizure, confusion, or altered mental status\n+- bowel/bladder dysfunction with spine symptoms\n+- rapidly worsening pain plus neurologic changes\n+- other explicitly concerning clinician findings\n+\n+Suggested plan language:\n+- \"Given the presence of red-flag symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.\"\n+- \"Patient was advised to seek immediate care for any worsening weakness, numbness, severe headache, vision change, speech difficulty, gait instability, or other new neurologic symptoms.\"\n+\n+## Style guidance\n+\n+- Be concise.\n+- Use neutral clinical language.\n+- Prefer \"reports,\" \"endorses,\" \"denies,\" \"exam notable for,\" \"concerning for.\"\n+- If details are missing, do not compensate by guessing.\n+- If the source already includes a likely diagnosis or plan, preserve it faithfully in cleaner SOAP format.\n+\n+## Example\n+\n+Input narrative:\n+\"Patient reports low back pain for 1 week after lifting a box. Over the last 2 days, pain radiates down the right leg with numbness in the right foot. Exam shows decreased sensation over the dorsum of the right foot and positive straight-leg raise on the right. No bowel or bladder symptoms mentioned.\"\n+\n+Output:\n+Subjective:\n+- Reports 1 week of low back pain after lifting injury, with 2 days of radiation down the right leg and associated numbness in the right foot.\n+\n+Objective:\n+- Exam notable for decreased sensation over the dorsum of the right foot.\n+- Positive straight-leg raise on the right.\n+\n+Assessment:\n+- Acute low back pain with right-sided radicular symptoms and objective sensory deficit, concerning for lumbar radiculopathy. Given the documented neurologic abnormality, symptoms warrant prompt in-person evaluation and close monitoring for progression.\n+\n+Plan:\n+- Recommend prompt clinical follow-up/in-person evaluation.\n+- Advise immediate emergency evaluation for new or worsening weakness, progressive numbness, saddle anesthesia, bowel or bladder dysfunction, fever, or uncontrolled pain.\n+\n+## Common mistakes to avoid\n+\n+- Moving patient-reported symptoms into Objective\n+- Adding normal findings that were never stated\n+- Writing an assessment that ignores documented red flags\n+- Producing a routine conservative plan despite focal neurologic deficits\n+- Inventing medications, dosages, imaging, or follow-up intervals\n+- Overly broad differentials that distract from the main problem\n+\n+## Minimal decision rule\n+\n+If the case is routine and non-concerning:\n+- produce a standard SOAP note faithful to the narrative\n+\n+If the case includes red flags or abnormal neurologic findings:\n+- make the assessment explicitly cautious\n+- make the plan explicitly safety-oriented and escalated", + "content_snapshot": { + "SKILL.md": "---\nname: clinical-soap-note-from-narrative\ndescription: Convert a narrative clinical encounter into a structured SOAP note by separating subjective and objective data, generating a problem-focused assessment, and adding an appropriate safety-conscious plan when red flags or neurologic abnormalities are present.\n---\n\n# Clinical SOAP Note From Narrative\n\nUse this skill when you are given a free-text clinical encounter, visit summary, or narrative case description and need to produce a structured SOAP note.\n\nThis workflow is designed to:\n- preserve the distinction between patient-reported history and clinician-observed findings\n- avoid inventing exam findings, diagnostics, or treatment details\n- produce a concise, problem-focused assessment\n- add an appropriately cautious plan when red-flag symptoms or abnormal neurologic findings are described\n\n## Core principles\n\n1. Do not add facts that were not provided.\n2. Keep subjective and objective information separated.\n3. Preserve uncertainty when the source is uncertain.\n4. Make the assessment clinically coherent but problem-focused.\n5. Escalate the plan when the narrative includes red flags, worsening symptoms, or abnormal neurologic findings.\n6. If the source lacks information, omit it or mark it as not provided rather than fabricating content.\n\n## Step-by-step workflow\n\n### 1) Read the encounter and extract source facts\n\nIdentify and group all explicit facts from the narrative into:\n- symptoms and history\n- timing and progression\n- relevant negatives\n- exam findings\n- prior treatments or self-care\n- clinician impression or likely diagnosis if stated\n- follow-up or return precautions if stated\n\nBefore drafting, mentally separate:\n- Subjective = what the patient reports, describes, denies, or experiences\n- Objective = observed exam findings, measured values, test results, and clinician-documented physical findings\n\n### 2) Build the Subjective section\n\nInclude only history elements supported by the narrative:\n- chief concern\n- onset, duration, course\n- associated symptoms\n- aggravating/alleviating factors\n- pertinent negatives\n- relevant prior history or attempted treatments, if provided\n\nKeep it concise and clinical. Rewrite into standard medical style without changing meaning.\n\nExample transformation:\n- Narrative: \"He says the headache started 3 days ago, is getting worse, and now he has tingling in his left arm.\"\n- Subjective: \"Reports 3 days of worsening headache with associated left arm tingling.\"\n\n### 3) Build the Objective section\n\nInclude only documented objective data:\n- vital signs, if given\n- physical exam findings\n- neurologic findings\n- imaging/lab results, if given\n\nImportant:\n- Do not infer a normal exam if none was described.\n- Do not add routine headings with normal findings unless explicitly provided.\n- If the exam is sparse, keep the Objective sparse.\n\nGood:\n- \"Neuro: Decreased sensation in left upper extremity.\"\nAvoid:\n- \"CN II-XII intact\" unless the narrative explicitly states this.\n\n### 4) Write a problem-focused Assessment\n\nSynthesize the likely clinical issue using only the available facts.\n\nThe assessment should:\n- summarize the main problem in 1-3 sentences\n- mention key supporting features\n- note important uncertainty when present\n- avoid overcommitting to a diagnosis not established in the source\n\nPreferred style:\n- \"Presentation is concerning for...\"\n- \"Symptoms are most consistent with...\"\n- \"Given X and Y, cannot exclude...\"\n\nIf the narrative includes neurologic deficits, red-flag symptoms, or concerning progression, the assessment should explicitly reflect concern rather than minimizing it.\n\nExample:\n- \"Worsening headache with unilateral sensory symptoms is concerning for a neurologic process and warrants urgent evaluation; benign primary headache cannot be assumed from the available information.\"\n\n### 5) Write the Plan with safety escalation when warranted\n\nBase the plan on what is provided, but structure it clearly.\n\nPossible plan components:\n- symptomatic treatment already recommended or used\n- monitoring or follow-up\n- diagnostic evaluation if stated or clearly warranted by the narrative\n- return precautions / emergency precautions\n\nWhen red flags are present, include a safety-conscious plan such as:\n- urgent ED evaluation\n- same-day in-person neurologic assessment\n- immediate imaging/workup if the narrative supports that urgency\n- explicit return precautions for worsening weakness, numbness, severe headache, speech changes, vision changes, gait instability, altered mental status, bowel/bladder dysfunction, fever, or other relevant warning signs\n\nDo not understate urgency if the input includes:\n- focal neurologic deficits\n- new weakness or numbness\n- severe or worsening headache with neuro symptoms\n- altered mental status\n- seizure\n- saddle anesthesia or bowel/bladder changes\n- rapidly progressive symptoms\n- other clearly dangerous features\n\n### 6) Final quality check\n\nBefore finalizing, verify:\n- no invented vitals, exam findings, or test results\n- subjective and objective are not mixed\n- assessment reflects the actual level of concern\n- plan contains clear escalation when red flags are present\n- note is concise and clinically readable\n\n## SOAP note template\n\nUse this structure:\n\nSubjective:\n- [Chief concern and history in concise prose or bullets]\n\nObjective:\n- [Only provided exam findings, vitals, tests]\n\nAssessment:\n- [Focused synthesis of the main clinical issue, including uncertainty or concern]\n\nPlan:\n- [Treatment / next steps / follow-up / precautions]\n\n## Safety trigger guide\n\nEscalate the plan when the narrative includes any of the following:\n- focal neurologic deficit\n- progressive neurologic symptoms\n- new unilateral weakness or numbness\n- severe or worsening headache with neurologic symptoms\n- syncope, seizure, confusion, or altered mental status\n- bowel/bladder dysfunction with spine symptoms\n- rapidly worsening pain plus neurologic changes\n- other explicitly concerning clinician findings\n\nSuggested plan language:\n- \"Given the presence of red-flag symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.\"\n- \"Patient was advised to seek immediate care for any worsening weakness, numbness, severe headache, vision change, speech difficulty, gait instability, or other new neurologic symptoms.\"\n\n## Style guidance\n\n- Be concise.\n- Use neutral clinical language.\n- Prefer \"reports,\" \"endorses,\" \"denies,\" \"exam notable for,\" \"concerning for.\"\n- If details are missing, do not compensate by guessing.\n- If the source already includes a likely diagnosis or plan, preserve it faithfully in cleaner SOAP format.\n\n## Example\n\nInput narrative:\n\"Patient reports low back pain for 1 week after lifting a box. Over the last 2 days, pain radiates down the right leg with numbness in the right foot. Exam shows decreased sensation over the dorsum of the right foot and positive straight-leg raise on the right. No bowel or bladder symptoms mentioned.\"\n\nOutput:\nSubjective:\n- Reports 1 week of low back pain after lifting injury, with 2 days of radiation down the right leg and associated numbness in the right foot.\n\nObjective:\n- Exam notable for decreased sensation over the dorsum of the right foot.\n- Positive straight-leg raise on the right.\n\nAssessment:\n- Acute low back pain with right-sided radicular symptoms and objective sensory deficit, concerning for lumbar radiculopathy. Given the documented neurologic abnormality, symptoms warrant prompt in-person evaluation and close monitoring for progression.\n\nPlan:\n- Recommend prompt clinical follow-up/in-person evaluation.\n- Advise immediate emergency evaluation for new or worsening weakness, progressive numbness, saddle anesthesia, bowel or bladder dysfunction, fever, or uncontrolled pain.\n\n## Common mistakes to avoid\n\n- Moving patient-reported symptoms into Objective\n- Adding normal findings that were never stated\n- Writing an assessment that ignores documented red flags\n- Producing a routine conservative plan despite focal neurologic deficits\n- Inventing medications, dosages, imaging, or follow-up intervals\n- Overly broad differentials that distract from the main problem\n\n## Minimal decision rule\n\nIf the case is routine and non-concerning:\n- produce a standard SOAP note faithful to the narrative\n\nIf the case includes red flags or abnormal neurologic findings:\n- make the assessment explicitly cautious\n- make the plan explicitly safety-oriented and escalated" + }, + "created_at": "2026-04-12T02:49:14.949441", + "created_by": "" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 1, + "total_applied": 1, + "total_completions": 1, + "total_fallbacks": 0, + "recent_analyses": [ + { + "task_id": "0112fc9b-c3b2-4084-8993-5a4abb1f54f1_phase1", + "timestamp": "2026-04-12T02:49:41.395922", + "task_completed": true, + "execution_note": "The agent completed the task in a single iteration by producing a structured SOAP note from the narrative visit summary. The note largely preserved subjective versus objective data and appropriately escalated the plan because the case included post-traumatic headache with a documented mild coordination deficit, although it added a few plan details not explicitly stated in the source.", + "tool_issues": [], + "skill_judgments": [ + { + "skill_id": "clinical-soap-note-from-narrative__v0_9ff620af", + "skill_applied": true, + "note": "The agent effectively followed the skill's core workflow: it converted the narrative into Subjective/Objective sections without inventing exam findings, synthesized a focused assessment, and recognized the abnormal neurologic finding as a safety trigger warranting urgent escalation. Minor deviation: the plan included extra management specifics such as cognitive rest, no driving, and informing a parent/guardian, which were clinically reasonable but not directly provided in the source." + } + ], + "evolution_suggestions": [ + { + "type": "derived", + "target_skills": [ + "clinical-soap-note-from-narrative__v0_9ff620af" + ], + "target_skill": "clinical-soap-note-from-narrative__v0_9ff620af", + "category": "workflow", + "direction": "Create an enhanced version that explicitly handles adolescent head injury/concussion encounters by distinguishing when it is appropriate to add standard safety counseling beyond the source narrative versus when to remain strictly extractive. This would help preserve the skill's non-fabrication rule while still supporting clinically expected anticipatory guidance in red-flag trauma cases." + } + ], + "analyzed_by": "", + "analyzed_at": "2026-04-12T02:49:41.395922" + } + ], + "first_seen": "2026-04-12T02:49:14.949447", + "last_updated": "2026-04-12T02:49:41.397517" + }, + { + "skill_id": "single-retry-transient-failures__v0_cb599f5d", + "name": "single-retry-transient-failures", + "description": "Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/single-retry-transient-failures/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "imported", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": null, + "change_summary": "", + "content_diff": "--- a/.upload_meta.json\n+++ b/.upload_meta.json\n@@ -0,0 +1,7 @@\n+{\n+ \"origin\": \"captured\",\n+ \"parent_skill_ids\": [],\n+ \"change_summary\": \"Captured a workflow for handling likely transient upstream failures by doing one minimal retry first and explicitly recording whether the issue is intermittent or reproducible.\",\n+ \"created_by\": \"gpt-5.4\",\n+ \"tags\": []\n+}\n\n--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,228 @@\n+---\n+name: single-retry-transient-failures\n+description: Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.\n+---\n+\n+# Single Retry for Transient Failures\n+\n+## Purpose\n+\n+Use this workflow when a task fails with a likely transient infrastructure problem, such as:\n+\n+- HTTP 5xx from an upstream service\n+- gateway/proxy failures like 502, 503, 504\n+- temporary connection resets or timeouts\n+- rate-limit edge cases that may clear immediately\n+- brief platform instability not obviously caused by local changes\n+\n+The goal is to quickly distinguish:\n+\n+- transient platform instability, vs.\n+- a reproducible product or code issue\n+\n+This avoids wasting time debugging or changing code before confirming the problem persists.\n+\n+## When to use this\n+\n+Apply this skill when all of the following are true:\n+\n+1. The failure appears external or infrastructural.\n+2. There is no strong evidence yet that a recent code/config change caused it.\n+3. Retrying once is low-risk and does not create harmful side effects.\n+4. You can re-run the smallest possible failing step.\n+\n+Do not use this as an excuse for repeated blind retries.\n+\n+## Core rule\n+\n+Before deeper investigation, perform exactly one minimal retry of the failing operation.\n+\n+- Minimal retry = rerun only the smallest step needed to test whether the issue persists.\n+- One retry only = enough to test intermittency without masking a real defect.\n+\n+After the retry, explicitly record the outcome.\n+\n+## Procedure\n+\n+### 1) Confirm the error looks transient\n+\n+Treat the issue as potentially transient if signals include:\n+\n+- HTTP 502/503/504\n+- upstream service unavailable\n+- network timeout during dependency call\n+- temporary DNS/TLS/proxy/connectivity failure\n+- infrastructure-generated error page\n+- job failure with no local stack trace pointing to your code\n+\n+If the error clearly points to deterministic local logic, skip this skill and debug normally.\n+\n+### 2) Check retry safety\n+\n+Before retrying, verify:\n+\n+- rerunning will not duplicate destructive side effects\n+- rerunning will not create bad state\n+- if side effects exist, there is idempotency protection or safe rollback\n+- credentials, environment, and inputs remain unchanged\n+\n+If retry is unsafe, do not retry blindly. Instead document why and investigate more carefully.\n+\n+### 3) Perform one minimal retry\n+\n+Retry only the failing step, not the entire workflow unless necessary.\n+\n+Examples:\n+\n+- rerun one API request, not the whole deployment\n+- rerun one test shard, not the whole test suite\n+- rerun one build/download step, not all CI jobs\n+- repeat the same command with the same inputs\n+\n+Keep the retry minimal:\n+\n+- same inputs\n+- same environment\n+- no code changes\n+- no config changes\n+- no workaround added yet\n+\n+This preserves the diagnostic value of the retry.\n+\n+### 4) Record both attempts clearly\n+\n+Capture:\n+\n+- original failure timestamp\n+- original error summary\n+- whether the retry used identical inputs\n+- retry result: passed or failed\n+- if failed again, whether the error is materially the same\n+\n+Use short, explicit wording so future follow-up can tell what happened.\n+\n+Example status notes:\n+\n+- \"Initial run failed with upstream 502. Performed one identical retry; retry succeeded. Treat as transient platform issue unless it recurs.\"\n+- \"Initial run failed with 503. One minimal retry failed with same 503. Issue appears reproducible; continue investigation.\"\n+- \"Initial timeout retried once and succeeded. No code changes made; likely intermittent dependency instability.\"\n+\n+### 5) Branch based on the retry result\n+\n+#### If the retry succeeds\n+\n+Conclude that the failure was likely intermittent.\n+\n+Then:\n+\n+- avoid unnecessary code changes\n+- note that the issue is not currently reproducible\n+- proceed with the task if appropriate\n+- flag possible platform instability if relevant\n+- monitor for recurrence\n+\n+Do not over-investigate unless:\n+- the task requires high confidence in reliability, or\n+- the same transient pattern is recurring often\n+\n+#### If the retry fails again\n+\n+Treat the issue as likely reproducible.\n+\n+Then:\n+\n+- begin deeper investigation\n+- inspect logs, traces, and recent changes\n+- isolate the failing subsystem\n+- consider fixes, mitigations, or escalations\n+\n+The single retry has now served its purpose: it ruled out a one-off blip.\n+\n+## Decision table\n+\n+| Situation | Action |\n+|---|---|\n+| Likely upstream/infrastructure 5xx, safe to retry | Retry once minimally |\n+| Retry succeeds | Record as likely transient; avoid unnecessary changes |\n+| Retry fails similarly | Treat as reproducible; investigate deeply |\n+| Retry unsafe due to side effects | Do not retry blindly; document and investigate safely |\n+| Error clearly caused by deterministic local logic | Skip this workflow |\n+\n+## Recommended phrasing for reports\n+\n+Use concise language that preserves diagnostic value.\n+\n+### Success on retry\n+\n+- \"Observed likely transient upstream failure; one minimal retry succeeded with no changes.\"\n+- \"Issue appears intermittent rather than reproducible.\"\n+- \"No product/code change made because retry cleared the failure.\"\n+\n+### Failure on retry\n+\n+- \"Performed one minimal retry to test intermittency; failure reproduced.\"\n+- \"Issue is not a one-off transient; continuing root-cause investigation.\"\n+\n+### Retry not attempted\n+\n+- \"Likely transient error observed, but retry was not safe due to non-idempotent side effects.\"\n+\n+## Guardrails\n+\n+### Do\n+\n+- retry once\n+- retry the smallest possible unit\n+- keep inputs unchanged\n+- record what happened\n+- use the retry result to guide next steps\n+\n+### Do not\n+\n+- keep retrying until success\n+- modify code before confirming reproducibility\n+- rerun a large workflow when a smaller reproduction is available\n+- hide the fact that the first failure occurred\n+- assume success on retry means the system is healthy\n+\n+## Example workflow\n+\n+### Example 1: Upstream 502 during a task\n+\n+1. A command fails with HTTP 502 from a dependency.\n+2. No local code changes explain it.\n+3. Rerun the same command once with the same inputs.\n+4. If it succeeds, record:\n+ - \"Initial 502 appears transient; single retry succeeded.\"\n+5. Continue without code changes.\n+\n+### Example 2: Timeout during CI dependency fetch\n+\n+1. Dependency download times out.\n+2. Retry only the fetch step once.\n+3. If it times out again, record:\n+ - \"Single retry reproduced timeout; investigating network/dependency issue.\"\n+4. Move into deeper diagnosis.\n+\n+## Why this works\n+\n+A single minimal retry is a fast diagnostic tool:\n+\n+- low effort\n+- low risk when safe\n+- preserves signal\n+- prevents premature debugging\n+- separates intermittent infrastructure instability from true reproducible defects\n+\n+This is especially useful in automated environments, CI systems, remote execution, and tasks that depend on external services.\n+\n+## Completion checklist\n+\n+Before finishing, confirm:\n+\n+- [ ] The error was plausibly transient\n+- [ ] Retry was safe\n+- [ ] Only one minimal retry was performed\n+- [ ] No code/config changes were made before the retry\n+- [ ] The retry outcome was explicitly documented\n+- [ ] Next actions were chosen based on whether the issue reproduced", + "content_snapshot": { + ".upload_meta.json": "{\n \"origin\": \"captured\",\n \"parent_skill_ids\": [],\n \"change_summary\": \"Captured a workflow for handling likely transient upstream failures by doing one minimal retry first and explicitly recording whether the issue is intermittent or reproducible.\",\n \"created_by\": \"gpt-5.4\",\n \"tags\": []\n}\n", + "SKILL.md": "---\nname: single-retry-transient-failures\ndescription: Perform one minimal retry for likely transient upstream or infrastructure errors before deeper investigation, and record whether the failure is intermittent or reproducible.\n---\n\n# Single Retry for Transient Failures\n\n## Purpose\n\nUse this workflow when a task fails with a likely transient infrastructure problem, such as:\n\n- HTTP 5xx from an upstream service\n- gateway/proxy failures like 502, 503, 504\n- temporary connection resets or timeouts\n- rate-limit edge cases that may clear immediately\n- brief platform instability not obviously caused by local changes\n\nThe goal is to quickly distinguish:\n\n- transient platform instability, vs.\n- a reproducible product or code issue\n\nThis avoids wasting time debugging or changing code before confirming the problem persists.\n\n## When to use this\n\nApply this skill when all of the following are true:\n\n1. The failure appears external or infrastructural.\n2. There is no strong evidence yet that a recent code/config change caused it.\n3. Retrying once is low-risk and does not create harmful side effects.\n4. You can re-run the smallest possible failing step.\n\nDo not use this as an excuse for repeated blind retries.\n\n## Core rule\n\nBefore deeper investigation, perform exactly one minimal retry of the failing operation.\n\n- Minimal retry = rerun only the smallest step needed to test whether the issue persists.\n- One retry only = enough to test intermittency without masking a real defect.\n\nAfter the retry, explicitly record the outcome.\n\n## Procedure\n\n### 1) Confirm the error looks transient\n\nTreat the issue as potentially transient if signals include:\n\n- HTTP 502/503/504\n- upstream service unavailable\n- network timeout during dependency call\n- temporary DNS/TLS/proxy/connectivity failure\n- infrastructure-generated error page\n- job failure with no local stack trace pointing to your code\n\nIf the error clearly points to deterministic local logic, skip this skill and debug normally.\n\n### 2) Check retry safety\n\nBefore retrying, verify:\n\n- rerunning will not duplicate destructive side effects\n- rerunning will not create bad state\n- if side effects exist, there is idempotency protection or safe rollback\n- credentials, environment, and inputs remain unchanged\n\nIf retry is unsafe, do not retry blindly. Instead document why and investigate more carefully.\n\n### 3) Perform one minimal retry\n\nRetry only the failing step, not the entire workflow unless necessary.\n\nExamples:\n\n- rerun one API request, not the whole deployment\n- rerun one test shard, not the whole test suite\n- rerun one build/download step, not all CI jobs\n- repeat the same command with the same inputs\n\nKeep the retry minimal:\n\n- same inputs\n- same environment\n- no code changes\n- no config changes\n- no workaround added yet\n\nThis preserves the diagnostic value of the retry.\n\n### 4) Record both attempts clearly\n\nCapture:\n\n- original failure timestamp\n- original error summary\n- whether the retry used identical inputs\n- retry result: passed or failed\n- if failed again, whether the error is materially the same\n\nUse short, explicit wording so future follow-up can tell what happened.\n\nExample status notes:\n\n- \"Initial run failed with upstream 502. Performed one identical retry; retry succeeded. Treat as transient platform issue unless it recurs.\"\n- \"Initial run failed with 503. One minimal retry failed with same 503. Issue appears reproducible; continue investigation.\"\n- \"Initial timeout retried once and succeeded. No code changes made; likely intermittent dependency instability.\"\n\n### 5) Branch based on the retry result\n\n#### If the retry succeeds\n\nConclude that the failure was likely intermittent.\n\nThen:\n\n- avoid unnecessary code changes\n- note that the issue is not currently reproducible\n- proceed with the task if appropriate\n- flag possible platform instability if relevant\n- monitor for recurrence\n\nDo not over-investigate unless:\n- the task requires high confidence in reliability, or\n- the same transient pattern is recurring often\n\n#### If the retry fails again\n\nTreat the issue as likely reproducible.\n\nThen:\n\n- begin deeper investigation\n- inspect logs, traces, and recent changes\n- isolate the failing subsystem\n- consider fixes, mitigations, or escalations\n\nThe single retry has now served its purpose: it ruled out a one-off blip.\n\n## Decision table\n\n| Situation | Action |\n|---|---|\n| Likely upstream/infrastructure 5xx, safe to retry | Retry once minimally |\n| Retry succeeds | Record as likely transient; avoid unnecessary changes |\n| Retry fails similarly | Treat as reproducible; investigate deeply |\n| Retry unsafe due to side effects | Do not retry blindly; document and investigate safely |\n| Error clearly caused by deterministic local logic | Skip this workflow |\n\n## Recommended phrasing for reports\n\nUse concise language that preserves diagnostic value.\n\n### Success on retry\n\n- \"Observed likely transient upstream failure; one minimal retry succeeded with no changes.\"\n- \"Issue appears intermittent rather than reproducible.\"\n- \"No product/code change made because retry cleared the failure.\"\n\n### Failure on retry\n\n- \"Performed one minimal retry to test intermittency; failure reproduced.\"\n- \"Issue is not a one-off transient; continuing root-cause investigation.\"\n\n### Retry not attempted\n\n- \"Likely transient error observed, but retry was not safe due to non-idempotent side effects.\"\n\n## Guardrails\n\n### Do\n\n- retry once\n- retry the smallest possible unit\n- keep inputs unchanged\n- record what happened\n- use the retry result to guide next steps\n\n### Do not\n\n- keep retrying until success\n- modify code before confirming reproducibility\n- rerun a large workflow when a smaller reproduction is available\n- hide the fact that the first failure occurred\n- assume success on retry means the system is healthy\n\n## Example workflow\n\n### Example 1: Upstream 502 during a task\n\n1. A command fails with HTTP 502 from a dependency.\n2. No local code changes explain it.\n3. Rerun the same command once with the same inputs.\n4. If it succeeds, record:\n - \"Initial 502 appears transient; single retry succeeded.\"\n5. Continue without code changes.\n\n### Example 2: Timeout during CI dependency fetch\n\n1. Dependency download times out.\n2. Retry only the fetch step once.\n3. If it times out again, record:\n - \"Single retry reproduced timeout; investigating network/dependency issue.\"\n4. Move into deeper diagnosis.\n\n## Why this works\n\nA single minimal retry is a fast diagnostic tool:\n\n- low effort\n- low risk when safe\n- preserves signal\n- prevents premature debugging\n- separates intermittent infrastructure instability from true reproducible defects\n\nThis is especially useful in automated environments, CI systems, remote execution, and tasks that depend on external services.\n\n## Completion checklist\n\nBefore finishing, confirm:\n\n- [ ] The error was plausibly transient\n- [ ] Retry was safe\n- [ ] Only one minimal retry was performed\n- [ ] No code/config changes were made before the retry\n- [ ] The retry outcome was explicitly documented\n- [ ] Next actions were chosen based on whether the issue reproduced" + }, + "created_at": "2026-04-12T02:49:14.950105", + "created_by": "" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:49:14.950108", + "last_updated": "2026-04-12T02:49:14.950108" + }, + { + "skill_id": "verify-before-confirming__v1_acf0d1bc", + "name": "verify-before-confirming", + "description": "Require a minimal evidence check before asserting that a status or success condition is true.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/verify-before-confirming/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "imported", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": null, + "change_summary": "", + "content_diff": "--- a/.upload_meta.json\n+++ b/.upload_meta.json\n@@ -0,0 +1,9 @@\n+{\n+ \"origin\": \"fixed\",\n+ \"parent_skill_ids\": [\n+ \"verify-before-confirming__v0_109e009a\"\n+ ],\n+ \"change_summary\": \"Added claim-matching verification guidance so confirmations must validate the exact named tool or report the claim as unverified.\",\n+ \"created_by\": \"openspace\",\n+ \"tags\": []\n+}\n\n--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,126 @@\n+---\n+name: verify-before-confirming\n+description: Require a minimal evidence check before asserting that a status or success condition is true.\n+---\n+\n+# Verify Before Confirming\n+\n+Use this workflow when a task asks for status confirmation, success confirmation, or a short “is it working?” answer. Do not assert success based only on expectation, prior context, or a single unverified statement. First perform at least one lightweight verification step, then answer briefly with the verified result.\n+\n+## When to Use\n+\n+Apply this skill when the user asks you to confirm whether something is:\n+\n+- working\n+- complete\n+- running\n+- connected\n+- deployed\n+- fixed\n+- available\n+- healthy\n+- successful\n+\n+Examples:\n+\n+- “Confirm the relay is working.”\n+- “Is the service up?”\n+- “Check whether the job completed.”\n+- “Verify the recording was saved.”\n+- “Make sure the integration is active.”\n+\n+## Workflow\n+\n+1. Identify the claim being confirmed.\n+ - Example: “The relay is working.”\n+ - Example: “The build completed successfully.”\n+ - Example: “The recording exists.”\n+\n+2. Choose the smallest available verification method.\n+ Prefer the least invasive check that can provide real evidence, such as:\n+ - reading recent logs\n+ - checking a status endpoint\n+ - listing expected output files\n+ - inspecting a recording/artifact\n+ - running a diagnostic command\n+ - checking a process, job, or service status\n+ - verifying timestamps, exit codes, or health checks\n+ The verification must match the exact claim being confirmed. Do not substitute a nearby or weaker check that only shows general availability, routing, or partial system access.\n+\n+ - If the claim names a specific tool, service, artifact, integration, or endpoint, verify that named thing directly when possible.\n+ - Do not treat generic introspection, provider discovery, or session visibility as proof that a specific tool invocation works unless the claim is specifically about introspection or discovery.\n+ - For tool-availability or connectivity claims, prefer directly invoking or inspecting the named tool itself with a safe read-only or no-op check when available.\n+ - If the specific thing cannot be inspected or invoked, say the claim remains unverified rather than inferring success from related signals.\n+\n+3. Run or inspect the verification source before responding.\n+ Do not skip this step unless no verification source or tool access exists.\n+\n+4. Interpret the evidence conservatively.\n+ - If the check passes, say what was verified.\n+ - If the check is inconclusive, say it is inconclusive and mention what was checked.\n+ - If the check fails, state the failure rather than asserting success.\n+ - If the evidence only confirms a related capability but not the exact claim, explicitly say that the exact claim was not verified.\n+\n+5. Final answer: one short sentence when the user requested only confirmation.\n+ Include the verified evidence in compressed form.\n+\n+## Response Patterns\n+\n+Verified success:\n+\n+“Verified: the service health check returned OK.”\n+\n+“Confirmed: the latest log shows the relay connected successfully.”\n+\n+“Verified: the expected recording file exists and was updated today.”\n+\n+Inconclusive:\n+\n+“I couldn’t fully confirm it; the process is running, but no recent success log was available.”\n+\n+“Status is inconclusive: the endpoint responded, but the expected artifact was not present.”\n+\n+Failure:\n+\n+“Not confirmed: the diagnostic command failed with a connection timeout.”\n+\n+“Not working yet: the latest log shows authentication errors.”\n+\n+## Rules\n+\n+- Do not mark a status-confirmation task complete without checking at least one available evidence source.\n+- The evidence source must be relevant to the exact claim, not just to a neighboring capability or tool path.\n+- Do not claim success merely because no error is visible.\n+- Do not treat tool listing, backend/provider discovery, or session metadata as confirmation that a specific named tool executes successfully unless that exact execution claim was tested.\n+- When asked whether a particular tool is available, connected, or working, validate that specific tool directly when possible; otherwise report that the claim is unverified.\n+- Do not over-verify if the task only needs a simple confirmation; one relevant check is usually enough.\n+- Keep the final answer concise, especially when the user asked for a simple status confirmation.\n+- If tools are unavailable, say so explicitly and avoid pretending verification occurred.\n+\n+## Minimal Verification Examples\n+\n+For a service:\n+\n+1. Run a health/status command or check recent logs.\n+2. Reply: “Verified: the health check reports the service is running.”\n+\n+For a file or recording:\n+\n+1. List or inspect the expected artifact path.\n+2. Reply: “Verified: the recording file exists and has a recent timestamp.”\n+\n+For a relay, integration, or connection:\n+\n+1. Check logs, events, or a diagnostic command showing recent activity.\n+2. Reply: “Confirmed: recent logs show the relay connected and forwarded traffic.”\n+\n+For a background job:\n+\n+1. Check job status, exit code, or output artifact.\n+2. Reply: “Verified: the job completed successfully with exit code 0.”\n+\n+For a named tool or tool-connectivity claim:\n+\n+1. Verify the specifically named tool directly, ideally with a safe invocation or direct inspection of that tool's availability/status.\n+2. Do not rely only on provider listing, session lookup, or presence of other tools as a proxy.\n+3. Reply: “Verified: the named tool responded to a read-only check.” or “Unverified: I could inspect the provider, but I could not directly confirm the named tool.”\n", + "content_snapshot": { + ".upload_meta.json": "{\n \"origin\": \"fixed\",\n \"parent_skill_ids\": [\n \"verify-before-confirming__v0_109e009a\"\n ],\n \"change_summary\": \"Added claim-matching verification guidance so confirmations must validate the exact named tool or report the claim as unverified.\",\n \"created_by\": \"openspace\",\n \"tags\": []\n}\n", + "SKILL.md": "---\nname: verify-before-confirming\ndescription: Require a minimal evidence check before asserting that a status or success condition is true.\n---\n\n# Verify Before Confirming\n\nUse this workflow when a task asks for status confirmation, success confirmation, or a short “is it working?” answer. Do not assert success based only on expectation, prior context, or a single unverified statement. First perform at least one lightweight verification step, then answer briefly with the verified result.\n\n## When to Use\n\nApply this skill when the user asks you to confirm whether something is:\n\n- working\n- complete\n- running\n- connected\n- deployed\n- fixed\n- available\n- healthy\n- successful\n\nExamples:\n\n- “Confirm the relay is working.”\n- “Is the service up?”\n- “Check whether the job completed.”\n- “Verify the recording was saved.”\n- “Make sure the integration is active.”\n\n## Workflow\n\n1. Identify the claim being confirmed.\n - Example: “The relay is working.”\n - Example: “The build completed successfully.”\n - Example: “The recording exists.”\n\n2. Choose the smallest available verification method.\n Prefer the least invasive check that can provide real evidence, such as:\n - reading recent logs\n - checking a status endpoint\n - listing expected output files\n - inspecting a recording/artifact\n - running a diagnostic command\n - checking a process, job, or service status\n - verifying timestamps, exit codes, or health checks\n The verification must match the exact claim being confirmed. Do not substitute a nearby or weaker check that only shows general availability, routing, or partial system access.\n\n - If the claim names a specific tool, service, artifact, integration, or endpoint, verify that named thing directly when possible.\n - Do not treat generic introspection, provider discovery, or session visibility as proof that a specific tool invocation works unless the claim is specifically about introspection or discovery.\n - For tool-availability or connectivity claims, prefer directly invoking or inspecting the named tool itself with a safe read-only or no-op check when available.\n - If the specific thing cannot be inspected or invoked, say the claim remains unverified rather than inferring success from related signals.\n\n3. Run or inspect the verification source before responding.\n Do not skip this step unless no verification source or tool access exists.\n\n4. Interpret the evidence conservatively.\n - If the check passes, say what was verified.\n - If the check is inconclusive, say it is inconclusive and mention what was checked.\n - If the check fails, state the failure rather than asserting success.\n - If the evidence only confirms a related capability but not the exact claim, explicitly say that the exact claim was not verified.\n\n5. Final answer: one short sentence when the user requested only confirmation.\n Include the verified evidence in compressed form.\n\n## Response Patterns\n\nVerified success:\n\n“Verified: the service health check returned OK.”\n\n“Confirmed: the latest log shows the relay connected successfully.”\n\n“Verified: the expected recording file exists and was updated today.”\n\nInconclusive:\n\n“I couldn’t fully confirm it; the process is running, but no recent success log was available.”\n\n“Status is inconclusive: the endpoint responded, but the expected artifact was not present.”\n\nFailure:\n\n“Not confirmed: the diagnostic command failed with a connection timeout.”\n\n“Not working yet: the latest log shows authentication errors.”\n\n## Rules\n\n- Do not mark a status-confirmation task complete without checking at least one available evidence source.\n- The evidence source must be relevant to the exact claim, not just to a neighboring capability or tool path.\n- Do not claim success merely because no error is visible.\n- Do not treat tool listing, backend/provider discovery, or session metadata as confirmation that a specific named tool executes successfully unless that exact execution claim was tested.\n- When asked whether a particular tool is available, connected, or working, validate that specific tool directly when possible; otherwise report that the claim is unverified.\n- Do not over-verify if the task only needs a simple confirmation; one relevant check is usually enough.\n- Keep the final answer concise, especially when the user asked for a simple status confirmation.\n- If tools are unavailable, say so explicitly and avoid pretending verification occurred.\n\n## Minimal Verification Examples\n\nFor a service:\n\n1. Run a health/status command or check recent logs.\n2. Reply: “Verified: the health check reports the service is running.”\n\nFor a file or recording:\n\n1. List or inspect the expected artifact path.\n2. Reply: “Verified: the recording file exists and has a recent timestamp.”\n\nFor a relay, integration, or connection:\n\n1. Check logs, events, or a diagnostic command showing recent activity.\n2. Reply: “Confirmed: recent logs show the relay connected and forwarded traffic.”\n\nFor a background job:\n\n1. Check job status, exit code, or output artifact.\n2. Reply: “Verified: the job completed successfully with exit code 0.”\n\nFor a named tool or tool-connectivity claim:\n\n1. Verify the specifically named tool directly, ideally with a safe invocation or direct inspection of that tool's availability/status.\n2. Do not rely only on provider listing, session lookup, or presence of other tools as a proxy.\n3. Reply: “Verified: the named tool responded to a read-only check.” or “Unverified: I could inspect the provider, but I could not directly confirm the named tool.”\n" + }, + "created_at": "2026-04-12T02:49:14.950636", + "created_by": "" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:49:14.950638", + "last_updated": "2026-04-12T02:49:14.950638" + }, + { + "skill_id": "clinical-soap-note-from-narrative-enhanced__v0_9bf80fad", + "name": "clinical-soap-note-from-narrative-enhanced", + "description": "Convert a narrative clinical encounter into a structured SOAP note by separating subjective and objective data, generating a problem-focused assessment, and adding an appropriate safety-conscious plan when red flags or neurologic abnormalities are present.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/clinical-soap-note-from-narrative-enhanced/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "derived", + "generation": 1, + "parent_skill_ids": [ + "clinical-soap-note-from-narrative__v0_9ff620af" + ], + "source_task_id": "0112fc9b-c3b2-4084-8993-5a4abb1f54f1_phase1", + "change_summary": "Rewrote the skill to add explicit decision rules for adolescent head injury/concussion cases, distinguishing strictly extractive SOAP generation from limited standard safety counseling when trauma red flags justify anticipatory guidance.", + "content_diff": "--- a/SKILL.md\n+++ b/SKILL.md\n@@ -1,132 +1,255 @@\n ---\n-name: clinical-soap-note-from-narrative\n-description: Convert a narrative clinical encounter into a structured SOAP note by separating subjective and objective data, generating a problem-focused assessment, and adding an appropriate safety-conscious plan when red flags or neurologic abnormalities are present.\n+name: concussion-soap-safety\n+description: Convert clinical narratives into structured SOAP notes while preserving strict source fidelity, with explicit rules for adolescent head injury/concussion cases on when standard safety counseling may be added versus when the note must remain purely extractive.\n ---\n \n-# Clinical SOAP Note From Narrative\n-\n-Use this skill when you are given a free-text clinical encounter, visit summary, or narrative case description and need to produce a structured SOAP note.\n-\n-This workflow is designed to:\n+# Concussion-Sensitive SOAP Note From Narrative\n+\n+Use this skill when you are given a free-text clinical encounter, visit summary, urgent care note, sports injury narrative, or case description and need to produce a structured SOAP note.\n+\n+This skill is designed to:\n - preserve the distinction between patient-reported history and clinician-observed findings\n - avoid inventing exam findings, diagnostics, or treatment details\n - produce a concise, problem-focused assessment\n-- add an appropriately cautious plan when red-flag symptoms or abnormal neurologic findings are described\n+- escalate the plan when red flags, trauma warning signs, or abnormal neurologic findings are present\n+- explicitly handle adolescent head injury/concussion encounters without violating the non-fabrication rule\n+- distinguish when limited standard safety counseling is appropriate to add versus when the note should remain strictly extractive\n+\n+## Scope\n+\n+This skill works for general outpatient, urgent care, sports medicine, and episodic clinical narratives. It is especially useful for:\n+- headaches and neurologic complaints\n+- musculoskeletal pain with neurologic symptoms\n+- post-traumatic symptom narratives\n+- adolescent head injury/concussion encounters\n+- cases where the plan must reflect safety risk without inventing unsupported management details\n \n ## Core principles\n \n 1. Do not add facts that were not provided.\n 2. Keep subjective and objective information separated.\n 3. Preserve uncertainty when the source is uncertain.\n-4. Make the assessment clinically coherent but problem-focused.\n-5. Escalate the plan when the narrative includes red flags, worsening symptoms, or abnormal neurologic findings.\n+4. Make the assessment clinically coherent but tightly grounded in the source.\n+5. Escalate the plan when the narrative includes red flags, worsening symptoms, trauma warning signs, or abnormal neurologic findings.\n 6. If the source lacks information, omit it or mark it as not provided rather than fabricating content.\n+7. In concussion/head injury cases, distinguish between:\n+ - extractive content taken directly from the source\n+ - standard safety counseling that may be added only in narrowly defined situations\n+8. Never add detailed treatment regimens, return-to-play stages, school accommodations, medication advice, driving restrictions, supervision arrangements, or disposition details unless the source states them or the narrative clearly requires immediate emergency escalation.\n+\n+## Decision mode: extractive vs limited safety augmentation\n+\n+Before writing the note, determine which mode applies.\n+\n+### Mode 1: Strictly extractive\n+Use this by default.\n+\n+Choose strictly extractive when:\n+- the case is routine and stable\n+- there are no red flags or abnormal neurologic findings\n+- the narrative does not involve head trauma/concussion\n+- the narrative involves minor head injury symptoms but no concerning features and no clinician-implied need for escalation\n+- adding counseling would go beyond what is needed to safely reflect the source\n+\n+In this mode:\n+- the SOAP note should only restate or reorganize provided information\n+- do not add standard concussion counseling just because it is commonly expected\n+- do not add “brain rest,” “return-to-play,” “no sports,” “no screens,” “inform parent/guardian,” or similar advice unless stated in the source\n+\n+### Mode 2: Limited safety augmentation\n+Use this only when the narrative includes head injury/concussion features plus safety concern.\n+\n+Choose limited safety augmentation when:\n+- the encounter involves head trauma or suspected concussion, especially in an adolescent or sports context\n+AND\n+- the narrative contains red flags, worsening symptoms, abnormal neurologic findings, concerning progression, or clinician-documented concern that warrants urgent evaluation or explicit danger counseling\n+\n+Examples of triggers:\n+- worsening headache after head injury\n+- vomiting, seizure, confusion, somnolence, or altered mental status\n+- focal neurologic deficit\n+- abnormal coordination, gait, balance, or mental status findings\n+- loss of consciousness if described as concerning or accompanied by persistent symptoms\n+- severe mechanism plus ongoing symptoms\n+- deteriorating course after injury\n+- clinician recommendation for ED transfer, urgent imaging, or same-day escalation\n+\n+In this mode, you may add only:\n+- a concise recommendation for urgent or emergency evaluation when clearly warranted by the narrative\n+- explicit return/emergency precautions for neurologic deterioration or worsening head injury symptoms\n+\n+Do not add broader concussion management advice unless the source already includes it.\n+\n+## What standard counseling may be added, and what may not\n+\n+### Permitted added counseling in limited safety augmentation mode\n+Only when trauma/concussion red flags or abnormal neurologic findings are present, you may add concise safety language such as:\n+- “Given the presence of concerning post-traumatic symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.”\n+- “Advise immediate care for worsening headache, repeated vomiting, confusion, seizure, weakness, numbness, vision change, speech difficulty, gait instability, increasing drowsiness, or other new neurologic symptoms.”\n+\n+This is allowed because it reflects high-level safety escalation rather than inventing detailed management.\n+\n+### Not permitted unless explicitly supported by the source\n+Do not add:\n+- cognitive rest instructions\n+- school absence or academic accommodations\n+- return-to-play or sports restriction timelines\n+- no driving or no screen-time instructions\n+- parent/guardian notification instructions\n+- observation frequency at home\n+- medication recommendations or dosing\n+- imaging orders not stated or clearly implied by an urgent transfer recommendation\n+- specialist referrals not stated\n+- definitive concussion diagnosis if the source does not support it\n \n ## Step-by-step workflow\n \n ### 1) Read the encounter and extract source facts\n \n-Identify and group all explicit facts from the narrative into:\n+Identify and group all explicit facts into:\n - symptoms and history\n - timing and progression\n+- mechanism of injury, if any\n - relevant negatives\n - exam findings\n+- neurologic findings\n - prior treatments or self-care\n - clinician impression or likely diagnosis if stated\n-- follow-up or return precautions if stated\n-\n-Before drafting, mentally separate:\n+- follow-up or precautions if stated\n+\n+Mentally separate:\n - Subjective = what the patient reports, describes, denies, or experiences\n-- Objective = observed exam findings, measured values, test results, and clinician-documented physical findings\n-\n-### 2) Build the Subjective section\n+- Objective = observed exam findings, measured values, test results, and clinician-documented findings\n+\n+### 2) Screen for safety triggers\n+\n+Check for any of the following:\n+- focal neurologic deficit\n+- progressive neurologic symptoms\n+- new unilateral weakness or numbness\n+- severe or worsening headache\n+- head trauma with ongoing or worsening symptoms\n+- abnormal coordination, balance, gait, or mental status\n+- syncope, seizure, confusion, or altered mental status\n+- repeated vomiting\n+- bowel/bladder dysfunction with spine symptoms\n+- rapidly worsening pain plus neurologic change\n+- other explicitly concerning clinician findings\n+\n+If present, the assessment must reflect concern and the plan must be escalated.\n+\n+### 3) Identify whether this is a head injury/concussion-type encounter\n+\n+Look for:\n+- blow to head, fall, collision, sports injury, assault, or other head trauma\n+- post-traumatic headache, dizziness, nausea, photophobia, concentration difficulty, imbalance, or confusion\n+- explicit mention of concussion concern\n+- adolescent/school/sports context suggesting a youth concussion presentation\n+\n+Then decide:\n+- no head injury pattern -> use general SOAP workflow\n+- head injury pattern without red flags -> stay strictly extractive unless the source itself includes counseling\n+- head injury pattern with red flags/abnormal neuro findings -> use limited safety augmentation\n+\n+### 4) Build the Subjective section\n \n Include only history elements supported by the narrative:\n - chief concern\n - onset, duration, course\n+- mechanism of injury if reported\n - associated symptoms\n - aggravating/alleviating factors\n - pertinent negatives\n - relevant prior history or attempted treatments, if provided\n \n-Keep it concise and clinical. Rewrite into standard medical style without changing meaning.\n-\n-Example transformation:\n-- Narrative: \"He says the headache started 3 days ago, is getting worse, and now he has tingling in his left arm.\"\n-- Subjective: \"Reports 3 days of worsening headache with associated left arm tingling.\"\n-\n-### 3) Build the Objective section\n+Keep it concise and clinical.\n+\n+Examples:\n+- “Reports headache since striking head during basketball yesterday, with associated dizziness and nausea.”\n+- “Reports 3 days of worsening headache with associated left arm tingling.”\n+\n+Do not move patient-reported symptoms into Objective.\n+\n+### 5) Build the Objective section\n \n Include only documented objective data:\n - vital signs, if given\n - physical exam findings\n - neurologic findings\n-- imaging/lab results, if given\n+- test results, if given\n \n Important:\n-- Do not infer a normal exam if none was described.\n-- Do not add routine headings with normal findings unless explicitly provided.\n-- If the exam is sparse, keep the Objective sparse.\n+- do not infer a normal exam if none was described\n+- do not add routine normal headings unless explicitly provided\n+- if the exam is sparse, keep the Objective sparse\n \n Good:\n-- \"Neuro: Decreased sensation in left upper extremity.\"\n+- “Neuro: Mild difficulty with tandem gait.”\n+- “Coordination exam notable for slight imbalance.”\n+- “Decreased sensation in left upper extremity.”\n+\n Avoid:\n-- \"CN II-XII intact\" unless the narrative explicitly states this.\n-\n-### 4) Write a problem-focused Assessment\n-\n-Synthesize the likely clinical issue using only the available facts.\n+- “PERRLA, EOMI, CN II-XII intact” unless explicitly documented\n+\n+### 6) Write a focused Assessment\n \n The assessment should:\n-- summarize the main problem in 1-3 sentences\n-- mention key supporting features\n-- note important uncertainty when present\n+- summarize the main clinical issue in 1-3 sentences\n+- cite the key supporting features\n+- preserve uncertainty when appropriate\n - avoid overcommitting to a diagnosis not established in the source\n \n-Preferred style:\n-- \"Presentation is concerning for...\"\n-- \"Symptoms are most consistent with...\"\n-- \"Given X and Y, cannot exclude...\"\n-\n-If the narrative includes neurologic deficits, red-flag symptoms, or concerning progression, the assessment should explicitly reflect concern rather than minimizing it.\n+Preferred language:\n+- “Symptoms are most consistent with...”\n+- “Presentation is concerning for...”\n+- “Given X and Y, cannot exclude...”\n+\n+For head trauma cases:\n+- if symptoms suggest concussion but the source is not definitive, say “post-traumatic symptoms concerning for concussion” rather than stating a confirmed diagnosis\n+- if abnormal neurologic findings are present, explicitly note that benign/self-limited injury cannot be assumed from the available information\n \n Example:\n-- \"Worsening headache with unilateral sensory symptoms is concerning for a neurologic process and warrants urgent evaluation; benign primary headache cannot be assumed from the available information.\"\n-\n-### 5) Write the Plan with safety escalation when warranted\n+- “Post-traumatic headache with documented coordination abnormality is concerning for concussion or other acute neurologic process after head injury and warrants urgent evaluation; uncomplicated minor head injury cannot be assumed from the available information.”\n+\n+### 7) Write the Plan\n \n Base the plan on what is provided, but structure it clearly.\n \n-Possible plan components:\n+Possible components:\n - symptomatic treatment already recommended or used\n - monitoring or follow-up\n-- diagnostic evaluation if stated or clearly warranted by the narrative\n-- return precautions / emergency precautions\n-\n-When red flags are present, include a safety-conscious plan such as:\n-- urgent ED evaluation\n-- same-day in-person neurologic assessment\n-- immediate imaging/workup if the narrative supports that urgency\n-- explicit return precautions for worsening weakness, numbness, severe headache, speech changes, vision changes, gait instability, altered mental status, bowel/bladder dysfunction, fever, or other relevant warning signs\n-\n-Do not understate urgency if the input includes:\n-- focal neurologic deficits\n-- new weakness or numbness\n-- severe or worsening headache with neuro symptoms\n-- altered mental status\n-- seizure\n-- saddle anesthesia or bowel/bladder changes\n-- rapidly progressive symptoms\n-- other clearly dangerous features\n-\n-### 6) Final quality check\n+- diagnostic evaluation if stated\n+- return precautions or emergency precautions\n+\n+#### For routine non-concerning cases\n+- remain extractive\n+- preserve stated follow-up or conservative care\n+- do not embellish the plan\n+\n+#### For red-flag or abnormal neurologic cases\n+- explicitly escalate urgency\n+- include urgent ED evaluation or prompt in-person neurologic assessment when supported by the narrative\n+- include clear return precautions for worsening neurologic or trauma symptoms\n+\n+#### For adolescent head injury/concussion cases\n+Apply the mode rules:\n+\n+If stable and non-red-flag:\n+- remain extractive unless the source already includes concussion counseling\n+\n+If red-flag or abnormal neurologic:\n+- you may add brief standard emergency precautions\n+- do not add broad concussion management instructions beyond those precautions\n+\n+### 8) Final quality check\n \n Before finalizing, verify:\n-- no invented vitals, exam findings, or test results\n+- no invented vitals, exam findings, tests, or treatments\n - subjective and objective are not mixed\n-- assessment reflects the actual level of concern\n-- plan contains clear escalation when red flags are present\n-- note is concise and clinically readable\n+- the assessment matches the actual level of concern\n+- the plan is not falsely detailed\n+- if safety counseling was added, it is limited to high-level emergency/return precautions justified by red flags or abnormal neurologic findings\n+- no unsupported concussion-specific restrictions or school/sports instructions were inserted\n \n ## SOAP note template\n \n@@ -151,27 +274,58 @@\n - progressive neurologic symptoms\n - new unilateral weakness or numbness\n - severe or worsening headache with neurologic symptoms\n+- post-traumatic neurologic abnormality\n - syncope, seizure, confusion, or altered mental status\n+- repeated vomiting after head injury\n - bowel/bladder dysfunction with spine symptoms\n - rapidly worsening pain plus neurologic changes\n - other explicitly concerning clinician findings\n \n-Suggested plan language:\n-- \"Given the presence of red-flag symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.\"\n-- \"Patient was advised to seek immediate care for any worsening weakness, numbness, severe headache, vision change, speech difficulty, gait instability, or other new neurologic symptoms.\"\n-\n-## Style guidance\n-\n-- Be concise.\n-- Use neutral clinical language.\n-- Prefer \"reports,\" \"endorses,\" \"denies,\" \"exam notable for,\" \"concerning for.\"\n-- If details are missing, do not compensate by guessing.\n-- If the source already includes a likely diagnosis or plan, preserve it faithfully in cleaner SOAP format.\n-\n-## Example\n-\n+Suggested escalated plan language:\n+- “Given the presence of red-flag symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.”\n+- “Patient was advised to seek immediate care for worsening weakness, numbness, severe headache, repeated vomiting, vision change, speech difficulty, gait instability, confusion, seizure, increasing drowsiness, or other new neurologic symptoms.”\n+\n+## Adolescent head injury/concussion guidance\n+\n+Use this section when the narrative suggests a youth concussion-type encounter.\n+\n+### If the narrative is mild and uncomplicated\n+Examples:\n+- headache after a sports collision\n+- dizziness after a minor head bump\n+- possible concussion discussed, but no red flags or objective neurologic deficits\n+\n+Then:\n+- keep the note extractive\n+- preserve any provided diagnosis, plan, and counseling\n+- do not independently add standard concussion handouts or anticipatory guidance\n+\n+### If the narrative includes danger features\n+Examples:\n+- worsening headache after injury\n+- abnormal balance or coordination\n+- confusion or unusual behavior\n+- vomiting\n+- focal weakness/numbness\n+- significant exam abnormality\n+- clinician concern requiring urgent escalation\n+\n+Then:\n+- make the assessment explicitly cautious\n+- include urgent evaluation/emergency precautions\n+- keep any added counseling narrow, safety-oriented, and high level\n+\n+### Practical rule\n+Ask:\n+1. Am I adding a fact? If yes, do not add it.\n+2. Am I adding a detailed management instruction not stated in the source? If yes, do not add it.\n+3. Am I adding only generic emergency precautions because the narrative shows red flags or abnormal neurologic findings? If yes, that is acceptable.\n+\n+## Examples\n+\n+### Example 1: Routine non-traumatic case\n Input narrative:\n-\"Patient reports low back pain for 1 week after lifting a box. Over the last 2 days, pain radiates down the right leg with numbness in the right foot. Exam shows decreased sensation over the dorsum of the right foot and positive straight-leg raise on the right. No bowel or bladder symptoms mentioned.\"\n+“Patient reports low back pain for 1 week after lifting a box. Over the last 2 days, pain radiates down the right leg with numbness in the right foot. Exam shows decreased sensation over the dorsum of the right foot and positive straight-leg raise on the right. No bowel or bladder symptoms mentioned.”\n \n Output:\n Subjective:\n@@ -188,20 +342,80 @@\n - Recommend prompt clinical follow-up/in-person evaluation.\n - Advise immediate emergency evaluation for new or worsening weakness, progressive numbness, saddle anesthesia, bowel or bladder dysfunction, fever, or uncontrolled pain.\n \n+### Example 2: Adolescent head injury with red flags\n+Input narrative:\n+“Teen hit his head during soccer 2 days ago. Since then he has had worsening headache and nausea. On exam he is alert but has mild difficulty with tandem gait. Provider is concerned and recommends further evaluation.”\n+\n+Output:\n+Subjective:\n+- Reports head injury during soccer 2 days ago followed by worsening headache and nausea.\n+\n+Objective:\n+- Alert on exam.\n+- Mild difficulty with tandem gait.\n+\n+Assessment:\n+- Post-traumatic headache and nausea with documented gait abnormality after head injury are concerning for concussion or another acute neurologic process. Given the abnormal neurologic finding and worsening symptoms, uncomplicated minor head injury cannot be assumed.\n+\n+Plan:\n+- Recommend urgent further evaluation.\n+- Advise immediate emergency care for worsening headache, repeated vomiting, confusion, seizure, weakness, numbness, vision change, speech difficulty, gait worsening, increasing drowsiness, or other new neurologic symptoms.\n+\n+Note why this is acceptable:\n+- The urgent evaluation is supported by the source.\n+- The added precautions are narrow safety counseling tied to red flags.\n+- The note does not add cognitive rest, return-to-play, school restrictions, or family supervision instructions.\n+\n+### Example 3: Adolescent head injury without red flags\n+Input narrative:\n+“15-year-old struck head lightly on cabinet yesterday. Today has mild headache. Neuro exam normal. Clinician suspects mild concussion and recommends rest and pediatric follow-up.”\n+\n+Output:\n+Subjective:\n+- Reports mild headache beginning after striking head on a cabinet yesterday.\n+\n+Objective:\n+- Neurologic exam normal.\n+\n+Assessment:\n+- Mild post-traumatic headache; clinician suspects mild concussion.\n+\n+Plan:\n+- Rest and pediatric follow-up as recommended in the source.\n+\n+Note why this is correct:\n+- The plan remains extractive.\n+- No extra return-to-play, school, driving, or screen-time advice is added unless present in the source.\n+\n ## Common mistakes to avoid\n \n - Moving patient-reported symptoms into Objective\n - Adding normal findings that were never stated\n-- Writing an assessment that ignores documented red flags\n-- Producing a routine conservative plan despite focal neurologic deficits\n+- Ignoring documented red flags or neurologic abnormalities\n+- Producing a routine conservative plan despite dangerous features\n - Inventing medications, dosages, imaging, or follow-up intervals\n-- Overly broad differentials that distract from the main problem\n+- Adding standard concussion counseling in every adolescent head injury case\n+- Adding return-to-play, school, parent/guardian, or cognitive-rest instructions not supported by the source\n+- Writing a definitive concussion diagnosis when the source only supports concern or suspicion\n \n ## Minimal decision rule\n \n If the case is routine and non-concerning:\n - produce a standard SOAP note faithful to the narrative\n \n-If the case includes red flags or abnormal neurologic findings:\n+If the case includes red flags, post-traumatic warning signs, or abnormal neurologic findings:\n - make the assessment explicitly cautious\n-- make the plan explicitly safety-oriented and escalated+- make the plan explicitly safety-oriented and escalated\n+\n+If the case is an adolescent head injury/concussion encounter:\n+- remain strictly extractive unless the narrative shows clear safety concern\n+- only add narrow emergency precautions when red flags or abnormal neurologic findings justify them\n+\n+## Output expectations\n+\n+The final note should be:\n+- concise\n+- clinically readable\n+- faithful to the source\n+- appropriately cautious when danger signs are present\n+- restrained about adding counseling unless the limited safety augmentation rule is met\n", + "content_snapshot": { + "SKILL.md": "---\nname: concussion-soap-safety\ndescription: Convert clinical narratives into structured SOAP notes while preserving strict source fidelity, with explicit rules for adolescent head injury/concussion cases on when standard safety counseling may be added versus when the note must remain purely extractive.\n---\n\n# Concussion-Sensitive SOAP Note From Narrative\n\nUse this skill when you are given a free-text clinical encounter, visit summary, urgent care note, sports injury narrative, or case description and need to produce a structured SOAP note.\n\nThis skill is designed to:\n- preserve the distinction between patient-reported history and clinician-observed findings\n- avoid inventing exam findings, diagnostics, or treatment details\n- produce a concise, problem-focused assessment\n- escalate the plan when red flags, trauma warning signs, or abnormal neurologic findings are present\n- explicitly handle adolescent head injury/concussion encounters without violating the non-fabrication rule\n- distinguish when limited standard safety counseling is appropriate to add versus when the note should remain strictly extractive\n\n## Scope\n\nThis skill works for general outpatient, urgent care, sports medicine, and episodic clinical narratives. It is especially useful for:\n- headaches and neurologic complaints\n- musculoskeletal pain with neurologic symptoms\n- post-traumatic symptom narratives\n- adolescent head injury/concussion encounters\n- cases where the plan must reflect safety risk without inventing unsupported management details\n\n## Core principles\n\n1. Do not add facts that were not provided.\n2. Keep subjective and objective information separated.\n3. Preserve uncertainty when the source is uncertain.\n4. Make the assessment clinically coherent but tightly grounded in the source.\n5. Escalate the plan when the narrative includes red flags, worsening symptoms, trauma warning signs, or abnormal neurologic findings.\n6. If the source lacks information, omit it or mark it as not provided rather than fabricating content.\n7. In concussion/head injury cases, distinguish between:\n - extractive content taken directly from the source\n - standard safety counseling that may be added only in narrowly defined situations\n8. Never add detailed treatment regimens, return-to-play stages, school accommodations, medication advice, driving restrictions, supervision arrangements, or disposition details unless the source states them or the narrative clearly requires immediate emergency escalation.\n\n## Decision mode: extractive vs limited safety augmentation\n\nBefore writing the note, determine which mode applies.\n\n### Mode 1: Strictly extractive\nUse this by default.\n\nChoose strictly extractive when:\n- the case is routine and stable\n- there are no red flags or abnormal neurologic findings\n- the narrative does not involve head trauma/concussion\n- the narrative involves minor head injury symptoms but no concerning features and no clinician-implied need for escalation\n- adding counseling would go beyond what is needed to safely reflect the source\n\nIn this mode:\n- the SOAP note should only restate or reorganize provided information\n- do not add standard concussion counseling just because it is commonly expected\n- do not add “brain rest,” “return-to-play,” “no sports,” “no screens,” “inform parent/guardian,” or similar advice unless stated in the source\n\n### Mode 2: Limited safety augmentation\nUse this only when the narrative includes head injury/concussion features plus safety concern.\n\nChoose limited safety augmentation when:\n- the encounter involves head trauma or suspected concussion, especially in an adolescent or sports context\nAND\n- the narrative contains red flags, worsening symptoms, abnormal neurologic findings, concerning progression, or clinician-documented concern that warrants urgent evaluation or explicit danger counseling\n\nExamples of triggers:\n- worsening headache after head injury\n- vomiting, seizure, confusion, somnolence, or altered mental status\n- focal neurologic deficit\n- abnormal coordination, gait, balance, or mental status findings\n- loss of consciousness if described as concerning or accompanied by persistent symptoms\n- severe mechanism plus ongoing symptoms\n- deteriorating course after injury\n- clinician recommendation for ED transfer, urgent imaging, or same-day escalation\n\nIn this mode, you may add only:\n- a concise recommendation for urgent or emergency evaluation when clearly warranted by the narrative\n- explicit return/emergency precautions for neurologic deterioration or worsening head injury symptoms\n\nDo not add broader concussion management advice unless the source already includes it.\n\n## What standard counseling may be added, and what may not\n\n### Permitted added counseling in limited safety augmentation mode\nOnly when trauma/concussion red flags or abnormal neurologic findings are present, you may add concise safety language such as:\n- “Given the presence of concerning post-traumatic symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.”\n- “Advise immediate care for worsening headache, repeated vomiting, confusion, seizure, weakness, numbness, vision change, speech difficulty, gait instability, increasing drowsiness, or other new neurologic symptoms.”\n\nThis is allowed because it reflects high-level safety escalation rather than inventing detailed management.\n\n### Not permitted unless explicitly supported by the source\nDo not add:\n- cognitive rest instructions\n- school absence or academic accommodations\n- return-to-play or sports restriction timelines\n- no driving or no screen-time instructions\n- parent/guardian notification instructions\n- observation frequency at home\n- medication recommendations or dosing\n- imaging orders not stated or clearly implied by an urgent transfer recommendation\n- specialist referrals not stated\n- definitive concussion diagnosis if the source does not support it\n\n## Step-by-step workflow\n\n### 1) Read the encounter and extract source facts\n\nIdentify and group all explicit facts into:\n- symptoms and history\n- timing and progression\n- mechanism of injury, if any\n- relevant negatives\n- exam findings\n- neurologic findings\n- prior treatments or self-care\n- clinician impression or likely diagnosis if stated\n- follow-up or precautions if stated\n\nMentally separate:\n- Subjective = what the patient reports, describes, denies, or experiences\n- Objective = observed exam findings, measured values, test results, and clinician-documented findings\n\n### 2) Screen for safety triggers\n\nCheck for any of the following:\n- focal neurologic deficit\n- progressive neurologic symptoms\n- new unilateral weakness or numbness\n- severe or worsening headache\n- head trauma with ongoing or worsening symptoms\n- abnormal coordination, balance, gait, or mental status\n- syncope, seizure, confusion, or altered mental status\n- repeated vomiting\n- bowel/bladder dysfunction with spine symptoms\n- rapidly worsening pain plus neurologic change\n- other explicitly concerning clinician findings\n\nIf present, the assessment must reflect concern and the plan must be escalated.\n\n### 3) Identify whether this is a head injury/concussion-type encounter\n\nLook for:\n- blow to head, fall, collision, sports injury, assault, or other head trauma\n- post-traumatic headache, dizziness, nausea, photophobia, concentration difficulty, imbalance, or confusion\n- explicit mention of concussion concern\n- adolescent/school/sports context suggesting a youth concussion presentation\n\nThen decide:\n- no head injury pattern -> use general SOAP workflow\n- head injury pattern without red flags -> stay strictly extractive unless the source itself includes counseling\n- head injury pattern with red flags/abnormal neuro findings -> use limited safety augmentation\n\n### 4) Build the Subjective section\n\nInclude only history elements supported by the narrative:\n- chief concern\n- onset, duration, course\n- mechanism of injury if reported\n- associated symptoms\n- aggravating/alleviating factors\n- pertinent negatives\n- relevant prior history or attempted treatments, if provided\n\nKeep it concise and clinical.\n\nExamples:\n- “Reports headache since striking head during basketball yesterday, with associated dizziness and nausea.”\n- “Reports 3 days of worsening headache with associated left arm tingling.”\n\nDo not move patient-reported symptoms into Objective.\n\n### 5) Build the Objective section\n\nInclude only documented objective data:\n- vital signs, if given\n- physical exam findings\n- neurologic findings\n- test results, if given\n\nImportant:\n- do not infer a normal exam if none was described\n- do not add routine normal headings unless explicitly provided\n- if the exam is sparse, keep the Objective sparse\n\nGood:\n- “Neuro: Mild difficulty with tandem gait.”\n- “Coordination exam notable for slight imbalance.”\n- “Decreased sensation in left upper extremity.”\n\nAvoid:\n- “PERRLA, EOMI, CN II-XII intact” unless explicitly documented\n\n### 6) Write a focused Assessment\n\nThe assessment should:\n- summarize the main clinical issue in 1-3 sentences\n- cite the key supporting features\n- preserve uncertainty when appropriate\n- avoid overcommitting to a diagnosis not established in the source\n\nPreferred language:\n- “Symptoms are most consistent with...”\n- “Presentation is concerning for...”\n- “Given X and Y, cannot exclude...”\n\nFor head trauma cases:\n- if symptoms suggest concussion but the source is not definitive, say “post-traumatic symptoms concerning for concussion” rather than stating a confirmed diagnosis\n- if abnormal neurologic findings are present, explicitly note that benign/self-limited injury cannot be assumed from the available information\n\nExample:\n- “Post-traumatic headache with documented coordination abnormality is concerning for concussion or other acute neurologic process after head injury and warrants urgent evaluation; uncomplicated minor head injury cannot be assumed from the available information.”\n\n### 7) Write the Plan\n\nBase the plan on what is provided, but structure it clearly.\n\nPossible components:\n- symptomatic treatment already recommended or used\n- monitoring or follow-up\n- diagnostic evaluation if stated\n- return precautions or emergency precautions\n\n#### For routine non-concerning cases\n- remain extractive\n- preserve stated follow-up or conservative care\n- do not embellish the plan\n\n#### For red-flag or abnormal neurologic cases\n- explicitly escalate urgency\n- include urgent ED evaluation or prompt in-person neurologic assessment when supported by the narrative\n- include clear return precautions for worsening neurologic or trauma symptoms\n\n#### For adolescent head injury/concussion cases\nApply the mode rules:\n\nIf stable and non-red-flag:\n- remain extractive unless the source already includes concussion counseling\n\nIf red-flag or abnormal neurologic:\n- you may add brief standard emergency precautions\n- do not add broad concussion management instructions beyond those precautions\n\n### 8) Final quality check\n\nBefore finalizing, verify:\n- no invented vitals, exam findings, tests, or treatments\n- subjective and objective are not mixed\n- the assessment matches the actual level of concern\n- the plan is not falsely detailed\n- if safety counseling was added, it is limited to high-level emergency/return precautions justified by red flags or abnormal neurologic findings\n- no unsupported concussion-specific restrictions or school/sports instructions were inserted\n\n## SOAP note template\n\nUse this structure:\n\nSubjective:\n- [Chief concern and history in concise prose or bullets]\n\nObjective:\n- [Only provided exam findings, vitals, tests]\n\nAssessment:\n- [Focused synthesis of the main clinical issue, including uncertainty or concern]\n\nPlan:\n- [Treatment / next steps / follow-up / precautions]\n\n## Safety trigger guide\n\nEscalate the plan when the narrative includes any of the following:\n- focal neurologic deficit\n- progressive neurologic symptoms\n- new unilateral weakness or numbness\n- severe or worsening headache with neurologic symptoms\n- post-traumatic neurologic abnormality\n- syncope, seizure, confusion, or altered mental status\n- repeated vomiting after head injury\n- bowel/bladder dysfunction with spine symptoms\n- rapidly worsening pain plus neurologic changes\n- other explicitly concerning clinician findings\n\nSuggested escalated plan language:\n- “Given the presence of red-flag symptoms/abnormal neurologic findings, urgent emergency department evaluation is recommended.”\n- “Patient was advised to seek immediate care for worsening weakness, numbness, severe headache, repeated vomiting, vision change, speech difficulty, gait instability, confusion, seizure, increasing drowsiness, or other new neurologic symptoms.”\n\n## Adolescent head injury/concussion guidance\n\nUse this section when the narrative suggests a youth concussion-type encounter.\n\n### If the narrative is mild and uncomplicated\nExamples:\n- headache after a sports collision\n- dizziness after a minor head bump\n- possible concussion discussed, but no red flags or objective neurologic deficits\n\nThen:\n- keep the note extractive\n- preserve any provided diagnosis, plan, and counseling\n- do not independently add standard concussion handouts or anticipatory guidance\n\n### If the narrative includes danger features\nExamples:\n- worsening headache after injury\n- abnormal balance or coordination\n- confusion or unusual behavior\n- vomiting\n- focal weakness/numbness\n- significant exam abnormality\n- clinician concern requiring urgent escalation\n\nThen:\n- make the assessment explicitly cautious\n- include urgent evaluation/emergency precautions\n- keep any added counseling narrow, safety-oriented, and high level\n\n### Practical rule\nAsk:\n1. Am I adding a fact? If yes, do not add it.\n2. Am I adding a detailed management instruction not stated in the source? If yes, do not add it.\n3. Am I adding only generic emergency precautions because the narrative shows red flags or abnormal neurologic findings? If yes, that is acceptable.\n\n## Examples\n\n### Example 1: Routine non-traumatic case\nInput narrative:\n“Patient reports low back pain for 1 week after lifting a box. Over the last 2 days, pain radiates down the right leg with numbness in the right foot. Exam shows decreased sensation over the dorsum of the right foot and positive straight-leg raise on the right. No bowel or bladder symptoms mentioned.”\n\nOutput:\nSubjective:\n- Reports 1 week of low back pain after lifting injury, with 2 days of radiation down the right leg and associated numbness in the right foot.\n\nObjective:\n- Exam notable for decreased sensation over the dorsum of the right foot.\n- Positive straight-leg raise on the right.\n\nAssessment:\n- Acute low back pain with right-sided radicular symptoms and objective sensory deficit, concerning for lumbar radiculopathy. Given the documented neurologic abnormality, symptoms warrant prompt in-person evaluation and close monitoring for progression.\n\nPlan:\n- Recommend prompt clinical follow-up/in-person evaluation.\n- Advise immediate emergency evaluation for new or worsening weakness, progressive numbness, saddle anesthesia, bowel or bladder dysfunction, fever, or uncontrolled pain.\n\n### Example 2: Adolescent head injury with red flags\nInput narrative:\n“Teen hit his head during soccer 2 days ago. Since then he has had worsening headache and nausea. On exam he is alert but has mild difficulty with tandem gait. Provider is concerned and recommends further evaluation.”\n\nOutput:\nSubjective:\n- Reports head injury during soccer 2 days ago followed by worsening headache and nausea.\n\nObjective:\n- Alert on exam.\n- Mild difficulty with tandem gait.\n\nAssessment:\n- Post-traumatic headache and nausea with documented gait abnormality after head injury are concerning for concussion or another acute neurologic process. Given the abnormal neurologic finding and worsening symptoms, uncomplicated minor head injury cannot be assumed.\n\nPlan:\n- Recommend urgent further evaluation.\n- Advise immediate emergency care for worsening headache, repeated vomiting, confusion, seizure, weakness, numbness, vision change, speech difficulty, gait worsening, increasing drowsiness, or other new neurologic symptoms.\n\nNote why this is acceptable:\n- The urgent evaluation is supported by the source.\n- The added precautions are narrow safety counseling tied to red flags.\n- The note does not add cognitive rest, return-to-play, school restrictions, or family supervision instructions.\n\n### Example 3: Adolescent head injury without red flags\nInput narrative:\n“15-year-old struck head lightly on cabinet yesterday. Today has mild headache. Neuro exam normal. Clinician suspects mild concussion and recommends rest and pediatric follow-up.”\n\nOutput:\nSubjective:\n- Reports mild headache beginning after striking head on a cabinet yesterday.\n\nObjective:\n- Neurologic exam normal.\n\nAssessment:\n- Mild post-traumatic headache; clinician suspects mild concussion.\n\nPlan:\n- Rest and pediatric follow-up as recommended in the source.\n\nNote why this is correct:\n- The plan remains extractive.\n- No extra return-to-play, school, driving, or screen-time advice is added unless present in the source.\n\n## Common mistakes to avoid\n\n- Moving patient-reported symptoms into Objective\n- Adding normal findings that were never stated\n- Ignoring documented red flags or neurologic abnormalities\n- Producing a routine conservative plan despite dangerous features\n- Inventing medications, dosages, imaging, or follow-up intervals\n- Adding standard concussion counseling in every adolescent head injury case\n- Adding return-to-play, school, parent/guardian, or cognitive-rest instructions not supported by the source\n- Writing a definitive concussion diagnosis when the source only supports concern or suspicion\n\n## Minimal decision rule\n\nIf the case is routine and non-concerning:\n- produce a standard SOAP note faithful to the narrative\n\nIf the case includes red flags, post-traumatic warning signs, or abnormal neurologic findings:\n- make the assessment explicitly cautious\n- make the plan explicitly safety-oriented and escalated\n\nIf the case is an adolescent head injury/concussion encounter:\n- remain strictly extractive unless the narrative shows clear safety concern\n- only add narrow emergency precautions when red flags or abnormal neurologic findings justify them\n\n## Output expectations\n\nThe final note should be:\n- concise\n- clinically readable\n- faithful to the source\n- appropriately cautious when danger signs are present\n- restrained about adding counseling unless the limited safety augmentation rule is met\n" + }, + "created_at": "2026-04-12T02:50:48.486763", + "created_by": "gpt-5.4" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:50:48.486771", + "last_updated": "2026-04-12T02:50:48.486771" + }, + { + "skill_id": "verify-build-artifacts__v0_0d98babd", + "name": "verify-build-artifacts", + "description": "Verify that expected output files were actually created and usable before declaring a build successful, especially when commands return nonzero exit codes or emit warning-heavy logs.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/verify-build-artifacts/SKILL.md", + "is_active": true, + "category": "tool_guide", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "captured", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": "02314fc6-a24e-42f4-a8cd-362cae0f0ec1_phase1", + "change_summary": "Captured a reusable skill for confirming output artifacts exist and are usable after build tools emit errors, warnings, or ambiguous logs.", + "content_diff": "--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,245 @@\n+---\n+name: verify-build-artifacts\n+description: Verify that expected output files were actually created and usable before declaring a build successful, especially when commands return nonzero exit codes or emit warning-heavy logs.\n+---\n+\n+# Verify Build Artifacts\n+\n+Use this skill when a build, conversion, or rendering command produces ambiguous results — for example:\n+\n+- the command exits nonzero\n+- the logs contain warnings or partial failures\n+- the tool may still emit usable outputs despite errors\n+- multiple fallback commands were attempted\n+- success cannot be inferred from logs alone\n+\n+This is especially important for artifact-producing tools such as LaTeX, pandoc, compilers, renderers, bundlers, and document converters.\n+\n+## Core principle\n+\n+Never declare completion based only on:\n+- a command having run\n+- partial progress in logs\n+- assumptions about tool behavior\n+- \"it usually produces the file\"\n+\n+Instead, verify the expected artifact directly.\n+\n+## When to apply this\n+\n+Apply artifact verification whenever:\n+\n+1. The command exit code is nonzero.\n+2. The command output includes errors, warnings, or missing-resource messages.\n+3. The tool is known to sometimes produce output even on failure.\n+4. You used fallback strategies and need to know which one actually worked.\n+5. The final answer depends on a specific file existing.\n+\n+Examples:\n+- `pdflatex`, `xelatex`, `lualatex`\n+- `pandoc`\n+- document generation pipelines\n+- code compilation producing binaries or bundles\n+- image/video rendering\n+- archive/export commands\n+\n+## Procedure\n+\n+### 1. Identify the expected artifact\n+\n+Before or immediately after running the build, name the exact file you need.\n+\n+Examples:\n+- `report.pdf`\n+- `dist/app.js`\n+- `build/output.zip`\n+\n+If there are several acceptable outputs, list them explicitly and decide which counts as success.\n+\n+## 2. Run the build command and capture its result\n+\n+Record:\n+- exit status\n+- stdout/stderr or log file\n+- output path(s)\n+\n+Do not treat warnings or a nonzero exit code as automatic proof of total failure or success.\n+\n+## 3. Check whether the artifact exists\n+\n+After the command finishes, inspect the filesystem directly.\n+\n+Shell example:\n+[ -f report.pdf ] && echo \"exists\" || echo \"missing\"\n+\n+For a stronger check:\n+ls -l report.pdf\n+\n+Useful questions:\n+- Does the file exist?\n+- Is it in the expected location?\n+- Is it non-empty?\n+- Was it modified recently?\n+\n+## 4. Perform a basic usability check\n+\n+Existence alone is sometimes insufficient. Confirm the artifact is not obviously broken.\n+\n+Examples:\n+- check file size is greater than zero\n+- inspect MIME/file type\n+- open metadata if available\n+- ensure the file is newer than the source or build start time\n+\n+Examples:\n+file report.pdf\n+stat report.pdf\n+\n+For PDFs specifically:\n+- verify the file exists\n+- ensure it is non-empty\n+- optionally inspect with `pdfinfo` if available\n+\n+Example:\n+pdfinfo report.pdf >/dev/null 2>&1 && echo \"readable PDF\"\n+\n+## 5. Reconcile exit code vs artifact state\n+\n+Use this decision logic:\n+\n+### Case A: Exit code success, artifact present\n+Treat as success.\n+\n+### Case B: Exit code failure, artifact present and usable\n+Treat as partial/qualified success only if the requested deliverable exists and appears usable.\n+In your final report:\n+- say the command reported errors or warnings\n+- say the artifact was nevertheless generated\n+- mention any limitations if known\n+\n+### Case C: Exit code success, artifact missing\n+Treat as failure. Do not claim completion.\n+\n+### Case D: Exit code failure, artifact missing\n+Treat as failure. Investigate or use fallback steps.\n+\n+## 6. If multiple build attempts were used, verify after each meaningful attempt\n+\n+When trying fallbacks, do not assume the last command worked just because it looked better.\n+\n+Example workflow:\n+1. run `pdflatex`\n+2. verify `report.pdf`\n+3. if missing, run `xelatex`\n+4. verify again\n+5. if still missing, run `pandoc`\n+6. verify again\n+\n+Track which command actually produced the artifact.\n+\n+## 7. Base your final response on verified state, not hopeful interpretation\n+\n+Before declaring success, state one of:\n+- artifact verified at ``\n+- artifact not found\n+- artifact found but validity uncertain\n+- artifact generated with warnings/errors\n+\n+This prevents false completion claims.\n+\n+## Recommended reporting template\n+\n+Use wording like:\n+\n+- \"The build command exited with errors, but `output.pdf` was generated and is present at the expected path.\"\n+- \"The logs showed warnings; I verified that `dist/app.js` exists and is non-empty.\"\n+- \"I attempted multiple build paths, but no final artifact was found, so I cannot claim completion.\"\n+- \"The command completed, but the expected artifact was missing; treating this as unsuccessful.\"\n+\n+## Minimal shell patterns\n+\n+### Simple existence check\n+build_command\n+if [ -f output.pdf ]; then\n+ echo \"Artifact verified: output.pdf\"\n+else\n+ echo \"Artifact missing: output.pdf\"\n+fi\n+\n+### Existence and non-empty check\n+build_command\n+if [ -s output.pdf ]; then\n+ echo \"Artifact verified and non-empty\"\n+else\n+ echo \"Artifact missing or empty\"\n+fi\n+\n+### Preserve exit code while still checking artifact\n+build_command\n+status=$?\n+\n+if [ -s output.pdf ]; then\n+ echo \"Artifact exists\"\n+else\n+ echo \"Artifact missing\"\n+fi\n+\n+exit $status\n+\n+### Qualified success logic\n+build_command\n+status=$?\n+\n+if [ -s output.pdf ]; then\n+ echo \"Build returned status $status, but artifact exists\"\n+else\n+ echo \"Build failed and artifact is missing\"\n+fi\n+\n+## Tool-specific notes\n+\n+### LaTeX\n+LaTeX commands may:\n+- return nonzero because of warnings or unresolved references\n+- emit a PDF despite incomplete logs\n+- require multiple passes\n+\n+Always verify the PDF directly after each run:\n+- `pdflatex`\n+- `xelatex`\n+- `lualatex`\n+\n+If bibliography or references are involved, rerun as needed, but do not declare success unless the final PDF exists.\n+\n+### pandoc\n+`pandoc` may fail because of a missing PDF engine, template issue, or embedded resource problem.\n+Even so, verify whether the requested output file was created.\n+\n+For PDF targets, check:\n+- target file exists\n+- file is non-empty\n+- optional readability via `pdfinfo` or `file`\n+\n+## Anti-patterns to avoid\n+\n+Do not:\n+- claim success because \"the command mostly worked\"\n+- assume logs mentioning output imply the file exists\n+- stop at the first promising warning-free line\n+- ignore the possibility of partial output\n+- omit artifact verification after fallback attempts\n+\n+## Compact checklist\n+\n+Before finishing, confirm:\n+\n+- What exact artifact was required?\n+- Did I check the filesystem directly?\n+- Is the file non-empty?\n+- If the command failed, did I still verify whether output exists?\n+- If multiple attempts were made, do I know which one produced the artifact?\n+- Does my final response match the verified artifact state?\n+\n+## Success standard\n+\n+A task involving build output is complete only when the expected artifact has been verified at the filesystem level, not merely inferred from command execution or logs.", + "content_snapshot": { + "SKILL.md": "---\nname: verify-build-artifacts\ndescription: Verify that expected output files were actually created and usable before declaring a build successful, especially when commands return nonzero exit codes or emit warning-heavy logs.\n---\n\n# Verify Build Artifacts\n\nUse this skill when a build, conversion, or rendering command produces ambiguous results — for example:\n\n- the command exits nonzero\n- the logs contain warnings or partial failures\n- the tool may still emit usable outputs despite errors\n- multiple fallback commands were attempted\n- success cannot be inferred from logs alone\n\nThis is especially important for artifact-producing tools such as LaTeX, pandoc, compilers, renderers, bundlers, and document converters.\n\n## Core principle\n\nNever declare completion based only on:\n- a command having run\n- partial progress in logs\n- assumptions about tool behavior\n- \"it usually produces the file\"\n\nInstead, verify the expected artifact directly.\n\n## When to apply this\n\nApply artifact verification whenever:\n\n1. The command exit code is nonzero.\n2. The command output includes errors, warnings, or missing-resource messages.\n3. The tool is known to sometimes produce output even on failure.\n4. You used fallback strategies and need to know which one actually worked.\n5. The final answer depends on a specific file existing.\n\nExamples:\n- `pdflatex`, `xelatex`, `lualatex`\n- `pandoc`\n- document generation pipelines\n- code compilation producing binaries or bundles\n- image/video rendering\n- archive/export commands\n\n## Procedure\n\n### 1. Identify the expected artifact\n\nBefore or immediately after running the build, name the exact file you need.\n\nExamples:\n- `report.pdf`\n- `dist/app.js`\n- `build/output.zip`\n\nIf there are several acceptable outputs, list them explicitly and decide which counts as success.\n\n## 2. Run the build command and capture its result\n\nRecord:\n- exit status\n- stdout/stderr or log file\n- output path(s)\n\nDo not treat warnings or a nonzero exit code as automatic proof of total failure or success.\n\n## 3. Check whether the artifact exists\n\nAfter the command finishes, inspect the filesystem directly.\n\nShell example:\n[ -f report.pdf ] && echo \"exists\" || echo \"missing\"\n\nFor a stronger check:\nls -l report.pdf\n\nUseful questions:\n- Does the file exist?\n- Is it in the expected location?\n- Is it non-empty?\n- Was it modified recently?\n\n## 4. Perform a basic usability check\n\nExistence alone is sometimes insufficient. Confirm the artifact is not obviously broken.\n\nExamples:\n- check file size is greater than zero\n- inspect MIME/file type\n- open metadata if available\n- ensure the file is newer than the source or build start time\n\nExamples:\nfile report.pdf\nstat report.pdf\n\nFor PDFs specifically:\n- verify the file exists\n- ensure it is non-empty\n- optionally inspect with `pdfinfo` if available\n\nExample:\npdfinfo report.pdf >/dev/null 2>&1 && echo \"readable PDF\"\n\n## 5. Reconcile exit code vs artifact state\n\nUse this decision logic:\n\n### Case A: Exit code success, artifact present\nTreat as success.\n\n### Case B: Exit code failure, artifact present and usable\nTreat as partial/qualified success only if the requested deliverable exists and appears usable.\nIn your final report:\n- say the command reported errors or warnings\n- say the artifact was nevertheless generated\n- mention any limitations if known\n\n### Case C: Exit code success, artifact missing\nTreat as failure. Do not claim completion.\n\n### Case D: Exit code failure, artifact missing\nTreat as failure. Investigate or use fallback steps.\n\n## 6. If multiple build attempts were used, verify after each meaningful attempt\n\nWhen trying fallbacks, do not assume the last command worked just because it looked better.\n\nExample workflow:\n1. run `pdflatex`\n2. verify `report.pdf`\n3. if missing, run `xelatex`\n4. verify again\n5. if still missing, run `pandoc`\n6. verify again\n\nTrack which command actually produced the artifact.\n\n## 7. Base your final response on verified state, not hopeful interpretation\n\nBefore declaring success, state one of:\n- artifact verified at ``\n- artifact not found\n- artifact found but validity uncertain\n- artifact generated with warnings/errors\n\nThis prevents false completion claims.\n\n## Recommended reporting template\n\nUse wording like:\n\n- \"The build command exited with errors, but `output.pdf` was generated and is present at the expected path.\"\n- \"The logs showed warnings; I verified that `dist/app.js` exists and is non-empty.\"\n- \"I attempted multiple build paths, but no final artifact was found, so I cannot claim completion.\"\n- \"The command completed, but the expected artifact was missing; treating this as unsuccessful.\"\n\n## Minimal shell patterns\n\n### Simple existence check\nbuild_command\nif [ -f output.pdf ]; then\n echo \"Artifact verified: output.pdf\"\nelse\n echo \"Artifact missing: output.pdf\"\nfi\n\n### Existence and non-empty check\nbuild_command\nif [ -s output.pdf ]; then\n echo \"Artifact verified and non-empty\"\nelse\n echo \"Artifact missing or empty\"\nfi\n\n### Preserve exit code while still checking artifact\nbuild_command\nstatus=$?\n\nif [ -s output.pdf ]; then\n echo \"Artifact exists\"\nelse\n echo \"Artifact missing\"\nfi\n\nexit $status\n\n### Qualified success logic\nbuild_command\nstatus=$?\n\nif [ -s output.pdf ]; then\n echo \"Build returned status $status, but artifact exists\"\nelse\n echo \"Build failed and artifact is missing\"\nfi\n\n## Tool-specific notes\n\n### LaTeX\nLaTeX commands may:\n- return nonzero because of warnings or unresolved references\n- emit a PDF despite incomplete logs\n- require multiple passes\n\nAlways verify the PDF directly after each run:\n- `pdflatex`\n- `xelatex`\n- `lualatex`\n\nIf bibliography or references are involved, rerun as needed, but do not declare success unless the final PDF exists.\n\n### pandoc\n`pandoc` may fail because of a missing PDF engine, template issue, or embedded resource problem.\nEven so, verify whether the requested output file was created.\n\nFor PDF targets, check:\n- target file exists\n- file is non-empty\n- optional readability via `pdfinfo` or `file`\n\n## Anti-patterns to avoid\n\nDo not:\n- claim success because \"the command mostly worked\"\n- assume logs mentioning output imply the file exists\n- stop at the first promising warning-free line\n- ignore the possibility of partial output\n- omit artifact verification after fallback attempts\n\n## Compact checklist\n\nBefore finishing, confirm:\n\n- What exact artifact was required?\n- Did I check the filesystem directly?\n- Is the file non-empty?\n- If the command failed, did I still verify whether output exists?\n- If multiple attempts were made, do I know which one produced the artifact?\n- Does my final response match the verified artifact state?\n\n## Success standard\n\nA task involving build output is complete only when the expected artifact has been verified at the filesystem level, not merely inferred from command execution or logs." + }, + "created_at": "2026-04-12T02:55:10.940721", + "created_by": "gpt-5.4" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:55:10.940769", + "last_updated": "2026-04-12T02:55:10.940771" + }, + { + "skill_id": "adaptive-document-output__v0_1a22c8b2", + "name": "adaptive-document-output", + "description": "Generate documents reliably by probing available conversion tools first, then selecting PDF, HTML, or source output based on what is actually installed.", + "path": "/Users/admin/PycharmProjects/openspace/openspace/skills/adaptive-document-output/SKILL.md", + "is_active": true, + "category": "workflow", + "tags": [], + "visibility": "private", + "creator_id": "", + "lineage": { + "origin": "captured", + "generation": 0, + "parent_skill_ids": [], + "source_task_id": "02314fc6-a24e-42f4-a8cd-362cae0f0ec1_phase1", + "change_summary": "Added a workflow skill for resilient document generation that detects installed converters first and chooses the best available output path instead of assuming PDF tooling exists.", + "content_diff": "--- a/SKILL.md\n+++ b/SKILL.md\n@@ -0,0 +1,272 @@\n+---\n+name: adaptive-document-output\n+description: Generate documents reliably by probing available conversion tools first, then selecting PDF, HTML, or source output based on what is actually installed.\n+---\n+\n+# Adaptive Document Output\n+\n+This skill defines a fallback workflow for document generation when the desired final format may require tools that are not installed. It is especially useful for agents that need to produce reports, resumes, invoices, or other formatted deliverables in constrained environments.\n+\n+The key principle is: do not assume a PDF engine exists. Probe the environment first, then choose the best achievable output format and conversion path.\n+\n+## When to use this skill\n+\n+Use this workflow when:\n+- You need to generate a formatted document, often ideally as PDF\n+- The runtime environment may or may not have document converters installed\n+- Multiple conversion tools might be available\n+- You want graceful degradation instead of repeated failing commands\n+\n+Typical cases:\n+- Markdown to PDF/HTML\n+- HTML to PDF\n+- LaTeX to PDF\n+- Templated report generation\n+- CI or sandboxed agent environments\n+\n+## Supported tool probes\n+\n+Check for these tools in this order unless task constraints suggest otherwise:\n+1. `pandoc`\n+2. `weasyprint`\n+3. `xelatex`\n+4. `pdflatex`\n+5. `wkhtmltopdf`\n+\n+These tools enable different output strategies:\n+- `pandoc`: versatile conversion hub; may still require a PDF engine for direct PDF output\n+- `weasyprint`: strong HTML/CSS to PDF path\n+- `xelatex`: robust Unicode-aware LaTeX to PDF\n+- `pdflatex`: LaTeX to PDF when Unicode/font needs are simpler\n+- `wkhtmltopdf`: HTML to PDF fallback\n+\n+## Workflow\n+\n+### 1. Clarify acceptable outputs\n+\n+Before generating files, determine the acceptable fallback order.\n+\n+Recommended preference:\n+1. PDF\n+2. HTML\n+3. Markdown or LaTeX source\n+\n+If the task explicitly requires PDF and no PDF path exists, still generate the best intermediate source and explain the limitation.\n+\n+### 2. Probe installed tools first\n+\n+Never start by issuing a guessed conversion command. Check what is actually present.\n+\n+Example shell probe:\n+#!/usr/bin/env bash\n+for cmd in pandoc weasyprint xelatex pdflatex wkhtmltopdf; do\n+ if command -v \"$cmd\" >/dev/null 2>&1; then\n+ echo \"$cmd: yes\"\n+ else\n+ echo \"$cmd: no\"\n+ fi\n+done\n+\n+Or compact form:\n+available() { command -v \"$1\" >/dev/null 2>&1; }\n+\n+### 3. Choose a generation strategy from available tools\n+\n+Use the following decision logic.\n+\n+#### Strategy A: `pandoc` plus a working PDF engine\n+Use when:\n+- `pandoc` is installed\n+- and either `xelatex` or `pdflatex` is installed\n+\n+Preferred command:\n+- Prefer `xelatex` over `pdflatex` for Unicode, modern fonts, and fewer encoding issues\n+\n+Examples:\n+pandoc input.md -o output.pdf --pdf-engine=xelatex\n+pandoc input.md -o output.pdf --pdf-engine=pdflatex\n+\n+Use this path when the source is Markdown and you want direct PDF generation.\n+\n+#### Strategy B: HTML intermediate plus `weasyprint`\n+Use when:\n+- `pandoc` is installed and `weasyprint` is installed\n+- or you can generate HTML by another means and `weasyprint` is installed\n+\n+Examples:\n+pandoc input.md -o output.html\n+weasyprint output.html output.pdf\n+\n+This is often the best fallback when direct pandoc-to-PDF fails due to missing TeX engines.\n+\n+#### Strategy C: HTML intermediate plus `wkhtmltopdf`\n+Use when:\n+- `wkhtmltopdf` is installed\n+- and you can produce HTML\n+\n+Examples:\n+pandoc input.md -o output.html\n+wkhtmltopdf output.html output.pdf\n+\n+Use this when `weasyprint` is unavailable.\n+\n+#### Strategy D: Native LaTeX compilation\n+Use when:\n+- you already have `.tex`\n+- and `xelatex` or `pdflatex` is installed\n+\n+Examples:\n+xelatex -interaction=nonstopmode -halt-on-error doc.tex\n+pdflatex -interaction=nonstopmode -halt-on-error doc.tex\n+\n+Prefer `xelatex` for multilingual text and font flexibility.\n+\n+#### Strategy E: No PDF path available\n+Use when:\n+- no viable PDF engine or converter exists\n+\n+Then:\n+- generate HTML if possible\n+- otherwise generate Markdown or LaTeX source\n+- clearly report that PDF could not be produced because no supported PDF toolchain is installed\n+\n+Examples:\n+pandoc input.md -o output.html\n+cp input.md deliverable.md\n+\n+## Recommended decision tree\n+\n+Follow this exact order unless the task has stronger constraints:\n+\n+1. Probe tools.\n+2. If `pandoc` and `xelatex` exist, generate PDF via pandoc + xelatex.\n+3. Else if `pandoc` and `pdflatex` exist, generate PDF via pandoc + pdflatex.\n+4. Else if `pandoc` and `weasyprint` exist, generate HTML then PDF via weasyprint.\n+5. Else if `pandoc` and `wkhtmltopdf` exist, generate HTML then PDF via wkhtmltopdf.\n+6. Else if source is LaTeX and `xelatex` exists, compile directly.\n+7. Else if source is LaTeX and `pdflatex` exists, compile directly.\n+8. Else if `pandoc` exists, emit HTML or another portable intermediate.\n+9. Else emit the highest-value source format you can generate directly.\n+\n+## Practical command patterns\n+\n+### Markdown input, adaptive output\n+#!/usr/bin/env bash\n+set -euo pipefail\n+\n+infile=\"${1:-input.md}\"\n+base=\"${2:-output}\"\n+\n+have() { command -v \"$1\" >/dev/null 2>&1; }\n+\n+if have pandoc && have xelatex; then\n+ pandoc \"$infile\" -o \"${base}.pdf\" --pdf-engine=xelatex\n+ echo \"Produced ${base}.pdf via pandoc + xelatex\"\n+elif have pandoc && have pdflatex; then\n+ pandoc \"$infile\" -o \"${base}.pdf\" --pdf-engine=pdflatex\n+ echo \"Produced ${base}.pdf via pandoc + pdflatex\"\n+elif have pandoc && have weasyprint; then\n+ pandoc \"$infile\" -o \"${base}.html\"\n+ weasyprint \"${base}.html\" \"${base}.pdf\"\n+ echo \"Produced ${base}.pdf via HTML + weasyprint\"\n+elif have pandoc && have wkhtmltopdf; then\n+ pandoc \"$infile\" -o \"${base}.html\"\n+ wkhtmltopdf \"${base}.html\" \"${base}.pdf\"\n+ echo \"Produced ${base}.pdf via HTML + wkhtmltopdf\"\n+elif have pandoc; then\n+ pandoc \"$infile\" -o \"${base}.html\"\n+ echo \"No PDF toolchain found; produced ${base}.html instead\"\n+else\n+ cp \"$infile\" \"${base}.md\"\n+ echo \"No converter found; copied source to ${base}.md\"\n+fi\n+\n+### LaTeX input, adaptive output\n+#!/usr/bin/env bash\n+set -euo pipefail\n+\n+texfile=\"${1:-doc.tex}\"\n+have() { command -v \"$1\" >/dev/null 2>&1; }\n+\n+if have xelatex; then\n+ xelatex -interaction=nonstopmode -halt-on-error \"$texfile\"\n+elif have pdflatex; then\n+ pdflatex -interaction=nonstopmode -halt-on-error \"$texfile\"\n+else\n+ echo \"No LaTeX PDF engine installed; cannot compile PDF\" >&2\n+ exit 1\n+fi\n+\n+## Error-handling guidance\n+\n+### If direct PDF conversion fails\n+Do not loop on the same failing assumption. Instead:\n+1. Inspect whether the failure is due to a missing engine\n+2. Switch to another supported path\n+3. Preserve useful intermediate artifacts such as `.html` or `.tex`\n+\n+Example:\n+- If `pandoc -o output.pdf` fails because no TeX engine is installed, retry with:\n+ - `pandoc input.md -o output.html`\n+ - then use `weasyprint` or `wkhtmltopdf` if available\n+\n+### If fonts or Unicode break LaTeX output\n+Prefer `xelatex` over `pdflatex`.\n+\n+### If no converter exists\n+Still provide a useful deliverable:\n+- polished Markdown\n+- standalone HTML\n+- LaTeX source\n+- a concise explanation of what blocked PDF generation\n+\n+## Output policy for autonomous agents\n+\n+When reporting results:\n+- State which tools were detected\n+- State which path was selected\n+- Name the produced files\n+- If PDF was not produced, explicitly say why and identify the fallback artifact\n+\n+Good example:\n+- Detected: `pandoc`, `weasyprint`\n+- Selected path: Markdown → HTML via pandoc, then HTML → PDF via weasyprint\n+- Produced: `report.html`, `report.pdf`\n+\n+Good fallback example:\n+- Detected: `pandoc` only\n+- No PDF engine available\n+- Produced: `report.html` as the best available deliverable\n+\n+## Heuristics\n+\n+- Prefer successful output over ideal-but-unavailable output\n+- Prefer deterministic detection over trial-and-error guesses\n+- Prefer preserving intermediates when switching strategies\n+- Prefer `xelatex` over `pdflatex` when both exist\n+- Prefer HTML as a universal intermediate when PDF engines are missing\n+\n+## Anti-patterns to avoid\n+\n+Avoid:\n+- Assuming `pandoc -o file.pdf` will work everywhere\n+- Assuming TeX is installed because `pandoc` is installed\n+- Repeating failed PDF commands without probing environment\n+- Discarding useful `.html` or `.tex` intermediates\n+- Claiming a PDF was produced without verifying the file exists\n+\n+## Minimal verification checklist\n+\n+Before declaring success:\n+- Confirm the selected converter command exited successfully\n+- Confirm the expected output file exists\n+- If PDF was requested but unavailable, confirm fallback file exists\n+- Report the exact fallback taken\n+\n+## Summary\n+\n+This workflow turns document generation into an adaptive process:\n+- probe tools first\n+- choose the best available route\n+- fall back cleanly\n+- always leave behind the highest-value output the environment supports", + "content_snapshot": { + "SKILL.md": "---\nname: adaptive-document-output\ndescription: Generate documents reliably by probing available conversion tools first, then selecting PDF, HTML, or source output based on what is actually installed.\n---\n\n# Adaptive Document Output\n\nThis skill defines a fallback workflow for document generation when the desired final format may require tools that are not installed. It is especially useful for agents that need to produce reports, resumes, invoices, or other formatted deliverables in constrained environments.\n\nThe key principle is: do not assume a PDF engine exists. Probe the environment first, then choose the best achievable output format and conversion path.\n\n## When to use this skill\n\nUse this workflow when:\n- You need to generate a formatted document, often ideally as PDF\n- The runtime environment may or may not have document converters installed\n- Multiple conversion tools might be available\n- You want graceful degradation instead of repeated failing commands\n\nTypical cases:\n- Markdown to PDF/HTML\n- HTML to PDF\n- LaTeX to PDF\n- Templated report generation\n- CI or sandboxed agent environments\n\n## Supported tool probes\n\nCheck for these tools in this order unless task constraints suggest otherwise:\n1. `pandoc`\n2. `weasyprint`\n3. `xelatex`\n4. `pdflatex`\n5. `wkhtmltopdf`\n\nThese tools enable different output strategies:\n- `pandoc`: versatile conversion hub; may still require a PDF engine for direct PDF output\n- `weasyprint`: strong HTML/CSS to PDF path\n- `xelatex`: robust Unicode-aware LaTeX to PDF\n- `pdflatex`: LaTeX to PDF when Unicode/font needs are simpler\n- `wkhtmltopdf`: HTML to PDF fallback\n\n## Workflow\n\n### 1. Clarify acceptable outputs\n\nBefore generating files, determine the acceptable fallback order.\n\nRecommended preference:\n1. PDF\n2. HTML\n3. Markdown or LaTeX source\n\nIf the task explicitly requires PDF and no PDF path exists, still generate the best intermediate source and explain the limitation.\n\n### 2. Probe installed tools first\n\nNever start by issuing a guessed conversion command. Check what is actually present.\n\nExample shell probe:\n#!/usr/bin/env bash\nfor cmd in pandoc weasyprint xelatex pdflatex wkhtmltopdf; do\n if command -v \"$cmd\" >/dev/null 2>&1; then\n echo \"$cmd: yes\"\n else\n echo \"$cmd: no\"\n fi\ndone\n\nOr compact form:\navailable() { command -v \"$1\" >/dev/null 2>&1; }\n\n### 3. Choose a generation strategy from available tools\n\nUse the following decision logic.\n\n#### Strategy A: `pandoc` plus a working PDF engine\nUse when:\n- `pandoc` is installed\n- and either `xelatex` or `pdflatex` is installed\n\nPreferred command:\n- Prefer `xelatex` over `pdflatex` for Unicode, modern fonts, and fewer encoding issues\n\nExamples:\npandoc input.md -o output.pdf --pdf-engine=xelatex\npandoc input.md -o output.pdf --pdf-engine=pdflatex\n\nUse this path when the source is Markdown and you want direct PDF generation.\n\n#### Strategy B: HTML intermediate plus `weasyprint`\nUse when:\n- `pandoc` is installed and `weasyprint` is installed\n- or you can generate HTML by another means and `weasyprint` is installed\n\nExamples:\npandoc input.md -o output.html\nweasyprint output.html output.pdf\n\nThis is often the best fallback when direct pandoc-to-PDF fails due to missing TeX engines.\n\n#### Strategy C: HTML intermediate plus `wkhtmltopdf`\nUse when:\n- `wkhtmltopdf` is installed\n- and you can produce HTML\n\nExamples:\npandoc input.md -o output.html\nwkhtmltopdf output.html output.pdf\n\nUse this when `weasyprint` is unavailable.\n\n#### Strategy D: Native LaTeX compilation\nUse when:\n- you already have `.tex`\n- and `xelatex` or `pdflatex` is installed\n\nExamples:\nxelatex -interaction=nonstopmode -halt-on-error doc.tex\npdflatex -interaction=nonstopmode -halt-on-error doc.tex\n\nPrefer `xelatex` for multilingual text and font flexibility.\n\n#### Strategy E: No PDF path available\nUse when:\n- no viable PDF engine or converter exists\n\nThen:\n- generate HTML if possible\n- otherwise generate Markdown or LaTeX source\n- clearly report that PDF could not be produced because no supported PDF toolchain is installed\n\nExamples:\npandoc input.md -o output.html\ncp input.md deliverable.md\n\n## Recommended decision tree\n\nFollow this exact order unless the task has stronger constraints:\n\n1. Probe tools.\n2. If `pandoc` and `xelatex` exist, generate PDF via pandoc + xelatex.\n3. Else if `pandoc` and `pdflatex` exist, generate PDF via pandoc + pdflatex.\n4. Else if `pandoc` and `weasyprint` exist, generate HTML then PDF via weasyprint.\n5. Else if `pandoc` and `wkhtmltopdf` exist, generate HTML then PDF via wkhtmltopdf.\n6. Else if source is LaTeX and `xelatex` exists, compile directly.\n7. Else if source is LaTeX and `pdflatex` exists, compile directly.\n8. Else if `pandoc` exists, emit HTML or another portable intermediate.\n9. Else emit the highest-value source format you can generate directly.\n\n## Practical command patterns\n\n### Markdown input, adaptive output\n#!/usr/bin/env bash\nset -euo pipefail\n\ninfile=\"${1:-input.md}\"\nbase=\"${2:-output}\"\n\nhave() { command -v \"$1\" >/dev/null 2>&1; }\n\nif have pandoc && have xelatex; then\n pandoc \"$infile\" -o \"${base}.pdf\" --pdf-engine=xelatex\n echo \"Produced ${base}.pdf via pandoc + xelatex\"\nelif have pandoc && have pdflatex; then\n pandoc \"$infile\" -o \"${base}.pdf\" --pdf-engine=pdflatex\n echo \"Produced ${base}.pdf via pandoc + pdflatex\"\nelif have pandoc && have weasyprint; then\n pandoc \"$infile\" -o \"${base}.html\"\n weasyprint \"${base}.html\" \"${base}.pdf\"\n echo \"Produced ${base}.pdf via HTML + weasyprint\"\nelif have pandoc && have wkhtmltopdf; then\n pandoc \"$infile\" -o \"${base}.html\"\n wkhtmltopdf \"${base}.html\" \"${base}.pdf\"\n echo \"Produced ${base}.pdf via HTML + wkhtmltopdf\"\nelif have pandoc; then\n pandoc \"$infile\" -o \"${base}.html\"\n echo \"No PDF toolchain found; produced ${base}.html instead\"\nelse\n cp \"$infile\" \"${base}.md\"\n echo \"No converter found; copied source to ${base}.md\"\nfi\n\n### LaTeX input, adaptive output\n#!/usr/bin/env bash\nset -euo pipefail\n\ntexfile=\"${1:-doc.tex}\"\nhave() { command -v \"$1\" >/dev/null 2>&1; }\n\nif have xelatex; then\n xelatex -interaction=nonstopmode -halt-on-error \"$texfile\"\nelif have pdflatex; then\n pdflatex -interaction=nonstopmode -halt-on-error \"$texfile\"\nelse\n echo \"No LaTeX PDF engine installed; cannot compile PDF\" >&2\n exit 1\nfi\n\n## Error-handling guidance\n\n### If direct PDF conversion fails\nDo not loop on the same failing assumption. Instead:\n1. Inspect whether the failure is due to a missing engine\n2. Switch to another supported path\n3. Preserve useful intermediate artifacts such as `.html` or `.tex`\n\nExample:\n- If `pandoc -o output.pdf` fails because no TeX engine is installed, retry with:\n - `pandoc input.md -o output.html`\n - then use `weasyprint` or `wkhtmltopdf` if available\n\n### If fonts or Unicode break LaTeX output\nPrefer `xelatex` over `pdflatex`.\n\n### If no converter exists\nStill provide a useful deliverable:\n- polished Markdown\n- standalone HTML\n- LaTeX source\n- a concise explanation of what blocked PDF generation\n\n## Output policy for autonomous agents\n\nWhen reporting results:\n- State which tools were detected\n- State which path was selected\n- Name the produced files\n- If PDF was not produced, explicitly say why and identify the fallback artifact\n\nGood example:\n- Detected: `pandoc`, `weasyprint`\n- Selected path: Markdown → HTML via pandoc, then HTML → PDF via weasyprint\n- Produced: `report.html`, `report.pdf`\n\nGood fallback example:\n- Detected: `pandoc` only\n- No PDF engine available\n- Produced: `report.html` as the best available deliverable\n\n## Heuristics\n\n- Prefer successful output over ideal-but-unavailable output\n- Prefer deterministic detection over trial-and-error guesses\n- Prefer preserving intermediates when switching strategies\n- Prefer `xelatex` over `pdflatex` when both exist\n- Prefer HTML as a universal intermediate when PDF engines are missing\n\n## Anti-patterns to avoid\n\nAvoid:\n- Assuming `pandoc -o file.pdf` will work everywhere\n- Assuming TeX is installed because `pandoc` is installed\n- Repeating failed PDF commands without probing environment\n- Discarding useful `.html` or `.tex` intermediates\n- Claiming a PDF was produced without verifying the file exists\n\n## Minimal verification checklist\n\nBefore declaring success:\n- Confirm the selected converter command exited successfully\n- Confirm the expected output file exists\n- If PDF was requested but unavailable, confirm fallback file exists\n- Report the exact fallback taken\n\n## Summary\n\nThis workflow turns document generation into an adaptive process:\n- probe tools first\n- choose the best available route\n- fall back cleanly\n- always leave behind the highest-value output the environment supports" + }, + "created_at": "2026-04-12T02:55:18.433237", + "created_by": "gpt-5.4" + }, + "tool_dependencies": [], + "critical_tools": [], + "total_selections": 0, + "total_applied": 0, + "total_completions": 0, + "total_fallbacks": 0, + "recent_analyses": [], + "first_seen": "2026-04-12T02:55:18.433253", + "last_updated": "2026-04-12T02:55:18.433254" + } +] \ No newline at end of file diff --git a/context/local-machine/admin-macos/mcp/repo-local.mcp.json b/context/local-machine/admin-macos/mcp/repo-local.mcp.json new file mode 100644 index 0000000..664da91 --- /dev/null +++ b/context/local-machine/admin-macos/mcp/repo-local.mcp.json @@ -0,0 +1,23 @@ +{ + "mcpServers": { + "openspace_evolution": { + "type": "stdio", + "command": "/Users/admin/PycharmProjects/openspace/.venv/bin/python", + "args": [ + "-m", + "openspace.evolution_mcp_server", + "--transport", + "stdio" + ], + "env": { + "OPENSPACE_WORKSPACE": "/Users/admin/PycharmProjects/openspace", + "OPENSPACE_HOST_SKILL_DIRS": "/Users/admin/.claude/projects/openspace/skills,/Users/admin/.claude/skills", + "OPENSPACE_MODEL": "gpt-5.4", + "OPENSPACE_LLM_API_BASE": "http://127.0.0.1:8080/v1", + "OPENSPACE_LLM_OPENAI_STREAM_COMPAT": "true", + "OPENSPACE_ENABLE_RECORDING": "false", + "OPENSPACE_BACKEND_SCOPE": "shell,system" + } + } + } +} diff --git a/gdpval_bench/run_benchmark.py b/gdpval_bench/run_benchmark.py index a3790eb..49d031c 100644 --- a/gdpval_bench/run_benchmark.py +++ b/gdpval_bench/run_benchmark.py @@ -388,6 +388,7 @@ def _make_config(cfg: Dict, phase: str, worker_id: int = 0): return OpenSpaceConfig( llm_model=cfg["model"], + llm_kwargs=cfg.get("llm_kwargs", {}), workspace_dir=str(rd / "workspace" / phase), recording_log_dir=rec_dir, recording_backends=cfg.get("backend_scope", ["shell", "web"]), @@ -1164,6 +1165,16 @@ async def main(args: argparse.Namespace) -> None: if getattr(args, "use_clawwork_productivity", False): cfg["use_clawwork_productivity"] = True + # Match CLI / MCP entrypoints: resolve provider credentials once and pass + # them into OpenSpaceConfig.llm_kwargs so benchmark runs work with custom + # OPENSPACE_LLM_* endpoints too. + from openspace.host_detection import build_llm_kwargs, load_runtime_env + + load_runtime_env() + resolved_model, llm_kwargs = build_llm_kwargs(cfg.get("model", "")) + cfg["model"] = resolved_model + cfg["llm_kwargs"] = llm_kwargs + # When using ClawWork productivity tools, ensure livebench is importable # before OpenSpace.initialize() (ShellSession loads productivity_tools which imports livebench) if cfg.get("use_clawwork_productivity"): diff --git a/openspace/skill_engine/evolver.py b/openspace/skill_engine/evolver.py index 818d8bf..e8ff6fa 100644 --- a/openspace/skill_engine/evolver.py +++ b/openspace/skill_engine/evolver.py @@ -43,6 +43,7 @@ from .patch import ( create_skill, fix_skill, derive_skill, + parse_multi_file_full, SKILL_FILENAME, ) from .skill_utils import ( @@ -71,6 +72,7 @@ EVOLUTION_FAILED = SkillEnginePrompts.EVOLUTION_FAILED _SKILL_CONTENT_MAX_CHARS = 12_000 # Max chars of SKILL.md in evolution prompt _MAX_SKILL_NAME_LENGTH = 50 # Max chars for a skill name (directory name) +_MULTI_FILE_FULL_HEADER_RE = re.compile(r"(?m)^\*\*\*\s*File:\s*") def _sanitize_skill_name(name: str) -> str: @@ -95,6 +97,88 @@ def _sanitize_skill_name(name: str) -> str: truncated = truncated[:last_hyphen] return truncated.strip("-") + +def _extract_generated_frontmatter_field(content: str, field_name: str) -> Optional[str]: + """Extract frontmatter fields from single-file or multi-file FULL outputs.""" + direct = _extract_frontmatter_field(content, field_name) + if direct: + return direct + + if _MULTI_FILE_FULL_HEADER_RE.search(content): + try: + skill_md = parse_multi_file_full(content).get(SKILL_FILENAME, "") + except Exception: + skill_md = "" + if skill_md: + nested = _extract_frontmatter_field(skill_md, field_name) + if nested: + return nested + + # Fall back to the top of the generated text to tolerate minor format drift. + head = "\n".join(content.splitlines()[:40]) + match = re.search( + rf"(?im)^\s*{re.escape(field_name)}\s*:\s*(.+?)\s*$", + head, + ) + if not match: + return None + + value = match.group(1).strip().strip("\"'") + return value or None + + +def _serialize_multi_file_full(files: Dict[str, str]) -> str: + """Serialize parsed FULL files back into the ``*** Begin Files`` format.""" + ordered_paths = [SKILL_FILENAME] + ordered_paths.extend(path for path in sorted(files) if path != SKILL_FILENAME) + + lines = ["*** Begin Files"] + for path in ordered_paths: + if path not in files: + continue + lines.append(f"*** File: {path}") + body = files[path].rstrip("\n") + if body: + lines.append(body) + lines.append("*** End Files") + return "\n".join(lines).strip() + "\n" + + +def _set_generated_frontmatter_field(content: str, field_name: str, value: str) -> str: + """Inject or update frontmatter fields in single-file or multi-file FULL outputs.""" + if _MULTI_FILE_FULL_HEADER_RE.search(content): + files = parse_multi_file_full(content) + files[SKILL_FILENAME] = _set_frontmatter_field( + files.get(SKILL_FILENAME, ""), + field_name, + value, + ) + return _serialize_multi_file_full(files) + + return _set_frontmatter_field(content, field_name, value) + + +def _fallback_captured_skill_name( + direction: str, + category: Optional[SkillCategory], +) -> str: + """Generate a deterministic fallback skill name from the capture direction.""" + hint = (direction or "").strip() + hint = re.split(r"[:.;\n]", hint, maxsplit=1)[0].strip() + hint = re.sub(r"(?i)^capture\s+", "", hint) + hint = re.sub(r"(?i)^a\s+reusable\s+", "", hint) + hint = re.sub(r"(?i)^reusable\s+", "", hint) + hint = re.sub(r"(?i)^(workflow|reference|tool[- ]guide)\s+for\s+", "", hint) + hint = re.sub(r"(?i)^(adding|creating|capturing|building)\s+", "", hint) + hint = re.sub(r"(?i)^(a|an|the)\s+", "", hint) + + fallback = _sanitize_skill_name(hint) + if fallback: + return fallback + + prefix = (category.value if category else "captured-skill").replace("_", "-") + return f"{prefix}-{uuid.uuid4().hex[:6]}" + _ANALYSIS_CONTEXT_MAX = 5 # Max recent analyses to include in prompt _ANALYSIS_NOTE_MAX_CHARS = 500 # Per-analysis note truncation @@ -937,15 +1021,26 @@ class SkillEvolver: new_content, change_summary = _extract_change_summary(new_content) # Extract name/description from the generated content - new_name = _extract_frontmatter_field(new_content, "name") - new_desc = _extract_frontmatter_field(new_content, "description") + new_name = _extract_generated_frontmatter_field(new_content, "name") + new_desc = _extract_generated_frontmatter_field(new_content, "description") if not new_name: - logger.warning("CAPTURED: LLM did not produce a valid skill name") - return None + new_name = _fallback_captured_skill_name( + ctx.suggestion.direction, + ctx.suggestion.category, + ) + logger.warning( + "CAPTURED: LLM did not produce a valid skill name; using fallback '%s'", + new_name, + ) # Sanitize name (enforce length limit + valid chars) new_name = _sanitize_skill_name(new_name) - new_content = _set_frontmatter_field(new_content, "name", new_name) + if not new_name: + new_name = _fallback_captured_skill_name( + ctx.suggestion.direction, + ctx.suggestion.category, + ) + new_content = _set_generated_frontmatter_field(new_content, "name", new_name) # Create new skill directory via create_skill (handles multi-file FULL) skill_dirs = self._registry._skill_dirs @@ -1528,4 +1623,4 @@ class SkillEvolver: f"better error handling or alternative approaches." ) - return None, "" \ No newline at end of file + return None, "" diff --git a/openspace/tool_layer.py b/openspace/tool_layer.py index 84a6457..1a902fc 100644 --- a/openspace/tool_layer.py +++ b/openspace/tool_layer.py @@ -357,6 +357,7 @@ class OpenSpace: self._task_done.clear() self._last_evolved_skills = [] # Reset per-execution tracking start_time = asyncio.get_event_loop().time() + execution_time = 0.0 # Use external task_id if provided, otherwise generate one if task_id is None: task_id = f"task_{uuid.uuid4().hex[:12]}" @@ -555,6 +556,9 @@ class OpenSpace: } finally: + if execution_time <= 0: + execution_time = asyncio.get_event_loop().time() - start_time + recording_dir = None if self._recording_manager and self._recording_manager.recording_status: recording_dir = self._recording_manager.trajectory_dir diff --git a/tests/test_evolver_captured_names.py b/tests/test_evolver_captured_names.py new file mode 100644 index 0000000..a511911 --- /dev/null +++ b/tests/test_evolver_captured_names.py @@ -0,0 +1,79 @@ +from openspace.skill_engine.evolver import ( + _extract_generated_frontmatter_field, + _fallback_captured_skill_name, + _set_generated_frontmatter_field, +) + + +def test_extract_generated_frontmatter_field_from_single_file() -> None: + content = """--- +name: safe-file-write +description: Write files with validation. +--- + +# Safe File Write +""" + + assert _extract_generated_frontmatter_field(content, "name") == "safe-file-write" + assert ( + _extract_generated_frontmatter_field(content, "description") + == "Write files with validation." + ) + + +def test_extract_generated_frontmatter_field_from_multi_file_full() -> None: + content = """*** Begin Files +*** File: SKILL.md +--- +name: local-acceptance-entry +description: Run a repo's backend and frontend together for review. +--- + +# Local Acceptance Entry +*** File: examples/start.sh +#!/usr/bin/env bash +echo start +*** End Files +""" + + assert ( + _extract_generated_frontmatter_field(content, "name") + == "local-acceptance-entry" + ) + assert ( + _extract_generated_frontmatter_field(content, "description") + == "Run a repo's backend and frontend together for review." + ) + + +def test_set_generated_frontmatter_field_updates_skill_md_in_multi_file_full() -> None: + content = """*** Begin Files +*** File: SKILL.md +--- +description: Run a repo's backend and frontend together for review. +--- + +# Local Acceptance Entry +*** File: examples/start.sh +#!/usr/bin/env bash +echo start +*** End Files +""" + + updated = _set_generated_frontmatter_field(content, "name", "local-acceptance-entry") + + assert "*** File: SKILL.md" in updated + assert "name: local-acceptance-entry" in updated + assert "*** File: examples/start.sh" in updated + + +def test_fallback_captured_skill_name_uses_direction_signal() -> None: + direction = ( + "Capture a reusable workflow for adding a local acceptance entry in " + "split backend/frontend repos: create one canonical foreground acceptance script." + ) + + fallback = _fallback_captured_skill_name(direction, None) + + assert fallback.startswith("local-acceptance-entry-in-split-backend") + assert len(fallback) <= 50