Workflow Runner

This skill is a proof-of-concept that mostly does what it says, but there are gaps and some risky choices you should consider before installing: - Sensitive on-disk session data: session-store.js writes session metadata (including sessionKey-like strings) to skills/workflow-runner/session-store.json. Those session identifiers can be sensitive — treat the file as credentials and audit/remove any real session tokens before using the skill. - Undeclared runtime dependencies: testing_worker.sh uses jq and the scripts use tar and standard shell utilities. The skill metadata lists no required binaries; ensure jq/tar are available or update the scripts/metadata. If jq is not present, tests may fail in ways that could be confusing. - Placeholder behavior: orchestrator.js only prints payloads for sessions_spawn and does not perform real API calls; no script actually performs the advertised local git commit. If you expect full automation, you or a reviewer must implement the platform-specific calls and the commit step and re-audit them. - Local artifacts and permissions: the skill writes to results/ and /tmp; run it in a dedicated workspace and ensure file permissions are appropriate. - Best practices: run this skill only in an isolated/dev environment, inspect and sanitize session-store.json (remove hardcoded sessionKeys), add declared dependencies, and implement/inspect any code that will call platform session APIs before granting it access to live session credentials. If you are uncomfortable with persistent session tokens on disk, do not install or disable persistence and manual-manage sessions instead.