Research Source 2026 10 02 Workflow Skill Integration - joeroberts/release-radar GitHub Wiki

Research source record — workflow skill integration

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: Plan workflow skill integration
  • Codex task ID: 01a0fdfc-1742-7d90-b151-08936a2c6b3b
  • Research date: 2026-10-02 (America/New_York)
  • Owning preservation ticket: #163
  • Preserved completed turns: 1
  • 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 — Integrated workflow plan and validation

  • Turn ID: 01a0fdff-ee99-7a21-9002-2ab515bf2cee
  • Started: 2026-10-02T19:03:23.000Z
  • Completed: 2026-10-02T19:10:06.000Z

User message — verbatim

Review the findings in tasks: Compare Cursor pstack skills & Compare external skills, and preset a plan to borrow/integrate processs, instructions, scripts, etc that will augment our development workflow. Look it I know already have some skills, but I think some of my skills that may ovrerlap may be too project specific. Maybe not. Either way what I'm looking to iterate and improve our workflow. Don't just skim the surface, dive deep, validate assumptions and assertions against trusted sources, evaluate effectiveness.

Assistant commentary — verbatim

I’ll read both tasks in depth, examine the skills they overlap with, and validate the recommendations against primary sources. I’ll use that evidence to propose a focused integration plan, including what to generalize, what to keep project specific, and what isn’t worth adopting.

Assistant commentary 2 — verbatim

I’m using Skill Creator’s guidance to assess reusable skill boundaries and OpenAI Docs to check Codex compatibility. I’m treating the earlier comparisons as hypotheses: especially whether the proposed techniques add capabilities you lack, or just repeat instructions you already have.

Assistant commentary 3 — verbatim

The first concrete finding is that “project specific” needs a finer distinction. Your RDS workflow intentionally contains library ownership and delivery rules; your macOS skills contain reusable platform knowledge. Those should stay specialized. A separate roadmap skill hardcodes Pursuit’s current phase and future sequence, which is a stronger candidate for moving into project-owned context. I also found that the existing patch-risk skill is a formal immutable-patch assessment, so it isn’t a lightweight substitute for every ordinary code review.

Assistant commentary 4 — verbatim

The useful additions are becoming clearer: tracing required outputs to real data sources, checking acceptance criteria that never made it into the implementation, and testing explicit debugging hypotheses. I found portability caveats in the scripts too: the external suite’s token analyzer reads Claude transcripts, and its “portability” checker enforces conventions that the Agent Skills standard doesn’t require. Research on repository instructions also reports mixed results, so the plan will include a small comparison against your current workflow before broad adoption.

Assistant commentary 5 — verbatim

I checked two pieces of pstack’s worktree-audit logic with synthetic inputs. Its path parser truncates paths containing spaces, and its classification marks a closed-but-unmerged PR as “safe.” I didn’t run the audit against your repositories. These are concrete reasons to borrow selected ideas without importing the scripts wholesale.

There’s also a useful design difference to preserve: pstack’s verification recipe stops only processes it started, while the installed macOS build skill describes stopping an existing app by process name. Any shared verification workflow should explicitly identify its app instance and test data before driving or cleaning them up.

Assistant final answer 6 — verbatim

I recommend building a small, reusable workflow layer around your existing specialist skills. The strongest opportunities are better design inputs, acceptance verification, and investigations. Installing either external suite wholesale would bring considerable duplication and incompatible process.

After reviewing Compare Cursor pstack skills and Compare external skills, I revisited the relevant upstream instructions and scripts, inspected your local skills, checked Release Radar’s current Wiki rules, and consulted primary documentation and research. I also ran two isolated probes of suspicious script logic.

Your concern about project specificity is partly right, but the distinction matters: project facts should stay local; reusable methods should travel across projects; platform expertise should remain specialized.

What I would change in the earlier assessments

