<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Best Practices on Shin Li</title><link>https://shin13.github.io/tags/best-practices/</link><description>Recent content in Best Practices on Shin Li</description><generator>Hugo</generator><language>en-US</language><copyright>Shin Li</copyright><lastBuildDate>Tue, 12 May 2026 06:53:59 +0800</lastBuildDate><atom:link href="https://shin13.github.io/tags/best-practices/index.xml" rel="self" type="application/rss+xml"/><item><title>[Dev] Following a Goal with Codex (/goal)</title><link>https://shin13.github.io/notes/following-a-goal-with-codex/</link><pubDate>Tue, 12 May 2026 06:00:00 +0800</pubDate><guid>https://shin13.github.io/notes/following-a-goal-with-codex/</guid><description>&lt;p&gt;I have been looking for a clean way to explain what &lt;code&gt;/goal&lt;/code&gt; really does in Codex.&lt;/p&gt;
&lt;p&gt;The most useful mental model I found is simple: &lt;code&gt;/goal&lt;/code&gt; is not a prettier prompt. It is a working contract for long-running agent work. You are telling the agent what success looks like, what the boundary is, and how to know when to stop.&lt;/p&gt;
&lt;p&gt;That framing matters because the feature is built for work that outlives one turn. If the objective is durable enough, the agent can keep making progress, validate its own steps, and come back to you with a result instead of a half-finished thought.&lt;/p&gt;</description></item></channel></rss>