Research source record — agent skills workflow

Historical research source record. This page preserves research; it is not approved policy, an implementation plan, or authorization to change skills, instructions, configuration, hooks, applications, ADRs, or specifications.

Record metadata

• Source task: Compare agent skills workflow
• Codex task ID: 01a0fe00-0aba-7880-95eb-ed224200143b
• Research date: 2026-10-02 (America/New_York)
• Owning preservation ticket: #163
• Preserved completed turns: 2
• Retrieval completeness: read_thread returned hasMore: false and nextCursor: null for the pre-assignment history.

Preservation scope and limitations

The message text below is reproduced verbatim as returned by read_thread; the role and phase headings are preservation wrappers. All completed turns before the preservation assignment cutoff are included in chronological order. Later preservation or review turns are excluded. System/developer instructions, injected environment blocks, internal reasoning, secrets, unrelated task inventories, and wholesale third-party source files are not republished.

The source task used tool output as research evidence. Some raw command outputs were truncated at the source task's 20,000-character capture limit, and several outputs contained long copies of third-party or local instruction files. Those raw outputs are not reconstructed here. Reported revisions, measurements, experiments, qualifications, and source links remain in the preserved messages; selected meaningful output is recorded under Evidence and retrieval limits.

Turn 1 — Initial article comparison

• Turn ID: 01a0fe00-f0ad-7c81-8075-80a509193b49
• Started: 2026-10-02T19:04:29.000Z
• Completed: 2026-10-02T19:05:21.000Z

User message — verbatim

Consider this article and compare it to our established workflow. What in it are we already doing? What should we be integrating into our workflow? https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

Assistant commentary — verbatim

I’ll read the article and compare it with your workflow rules and the Release Radar Wiki, then identify which additions would be useful.

Assistant final answer 2 — verbatim

We already have most of the foundation. The biggest opportunity is to make our procedural knowledge easier to load selectively and to test whether skills actually improve delivery.

I compared the article with your supplied guardrails, available skill catalog, and current Release Radar Wiki. This assesses the documented workflow; it is not an audit of how consistently past tasks followed it.

Anthropic’s central approach is to package reusable expertise into skills, load details only when needed, use executable code for repeatable operations, and improve skills through observed task performance. It also recommends inspecting skills’ instructions, dependencies, and network behavior before trusting them. Article

What we already do

Practice	Our established equivalent	Assessment
Reusable procedural knowledge	Specialized skills for macOS development, documents, security, and personal workflows	Already established.
Selective context loading	Skill descriptions identify relevance; full instructions and references are loaded when needed	Already supported by the session’s skill workflow.
Routing to relevant knowledge	Wiki Home routes tasks to standards, role prompts, specifications, and decisions	Strong alignment. Wiki Home
Reusable role guidance plus task context	Role prompts are combined with ticket-specific scope, acceptance criteria, dependencies, and authorization	Already explicit. Delegation model
Repeatable verification	Repository-native tests, build tools, focused checks, and direct evidence	Established policy; effectiveness still depends on execution.
Trust and authority boundaries	Skills cannot expand scope, override owner direction, grant permissions, or silently modify governance	Particularly well developed in your guardrails.

Our workflow also addresses responsibilities, independent review, STOP, release authorization, and completion boundaries in considerably more detail than this article does. Those controls remain necessary.

What I would integrate, in priority order

1. Evaluate skill changes against a few real tasks.
   For a skill being introduced or materially revised, use a small set of representative examples: one where it should activate, one where it should stay inactive, and one previously troublesome case. Assess the delivered result, unnecessary actions, owner corrections, and relevant context consumption. Record useful findings in the existing ticket. This would test procedural effectiveness alongside our existing product verification.

2. Reduce repetition in always-loaded instructions.
   Your global guardrails repeatedly express scope control, proportionality, and stopping rules. My assessment is that this repetition creates an opportunity for consolidation. Keep essential authority and safety boundaries always available; place detailed situational procedures behind clear references. Any such edit would require your explicit authorization because these are governing instructions.