Both comparisons identified useful techniques. Neither established that adopting those techniques would improve your actual delivery outcomes. They were source reviews, not effectiveness measurements.

There are also several refinements:

Earlier conclusion My assessment after deeper inspection
Existing platform skills cover much of the external workflow They cover execution mechanics well. They do not fully replace a general method for diagnosing uncertain failures or verifying an entire requested outcome.
Existing patch-risk assessment makes another review capability redundant Only partly. Your patch-risk skill requires an immutable patch, formal ratings, JSON output, and validation. It is useful for formal assessment, but disproportionate for many ordinary reviews. Borrow a few review questions without invoking the entire assessment.
App verification recipes are valuable Yes, especially for repeated journeys. Keep reusable instructions separate from the result of any particular run, and reuse existing tests before adding manual recipes.
More structured instructions should improve reliability Plausible, but not assured. Additional instructions can increase work without improving correctness.
External scripts are promising reusable assets Some encode substantial workflow assumptions; one audit script has concrete classification and parsing problems. They need individual evaluation.

The formal assessment boundary is explicit in your installed patch-risk skill.

Which existing skills should be generalized

Existing capability Recommendation Reason
macOS/iOS, SwiftUI, Terraform Keep specialized These encode platform mechanics and constraints. Generalizing them would discard useful knowledge.
rds-change-workflow Keep the RDS adapter; extract a method only when another library needs it Checking the consumer’s pinned version, verifying an actual library gap, and coordinating adoption are reusable. RDS ownership, task routing, and delivery authorization are specific.
rekon-roadmap-status Candidate for relocation and narrowing It hardcodes Pursuit’s phase and future sequence. Those are changing product facts, better maintained with the product.
augmenting-project-agents Keep its narrow /init trigger It already uses templates as supplemental guidance and avoids speculative repository instructions.
no-ai-slop Keep It already supplies a portable writing method. Another general writing suite adds little.
Release Radar’s development roles and records Keep in RR’s governance layer Ticket ownership, role continuity, Wiki authority, and release endpoints should not become universal assumptions.

I found rekon-roadmap-status on disk, but it is not listed in this task’s available-skills catalog. That demonstrates why “installed somewhere” and “available to this task” need separate checks. Its content is visibly project specific; I have not established that its current roadmap assertions are wrong. Roadmap skill, RDS workflow

The intended organization should be:

Location What belongs there
Global instructions Stable authority, safety, scope, and communication rules
Portable skills Repeatable methods with distinct triggers
Platform skills Toolchain and framework knowledge
Project-owned references Commands, fixtures, user journeys, architecture constraints, record locations
Tickets/task results Current scope, observations, verification results, outstanding work

This fits Codex’s documented progressive loading model. Precise descriptions matter because they influence selection; the full instructions load when selected. Adding many overlapping skills is therefore a routing concern as well as a maintenance concern. Official skill documentation

