.agents/skills/process-lifecycle/SKILL.md
Session creation, workspace isolation, cleanup
npx skillsauth add ronniegeraghty/hyoka process-lifecycleInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Each hyoka evaluation runs in an isolated workspace with its own session. Understanding process lifecycle is critical for debugging eval failures, preventing resource leaks, and writing tests.
When an evaluation starts:
// Create workspace directory
ws, err := NewWorkspace(ctx, "eval-run-123")
if err != nil {
return fmt.Errorf("create workspace: %w", err)
}
defer ws.Close() // Cleanup deferred
// Start Copilot session in workspace
sess, err := copilot.NewSession(ctx, &SessionOptions{
WorkingDir: ws.Path(),
Model: "claude-opus-4.6",
// ...
})
Workspace is created as a temporary directory:
/tmp/hyoka-{run_id}-XXXXXX%TEMP%\hyoka-{run_id}-XXXXXXCopilot SDK launches the agent process:
┌─────────────────────────────────────┐
│ hyoka (CLI process, PID 1234) │
└──────────────┬──────────────────────┘
│
├─→ Workspace: /tmp/hyoka-eval-1
│
└─→ Copilot process (PID 1235) [child]
├─→ MCP server (PID 1236) [grandchild]
└─→ Tool subprocess (PID 1237) [grandchild]
The CLI tracks all child PIDs for cleanup on signal.
Agent writes generated code to workspace:
/tmp/hyoka-eval-1/
main.py # Generated code
test_main.py # Generated tests
Copilot.log # Session log
action_timeline.json # Captured actions
The CLI captures all file operations in the action timeline.
When evaluation completes (success or failure):
// Workspace cleanup
if err := ws.Close(); err != nil {
slog.Warn("Workspace cleanup failed", "path", ws.Path(), "error", err)
}
// Copilot session cleanup
if err := sess.Close(); err != nil {
slog.Warn("Session cleanup failed", "error", err)
}
// Orphaned process cleanup (if signal received)
// kill all child PIDs
Cleanup removes:
Hyoka tracks child processes to ensure cleanup on interruption:
// hyoka/internal/eval/proctracker.go
tracker := NewProcessTracker()
// Register Copilot process
tracker.Add(sess.PID())
// On SIGINT, cleanup
<-sigChan
tracker.KillAll() // Kills all tracked processes
For long-running evaluations, PIDs are written to files:
reports/{run_id}/
pids.txt # List of tracked PIDs
If eval crashes, hyoka clean reads these files and kills orphaned processes.
Created ✓
Tools loaded ✓
MCP servers started ✓
Skills injected ✓
Ready for agent ✓
Agent running...
Tool calls executed...
Files written...
Actions captured...
Agent stopped ✓
Build phase (optional)
Review phase (if enabled)
Workspace preserved (for debugging)
Workspace deleted ✓
Session closed ✓
Processes killed ✓
Each eval is isolated to prevent:
This is achieved by:
go run ./hyoka clean
This command:
reports/{run_id}/pids.txtUseful after:
Per-evaluation guardrails prevent runaway sessions:
limits:
max_turns: 25 # Max agent turns
max_files: 50 # Max files created
max_output_size: 1048576 # Max output (1 MB)
max_session_actions: 50 # Max tool calls
When limit exceeded:
Generation phase stops → Session killed → Error reported
In tests, use stub workspaces:
// Stub workspace that doesn't create disk files
type stubWorkspace struct {
files map[string]string // In-memory files
}
func (sw *stubWorkspace) WriteFile(path, content string) error {
sw.files[path] = content
return nil
}
Never create real workspaces in tests (use stubs or temp directories).
hyoka/internal/eval/workspace.gohyoka/internal/eval/proctracker.gohyoka/cmd/clean.gohyoka/internal/eval/copilot.godevelopment
Identifies Azure SDK packages in generated code and checks whether they are the latest available versions. Use during code review to catch outdated dependencies.
development
Sets up build environments for generated Azure SDK code samples and attempts to compile/build without modifying generated files. Use during review to verify code compiles correctly.
development
# Java SDK Validation Skill You are a **Java Azure SDK validation reviewer** for generated code samples. Your job is to check whether generated Java code follows modern Azure SDK for Java conventions and flag violations of common anti-patterns that LLMs frequently produce. ## Rules 1. **NEVER modify generated code.** You are evaluating, not fixing. 2. Report all findings honestly — pass or fail with specific evidence. 3. Check every rule below. A single violation in a category means that cate
development
Reads generated Azure SDK code files and adds inline review comments without changing any actual code. Use during code review to annotate quality issues, best practices, and suggestions.