Rethinking Skills and Prompts for GPT-6 Astra  🔗 **Source:** [Rethinking Skills and Prompts for GPT-6 Astra](https://twitter.com/pvncher/status/2095991462416490862/?rw_tt_thread=True) > [!note]+ Document Notes > tags: [agent-instructions, skill-design, context-management, progressive-disclosure, coding-agents] > author: "eric provencher" > source: X (Twitter) > reference: https://twitter.com/pvncher/status/2095991462416490862/ > date created: 2026-09-06 > > > [!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: Rethinking skills and prompts for GPT-6 Astra > <!-- deep-read:sections start --> ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] - [[#🔄 Refactor Appendix — Rethinking skills and prompts for GPT-6 Astra]] ## 🔗 References - Source thread: https://twitter.com/pvncher/status/2095991462416490862/ - Author: eric provencher (pvncher), who describes updating the `$skill-creator` skill's guidance as "we", indicating he works on or with Codex tooling. ## 📝 Summary - **What happened:** A practitioner argues that agent instructions accumulated over the past year — skill files, `AGENTS.md`, task prompts — are now actively hurting results with a more capable model, and gives four specific failure modes plus fixes. - **Why it matters:** The claim inverts the usual advice. Instruction sets are normally treated as assets that compound; here they are depreciating stock that has to be re-audited on every model release, because guidance written to compensate for a weaker model becomes overconstraint on a stronger one. - **Stakeholders:** anyone maintaining a skills library or `AGENTS.md`, repository maintainers whose instructions steer other people's agents, and tooling teams shipping skill-creation defaults. - **Risks:** the advice is model-specific and self-interested — the author appears to work on the tooling he recommends, and the "trust the newer model more" conclusion is exactly what a vendor would say. It is also unfalsifiable as presented: no measurements accompany any claim. - **Bottom line:** the mechanism arguments are strong and checkable in your own repo; the model-superiority framing is unsupported and should be held separately from them. ## 📖 Main Content The thread makes five moves. **Instruction debt is real and invisible.** The premise is that steering a weaker model produced scaffolding that nobody removed, and that this scaffolding is now a cost rather than a benefit. > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "If you've been using agents in your projects over the last year, you've likely accumulated a lot of bloated instructions as you worked to steer the models toward good outcomes." **Skill descriptions compete for a shared budget.** The most mechanically specific claim in the piece, and the one with a named failure mode: descriptions are loaded into context for routing, and past a certain volume the harness truncates them. > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "Each skill comes with a name and description that are loaded into the model's context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit. The model ends up seeing less of each description, making it harder to know which skill to pick." He adds a second-order effect: descriptions that oversell themselves poison routing for every other skill. **Progressive disclosure as the marker of a good skill.** A root document should route rather than instruct. **Over-specification now hurts.** Recipes written for a model that needed them constrain a model that does not. **Boundaries and stopping points are separate problems.** Strong "ask first" language written to restrain an over-eager model makes a well-judged model stop too early; and the newer model is described as more tentative about when a task is finished, so completion should be defined up front. ## 🗒️ Notes #### Skill files - Skills are markdown prompts, sometimes with bundled scripts, best for workflow-specific or plugin-specific guidance. - Downloading many skills is named as "a mistake" — the cost is routing accuracy, not disk or money. - Three fixes: shortest sufficient descriptions, progressive disclosure via a router document, less prescriptive bodies. #### AGENTS.md - Applies on every task in the repo, so every line pays rent on every task. - Named anti-pattern: requiring a doc stack or repo map before any edit, which is absurd for a typo fix. - Named staleness: instructions telling the model to run tests, when the model now does that unprompted. - Suggested positive use: granting standing permission for a known-safe workflow, with the local-test-suite example quoted verbatim in the source. #### Decision boundaries - Strong permission-gating language is a residue of older model behavior and now causes premature stops. #### Persistence - The model may return after a first implementation with work remaining; define "done" in the request rather than relying on the model's judgment of it. #### Cross-model consequence - Repository instructions steer contributors' agents too, which may be different models entirely. ## 📚 References - No external sources, studies, or benchmarks are cited anywhere in the thread. Every claim is practitioner observation. - Three images are referenced as illustrations (a bad-vs-good skill description, an `AGENTS.md` anti-pattern) but the argument does not depend on reading them. - Model names used without definition: GPT-6 Astra, GPT-5.6 Sol, Luna. Treat these as the source's terms. ## 🗣️ Paraphrase Agents got better, so the props you built to hold up a weaker one are now in the way. Skills are the clearest case: their descriptions all share one routing budget, and when you install too many, the harness trims them until the model can no longer tell which one fits. Descriptions that beg to be chosen make this worse for everything else. Write the shortest description that still says when to use the skill; make the root file a router to deeper docs rather than a lecture; stop writing step-by-step recipes, because nuance is now handled better than instruction. `AGENTS.md` deserves the same audit, since it is charged against every task — telling the model to read the repo before a typo fix, or to remember to run tests it already runs, is pure overhead. Two behavioral notes: language you added to stop an old model from acting without asking will now stop a model that should keep going, and the new model tends to hand work back early, so state what finished means before it starts. ## 📰 Newsletter **Your prompt library is depreciating stock.** Everyone treats accumulated agent instructions as an asset. This thread argues they're the opposite: written to compensate for last year's model, they're now taxes on this year's. The sharpest bit is a mechanism, not a vibe — skill descriptions share one routing budget, and when you install too many, the harness starts truncating them. Your skills don't fail loudly. They just stop getting picked, and the model quietly chooses a worse one. Two things to try this week: delete the line in your `AGENTS.md` that tells the model to run tests (it already does), and re-read your longest skill description as if you were the router that has to choose between it and thirty others. The part to be skeptical of: the author appears to build the tooling he's recommending, and "trust the newer model more" is exactly what that person would say. The mechanisms are checkable in your own repo. The model-superiority claims aren't, and he offers no measurements for any of it. ## ✅ Action Items #### Personal / own tooling - Audit `~/.claude/skills/` descriptions for length and "pick me" phrasing. With 40+ skills installed, this is the exact regime the truncation claim describes. `#action/h1` - Re-read the global `CLAUDE.md` against the "does this still earn its place" test, which is already its stated quarterly practice (next: 2026-11). This source is an argument for doing it per model release rather than per quarter. `#action/h2` - Check whether any skill's root file instructs rather than routes; the deep-read skill's "Reading map" is already a router and is the pattern to copy. `#action/h3` #### WordPress — Training - If contributor-facing agent instructions ever ship in WordPress repos, the cross-model warning applies: guidance tuned to one model constrains contributors using another. `#action/h3` #### WordPress — Documentation - Same principle as docs-for-humans: a router page beats a monolith. Worth noting when agent-readable docs come up. `#action/h3` #### DevRel / OSPO / Community / The WPOCC / FAIR / other Make teams - Not applicable to this source. It is a coding-agent tooling thread with no WordPress, governance, or community dimension. ## 🧪 Hypotheses 1. Installing skills past some count measurably lowers correct-skill selection, holding task set fixed — testable by varying installed-skill count against a fixed benchmark of tasks with known correct skills. 2. Shortening descriptions to the minimum sufficient form improves selection accuracy more than rewriting skill bodies does. 3. Removing "run the tests" style instructions from `AGENTS.md` produces no measurable drop in test execution on current models. 4. Strong permission-gating language measurably increases premature stops, observable as more turns per completed task. 5. Stating a completion definition in the request reduces hand-backs more than any `AGENTS.md` persistence instruction does. 6. Repository instructions tuned on one model produce worse outcomes for contributors on a different model than no instructions at all. ## 📊 Methodology None. There is no study design, no dataset, no benchmark, and no before/after measurement anywhere in the thread. The evidence is entirely practitioner observation, plus the author's stated experience updating `$skill-creator` guidance in response to "failure modes we've seen in practice" — which is an appeal to unshared internal observation. Every hypothesis above is offered because the source supplies none. ## ❓ Questions - At what installed-skill count does description truncation begin, and is that threshold documented anywhere a user can check? - Is truncation silent? If the harness warns, the failure is manageable; if not, it is invisible debt of exactly the kind the thread warns about. - Does the advice generalize past Codex, or is the truncation behavior specific to that harness? - How should someone maintain instructions for a repo whose contributors use several different models, when the advice is explicitly model-specific? - What is the author's relationship to the product? "We recently updated its guidance" implies an insider position that is never disclosed outright. ## 🔮 Future Research - Published truncation thresholds and routing-accuracy curves per harness would convert all of this from folklore to engineering. - A method for versioning instruction sets against model releases — the piece implies instructions need an expiry date but proposes no mechanism. - Cross-model instruction portability: whether a neutral subset exists that helps every model, or whether tuning is inherently per-model. - Whether "audit your instructions with the model itself", the closing suggestion, actually finds the bloat or just agrees with whatever is already there. ## 💡 Implications - **Practice:** instruction sets need a review cadence tied to model releases, not the calendar. This directly challenges a quarterly pruning schedule. - **Design:** the router-plus-supporting-docs shape is the reusable takeaway, and it is independent of any specific model. - **Governance:** repository instructions are a cross-agent contract. Committing them steers other people's tools, which is an under-discussed maintainer responsibility. - **Security:** granting standing permission in `AGENTS.md` — the quoted local-test example — moves an approval boundary into a file anyone with commit access can edit. The source does not raise this. - **Cost:** shorter descriptions and router documents reduce context consumption per task, so the argument has a direct token-cost dimension the thread never states. ## 🧠 Learning Styles Assessment - **Visual:** partially served — three annotated screenshots contrast good and bad instructions, though the argument survives without them. - **Aural:** unserved; text only, no audio version. - **Verbal:** well served. Prose-heavy with clear section headers and concrete phrasing ("pick me energy"). - **Logical:** moderately served. Causal chains are stated (too many skills → truncation → worse routing) but never quantified. - **Kinesthetic:** served by the closing call to run an audit on your own repo, which is a real hands-on task. - **Social:** weakly served — a thread invites replies, but the piece itself is a monologue. - **Solitary:** well served; the whole exercise is a solo repo audit. - **Naturalistic:** not applicable. - **Reading level:** roughly grade 10–12. Short paragraphs, low jargon density, but assumes fluency with skills, `AGENTS.md`, context windows, and compaction. ## 📊 Accessibility Assessment - **Perceivable:** images carry illustrative captions in the body text, which partially compensates, but no alt text is present in the captured content (WCAG 1.1.1 — fails as captured). - **Operable:** platform-dependent; X's thread reader is keyboard navigable but the captured artifact imposes nothing of its own (WCAG 2.1.1 — not assessable here). - **Understandable:** strong. Plain language, consistent structure, terms used consistently (WCAG 3.1.5 — reading level is appropriate to the audience). - **Robust:** the text degrades cleanly without images, which is the main accessibility virtue here (WCAG 4.1.2). - **Structure:** section headings are present and meaningful, aiding navigation (WCAG 2.4.6). - **Contrast / visual presentation:** determined by the host platform, not the content. - **Overall:** the dependence on screenshots to show "bad vs good" examples is the one real barrier — those comparisons are not restated in text in full. ## 🌍 DEIB Assessment - **Cultural breadth:** narrow by subject. Assumes a professional software context with paid tooling access. - **Inclusive language:** neutral throughout; no gendered or exclusionary phrasing. The author is referred to here as the author or by name, since the source states no pronouns. - **Neurodiversity support:** better than average — short sections, explicit headers, one idea per paragraph, and a concrete closing action. - **Representation:** no people other than the author appear; nothing to assess. - **Psychological safety:** mildly negative framing ("that's a mistake") directed at practices rather than people, which is the appropriate target. - **Economic access:** the advice presumes access to a current frontier coding agent, which is a paid product. Readers without it get the transferable principles (routers, description length) but not the model-specific guidance. ## ✅ Logical Validity **Strong reasoning** - The truncation argument is a genuine mechanism with a stated causal chain, not an assertion: more skills → shared budget exceeded → descriptions shortened → routing degraded. - The cross-model warning is a real and rarely-made point about repository instructions being a contract with other people's tools. - Distinguishing "boundaries" from "persistence" is a useful separation; they present identically as the model stopping, but have different causes and different fixes. **Fallacies** - **Appeal to unshared authority.** "failure modes we've seen in practice" carries the weight of the skill-creator guidance changes, but the observations are never shown. The reader is asked to trust an internal dataset. Fix: publish the failure modes or the routing measurements. `#fallacy/appeal-to-authority` - **Undisclosed conflict of interest.** The author uses "we" for the team that ships `$skill-creator` while recommending its updated defaults and asserting the newest model's superiority, without stating the affiliation plainly. Fix: a one-line disclosure. `#fallacy/conflict-of-interest` - **Unfalsifiable capability claims.** "GPT-6 Astra has much better judgment" and "does that on its own" are stated without measurement or task scope, so no observation could contradict them. Fix: name the benchmark or scope the claim. `#fallacy/unfalsifiable-claim` - **Hasty generalization.** "Many people default to downloading a lot of skills into their projects" supports a universal recommendation with no evidence about how many, or with what effect. Fix: qualify, or measure. **Tone of voice** Direct, practitioner-to-practitioner, lightly imperative. Confident without hedging, which reads as authority but is doing work that evidence should be doing. ## 🛡️ DARVO Analysis Not applicable to this source. There is no accusation, no denial, and no victim/offender dynamic — it is prescriptive technical advice with no adversarial party. ## 🎯 Conclusion The durable contribution is one mechanism and one reframe. The mechanism: skill descriptions share a routing budget that silently truncates, so a large skill library degrades its own selection accuracy — a real, checkable failure that most people maintaining such libraries have never considered. The reframe: instruction sets depreciate against model releases, so they need an audit cadence tied to releases rather than the calendar. Both survive removing every claim about which model is better, which is the right way to read this, because those claims come with no evidence and from someone who appears to work on the product. For Courtney specifically, the skill-count regime described here is hers — 40+ installed skills, several with long descriptions — and the truncation claim is testable locally without taking the author's word for anything. ## 🔄 Refactor Appendix — Rethinking skills and prompts for GPT-6 Astra ### 📚 Literature Atoms (H3) #### [H1] Skill descriptions share one routing budget and truncate silently > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "Each skill comes with a name and description that are loaded into the model's context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit. The model ends up seeing less of each description, making it harder to know which skill to pick." The one claim in the thread with a real causal mechanism. It predicts a specific, non-obvious failure: adding a skill makes the *other* skills harder to select. No threshold or measurement is given. Tags: `#atom/literature/h1` #### [H2] Instructions written for a weaker model become overconstraint on a stronger one > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "If you've been using agents in your projects over the last year, you've likely accumulated a lot of bloated instructions as you worked to steer the models toward good outcomes." The organizing premise. Treats an instruction set as depreciating stock rather than an accumulating asset — which is the opposite of how most teams treat prompt libraries. Tags: `#atom/literature/h2` #### [H3] Repository instructions steer other people's agents, on other models > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "Repository skills also guide other contributors' agents, which may use different models. Guidance that helps Sol or Luna may overconstrain GPT-6 Astra, so consider which models will use the instructions you leave behind." Makes committed instructions a cross-agent contract and a maintainer responsibility. Rarely stated, and it cuts against the rest of the thread's per-model tuning advice. Tags: `#atom/literature/h3` #### [H4] Capability claims are asserted without measurement > [!quote] ID:rw_01m1tg2fr4dgmzxvet9bhrz410 > "Pay careful attention to how you describe boundaries. If a previous model did things on your behalf without permission, you may have added strong language to make it ask first. That can be useful, but GPT-6 Astra has much better judgment, and you should treat it as such." The load-bearing premise for half the advice — "trust it more" — carries no evidence and comes from someone who writes "we" about the tooling team. Recorded as the piece's central weakness. Tags: `#atom/literature/h4` `#fallacy/unfalsifiable-claim` `#fallacy/conflict-of-interest` ### 🧠 Permanent Candidates (H4) #### [P1] A shared routing budget makes each added option degrade selection for all the others When a system selects among options by reading their descriptions in a fixed budget, adding options is not free and not merely diminishing — past the budget it actively harms selection for options already present, because the mechanism compensates by truncating everything. This generalizes past agent skills to any router over a summarized catalog: tool menus, plugin registries, function-calling schemas, a documentation index. The counter-intuitive consequence is that curation beats accumulation, and that the marginal item can have negative value while looking free. *Candidate; one well-described mechanism from a practitioner source, no measurement.* Links: [[3. Resources/Permanent Notes/Progressive Disclosure Keeps A Plugin's Core Trustworthy]] · [[3. Resources/MOCs/AI Agent Safety MOC]] Tags: `#atom/zettel/z1` #### [P2] Guidance written to compensate for a weakness outlives the weakness Instructions added to work around a system's limitation persist after the limitation is fixed, and then act as constraints, because nothing in the workflow prompts their removal. The asymmetry is structural: the pain that motivates adding an instruction is felt immediately, while the cost of keeping a stale one is diffuse and never attributed. This applies to agent instructions, lint rules, code comments, runbooks, and onboarding docs alike. The fix is an expiry or review trigger tied to the thing that changed, not to a calendar. *Candidate; the source argues it for one domain, the pattern is broader.* Links: [[3. Resources/Permanent Notes/Instruction Files Are the Last Rung Not the First]] · [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] Tags: `#atom/zettel/z2` ### ✏️ Fleeting Queue - The closing "ask the model to audit your instructions" is self-referential — the model most likely to agree that constraints on it are unnecessary is the model being constrained. `#atom/fleeting/f1` - Standing permission granted in `AGENTS.md` moves an approval boundary into a committable file. Unremarked by the source, and a real supply-chain question. `#atom/fleeting/f1` - The global `CLAUDE.md` here already carries a rule shaped like this thread's advice: "a rule that hasn't prevented a failure in two quarters is a candidate to cut." `#atom/fleeting/f1` ### → Things 3 (max 2 actions) - [ ] Audit `~/.claude/skills/` for over-long and "pick me" descriptions; measure the total description budget across all installed skills. `#action/h1` - [ ] Add a model-release trigger to the CLAUDE.md pruning cadence, alongside the quarterly one. `#action/h2` <!-- deep-read:sections end --> 📄 **Full text:** [[Full Document Contents/Tweets/Rethinking Skills and Prompts for GPT-6 Astra.md|Rethinking Skills and Prompts for GPT-6 Astra by eric provencher]] ## Highlights - If you’ve been using agents in your projects over the last year, you’ve likely accumulated a lot of bloated instructions as you worked to steer the models toward good outcomes. With each release, it’s been worth revisiting those assumptions, but with GPT-6 Astra, that’s more important than ever. ([View Highlight](https://read.readwise.io/read/01m1vfb4hvs7nc5f9xt88c2sr9)) - Note: H2 — the organizing premise: an instruction set is depreciating stock, not an accumulating asset. Implies an audit cadence tied to model releases rather than the calendar, which cuts against a quarterly CLAUDE.md pruning schedule. #atom/literature/h2 - Tags: atom/literature/h2 - Many people default to downloading a lot of skills into their projects, but that’s a mistake. Each skill comes with a name and description that are loaded into the model’s context so it knows when to use them. Many descriptions are far too long, and when you add too many skills, Codex starts shortening their descriptions to fit. The model ends up seeing less of each description, making it harder to know which skill to pick. ([View Highlight](https://read.readwise.io/read/01m1vfb1tecgq35z3hmh3ffn98)) - Note: H1 — the only claim here with a real mechanism: skill descriptions share one routing budget, and past it the harness truncates them silently. Predicts a non-obvious failure — adding a skill makes the *other* skills harder to select. No threshold or measurement given; testable locally against a 40+ skill library. #atom/literature/h1 - Tags: atom/literature/h1 - Repository skills also guide other contributors’ agents, which may use different models. Guidance that helps Sol or Luna may overconstrain GPT-6 Astra, so consider which models will use the instructions you leave behind. ([View Highlight](https://read.readwise.io/read/01m1vfb7deb5byzfwwjss6hjp8)) - Note: H3 — committed instructions are a cross-agent contract and a maintainer responsibility, steering other people's tooling. Rarely stated, and it cuts against the rest of the thread's per-model tuning advice. #atom/literature/h3 - Tags: atom/literature/h3 - Pay careful attention to how you describe boundaries. If a previous model did things on your behalf without permission, you may have added strong language to make it ask first. That can be useful, but GPT-6 Astra has much better judgment, and you should treat it as such. It also takes your boundaries seriously and may stop work where you’d actually be happy for it to continue. ([View Highlight](https://read.readwise.io/read/01m1vfba8r2tjtv4j4qg675h0k)) - Note: H4 — the load-bearing "trust it more" premise, asserted with no measurement or task scope by an author who writes "we" about the tooling team. The piece's central weakness: half the advice rests on it. #atom/literature/h4 #fallacy/unfalsifiable-claim #fallacy/conflict-of-interest - Tags: fallacy/conflict-of-interest, atom/literature/h4, fallacy/unfalsifiable-claim