/ad-ground
Implements WORKFLOW §4 + §5 end-to-end as a single research pass. The four sources are joined by AND, not OR — every non-trivial change runs the full research pass, then synthesizes a happy path, then justifies any deviation. Output is the input to whatever skill or freeform turn produces the implementation plan; this skill does not write code.
Step 0 — Scope the research scope
Confirm what is being researched. The research scope is the smallest verifiable surface that captures the change: a function to add, a library to pick, a pattern to apply. State it in one sentence before research starts. If the surface is broader than one sentence captures, ask the user to narrow it; broad research scopes produce diluted research.
If the change is genuinely trivial (rename, typo, one-line refactor on a tested path), skip this skill.
Step 1 — Four-source research pass (all four required)
Source A — official documentation
For each language and library in scope, cite the canonical doc URL and version. Use WebFetch to confirm the page exists and read the relevant section; use WebSearch to locate it if the URL is unknown. If neither produces a confident hit, ask the user for a known-good link rather than fabricating one. Output: bulleted citations, one per language/library, each with URL plus a one-line summary of the relevant guidance.
Source B — validated implementation references
Find ≥1 (prefer 2–3) public implementation references solving the same technical research scope with similar techniques. References include open-source repos, Stack Overflow / forum answers, blog posts, and gists — anything with citable code or an explicit code-bearing answer. The match is technical, not domain — a CRUD-app-with-auth and a CLI-with-auth both hit "auth flow", and either is valid for the auth research scope. Use WebSearch (e.g. site:github.com <research scope> language:<lang>, site:stackoverflow.com <research scope>, <library> <research scope> example) and follow up with WebFetch of the specific page. Cite <source>:<locator> — <repo>:<path>:<line-range> for repos, <URL> for Stack Overflow / forum / blog / gist — and quote the relevant block. Never paraphrase code from training memory. If search is inconclusive, ask the user for a known reference.
Source C — in-repo examples
Grep / glob the current repo for analogous patterns. Cite <file>:<line> plus a one-line description of how the existing example handles the same shape. If the codebase has no analog, state that explicitly (real signal, not a gap).
Source D — git history
Run git log --all --oneline -- <relevant-paths>, git log --all --grep=<keyword>, and a sweep of sibling active branches (git branch -a, then git log <branch> -- <paths> on those that look related). Surface any prior attempt or sibling solution — including abandoned ones — with <commit-sha> plus the touching file path and a one-line description. If the search is genuinely empty, state "no prior attempt found" — that is the valid Source D outcome when there isn't one. Narrow with --grep or -S on multi-thousand-commit repos.
Step 2 — Happy path synthesis
In one paragraph, name the most-grounded approach for the research scope and cite at least one source per Source A / B / C. Source D is included when it produced a hit; otherwise mark "no prior attempt found." The paragraph is the canonical answer the engineer would give if asked "what is the canonical, idiomatic way to solve this here?" — the question WORKFLOW.md §4 frames.