agentsclimarketplace
Sign in

Feature request research

Skill bakerstreetco/skills/feature-request-research

Research an existing codebase, pull requests, issues, commits, and documentation before planning or implementing a feature request. Use when asked to investigate whether a feature request already exists, find prior attempts, identify related code paths, compare implementation options, or produce an evidence-backed recommendation before writing code.From its SKILL.md

Install
npx -y skills add bakerstreetco/skills --skill feature-request-research

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, 619 tokens by cl100k_base, as published. Nobody here has run it

Feature Request Research

Use this skill to answer "what should we know before building this?" Ground every conclusion in repository evidence, issue/PR history, docs, tests, and the current code.

Do not implement code changes unless the user explicitly asks to move from research into implementation.

Research Workflow

  1. Capture the request in one or two sentences, including the user-visible behavior, affected product area, and any acceptance criteria.
  2. Inspect repository basics:
git status --short
git branch --show-current
git remote -v
git log -5 --oneline
  1. Search the codebase for domain terms, UI labels, routes, commands, API names, config keys, test names, and nearby concepts:
rg -n "term|related phrase|apiName" .
rg --files
  1. Trace the most relevant implementation paths through callers, tests, fixtures, docs, public exports, route handlers, feature flags, generated files, and package boundaries.
  2. If a GitHub remote and gh authentication are available, search existing and historical issue/PR evidence:
gh issue list --state all --search "terms from request" --limit 20
gh pr list --state all --search "terms from request" --limit 20
gh pr view <number> --comments --files
gh issue view <number> --comments
  1. If gh is unavailable, unauthenticated, or the repository is not hosted on GitHub, continue with local git evidence and state the limitation briefly.
  2. Review prior attempts or related changes with local history when useful:
git log --all --oneline -- "path/to/relevant/file"
git log --all --grep "term from request"
git blame -- "path/to/relevant/file"

Analysis

Separate evidence from inference:

  • Existing support: what already works, what is hidden behind flags/config, and what only needs exposure or wiring.
  • Prior art: related PRs, issues, commits, reverted attempts, TODOs, docs promises, and test coverage.
  • Affected surface: files, modules, owners, APIs, database/storage, background jobs, UI states, and migration risks.
  • Constraints: compatibility, permissions, security/privacy, performance, rollout, release process, generated artifacts, and known flaky areas.
  • Options: at least two plausible implementation approaches when the solution is not obvious, with tradeoffs.
  • Unknowns: questions that genuinely block a confident recommendation.

Output

Return a concise research brief with:

  • Request summary.
  • Evidence found, with file paths, PR/issue numbers, commit hashes, or commands used.
  • Relevant code paths and tests to inspect first.
  • Recommendation and why.
  • Implementation outline only if enough evidence supports it.
  • Risks, unknowns, and suggested verification.

Do not fabricate PRs, issues, links, owners, metrics, or behavior. If evidence is missing, say so plainly.

What ships with it: 2 files

899 B alongside SKILL.md

agents/

Keep looking

Skills are one crate of 326,645. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.