What to borrow, with concrete adaptations

  1. Acceptance verification that starts from the requested outcome. Highest priority.

    Borrow JSMastery’s check for requirements that never appeared in the implementation, combined with pstack’s practical launch, drive, observe, and cleanup recipe.

    A reusable acceptance-verification skill should:

    • Derive checks from the user’s acceptance criteria, including required but unimplemented behavior.
    • Use the project’s existing tests and runtime tools.
    • Record the candidate revision/build and relevant environment.
    • Distinguish passed, failed, missing, blocked, and not run.
    • Report the observable result supporting each consequential conclusion.
    • Separate a reusable recipe from this run’s results.

    The additional not run classification matters: an intentionally omitted check and a check prevented by an environmental blocker are different situations.

    Adapt the evidence requirement to the property. A focused unit test can establish a calculation; persistence needs a persistence check; a visual claim needs rendered inspection. Requiring a full app launch for every property would add cost without necessarily strengthening the evidence.

    Sources: JSMastery verification, pstack verification recipes.

  2. Trace important outputs to their sources before implementation.

    Borrow JSMastery’s value-sourcing technique as a short addition to feature design, using existing specifications or ticket assignments.

    For example:

    Required output Questions to resolve
    “Verified” status Which verification result establishes it, for which revision, and when does it become stale?
    Displayed version Installed application, local build, Git tag, or remote release?
    Completion timestamp Which event supplies it, and which timezone is displayed?

    Extend “where does the value come from?” with freshness, failure behavior, and ownership when those affect correctness. This catches design gaps that a screen list or API table misses.

    Do not require a data-provenance table for every decorative label or introduce another specification hierarchy. Upstream specification template

  3. A portable debugging method that uses your existing platform tools.

    Adapt JSMastery’s reproduction → localization → hypothesis → experiment → correction → verification loop.

    Two changes are essential:

    • A successful experiment supports a hypothesis; it does not automatically prove a unique root cause.
    • Intermittent failures may require bounded observation or an authorized mitigation before complete diagnosis. Deterministic reproduction cannot be an absolute prerequisite for useful work.

    Google’s SRE guidance supports hypothesis-driven troubleshooting and explicitly illustrates mitigation preceding final root-cause identification. Google SRE

    A systematic-debugging skill should maintain only enough state to identify the current hypothesis, discriminating experiment, result, and next action. Regression protection should accompany the fix under the project’s testing rules. Sibling defects should be reported unless already in scope. Upstream debugging skill

  4. Evidence-aware decision investigations.

    Adapt pstack’s distinction between documented rationale, supported inference, speculation, and unknowns into decision-investigation.

    Start with the relevant code, history, linked issue, and accepted decision. Expand only when a specific unanswered question warrants another source. Do not inherit the default search across seven evidence categories and accompanying agent fan-out.

    Also distinguish documented intent from demonstrated outcome. A PR saying “improves performance” establishes the author’s stated purpose, not that performance improved. pstack investigation, evidence framework

  5. Add one useful question to ordinary review.

    Borrow: “Which assumptions make this change safe, and what would falsify them?”

    Apply it to affected boundaries: serialized data, configuration, asynchronous work, consumers, and recovery. Use the cheapest relevant existing check. Do not inherit pstack’s requirement to write a new script or reduce every change to one decisive fact. pstack blast-radius review

The scripts need more selectivity than the prose

Candidate Finding Decision
pstack worktree-audit.sh An isolated probe truncated a path containing spaces. Another classified a clean worktree with a closed, unmerged PR as safe. It also labels untracked-only files “scratch” and performs a fetch despite describing itself as read-only. Do not import. It does not itself delete worktrees, but its recommendation is unsafe to treat as deletion evidence.
pstack check-plan.mjs Requires a particular program structure, ten live-verification lanes, performance sections, and punctuation conventions. Reject. It validates pstack’s process template, not whether our plan is appropriate.
pstack orchestration/PR watcher Contains substantial TypeScript machinery and tests. Defer. No demonstrated gap justifies importing another orchestration system. Tests establish selected behavior, not compatibility with our policy.
JSMastery portability checker Mixes useful size/structure checks with suite-specific rules, including mandatory allowed-tools and punctuation restrictions. Borrow selected checks only if needed.
JSMastery token analyzer Reads Claude Code transcript structures and uses approximate cost weights. Do not port now. It is not a Codex usage measurement tool.

Sources: worktree audit, plan checker, pstack tools, JSMastery scripts.

The Agent Skills specification makes allowed-tools optional and experimental. Its presence is not proof of portable permission enforcement. Agent Skills specification

For verification helpers, the first choice should be existing repository commands. Add a helper only for a repeated mechanical gap, such as identifying the exact running test instance. Cleanup must target resources the run owns. Process existence alone does not establish the correct build, data directory, or readiness.

How I would establish effectiveness

