Research source record — external skills

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 external skills
• Codex task ID: 01a0fdf1-107a-7831-8d87-733919954c32
• 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 — JavaScript Mastery skills comparison

• Turn ID: 01a0fdf2-3a2b-7ca2-99d7-f03edc255d1a
• Started: 2026-10-02T18:48:25.000Z
• Completed: 2026-10-02T18:51:13.000Z

User message — verbatim

Can you evaluate these skills, and compare them to skills that we have, and how we can "borrow" from what is done here if you think there is value? https://github.com/jsmastery-pro/skills

Assistant commentary — verbatim

I’ll inspect the repository’s skills, compare them with your installed catalog, and identify useful ideas we could adapt without duplicating what you already have.

Assistant commentary 2 — verbatim

These skills form a general development workflow, with substantial overlap with your existing guardrails. The most promising additions are their checks for missing design decisions, tracing outputs back to real data sources, and testing beyond what the implementation happens to do. I’m checking the details for conflicts with your workflow before recommending what to borrow.

Assistant final answer 3 — verbatim

Yes, there is value here. I would selectively adapt a few techniques rather than install the full suite. Your existing skills provide more specific platform capabilities, and your guardrails already cover much of their delivery discipline. Their strongest contribution is making design completeness and acceptance verification concrete.

I inspected the nine skill entry points and selected supporting guides at commit 43b69e4. I compared them with your available catalog, directly reading relevant macOS, RDS, Sites, security-review, and writing skills. This was a source review; I did not benchmark their execution or install anything.

Their skill	Comparison with what you have	My recommendation
scope	Your instructions already require bounded outcomes, acceptance criteria, dependencies, and coherent delivery chunks. Their reusable product-planning interface adds some convenience.	Borrow selected planning questions; avoid introducing another scope tracker.
audit	Generates and maintains project context in AGENTS.md. You already have explicit governance around instruction files and /init augmentation.	Do not adopt its automatic context-writing workflow.
architect	Your platform skills address implementation choices; their skill adds a general method for finding unresolved product and technical decisions.	Highest-value source to adapt.
develop	Broad UI/backend guidance overlaps with your more specific SwiftUI, RDS, Terraform, and Sites skills.	Keep your specialists; borrow the checks for unresolved decisions.
check	Separates runtime acceptance verification from independent code review, consistent with your guardrails.	Borrow its concrete verification classifications.
test	Adds a general test-writing guide beyond macOS test triage and Terraform-specific testing.	Borrow observable-behavior testing and explicit coverage gaps, preserving your test-first workflow.
debug	Your macOS debugging skills cover tools and platform failures; this supplies a general investigation method.	Useful candidate for a small, portable debugging skill.
document	Produces PR descriptions, changelogs, release notes, and postmortems from evidence. Your no-ai-slop skill primarily edits writing.	Borrow lightweight document templates when useful.
sync	Reconciles instructions, scope, and specification statuses automatically. This conflicts with parts of your governance and canonical-record model.	Borrow drift detection, not its automatic edits.

The comparisons above concern their nine-skill workflow; they are not replacements for the specialized capabilities in your catalog.

The three ideas I would borrow first:

1. Trace important outputs to their sources before building.
   Their architecture template asks where each produced or displayed value comes from: an input, stored field, calculation, or prior decision. This catches omissions that an endpoint list or screen mockup can hide.

   For example, a release status display needs a defined source for the version, completion state, verification result, and timestamp. If “verified” has no authoritative source, the design is incomplete even if the UI is fully specified.

   I would add this as a short, risk-focused check within an existing feature specification or architecture assignment. Avoid requiring a giant table for every label. Their value-sourcing template

2. Verify the requested behavior, including things that were never implemented.
   Their verification guide explicitly looks beyond the diff. An acceptance criterion with no corresponding implementation remains on the checklist. It distinguishes missing implementation, runtime failure, and inability to exercise a behavior.

   Your rules already require direct evidence. The useful addition is a compact result vocabulary: passed, failed, missing, blocked, with the relevant observation. Put that in the existing ticket or QA result rather than creating another evidence system. Their runtime verification guide

3. Make debugging hypotheses explicit.
   Their sequence is practical: reproduce, localize, state one falsifiable explanation, run the smallest experiment, fix the cause, then repeat the reproduction. This complements your platform tooling well.

   A short general debugging skill could supply the method, then select your macOS/iOS tools as needed. I would remove its suggestion to potentially fix sibling occurrences unless those are within the authorized scope. Their debugging skill

There are several reasons I would not import the suite unchanged.

• The UI direction conflicts with your native-app conventions. It treats default platform controls and system-font-only styling as potential disqualifiers and calls for maximalist surfaces in some cases. Your macOS SwiftUI skill deliberately favors native controls, materials, and desktop density. Keep its attention to loading/error/empty states; reject the universal visual prescription. Their UI guide
• Its lifecycle would introduce conflicting records and semantics. It creates scope/specification files and sometimes equates a specification becoming “Accepted” with implementation completion. Release Radar separates accepted decisions, mutable specifications, and ticket status. Its sync also edits governing instructions. Specification lifecycle, sync behavior
• It adds avoidable pauses. The test skill asks on every run whether to execute tests, and its normal entry point follows implementation. That fits poorly with your authorized autonomous execution and Release Radar’s test-first requirement. Test skill
• Some prescriptions need tighter boundaries. The backend guide requires applying migrations against the target database. That must be restricted to an authorized environment; it cannot become permission to mutate owner or shared data. Backend guide
• Their automated checks establish convention compliance, not effectiveness. The package’s test command runs a portability/convention checker. That is useful maintenance tooling, but it does not demonstrate that the workflow produces better implementations. Package scripts

My recommendation is to pilot the value-source check and missing-behavior check on one substantive feature, using existing records. A compact general debugging skill is the strongest candidate for a new reusable skill. Any adaptation should preserve upstream attribution and the notice accompanying copied material under their MIT license.

No files, skills, or governing instructions were changed; no temporary files were created.

Evidence and retrieval limits

• The review is bound to JavaScript Mastery skills commit 43b69e44c9ca905fe3a3418ccdf4102255e20d40 and reports inspection of nine skill entrypoints plus selected supporting guides.
• The source task states that this was a source review: it did not install the suite or benchmark its execution.
• Several raw upstream and local skill reads were truncated at 20,000 characters. The answer preserves the source task's comparisons, source links, licensing qualification, and explicit limits; incomplete third-party file copies were not reconstructed.