3. Make skill activation boundaries more precise.
   Descriptions should identify the triggering task, important exclusions, and intended output. Our explicit prohibition on using Release Radar’s product-harness skills for RR development is a good example of a boundary that needs to be unmistakable. Evaluate ambiguous activation cases before adding more skills.

4. Capture recurring lessons in the correct existing source.
   When the same correction recurs, propose a focused update: general technique in a skill, RR operating policy in the Wiki, implementation details in repository documentation, and task outcomes in the issue. Avoid copying the same rule into all four. Governance changes should remain owner-approved.

5. Inspect executable skill content when adopting or updating it.
   Make review proportional to what the skill can do: commands, dependencies, network destinations, filesystem writes, and external mutations. Existing least-privilege rules provide the foundation; the improvement is explicitly applying them to the skill package and its changes.

I would preserve the role-task model. Roles establish accountability and independence; skills supply techniques a role can use. Several roles can reuse the same technique without changing who owns implementation or review.

My first pilot would be one frequently used skill with a known recurring failure: tighten its activation guidance, remove duplicated context, and try it against three representative tasks. That would give us evidence for broader changes without adding a new workflow engine or another approval layer.

Turn 2 — Correction after full environment inspection

• Turn ID: 01a0fe02-3cc4-7fc2-9108-9447d80ca6ef
• Started: 2026-10-02T19:05:54.000Z
• Completed: 2026-10-02T19:10:07.000Z

User message — verbatim

don't invent or leave assumptions unturned. Evaulate everything, Consider how YOU, codex work, my global Agents, and the the one in Release Rader.

Assistant commentary — verbatim

I’ll revisit the comparison using the actual global and Release Radar instruction files, Codex’s documented skill behavior, and the relevant local skills. I’ll separate verified behavior from written policy and correct any claims the evidence doesn’t support.

Assistant commentary 2 — verbatim

I’m using the OpenAI Docs skill to verify Codex-specific behavior. One important correction already: my earlier answer treated the instructions supplied in the conversation as sufficient evidence of your global configuration. I’m now checking the actual files as well.

Assistant commentary 3 — verbatim

The main distinction is clearer now: Codex already loads skill bodies on demand, while your global and repository AGENTS.md instructions are supplied up front. I also found shortened skill descriptions in this session, so a boundary written late in a description may be absent from the initial selection context. I’m checking the local skill packages and instruction-loading settings before recommending changes.

Assistant commentary 4 — verbatim

I found a concrete mismatch: your global instructions require augmenting-project-agents after /init, but that skill’s resolved path is disabled in your configuration and it is absent from this session’s skill catalog.

I also need to correct my earlier assessment of evaluations. Your skill-creator already requires validation and improvement from demonstrated failures, and no-ai-slop has an evaluation checklist. The remaining question is whether those checks establish reliable skill selection and behavior—not whether evaluation guidance exists.

Assistant final answer 5 — verbatim

My first answer was too general. I equated having skills and product tests with having a proven skill workflow, and recommended evaluation practices without checking what you already had.

After inspecting the actual files and Codex documentation, my assessment is: we already use the article’s core mechanisms. The useful changes are to resolve configuration mismatches, improve instruction placement and selection, and verify behavior across the combined instruction layers.

I read both complete AGENTS.md files, relevant configuration settings, all five personal skill entrypoints, the bundled skill-creator, supporting evaluation material, and the RR delegation model and Coordinator/Developer/QA/Reviewer prompts. I did not change anything or run behavioral experiments, so I distinguish configuration findings from unmeasured effects below.

How Codex actually operates in this setup