The research does not support a blanket “more instructions is better” claim:

  • A study of 124 PRs across ten repositories reported lower median runtime and output-token consumption with AGENTS.md. Lulla et al.
  • Another study found no general task-success improvement and over 20% higher inference cost on average. Its evaluation focused on Python and did not establish effects on all security or code-quality properties. Gloaguen et al., revised September 2026

These evaluate repository context files, not our proposed skills. They justify local comparison, not removing your guardrails or promising a particular improvement.

I would use a small pilot with these cases:

Case What the added method must demonstrate
Feature with an omitted acceptance criterion Detect the omission despite passing existing tests
UI with an ambiguous data source Identify the unresolved source before implementation
Misleading debugging symptom Reject a plausible wrong hypothesis using evidence
Intermittent failure Report uncertainty and propose a bounded next experiment
Historical decision with conflicting records Preserve the contradiction without inventing intent
Simple edit Avoid unnecessary workflow activation

Compare the current workflow with one added technique at a time, using the same task, starting revision, model/effort, and tool access. Keep existing governance in both conditions. Have an independent evaluator assess actual artifacts without knowing which variant produced them.

Measure correctness first, then owner corrections, unrelated changes, unnecessary actions, elapsed time, and task-specific usage where available. Do not use account-wide usage changes as per-task cost evidence.

A small pilot is directional evidence. Repeat ambiguous cases before promoting a technique. OpenAI’s evaluation guidance similarly recommends defining a small set of observable outcome and efficiency checks before writing the skill. Official skill evaluation guidance

Proposed implementation sequence

  1. Establish ownership and baseline.
    Choose a version-controlled canonical home for portable workflow assets. Treat installed personal skills and plugin caches as distribution locations. Record the selected upstream revisions and retain applicable notices for copied material. Inventory only the affected skills and references.

  2. Build the first bounded package.
    Draft acceptance-verification, its optional project recipe, and the short value-source design check. Pilot them on one substantive feature. Add no new runtime framework.

  3. Add investigation methods independently.
    Draft systematic-debugging, then decision-investigation. Evaluate each against suitable cases before combining them into normal use. Use existing platform skills for execution.

  4. Integrate proven methods into project workflows.
    For RR, place design questions in the appropriate assignment/specification guidance, acceptance checks with QA, and the assumption question with Reviewer. Preserve QA’s test ownership and the ticket/Wiki record model. RR adoption requires its own authorized ticket and the applicable role workflow. Current delegation model

  5. Relocate volatile knowledge and stop.
    Move Pursuit-specific roadmap facts into its canonical project records if authorized. Keep RDS-specific authority in its adapter. Maintain verification recipes when affected behavior changes; reassess portable skills after demonstrated failures or runtime changes.

The first implementation batch should be acceptance verification plus value-source checking. Those most directly address incomplete outcomes and invented assumptions while fitting your existing delivery process. Debugging comes next; rationale investigation follows where historical uncertainty is recurring.

No skills, governing instructions, repository files, or external records were changed. The two script probes used synthetic inputs; neither upstream suite was installed or benchmarked. No temporary files were created.

Evidence and retrieval limits

  • The source task reports two isolated synthetic probes of pstack's worktree-audit.sh. The recorded output was:
pstack path parser, input path: /Users/example/Projects/My App
observed parsed path: /Users/example/Projects/My
pstack bucket logic, clean/unmerged/CLOSED PR: safe
  • The source task explicitly states that it did not run the audit against the owner's repositories and did not install or benchmark either external suite.
  • Upstream revisions preserved in the answer are Cursor pstack commit 7022c81efb48d8b5eb15498ce6043a3bd74b694c and JavaScript Mastery skills commit 43b69e44c9ca905fe3a3418ccdf4102255e20d40.
  • Several long raw reads of upstream and local files were truncated in the source task. The candidate preserves the reported findings and exact experiment output above, not the incomplete file copies.
  • The empirical claims about repository context files are retained with their original limitations and links; the source answer says they do not directly evaluate the proposed skills.