Skip to content
Back to skills

Licensed Machine Prompt Orchestration

ASecurity

Design self-contained prompts for licensed machines (Windows, no Hermes) that Claude Code / Codex / Gemini CLIs can execute autonomously. Covers fixture generation, solver validation, and cross-machine data bridging.

  • 17 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 9, 2026
toolspythonrustgoshellbashgitapi

Works with

  • claude code
  • terminal
  • cli
  • api

Security analysis

A92/100
  • mediumInstalls packages at runtime which could introduce malicious dependencies

Pro shows the line behind each finding and how to fix it

Scanned September 28, 2026

npx -y skills add vamseeachanta/workspace-hub --skill licensed-machine-prompt-orchestration --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Licensed Machine Prompt Orchestration?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Licensed Machine Prompt Orchestration
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/vamseeachanta-licensed-machine-prompt-orchestration/badge)](https://www.skillsdirectory.com/skills/vamseeachanta-licensed-machine-prompt-orchestration)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: licensed-machine-prompt-orchestration
description: Design self-contained prompts for licensed machines (Windows, no Hermes) that Claude Code / Codex / Gemini CLIs can execute autonomously. Covers fixture generation, solver validation, and cross-machine data bridging.
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [licensed-machine, prompts, orchestration, solver, fixtures, cross-machine]
    related_skills: [digitalmodel-orcawave-orcaflex-workflow, overnight-parallel-agent-prompts]
---

# Licensed-Machine Prompt Orchestration

Use this skill when you need to prepare work for a machine that has commercial solver licenses (OrcFxAPI, ANSYS, etc.) but does NOT have Hermes installed. The machine typically has Claude Code CLI, Codex CLI, and/or Gemini CLI available.

## When to use

- Generating solver fixtures (.owr, .sim, .dat) that require licensed APIs
- Validating dev-primary pipeline outputs against authoritative solver data
- Running calculations that can only execute on the licensed machine
- Any cross-machine workflow where dev-primary prepares code and the licensed machine produces evidence

## Prompt design principles (learned from 3 iterations)

### 1. Self-contained — no external context assumed

The agent on the licensed machine has NO memory, NO skills, NO Hermes. Every prompt must include:
- Exact workspace path (e.g., `<workspace-root>\workspace-hub`)
- Which Python command to use (`python` not `uv run` on Windows)
- Full inline scripts — do NOT reference functions in packages the agent might not find
- `git pull` as the first step, `git push` as the last step

### 2. Inline Python over module imports

BAD (breaks when sys.path isn't set up):
```
from digitalmodel.hydrodynamics.hull_library.rao_extractor import xlsx_to_rao_data
```

GOOD (works anywhere):
```python
python -c "
import OrcFxAPI
d = OrcFxAPI.Diffraction()
d.LoadResults(r'path\to\file.owr')
print('Frequencies:', len(d.frequencies))
"
```

For longer scripts, use `python << 'PYEOF'` heredoc on Git Bash, or write a temp .py file.

If you MUST import from the repo, prefix with:
```python
import sys; sys.path.insert(0, r'digitalmodel\src')
```

### 3. Each prompt writes to non-overlapping paths

Structure prompts so Terminal 1 runs them sequentially and each writes to different directories:
- PROMPT 1 → `digitalmodel/tests/fixtures/solver/hemisphere.*`
- PROMPT 2 → `digitalmodel/tests/fixtures/solver/L02_*`
- PROMPT 3 → `output/orcaflex_validation/*`

This avoids git contention if prompts are accidentally parallelized.

### 4. Graceful failure — always comment on the issue

Every prompt must have a failure path that:
1. Catches the error
2. Comments on the relevant GitHub issue explaining what failed
3. Moves on to the next prompt

Example:
```
If it fails, skip to STEP 5 and do:
    gh issue comment 1789 --body "Hemisphere BLOCKED. Error: [paste]. Moving on."
```

### 5. Verify before commit

Every prompt should include a verification step BETWEEN generation and commit:
```python
# Verify the fixture loads
python -c "import OrcFxAPI; d=OrcFxAPI.Diffraction(); d.LoadResults(r'path.owr'); print('OK:', len(d.frequencies), 'freqs')"
```

### 6. Use the same xlsx export template everywhere

When generating xlsx sidecars from .owr files, use this canonical template. It produces the "pipeline format" that the rao_extractor.py can auto-detect:

Sheets: Summary, RAOs, AddedMass, Damping, Discretization
- RAOs columns: `{DOF}_Mag_H{heading}`, `{DOF}_Phase_H{heading}`
- AddedMass/Damping columns: `{DOFi}_{DOFj}` for full 6x6

CRITICAL: Sort frequencies ascending (`sort_idx = np.argsort(freq_rad)`) before writing.

## Licensed-machine prompt file structure

Place prompts at: `docs/plans/licensed-win-1-session-N-prompts.md`

Standard sections:
1. **Prerequisites** — git pull, pip install checks, OrcFxAPI version verify
2. **PROMPT N** blocks — each with Priority, Time estimate, Issue reference, STEP-by-STEP instructions
3. **Execution Plan** — Terminal 1 (sequential claude -p commands), Terminal 2 (verification)
4. **Git Contention Map** — table showing which prompt writes where
5. **Key Reminders** — python not uv run, git pull/push, digitalmodel is separate repo

## Execution on the licensed machine

```powershell
cd <workspace-root>\workspace-hub
git pull origin main
cd digitalmodel && git pull origin main && cd ..

claude -p "Read docs/plans/licensed-win-1-session-N-prompts.md, execute PROMPT 1. Use python (not uv run). Commit and push results."
claude -p "Read docs/plans/licensed-win-1-session-N-prompts.md, execute PROMPT 2. Use python (not uv run). Commit and push results."
```

## Cross-machine data bridge pattern

The key insight from this work stream: **use xlsx as the license-free data bridge**.

1. Licensed machine runs the solver → produces binary .owr
2. Licensed machine ALSO exports .xlsx sidecar (openpyxl, inline script)
3. Both .owr + .xlsx are committed to fixtures/
4. Dev-primary reads ONLY the .xlsx (no solver license needed)
5. Licensed machine validates xlsx matches .owr at machine-epsilon precision

This pattern works for any proprietary binary format where you need dev-primary to work without the licensed reader.

## OrcFxAPI version pitfalls (discovered on licensed-win-1)

| Pattern | Works | Does NOT work |
|---------|-------|---------------|
| Frequency count | `len(np.array(d.frequencies))` | `d.frequencyCount` |
| Heading count | `len(np.array(d.headings))` | `d.headingCount` |
| Body count | `np.array(d.addedMass).shape[1] // 6` | `d.bodyCount` |
| Model objects | count manually | `model.objectCount` |

Always use the numpy-array approach for portability across OrcFxAPI versions.

## Validation script pattern

After generating fixtures, always create a validation script that compares xlsx against .owr:

```python
# Pattern: load .owr with OrcFxAPI, load .xlsx with openpyxl, compare
# Validate: frequencies, RAO amplitudes (relative), added mass (absolute)
# Threshold: machine epsilon for pipeline-format xlsx (bit-exact)
# Store script at: scripts/solver/validate_xlsx_against_owr.py
```

The validation proves the xlsx sidecar is trustworthy — dev-primary work inherits this proof.

## Session report pattern

After each licensed-machine session, create:
`docs/reports/YYYY-MM-DD-licensed-win-1-session-N-report.md`

Include: outcomes table (DONE/BLOCKED per prompt), new fixtures, validation results, issue comments posted, API lessons learned, remaining work.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.