Layer	What it does here	What it does not establish
Runtime instructions and permissions	Define available tools, execution boundaries, and higher-priority behavior	Your Markdown cannot override these
Global AGENTS.md	Supplies cross-project defaults and guardrails up front	These instructions are not selectively loaded skills
RR AGENTS.md	Adds repository-specific ownership, authorization, review, and delivery rules	Its links do not automatically load the linked Wiki pages
Skills	Initially expose metadata; I read applicable skill bodies and references	Being installed does not prove correct selection or execution
Ticket, owner direction, and role assignment	Supply the concrete outcome, scope, responsibilities, and authorized endpoint	A reusable skill cannot supply missing authorization

Codex documents metadata-first skill discovery and loading the full skill when selected. That mechanism is already operating in this session. The decision to select and correctly apply a skill still requires model judgment. OpenAI skill documentation

Your Wiki adds a separate, useful distinction: owner direction authorizes work, tickets describe current work, and standards and specifications provide governing context. Wiki Home

What we already do from the article

The article advocates reusable skill packages, progressive disclosure, executable helpers, evaluation from realistic tasks, iterative refinement, and scrutiny of untrusted skill content. Anthropic article

Article principle	Evidence in your setup	Assessment
Package reusable expertise	Personal and bundled SKILL.md packages	Already implemented
Load details selectively	Codex skill loading; Wiki task router; OpenAI Docs routes to selected references	Already implemented
Separate specialized references	no-ai-slop loads eval.md; /init augmentation selects one template	Already implemented
Use executable helpers	Pushover has a notification script and a test script	Present; I did not run them
Improve skills from observed failures	Bundled skill-creator explicitly requires narrow corrections based on real usage	Already instructed
Evaluate skills	Skill-creator includes structural and behavioral guidance; no-ai-slop has output checks	Present, but these establish different properties
Inspect trust boundaries	Global rules constrain external actions, secrets, untrusted content, and governance changes	Strong written coverage; enforcement is a separate question

Consequently, “add progressive disclosure,” “start using scripts,” and “introduce evaluation” were too broad as recommendations.

The concrete findings

1. Your global /init requirement points to a disabled skill.

The global instructions require augmenting-project-agents after /init. Its symlink resolves to the same canonical path explicitly disabled in configuration. It is also absent from this session’s available-skills catalog.

The file exists, so this is not a missing-file problem. It is a mismatch between required workflow and configured availability.

Recommendation: decide whether augmentation remains intended. Then align the requirement and enablement. Automatically re-enabling it would assume why you disabled it.

2. Progressive disclosure applies to skills, but your global instructions remain substantial upfront context.

Measured directly:

• Global AGENTS.md: 613 lines, 37,603 bytes.
• RR AGENTS.md: 158 lines, 9,189 bytes.
• Combined file content: 46,792 bytes, before Wiki material and skill bodies.

The global file repeats related requirements across Scope Authority, Self-Authored Requirements, Skills Do Not Expand Scope, Review Feedback, No Recursive Verification, Terminal Validation, Process Limits, and Completion.

That repetition is verified. I have not measured whether reducing it improves reliability or cost. Some repetition may protect against known failures.

OpenAI documents a default instruction-discovery limit of 32 KiB; neither inspected configuration file sets project_doc_max_bytes. However, both instruction bodies are visible in this conversation, so claiming that your current task lost instructions would be false. The documented limit warrants checking other launch paths, not assuming this session was truncated. Instruction discovery

Recommendation: consolidate overlapping rules while preserving their distinct protections. Keep authorization, STOP, scope, secrets, ownership, and completion constraints directly available. Move only conditional procedural detail behind explicit routing. A blanket conversion of AGENTS.md into optional skills would weaken dependable access to essential rules.

3. Skill descriptions are actually shortened in this session.

For example, the visible description of rds-change-workflow ends before its full exclusion for ordinary app composition. The complete description contains that exclusion.

This matters because selection happens before the full body is read. Codex explicitly documents shortening descriptions when managing its initial skill-list budget. Skill discovery limits

Recommendation: put the discriminating trigger and most important exclusion early. Then check what the host actually presents. Editing the complete file alone does not establish that the selection context contains the needed boundary.

