Agent workflow research synthesis — 2026-10-02

Navigation aid for preserved research. This synthesis does not replace the verbatim source records, approve their proposals, or authorize implementation. When wording or emphasis differs, use the linked source section.

Scope and source map

This page reconciles the seven completed pre-preservation research turns named by issue #163. The source records preserve eight user messages, twenty assistant commentary messages, and seven final answers. The cutoff is the later preservation assignment; preservation and review messages are outside the historical record.

Source	Relevant sections
Compare agent skills workflow	Initial article comparison · Corrected environment-specific assessment · Evidence limits
Plan workflow skill integration	Integrated plan and validation · Reported synthetic output and limits
Compare Cursor pstack skills	Initial comparison · Progressive-disclosure correction · Global-instruction design investigation · Evidence limits
Compare external skills	JavaScript Mastery comparison · Evidence limits

What the records directly report

These are source-task observations or externally cited results, not newly verified facts from this preservation work.

• Cursor pstack was reviewed at commit 7022c81efb48d8b5eb15498ce6043a3bd74b694c; JavaScript Mastery skills were reviewed at commit 43b69e44c9ca905fe3a3418ccdf4102255e20d40. Both reviews explicitly say the suites were not installed or benchmarked. See the pstack initial comparison and external-skills comparison.
• The corrected agent-skills review reported a 2026-10-02 mismatch between the global /init requirement and the availability/configuration of augmenting-project-agents. It also reported shortened descriptions in the session skill catalog and exact instruction-file sizes. Those observations are environment- and date-dependent. See the corrected assessment.
• The integration task ran two synthetic probes against copied logic from pstack's worktree audit. It reported truncation of a path containing spaces and classification of a closed, unmerged PR as safe. It did not run the audit against owner repositories. See the integrated plan and exact preserved output.
• The integration task cited two studies with different reported outcomes for repository context files and explicitly warned that neither study evaluates the proposed skills. See How I would establish effectiveness.
• Long raw tool outputs in every research task included truncation. The source records preserve the resulting claims, qualifications, revisions, links, and selected meaningful output rather than reconstructing incomplete captures.

Findings that converge

Keep methods, platform expertise, and project state in different places

Across the records, reusable methods are candidates for portable skills; platform mechanics remain in specialized macOS, iOS, SwiftUI, Terraform, and similar skills; changing commands, journeys, architecture constraints, and roadmap state remain with the affected project. Project specificity is not treated as a flaw when it expresses real ownership or platform boundaries.

The integrated mapping is in Which existing skills should be generalized. The later progressive-disclosure record maps the same idea to governing instructions, skill metadata, skill bodies, references, project records, and task results in Turn 2.

Selectively adapt; do not import either suite wholesale

All comparisons reject wholesale adoption. Recurring reasons are duplicated controls, conflicting record lifecycles, broad agent fan-out, fixed process templates, Cursor-specific paths and task APIs, external-action differences, and scripts that encode assumptions not established for this workflow.

The external-suite conflicts appear in the JavaScript Mastery comparison. The pstack conflicts appear in the initial pstack comparison. Script-specific dispositions appear in the integrated plan.

Progressive disclosure already exists and needs sharper routing

The corrected article comparison says Codex already uses metadata-first skill discovery and loads selected bodies on demand; Release Radar already routes from Wiki Home to specific standards and role prompts. The proposed improvement is clearer selection metadata, explicit conditions for loading references, and separation of reusable methods from current project facts.

Mandatory authority, STOP, authorization, owner-data protection, and role ownership remain available before constrained actions. Moving a mandatory rule into an optional skill would weaken it. See the corrected environment assessment, progressive-disclosure synthesis, and routing design.

Four reusable techniques remain candidates

The records converge on four methods, with bounded adaptations:

1. Acceptance verification begins with the complete requested outcome, including requirements absent from the diff or implementation. Results distinguish passed, failed, missing, blocked, and not run.
2. Value-source checking traces consequential produced or displayed values to inputs, storage, calculations, or prior decisions, adding freshness, failure behavior, or ownership when correctness depends on them.
3. Systematic debugging uses reproduction, localization, explicit hypotheses, discriminating experiments, correction, and verification while preserving uncertainty for intermittent failures.
4. Decision investigation separates documented intent, supported inference, speculation, and unknowns, and expands evidence sources only when a specific unresolved question warrants it.

The most complete proposed forms are in What to borrow, with concrete adaptations. Their origins are preserved in the external comparison and initial pstack comparison.

Ordinary review also gains one proposed question: which assumptions make this change safe, and what would falsify them? The integrated record distinguishes that lightweight question from the formal immutable-patch assessment.

Evolving conclusions and unresolved differences

Topic	Earlier position	Later position or tension	Preserved status
First new method	The initial pstack review prioritized rationale investigation, followed by verification where repeated QA need existed. Source	The integration task and later pstack turn explicitly prioritize acceptance verification plus value-source checking. Integration · Correction	The later record is an explicit change of priority, not evidence that a pilot succeeded.
First overall implementation action	The corrected article review says first resolve the verified /init configuration mismatch, then revise duplicated global guidance and shortened metadata. Source	The integrated plan says the first implementation batch should be acceptance verification plus value-source checking. Source	Unresolved. One concerns alignment of an existing required workflow; the other concerns the first new-method pilot. The records do not approve either change or establish a single cross-workstream order.
Global instruction consolidation	The progressive-disclosure turn says broader reduction should be considered separately and not bundled into the first pilot. Source	After owner steering, the next turn investigates the design now and proposes evaluating consolidation first, then selective loading and new methods. Source	Investigation was accepted; implementation sequencing remains a proposal. Governance edits require separately authorized scope.
Patch-risk overlap	Initial pstack analysis described the formal patch-risk skill as more comprehensive and warned against a second comprehensive review skill. Source	The integration review clarifies that the formal skill is too heavy for many ordinary reviews and preserves only a lightweight assumption question. Source	Reconciled as two risk levels, not duplicate full skills.
Evaluation maturity	The first article comparison broadly recommended evaluating skill changes. Source	The corrected turn found existing structural and output evaluation guidance, then narrowed the gap to selection, scope preservation, and combined-layer behavior. Source	Correction preserved. Existing evaluation guidance is not evidence that every skill has behavioral coverage.

Proposed workstreams, not approved work

The records support two separable candidate workstreams:

• Existing-workflow alignment and instruction design: decide whether augmenting-project-agents remains intended; align requirement and availability; assess early skill-description boundaries; consolidate duplicate global wording without dropping obligations; evaluate combined global and Release Radar behavior.
• Reusable-method pilot: establish a version-controlled canonical home; draft acceptance verification and a risk-focused value-source check; test one technique at a time; later consider systematic debugging and decision investigation; integrate proven methods through existing Release Radar role ownership.

Possible local comparisons include a simple edit that should not activate a workflow, an omitted acceptance criterion, an ambiguous value source, a misleading or intermittent failure, a conflicting historical record, missing required guidance, an unauthorized release action, and a role handoff. These are proposed evaluation cases, not completed evaluations.

Effectiveness and current-state limits

The research establishes source content, overlaps, conflicts, and two narrow script failures. It does not establish that the proposed skills improve delivery. No source task benchmarked either external suite, ran the proposed workflow variants, or measured a production adoption.

The records recommend comparing one technique at a time with the same task, starting revision, model/effort, and tool access, while keeping governance constant and using an independent evaluator. That proposal itself remains untested.

Local paths, installed-skill availability, configuration, Wiki content, upstream default branches, and product state can change after 2026-10-02. Revision-bound upstream links are the strongest historical references. Links to main, local absolute paths, and observations about a particular session should be rechecked before future decisions.

Authorization boundary

These records authorize no implementation. In particular, they do not authorize changes to global or repository instructions, skills, hooks, configuration, applications, ADRs, specifications, external services, or Release Radar's development process. Any implementation needs a current owner direction, a bounded ticket, the applicable role assignment, and required review.