Coding Research
Run an implementation-research. Produce the research report directly in chat. Do not create, edit, delete, stage, commit, or open files for writing.
Boundary
Stay in research mode:
- Inspect the repo and external sources.
- Compare implementation approaches.
- Recommend one approach.
- Explain how it would be implemented at a concrete planning level.
Do not write code, tests, patches, commits, PRs, issue comments, or files. If the user asks for implementation while invoking this skill, deliver the research report and say which coding skill or normal coding pass should follow.
Autonomy
Proceed without interrupting the user. Make reasonable assumptions and label them. Ask a blocking question only when the goal is impossible to research safely because essential context is missing or contradictory. Put non-blocking open questions at the end of the report.
Local First
If the question relates to the current checkout, inspect the codebase before recommending anything:
- Read applicable instructions from the repository.
- Identify stack and dependency signals from package manifests, lockfiles, config, build files, imports, and framework conventions.
- Search for existing implementations, interfaces, tests, naming patterns, error handling, observability, data access, migrations, and deployment constraints near the affected area.
- Treat existing code as context, not a cage. If the best professional answer requires refactoring, replacing an abstraction, or changing architecture, recommend that clearly and explain the migration risk.
- Understand exactly how the code is currently implementing it.
Local inspection is complete when the report can name the relevant stack, architecture shape, existing patterns, tests, dependencies, and constraints that materially affect the decision.
Research Loop
Research as deeply as needed to compare the strongest viable approaches confidently. Use any source that helps reveal professional practice, but label evidence quality.
Prefer high-signal evidence:
- Official docs, specs, RFCs, standards, release notes.
- Framework/library source code and mature OSS implementations.
- Maintainer issues, PRs, design discussions, migration guides.
- Credible engineering blogs, postmortems, benchmarks, conference talks.
- Forum discussions, examples, and weaker articles as leads or background only.
Go deeper when the decision is architectural, high-impact, security-sensitive, performance-sensitive, hard to reverse, unfamiliar, or when sources conflict.
Decision Criteria
Operationalize "top-tier FANG-level engineering" as concrete criteria:
- Correctness and edge-case behavior.
- Simplicity at the interface and implementation level.
- Maintainability, locality, and fit with existing architecture.
- Scalability and performance under expected load.
- Security, privacy, and data-integrity risks.
- Testability through public seams.
- Observability, debugging, and operational failure modes.
- Migration path, rollback plan, and compatibility.
- Dependency maturity, ecosystem fit, and maintenance risk.
Approach Landscape
Always output multiple top-tier FANG-level approaches.
For each approach, include:
- What it is
- How it would work in this codebase.
- Pros and cons
- When this approach would be the right choice.
Report Format
Write the final answer in chat using this skeleton:
- Problem Restatement - the implementation goal and any assumptions.
- Codebase Context - relevant local architecture, stack, dependencies, tests, constraints, and tensions.
- Decision Criteria - the criteria that matter most for this problem.
- Approaches - the top-tier engineering approach landscape with evidence, examples, pros, cons, tradeoffs, risks, and fit.
- Recommendation - the chosen approach, why it wins for this codebase, and what evidence or judgment supports it.
- Implementation Plan - High level steps that describe how this plan would be implemented in my repo. Do not include code patches.
- Open Questions - only questions that genuinely affect the implementation decision.
Keep the report direct and comparative.
1---2name: coding-research3description: Research implementation approaches for coding work; compare options and recommend the best option.4license: MIT5---67# Coding Research89Run an implementation-research. Produce the research report directly in chat. Do not create, edit, delete, stage, commit, or open files for writing.1011## Boundary1213Stay in research mode:1415- Inspect the repo and external sources.16- Compare implementation approaches.17- Recommend one approach.18- Explain how it would be implemented at a concrete planning level.1920Do not write code, tests, patches, commits, PRs, issue comments, or files. If the user asks for implementation while invoking this skill, deliver the research report and say which coding skill or normal coding pass should follow.2122## Autonomy2324Proceed without interrupting the user. Make reasonable assumptions and label them. Ask a blocking question only when the goal is impossible to research safely because essential context is missing or contradictory. Put non-blocking open questions at the end of the report.2526## Local First2728If the question relates to the current checkout, inspect the codebase before recommending anything:2930- Read applicable instructions from the repository.31- Identify stack and dependency signals from package manifests, lockfiles, config, build files, imports, and framework conventions.32- Search for existing implementations, interfaces, tests, naming patterns, error handling, observability, data access, migrations, and deployment constraints near the affected area.33- Treat existing code as context, not a cage. If the best professional answer requires refactoring, replacing an abstraction, or changing architecture, recommend that clearly and explain the migration risk.34- Understand exactly how the code is currently implementing it.3536Local inspection is complete when the report can name the relevant stack, architecture shape, existing patterns, tests, dependencies, and constraints that materially affect the decision.3738## Research Loop3940Research as deeply as needed to compare the strongest viable approaches confidently. Use any source that helps reveal professional practice, but label evidence quality.4142Prefer high-signal evidence:4344- Official docs, specs, RFCs, standards, release notes.45- Framework/library source code and mature OSS implementations.46- Maintainer issues, PRs, design discussions, migration guides.47- Credible engineering blogs, postmortems, benchmarks, conference talks.48- Forum discussions, examples, and weaker articles as leads or background only.4950Go deeper when the decision is architectural, high-impact, security-sensitive, performance-sensitive, hard to reverse, unfamiliar, or when sources conflict.5152## Decision Criteria5354Operationalize "top-tier FANG-level engineering" as concrete criteria:5556- Correctness and edge-case behavior.57- Simplicity at the interface and implementation level.58- Maintainability, locality, and fit with existing architecture.59- Scalability and performance under expected load.60- Security, privacy, and data-integrity risks.61- Testability through public seams.62- Observability, debugging, and operational failure modes.63- Migration path, rollback plan, and compatibility.64- Dependency maturity, ecosystem fit, and maintenance risk.6566## Approach Landscape6768Always output multiple top-tier FANG-level approaches.6970For each approach, include:7172- What it is73- How it would work in this codebase.74- Pros and cons75- When this approach would be the right choice.7677## Report Format7879Write the final answer in chat using this skeleton:80811. **Problem Restatement** - the implementation goal and any assumptions.822. **Codebase Context** - relevant local architecture, stack, dependencies, tests, constraints, and tensions.833. **Decision Criteria** - the criteria that matter most for this problem.844. **Approaches** - the top-tier engineering approach landscape with evidence, examples, pros, cons, tradeoffs, risks, and fit.855. **Recommendation** - the chosen approach, why it wins for this codebase, and what evidence or judgment supports it.866. **Implementation Plan** - High level steps that describe how this plan would be implemented in my repo. Do not include code patches.877. **Open Questions** - only questions that genuinely affect the implementation decision.8889Keep the report direct and comparative.
ravihammond