This is evidence for improving metadata, not evidence that this particular skill has misfired.

4. RR’s role ownership must control how general-purpose skills are applied.

Your global rules allow an implementer to perform ordinary self-checks. RR’s more specific Developer prompt assigns test authoring and execution to QA. Reviewer remains independently responsible for reviewing the candidate. This is a repository-specific override, not inherently a contradiction. Developer prompt, QA prompt

A general development skill that says “implement, test, review, and deliver” cannot silently transfer all those responsibilities to the Developer task.

Recommendation: validate skill use within the assigned role. Keep technical procedures reusable, but preserve RR ownership and handoffs. Do not duplicate every role prompt into a second collection of skills: that would introduce competing maintained copies.

The existing prohibition on applying RR’s product harness to RR development should remain explicit in RR’s instructions.

5. Evaluation already exists; the distinction is what it proves.

I found three different forms:

• Skill-creator’s structural validator checks packaging and unfinished scaffolding.
• no-ai-slop’s evaluation checklist checks the generated writing.
• Skill-creator’s validation guidance calls for observable behavior and improvement from demonstrated failures.

None of those findings proves that all your skills have been tested for implicit selection, scope preservation, or interaction with RR rules. Equally, I cannot claim such testing has never happened without inspecting historical evidence.

Recommendation: when changing workflow instructions, test the affected decision in a fresh task with the real instruction layers present. Useful cases drawn from this setup include:

• An app-composition change that should not trigger shared RDS implementation.
• RR development that must not activate the RR product harness.
• An /init request with the intended augmentation configuration.
• A completion event where notification authorization is absent.
• A Developer assignment that must hand testing to QA.

Use the relevant cases, not a mandatory fixed count. OpenAI’s evaluation guidance specifically distinguishes outcomes, process, efficiency, and positive and negative invocation cases. Skill evaluation guidance

6. Written security rules and runtime enforcement must remain separate.

Your global rules already prohibit unauthorized external mutations and instruction-file changes. The current execution environment nevertheless has unrestricted filesystem access and no execution-approval gate. Those are observable runtime settings; Markdown rules still depend on my compliance.

Therefore, installing a trusted-looking skill or adding another prohibition does not create a technical containment boundary.

Recommendation: retain package inspection for skills with executable or external behavior, and verify the intended runtime permission profile separately. Do not claim that an instruction, hook, or passing test enforces more than it actually does. RR already states this principle clearly.

What I would integrate

The first change should address the verified /init configuration mismatch. Next, I would make a bounded revision to duplicated global guidance and shortened skill metadata, preserving every substantive constraint. I would evaluate those revisions against the specific affected behaviors under both global-only and RR contexts.

Keep the existing Wiki routing, role separation, source-of-truth rules, native tooling, and proportional review. The article provides no evidence that we should replace them, add more agents, create a workflow engine, or allow skills to rewrite governance autonomously.

The remaining uncertainty is behavioral: we have inspected what is installed, configured, and instructed, but have not measured which proposed revision makes Codex perform better. That requires controlled task runs before claiming improvement.

Evidence and retrieval limits

• The first turn is explicitly qualified as a comparison of documented workflow, not an audit of historical compliance.
• The second turn reports exact instruction-file measurements: global AGENTS.md at 613 lines and 37,603 bytes; Release Radar AGENTS.md at 158 lines and 9,189 bytes; 46,792 bytes combined. These were reported by the source task and were not remeasured during preservation.
• The second turn reports a configuration finding: augmenting-project-agents existed on disk, its resolved path was disabled, and it was absent from that session's skill catalog. This is an observation of the 2026-10-02 source environment, not a claim about current configuration.
• Raw reads of local instruction and skill files included truncated captures. The final answer preserves the source task's conclusions and uncertainty; omitted bytes were not reconstructed.
• Primary links embedded in the preserved answers include the Anthropic article, official OpenAI skill/instruction/evaluation documentation, and Release Radar Wiki role pages.