StarAgent: Skill for Codex

Simplify StarAgent

Prefer a few proven reductions over a broad rewrite. Optimize for less code, fewer states, and clearer ownership while preserving observable behavior unless the user explicitly authorizes a product change.

Establish Context

• Read .agents/staragent-dev/SKILL.md, ARCHITECTURE.md, and the documentation that owns the area under review.
• Inspect git status, the active diff, and recent history before editing. Preserve unrelated and uncommitted user work.
• Treat tmux as the runtime source of truth. Preserve Node scoping, local/remote parity, authentication boundaries, allowlisted execution, and Agent Session continuity.
• Start with the current diff and the largest relevant production files. Expand only when call-site evidence requires it.

Find Strong Candidates

Look for maintenance surface that costs more than it provides:

• Helpers, routes, fields, states, compatibility aliases, or configuration with no production consumer.
• Tests or documentation as the only consumer of behavior that is no longer a maintained contract.
• Multiple representations or caches for one fact, especially across Hub, Node, browser, and tmux state.
• Repeated normalization, proxy, rendering, or error-handling branches that can share one owner.
• Defensive copies, validators, locks, or fallbacks that protect no real trust or concurrency boundary.
• One-use wrappers that obscure a direct standard-library or framework operation.
• Hand-rolled parsing, retry, diff, or protocol machinery already covered by the Python standard library, a browser platform API, or an existing dependency.
• Comments and docs that restate implementation, describe removed behavior, or live above the layer that owns the contract.

Do not count formatting churn, renamed symbols, code moved into another wrapper, or a new dependency with equal glue as simplification.

Prove Each Candidate

1. Search the exact symbol, route, wire key, CSS class, data attribute, or configuration name with rg.
2. Classify every hit as production, test, documentation, generated output, or runtime state.
3. Inspect dynamic consumers: Jinja-generated paths, delegated browser events, Node capability payloads, tmux command construction, and string-based registries may not look like normal calls.
4. Check Git history when code looks historical or defensive; determine which failure or compatibility promise introduced it.
5. State the simpler owner and the behavior that remains. Estimate net deletion including replacement glue, tests, and docs.
6. Reject the candidate if it requires an unrequested feature decision, weakens a security boundary, or merely relocates complexity.