docs: update descriptions

[Planeshifter]

Description

This pull request:

• Prepends Return a to the description field of three package.json files in the @stdlib/regexp namespace so they match each package's own JSDoc and the convention used by the rest of the namespace.

Namespace summary

• Namespace: @stdlib/regexp
• Members analyzed: 27 (no autogenerated members excluded)
• Features analyzed: file tree, package.json keys, package.json description, package.json keywords, scripts keys, manifest.json shape, README headings, test/benchmark/example filenames, JSDoc shape (@param/@returns/@throws/@example), error-construction style, validation prologue, and per-package lib/ dependencies.
• Features with a clear majority (≥75%) and a fix applied: 1 (package.json description prefix — 24/27, 88.9%).
• Features with a clear majority but no fix applied (all outliers either justified by a semantic difference, gated out, or template-driven): file tree shape, README headings (## See Also excluded as generator-owned), test/test.main.js presence (missing in reviver and to-json, both pure re-exports of lib/main.js, so a test.main.js would duplicate test.js verbatim), and regex keyword (missing in reviver and to-json, both of which follow the utility-package keyword template rather than the regex-producer template).
• Features without a clear majority (excluded from drift analysis): error-class choice (5 packages throw Error, 4 throw TypeError; the variance reflects an open stdlib-wide convention question and is not safe to normalize as a metadata fix because it is observable behavior).
• Validation of error-construction was perfectly conformant across the 9 packages that throw at all: 9/9 use @stdlib/string/format. No normalization needed.

@stdlib/regexp/duration-string

The package's description field read Regular expression to match a duration string., while the public function's JSDoc reads Returns a regular expression to match a duration string. and 24 of 27 namespace siblings (88.9%) use the Return a regular expression to ... prefix in their description. Normalized the field so the package metadata matches both the function's own docstring and the surrounding convention.

@stdlib/regexp/extended-length-path

The description field read Regular expression to detect an extended-length path., out of step with the function's JSDoc (Returns a regular expression that matches an extended-length path.) and with the namespace convention (24/27 = 88.9%). Normalized to the Return a regular expression to ... form. Kept the verb detect rather than match to preserve the existing semantic distinction the original description drew.

@stdlib/regexp/semver

The description field read Regular expression to match a semantic version string., out of step with the function's JSDoc (Returns a regular expression to match a semantic version string.) and with the namespace convention (24/27 = 88.9%). Normalized to the Return a regular expression to ... form.

Related Issues

None.

Questions

No.

Other

Validation

• Structural extraction ran across all 27 members and produced presence counts for files, package.json keys, keywords, README headings, manifest.json shape, and test/benchmark/example filenames.
• Semantic extraction captured JSDoc shape (@param, @returns, @throws, @example), error-construction style, validation prologue, and require-based dependencies.
• Three-agent validation was invoked on the surviving correction (description prefix). The correction was confirmed mechanical, non-behavioral, and supported by both the per-package JSDoc and the namespace majority. References to the existing description strings outside package.json were checked (docs/types/index.d.ts, docs/repl.txt, lib/index.js module JSDoc) — none rely on the old prefix.
• Deliberately excluded from this pull request: the missing ## See Also README sections in 5 packages (generator-owned per the gate); the missing test/test.main.js in reviver and to-json (lib/index.js is a pure re-export of lib/main.js, so the file would duplicate test/test.js); the absent regex keyword in reviver and to-json (those packages follow the utility-package keyword template, not the regex-producer template); and the Error vs TypeError choice for the [platform]/[mode] argument across 5 packages (variance below the 75% majority threshold and observable behavior).

Checklist

• Read, understood, and followed the contributing guidelines.

AI Assistance

• Yes
• No

If you answered "yes" above, how did you use AI assistance?

• Code generation (e.g., when writing an implementation or fixing a bug)
• Test/benchmark generation
• Documentation (including examples)
• Research and understanding

Disclosure

This pull request was authored by Claude Code via an automated cross-package drift-detection routine that extracts structural and semantic features from every package in a randomly selected stdlib namespace, identifies the majority pattern per feature, and proposes corrections to outliers. Findings were filtered with a 75% majority threshold and reviewed against materiality and intentional-deviation gates before being applied. A human maintainer should promote this from draft after independent review.

---

@stdlib-js/reviewers

---

Generated by Claude Code

[stdlib-bot]

Coverage Report

Package	Statements	Branches	Functions	Lines
regexp/duration-string	$\\color{green}177/177$ $\\color{green}+100.00\\%$	$\\color{green}4/4$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}177/177$ $\\color{green}+100.00\\%$
regexp/extended-length-path	$\\color{green}143/143$ $\\color{green}+100.00\\%$	$\\color{green}4/4$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}143/143$ $\\color{green}+100.00\\%$
regexp/semver	$\\color{green}184/184$ $\\color{green}+100.00\\%$	$\\color{green}4/4$ $\\color{green}+100.00\\%$	$\\color{green}1/1$ $\\color{green}+100.00\\%$	$\\color{green}184/184$ $\\color{green}+100.00\\%$

The above coverage report was generated for the changes in this PR.