Advanced R&D
Mission
Build a version-aware evidence base before consequential work so implementation follows current primary sources instead of memory, snippets, or popularity.
Research Contract
Before searching, define:
- the decision or implementation the research must support
- the target versions, platform, runtime, and date boundary
- the required depth: API surface, behavior, constraints, compatibility, security, performance, or examples
- what would falsify the leading approach
- the stopping condition for sufficient evidence
Do not let research broaden task authority. Reading sources does not authorize installation, mutation, scraping behind access controls, account use, publication, or copying licensed material.
Source Workflow
- Inspect local manifests, locks, imports, generated API clients, vendored sources, and tests to identify the exact technology and version already in scope.
- Discover the authoritative project identity through official package metadata, registries, standards bodies, vendor documentation, or the canonical repository.
- Read primary sources first: versioned official documentation, specifications, source and tests at the relevant tag or commit, release notes, migration guides, and security advisories.
- Map the necessary surface. For a library, cover the relevant modules, functions, signatures, return types, exceptions, side effects, lifecycle, concurrency model, configuration, and examples. Do not read every API merely to claim completeness.
- Triangulate claims that are version-sensitive, ambiguous, consequential, or contradicted. Use source code or tests to resolve documentation gaps; label inference explicitly.
- Record a compact evidence matrix using Source Strategy. Use Technical Research for libraries, APIs, and standards.
- Convert findings into implementation constraints, rejected approaches, open questions, and verification steps before coding.
- Re-check the final design against the source set when implementation reveals a new API, version, or assumption.
Reliability Rules
- Prefer the exact version's docs and source over latest-version landing pages.
- Distinguish normative specification, maintained documentation, implementation behavior, examples, issues, and community commentary.
- Treat README examples, search snippets, generated summaries, and Q&A as discovery aids until confirmed by stronger sources.
- Record publication or update dates for time-sensitive material and retrieval dates for mutable pages.
- Cite the page that directly supports the claim, not a search result or generic project homepage.
- Quote sparingly; paraphrase and preserve the source's actual scope and caveats.
- Report contradictions, missing documentation, unsupported claims, and unverified compatibility instead of smoothing them over.
- Stop when every material decision has sufficient evidence and further searching is unlikely to change execution.
Output Contract
Before advanced implementation, retain a conversation-local brief containing:
- scoped question and environment/version identity
- authoritative sources with direct links or repository paths
- claim-to-source mappings and confidence
- constraints, deprecations, security notes, and compatibility boundaries
- unresolved conflicts or gaps
- implementation consequences and planned verification
Surface the brief to the user when requested, when research changes the expected approach, or when uncertainty remains material.
Authority and Artifact Policy
Keep notes conversation-local by default. Create a research brief, source matrix, downloaded corpus, cache, or citation file only when the user requests it or an existing authorized repository contract requires it. Do not install packages, clone repositories, or modify files solely because this skill activated.
Completion Gates
- Exact technology, version, and target environment are identified or explicitly unresolved.
- Material claims trace to suitable primary sources.
- Relevant API constraints and failure behavior are covered, not just happy-path examples.
- Source disagreement and inference are labeled.
- Research has been translated into concrete implementation and validation decisions.
1---2name: advanced-r-and-d3description: Perform source-grounded research before advanced or high-intensity analysis, design, or implementation across any domain. Use when research_intensity is advanced, including niche libraries, unfamiliar APIs, standards-sensitive behavior, consequential recommendations, or work whose correctness depends on current external documentation; do not use for routine tasks fully answered by stable local evidence.4---56# Advanced R&D78## Mission910Build a version-aware evidence base before consequential work so implementation follows current primary sources instead of memory, snippets, or popularity.1112## Research Contract1314Before searching, define:15161. the decision or implementation the research must support172. the target versions, platform, runtime, and date boundary183. the required depth: API surface, behavior, constraints, compatibility, security, performance, or examples194. what would falsify the leading approach205. the stopping condition for sufficient evidence2122Do not let research broaden task authority. Reading sources does not authorize installation, mutation, scraping behind access controls, account use, publication, or copying licensed material.2324## Source Workflow25261. Inspect local manifests, locks, imports, generated API clients, vendored sources, and tests to identify the exact technology and version already in scope.272. Discover the authoritative project identity through official package metadata, registries, standards bodies, vendor documentation, or the canonical repository.283. Read primary sources first: versioned official documentation, specifications, source and tests at the relevant tag or commit, release notes, migration guides, and security advisories.294. Map the necessary surface. For a library, cover the relevant modules, functions, signatures, return types, exceptions, side effects, lifecycle, concurrency model, configuration, and examples. Do not read every API merely to claim completeness.305. Triangulate claims that are version-sensitive, ambiguous, consequential, or contradicted. Use source code or tests to resolve documentation gaps; label inference explicitly.316. Record a compact evidence matrix using [Source Strategy](references/source-strategy.md). Use [Technical Research](references/technical-research.md) for libraries, APIs, and standards.327. Convert findings into implementation constraints, rejected approaches, open questions, and verification steps before coding.338. Re-check the final design against the source set when implementation reveals a new API, version, or assumption.3435## Reliability Rules36371. Prefer the exact version's docs and source over latest-version landing pages.382. Distinguish normative specification, maintained documentation, implementation behavior, examples, issues, and community commentary.393. Treat README examples, search snippets, generated summaries, and Q&A as discovery aids until confirmed by stronger sources.404. Record publication or update dates for time-sensitive material and retrieval dates for mutable pages.415. Cite the page that directly supports the claim, not a search result or generic project homepage.426. Quote sparingly; paraphrase and preserve the source's actual scope and caveats.437. Report contradictions, missing documentation, unsupported claims, and unverified compatibility instead of smoothing them over.448. Stop when every material decision has sufficient evidence and further searching is unlikely to change execution.4546## Output Contract4748Before advanced implementation, retain a conversation-local brief containing:49501. scoped question and environment/version identity512. authoritative sources with direct links or repository paths523. claim-to-source mappings and confidence534. constraints, deprecations, security notes, and compatibility boundaries545. unresolved conflicts or gaps556. implementation consequences and planned verification5657Surface the brief to the user when requested, when research changes the expected approach, or when uncertainty remains material.5859## Authority and Artifact Policy6061Keep notes conversation-local by default. Create a research brief, source matrix, downloaded corpus, cache, or citation file only when the user requests it or an existing authorized repository contract requires it. Do not install packages, clone repositories, or modify files solely because this skill activated.6263## Completion Gates64651. Exact technology, version, and target environment are identified or explicitly unresolved.662. Material claims trace to suitable primary sources.673. Relevant API constraints and failure behavior are covered, not just happy-path examples.684. Source disagreement and inference are labeled.695. Research has been translated into concrete implementation and validation decisions.
matt-bat