GPT-6 Astra: How to Write Better Prompts and Skills | HackerNoon  🔗 **Source:** [GPT-6 Astra: How to Write Better Prompts and Skills | HackerNoon](https://hackernoon.com/gpt-6-astra-how-to-write-better-prompts-and-skills) > [!note]+ Document Notes > tags: [prompt-engineering, agent-skills, ai-coding-agents, codex, agents-md] > author: Vladislav Guzey > source: HackerNoon > reference: https://hackernoon.com/gpt-6-astra-how-to-write-better-prompts-and-skills > date created: 2026-09-22 > > > [!info] Generated analysis — not the author's words. Sections below are machine-written > > from the captured source. Only text inside `> [!quote]` blocks is verbatim from the author. > > Do not quote or attribute any other line to the named author. > > # 🏷️ Title: GPT-6 Astra: How to Write Better Prompts and Skills > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [OpenAI: Rethinking skills and prompts for GPT-6 Astra](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) - [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills) - [OpenAI: Custom instructions with AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md) - [OpenAI: Prompting](https://learn.chatgpt.com/docs/prompting) - [OpenAI: Sandbox](https://learn.chatgpt.com/docs/sandboxing) - [OpenAI: GPT-6 Astra instruction following](https://developers.openai.com/api/docs/guides/latest-model) - [Author's full guide on proflead.dev](https://proflead.dev/posts/gpt-6-astra-codex-prompts-skills-agents-md/) - [Author's Codex video tutorial](https://youtu.be/FESNAh3gNyQ) ## 📝 Summary - **What happened:** Vladislav Guzey (proflead.dev) syndicated to HackerNoon a 2,134-word walkthrough of OpenAI's GPT-6 Astra guidance on prompts, skills, and AGENTS.md for Codex, using one running example: adding a supplied article to a website and preparing a local preview. - **Why it matters:** it splits agent instructions into three layers with distinct jobs — the task prompt (this request's result and inputs), `SKILL.md` (a reusable workflow), and `AGENTS.md` (project rules like build commands) — and shows how mixing them causes duplication and misrouting. - **Key stakeholders:** developers using Codex CLI; anyone authoring skills for any agent harness (the pattern transfers directly to Claude Code skills); teams maintaining shared AGENTS.md files. - **Risks and tradeoffs:** every recommendation rests on OpenAI documentation, not measured outcomes; the author states the test table is "expected behaviors to test, not results from a benchmark." The piece also funnels to the author's video and site. - **Bottom line:** define the finished result, give each skill one job with the job in the first words of its description, load references conditionally, write approval rules around specific actions and targets, and diagnose a pause's source before rewriting rules. ## 📖 Main Content - **Three instruction layers.** Task prompt = result + inputs for this request ("Add this article using this cover image"). `SKILL.md` = repeated workflow ("Prepare an article page and a local preview"). `AGENTS.md` = project rules ("Where posts live and which checks are required"). Keeping the build command in one project rule means one edit when it changes, instead of edits in every skill that copied it. - **Prompts describe the finished result.** The good example prompt names inputs, what to preserve (title, wording, code, links), permitted local changes, required checks, a no-deploy guard, visual inspection at two widths, the report format, and the stopping point ("Leave deployment for a separate instruction"). The author says not to prescribe every tool call unless order matters. - **Missing inputs need a rule.** Report the gap (e.g. no publication date) rather than invent a value; continue work that doesn't depend on it. - **One job per skill.** A broad description ("Help with websites, articles, content, design, and publishing") matches a navigation-menu bug it can't help with. The precise version names the job. Mechanism: Codex sees only name + description until it selects a skill, and descriptions may be shortened when many skills load. - **Progressive disclosure.** Keep `SKILL.md` short; put conditional material in `references/` with explicit "read X when Y" lines. Splitting files is optional; required project rules must stay intact. - **Approval rules around actions and targets.** "Show me the result before publishing to the live website" beats "ask before every step." Check what commands actually do first: a local command can hit a live service, a build script can deploy, a preview can be public. - **Instructions vs. access.** The sandbox limits file and network access; approval settings govern requests at that boundary. A prompt can't grant a missing permission. - **Verify the result, then test the skill's scope.** A passing build doesn't prove a cover is readable on a phone. Test with a complete input, a missing input, an unrelated request (should not trigger the skill), no browser tools, and a draft-only run. - **Investigate pauses.** Ask the agent to name the blocking instruction's file and quote it, or name the tool restriction. For a wider review, an audit prompt looks for vague descriptions, conflicting rules, unneeded required reading, repeated checks, and missing completion criteria — and stops at proposed edits. - **Uncertainty:** "GPT-6 Astra" specifics are attributed entirely to OpenAI pages; nothing in the article is model-specific beyond that attribution. The advice reads as harness-general. ### 🗒️ Notes - Example repo skill path: `.agents/skills/site-article-preview/SKILL.md` + `references/preview-checklist.md`. OpenAI lists repo `.agents/skills/` as a Codex skill location. - Invocation in Codex CLI: `$site-article-preview` or `/skills`. If missing, check location, filename, metadata, then restart. - The checklist includes "If a browser check is unavailable, say so. Do not describe that check as passed." — the honesty rule is written into the reference, not left to the model. - "Ask before every step" is framed as a failure mode because it interrupts the preparation the approval point exists to review. - Re-running checks: rerun affected checks after a fix; don't repeat a passing check when nothing relevant changed. - The audit prompt ends "Propose edits for review before changing these instruction files" — a different stopping point from the article workflow because shared instructions affect future tasks. - Footer: HackerNoon "Decentralize AI Hackathon" ad (Arweave, Nosana, MEXC) — not part of the argument. ## 📚 References - [OpenAI: Rethinking skills and prompts for GPT-6 Astra](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) — primary source for the whole piece - [OpenAI: Build skills](https://learn.chatgpt.com/docs/build-skills) — description-first selection, skill locations, ` mentions - [OpenAI: Custom instructions with AGENTS.md](https://learn.chatgpt.com/docs/agent-configuration/agents-md) - [OpenAI: Prompting](https://learn.chatgpt.com/docs/prompting) — goal, context, output, boundaries - [OpenAI: Sandbox](https://learn.chatgpt.com/docs/sandboxing) — access vs. approval controls - [OpenAI: GPT-6 Astra instruction following](https://developers.openai.com/api/docs/guides/latest-model) - [Anthropic: Agent Skills overview](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview) — same name/description-first loading and progressive disclosure in Claude's skill system (added for comparison; not cited by the author) ## 🗣️ Paraphrase - "Add this article to my website" is ambiguous: draft, local change, browser check, or publish? A saved file isn't a finished update if links break or the cover is missing. - OpenAI's Astra guide says to review your Codex instructions: focused skill descriptions, relevant supporting files, clear approval rules, explicit completion. - Task prompts, skills, and AGENTS.md each have a job: this request, a reusable workflow, and standing project rules. Put the build command in one place. - Describe the finished result and anything that changes how to do it. Don't script every tool call. Say what to do when an input is missing. - Give a skill one job and put that job at the front of its description, because the description is all the agent sees before choosing it. - Keep `SKILL.md` short, name the output and review, and leave project commands to project instructions. A checklist can live in a reference file if it'll grow. - Load extra references only when the task needs them (video embeds, translations); don't strip required rules while doing it. - Write approvals around the action and target — "show me before publishing live" — and check what your commands really touch. Prompts don't change permissions; the sandbox does. - Check the result for the failures that would make it unusable, and test the skill against inputs that should and shouldn't trigger it. - When the agent pauses unexpectedly, have it name the instruction or permission responsible before you rewrite anything. Audit instructions by proposing edits, not applying them. ## 📰 Newsletter - **Your skill description is a router, not a résumé.** Vladislav Guzey's [HackerNoon walkthrough](https://hackernoon.com/gpt-6-astra-how-to-write-better-prompts-and-skills) of OpenAI's [GPT-6 Astra guidance](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra) boils down to this: the agent picks a skill from its name and description alone, so "Help with websites, articles, content, design, and publishing" will grab your nav-menu bug and do nothing useful with it. The fix is one job, stated first. - For WordPress folks building agent workflows — block theme scaffolds, plugin release checklists, Playground previews — the three-layer split maps cleanly: the ticket in the prompt, the repeatable "prep a release" workflow in a skill, and "we use wp-env, run PHPCS before commit" in AGENTS.md. Put the build command in one file and stop editing it in six. - Best line for anyone who's watched an agent report green on a broken page: "A successful build also does not prove that a cover is readable or that a long code block fits on a phone." Pair it with the [Build skills docs](https://learn.chatgpt.com/docs/build-skills) and Anthropic's [Agent Skills overview](https://docs.claude.com/en/docs/agents-and-tools/agent-skills/overview) — the patterns carry across harnesses. ## ✅ Action Items #### DevRel - Developer advocacy: demo the "unrelated request should not trigger the skill" test live; it's the least-known check and the easiest to show. - Education: a 45-minute workshop — convert one repeated workflow into a one-job skill, then run the five-row test table against it. - Developer experience: publish a skill description lint (first clause names the job; no conjunction lists of 4+ domains). - Developer marketing: not applicable to this source — no campaign or funnel content. - Community management: collect before/after skill descriptions from community members as a shared example set. - Internal/external/cross-project: agree on one AGENTS.md location for build commands across repos so skills stop copying them. #### OSPO - Policy & Governance: treat shared AGENTS.md and skill files as governed artifacts — the article's audit prompt stops at proposed edits for this reason. - License Compliance: not applicable to this source — licensing isn't discussed. - Security Management: document which local commands contact live services or deploy; the article names build scripts and public previews as hidden risks. - Software Inventory: inventory skills per repo (`.agents/skills/`, `.claude/skills/`) with owner and last-tested date. - Developer Support: office hours on sandbox vs. approval settings — the article's key distinction. - Community Engagement: not applicable to this source. - Strategic Alignment: KPI candidate — mis-triggered skill rate on a fixed practice-request set. #### Community - Maintainers: add a `references/` checklist to release skills with "if a check can't run, say so; don't mark it passed." - Contributors: onboarding task — write the test-table rows for an existing skill. - Sponsors: not applicable to this source. - Ecosystem: cross-harness compatibility note: `.agents/skills/` (Codex) and `.claude/skills/` (Claude Code) use the same SKILL.md frontmatter shape. #### WordPress - Core: an AGENTS.md for wordpress-develop naming test commands and the no-commit-to-trunk boundary. - Core Performance: skill for "profile a change and report the metric" with an explicit completion definition. - Core AI: evaluation set for agent skills built on the Abilities API — include requests that should NOT match. - **Core Program Team:** track which teams maintain agent instruction files and who reviews changes. - Mobile: not applicable to this source. - Playground: preview skills that stop at a Playground link and never push to a live site — the article's draft-only stopping point. - Community: WordCamp talk angle — "one job per skill" with WordPress examples. - Training: Learn WordPress lesson on writing AGENTS.md for plugin repos. - Marketing: not applicable to this source. - Support: skill that drafts forum replies and reports missing environment info instead of guessing it. - Design: not applicable to this source beyond the desktop/mobile visual check. - Documentation: apply "read X when Y" progressive disclosure to long handbook pages consumed by agents. - Photos: not applicable to this source. - TV: not applicable to this source. - Polyglots: the article's `translation-style.md` example maps to per-locale glossary references loaded only on translation tasks. - Accessibility: add "check at mobile width; if no browser, report it unchecked" to theme preview skills. - Meta: AGENTS.md for wordpress.org repos documenting which scripts touch production. - CLI: WP-CLI commands that deploy or write to remote sites should be named in AGENTS.md as approval-gated. - Hosting: skill guidance on staging vs. live targets — the article's "identify the site that will change." - Tide: not applicable to this source. - Openverse: not applicable to this source. - Themes: theme-review skill with missing-screenshot and missing-readme cases in its test set. - Plugins: plugin-release skill that stops before SVN commit and reports check results. #### The WPOCC - Programs: fellowship module on authoring agent skills for maintainers. - Projects: documentation sprint — AGENTS.md for community-maintained plugins. - Funding experiments: not applicable to this source. ### FAIR - Technical independence: skill for verifying package signatures that reports unverifiable packages instead of assuming pass. - Policies and covenants: not applicable to this source. - Productized governance artifacts: publish an agent-instructions template alongside repo governance templates. ## 🧪 Hypotheses - H1: Skill descriptions that state one job in the first clause produce fewer false-positive skill selections than multi-domain descriptions on a fixed request set. - H2: Moving build commands from skills into AGENTS.md reduces stale-command failures after a build change. - H3: Prompts that specify a stopping point ("leave deployment for a separate instruction") cut unintended deploy attempts compared with prompts that don't. - H4: A checklist line "if a check can't run, say so; don't mark it passed" lowers the rate of false "verified" reports. - H5: Asking the agent to quote the blocking instruction resolves unexpected pauses in fewer turns than rewriting the prompt blind. ## 📊 Methodology - Build a fixed practice set of 30–50 requests per skill: complete input, missing input, unrelated request, missing tools, draft-only. Run each variant (broad vs. one-job description; commands in skill vs. AGENTS.md) 5+ times per request to account for nondeterminism. - Measure: skill-selection precision/recall, false-pass reports (compare claimed checks against logs), turns to resolution for pauses. - Data sources: agent transcripts and tool-call logs; skill-trigger events where the harness exposes them. - Analysis: paired comparison per request; report per-row pass rates matching the article's five-row table. ## ❓ Questions - How short does a description get when "many skills are available," and does front-loading survive that truncation? - Is any of this Astra-specific, or is it harness-general advice labeled with a model name? - Where should the completion definition live when prompt, skill, and AGENTS.md all state one and they disagree? - How do you test "the skill is not chosen" in a harness that doesn't log selection decisions? ## 🔮 Future Research - Measured comparisons of description styles on skill-selection accuracy across Codex and Claude Code. - Conflict resolution between instruction layers: which wins, and does the model say which it followed? - Cost of progressive disclosure: missed-reference rate when conditional "read X when Y" pointers are skipped. ## 💡 Implications - **Practice:** skill authors should treat the description as the routing interface and test negative cases, not just the happy path. - **Policy:** shared instruction files need review like code, since edits change future agent behavior. - **Security:** prompts are not access controls; deploy and live-data boundaries belong in sandbox and approval settings. - **Education:** the three-layer model gives a teachable taxonomy for agent instructions. - **Funding models:** not applicable to this source. ## 🧠 Learning Styles Assessment - Reading level estimate: Flesch-Kincaid grade ≈ 9–10 (short declarative sentences, moderate technical vocabulary; estimated, not computed). #### 👀 Visual learners - Present: two tables (instruction layers; practice-request test matrix), file-tree code blocks. - Improve: a diagram of prompt → skill → AGENTS.md → sandbox layers. #### 🔊 Aural learners - Present: linked companion video on YouTube. - Improve: audio narration of the article itself. #### 🗣️ Verbal learners - Present: bad/good example pairs for prompts and descriptions. - Improve: a glossary for "progressive disclosure," "sandbox," "approval settings." #### 🧩 Kinesthetic learners - Present: copy-paste `SKILL.md`, checklist, and audit prompt. - Improve: a starter repo to clone and run the test table against. #### 🧠 Logical learners - Present: the five-row test table with expected behaviors. - Improve: a decision tree for "where does this instruction go?" #### 🧑‍🤝‍🧑 Social learners - Present: none. - Improve: discussion prompt on shared AGENTS.md review. #### 🧘‍♀️ Solitary learners - Present: closing exercise — convert one repeated workflow. - Improve: self-check questions per section. #### 🌿 Naturalistic learners - Present: none. - Improve: not applicable to this source beyond noting fewer wasted agent runs. ## 📊 Accessibility Assessment #### Screen reader semantics - Present: H2 section headings; code in `<pre>`. - Improve: the two tables render as runs of `<p>` elements in the captured HTML, losing row/column relationships (WCAG 1.3.1 Info and Relationships). #### Keyboard navigation - Present: not assessable from captured text. - Improve: not applicable to this source (syndicated page chrome is outside the article). #### Contrast and readability - Present: plain sentences, short paragraphs. - Improve: not assessable from captured text. #### Text resizing and reflow - Present: not assessable. - Improve: long `<pre>` blocks need horizontal scroll at 320px (WCAG 1.4.10 Reflow allows this for code). #### Media and captions - Present: links to YouTube video; caption status unknown. - Improve: link a transcript (WCAG 1.2.2 Captions). #### Forms and interactions - Present: none. - Improve: not applicable to this source. #### Standards reference - Main gap: 1.3.1 for tables flattened to paragraphs; 1.2.2 unverified for the companion video. ## 🌍 DEIB Assessment #### Cultural breadth - Present: none specific; single website example. - Improve: examples outside web publishing. #### Inclusive language - Present: neutral, jargon mostly defined in context. - Improve: define "sandbox" and "progressive disclosure" on first use. #### Neurodiversity support - Present: chunked sections, consistent example throughout, explicit checklists. - Improve: a one-screen summary at the top. #### Representation - Present: not applicable to this source — no people depicted. - Improve: not applicable to this source. #### Psychological safety - Present: encourages reporting gaps and failed checks instead of hiding them. - Improve: not applicable to this source. ## ✅ Logical Validity #### Strong reasoning - Causal, mechanism-backed: descriptions matter *because* the agent sees only name + description before selecting (¶ "The description matters because…"). The claim names its mechanism and cites docs. - Counterexample reasoning: the broad description matching a navigation-menu bug shows the failure concretely. - Scope honesty: the test table is labeled "expected behaviors to test, not results from a benchmark," which blocks the reader from mistaking it for evidence. - Separation of controls: instructions vs. sandbox is a correct category distinction with a stated consequence (a prompt can't grant a missing permission). #### Fallacies - **Appeal to authority (mild)** — "OpenAI's prompting documentation recommends…", "Its GPT-6 Astra guide recommends…". Every normative claim rests on vendor guidance with no outcome data. Fix: add one measured before/after from the author's own runs. - **Hasty generalization (latent)** — one example workflow (article preview) stands in for all skill authoring. Fix: add a second, structurally different workflow. #### Tone of voice - Instructional, calm, second-person, low hype ("Splitting files is a choice, not a requirement"). Light self-promotion at open and close (video, website). ## 🛡️ DARVO Analysis - Deny: none identified. - Attack: none identified. - Reverse victim/offender: none identified. - Not applicable to this source — an instructional how-to with no accusation or dispute. ## 🎯 Conclusion - Bottom line: route by description, keep each skill to one job, put project rules in one place, load references on condition, gate specific actions, and verify the rendered result — then test the skill with a request that should *not* trigger it. - Next step: pick one skill you already use, rewrite its description so the job is the first clause, and run the five-row test table against it. ## 🔄 Refactor Appendix — GPT-6 Astra: How to Write Better Prompts and Skills ### 📚 Literature Atoms (H3) #### [H1] Agents select skills from name and description alone > [!quote] ID:rw_01m34h4m8nf5gcwtb0v401py57 > The description matters because Codex first sees a skill's name and description. It reads the full SKILL.md after selecting the skill. **Context & use**: - Section "Give a skill one job" - Explains why description wording drives misrouting; same loading model as Claude Code skills. **Tags**: #xref **Highlight**: [view highlight](https://read.readwise.io/read/01m34h4m8nf5gcwtb0v401py57) <!-- atomicity: 1 idea ✓ --> #### [H2] Prompts and sandboxes are separate controls > [!quote] ID:rw_01m34h4pefz5dexh4pyk9n40mx > Written instructions and technical access are separate controls. **Context & use**: - Section "Set approval rules around specific actions" - Instruction is the weakest enforcement rung; access limits live in sandbox and approval settings. **Tags**: #xref #aphorisms **Highlight**: [view highlight](https://read.readwise.io/read/01m34h4pefz5dexh4pyk9n40mx) <!-- atomicity: 1 idea ✓ --> #### [H3] Missing inputs get reported, not invented > [!quote] ID:rw_01m34h4nbmgeq0g9vh7s36n3g1 > If the article has no publication date, the agent should report that gap rather than invent an approved date. **Context & use**: - Section "Write a prompt that describes the finished result" - Pairs with continuing independent work; mirrors the "finish every other part" standing rule. **Tags**: #xref #addendum **Highlight**: [view highlight](https://read.readwise.io/read/01m34h4nbmgeq0g9vh7s36n3g1) <!-- atomicity: 1 idea ✓ --> #### [H4] A passing build doesn't prove the rendered page > [!quote] ID:rw_01m34h4qbqh7zpcjebybdw8zcw > A successful build also does not prove that a cover is readable or that a long code block fits on a phone. **Context & use**: - Section "Check the result and the skill's scope" - Same failure class as "file-level correctness is not proof of what's live." **Tags**: #xref **Highlight**: [view highlight](https://read.readwise.io/read/01m34h4qbqh7zpcjebybdw8zcw) <!-- atomicity: 1 idea ✓ --> ### 🧠 Permanent Candidates (H4) #### [P1] A skill description is a routing interface **Claim** (one sentence, Courtney's voice): The first clause of a skill description decides when the skill fires, so it has to name the one job the skill does. **Evidence pointer**: [[#[H1] Agents select skills from name and description alone]] **Scope & conditions**: holds for harnesses that load description-first (Codex, Claude Code); weaker where skills are invoked only explicitly by name. **Links**: - [[Progressive disclosure]] — because extends - [[skill-patterns]] — because applies-in skill authoring - [[The Maker Should Not Grade Its Own Homework]] — because contrasts on routing vs. verification <!-- atomicity: 1 idea ✓ --> #### [P2] Instructions are the weakest enforcement rung **Claim** (one sentence, Courtney's voice): A rule the agent can ignore by not reading it isn't enforced, so anything that must hold belongs in the sandbox, a hook, or a write gate. **Evidence pointer**: [[#[H2] Prompts and sandboxes are separate controls]] **Scope & conditions**: applies to safety and completeness rules that are mechanically checkable; judgment calls still live in instructions. **Links**: - [[Alarm fatigue before adding alarms]] — because contrasts on detection vs. prevention - [[readwise-deep-read]] — because evidence-for (the completeness rung ladder) <!-- atomicity: 1 idea ✓ --> ### ✏️ Fleeting Queue - [F1] Does any of Courtney's skills lack a negative-case test ("request that should not trigger it")? — skill-patterns audit #fleeting #inbox - [F2] Compare OpenAI's Astra guide with Anthropic's skill-authoring best practices for divergences — https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra #fleeting #inbox ### → Things 3 (max 2 actions) - [ ] Add a "should not trigger" row to the skill-patterns test checklist — skill authoring #things <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Articles/GPT-6 Astra How to Write Better Prompts and Skills HackerNoon.md|GPT-6 Astra: How to Write Better Prompts and Skills | HackerNoon by Vladislav Guzey]] ## Highlights - Missing information needs a rule too. If the article has no publication date, the agent should report that gap rather than invent an approved date. It can still inspect the layout and prepare work that does not depend on that decision. ([View Highlight](https://read.readwise.io/read/01m34h4nbmgeq0g9vh7s36n3g1)) - Note: Report the gap, continue the independent work. Same shape as the "if part is blocked, finish every other part" standing rule. - Tags: atom/literature/h2 - The description matters because Codex first sees a skill's name and description. It reads the full `SKILL.md` after selecting the skill. The [skills documentation](https://learn.chatgpt.com/docs/build-skills?ref=hackernoon.com) also explains that descriptions may be shortened when many skills are available. ([View Highlight](https://read.readwise.io/read/01m34h4m8nf5gcwtb0v401py57)) - Note: Skill routing happens on name + description alone; the body is read only after selection. Put the job first. - Tags: atom/literature/h1 - OpenAI calls this approach progressive disclosure: make supporting instructions available when the task needs them. Its [GPT-6 Astra guide](https://developers.openai.com/blog/rethinking-skills-and-prompts-for-gpt-6-astra?ref=hackernoon.com) recommends using a short main skill file to direct the model to relevant material. ([View Highlight](https://read.readwise.io/read/01m34h4s0yhgwe9bqjwqaq0231)) - Note: Progressive disclosure = the "Reading map" pattern in SKILL.md files: short main file, conditional pointers to references. - Tags: atom/zettel/z1 - Written instructions and technical access are separate controls. OpenAI's [sandbox documentation](https://learn.chatgpt.com/docs/sandboxing?ref=hackernoon.com) explains that the sandbox limits command access to files and network resources, while approval settings control how requests at those boundaries are handled. ([View Highlight](https://read.readwise.io/read/01m34h4pefz5dexh4pyk9n40mx)) - Note: A prompt is a request; the sandbox is enforcement. Matches the rung ladder: instruction is the weakest rung. - Tags: atom/literature/h1 - A successful build also does not prove that a cover is readable or that a long code block fits on a phone. Those need a visual check when suitable tools are available. ([View Highlight](https://read.readwise.io/read/01m34h4qbqh7zpcjebybdw8zcw)) - Note: Green build is not proof of the rendered result. Cf. "file-level correctness is not proof of what's live." - Tags: atom/literature/h2 - An unexpected pause may come from the task prompt, a skill, project guidance, or a tool permission. Identify the source before changing it. ([View Highlight](https://read.readwise.io/read/01m34h4r5xxnd6rf6e0xh3pj15)) - Note: Diagnose the layer before rewriting rules; parallels context → effort → model ordering. - Tags: action/h2, atom/literature/h3