agentsclimarketplace

Spec research

Skill h3y6e/spec-skills/skills/spec-research

Agent Skills for Spec-Driven Development

Install
npx -y skills add h3y6e/spec-skills --skill spec-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.

What its author says it does

Copied from the file, not written here

Investigate a specific topic and record findings in specs/{feature}/research/{topic}.md — covering technical options, library comparisons, API constraints, architecture trade-offs, or any open question that needs evidence before a decision can be made. Use this skill whenever someone wants to research a topic independently of spec/plan/implement phases, compare technical alternatives, investigate an API or platform constraint, run a proof of concept and document results, or says "research [topic]". This is a utility skill that can be invoked from any point in the spec-driven workflow or standalone. Don't use for writing specs, creating plans, or implementing code.

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

4.7 KB, as published. Nobody here has run it

Research Skill

Purpose

Core principle: Evidence before decisions. No recommendation without tested findings.

Investigate a focused topic and produce specs/{feature}/research/{topic}.md with findings, a decision, and impact assessment. This skill can be invoked independently or from any other skill when deeper investigation is needed.

Input

  • Research question or topic from the user
  • Existing specs/constitution.md when present
  • Existing specs/{feature}/spec.md when present
  • Existing specs/{feature}/plan.md when present
  • Existing specs/{feature}/research/*.md when present

Output

  • specs/{feature}/research/{topic}.md
  • Updated specs/{feature}/spec.md when findings change requirements
  • Updated specs/{feature}/plan.md when findings change execution design

Steps

  1. Resolve language and shared rules from specs/constitution.md when present; otherwise infer from the available workflow documents and the user's own message. Ask only if still unclear, then conduct all subsequent interaction in this language.
  2. Clarify the research scope.
    • Identify the feature slug and research topic
    • Frame a clear research question
    • Determine whether existing spec.md or plan.md context is relevant
  3. Gather information.
    • Read existing project context (spec.md, plan.md, other research/*.md)
    • Investigate external sources: documentation, APIs, library comparisons, platform constraints
    • Run a proof of concept when hands-on validation is needed — don't trust documentation alone for critical decisions
    • Compare against working examples or reference implementations when a pattern already exists
    • For failures or unexpected behavior, reproduce the symptom and identify root cause before recommending fixes
    • Form a hypothesis, test it minimally, then record what you found. One variable at a time.
  4. Create the research file from references/research-template.md.
    • Research Question: one clear question the research answers
    • Context: feature, topic, and scope of investigation
    • Sources: all references consulted
    • Findings: factual observations with evidence
    • Decision: selected option with rationale AND alternatives considered — a decision without rejected alternatives is not a real decision
    • Impact: assessed effect on spec, plan, and tasks
    • Follow-ups: remaining open items, if any
  5. Assess impact on existing documents.
    • If findings change requirements or user-visible behavior: flag spec impact
    • If findings change spec-to-spec prerequisites: update spec.md frontmatter dependencies and flag spec impact
    • If findings change execution design, task dependencies, or validation strategy: flag plan impact
    • If no upstream documents exist yet, record impact as guidance for future phases
  6. Apply backflow when existing approved documents are affected.
    • Update spec.md and reset its status to draft when findings are spec-impacting
    • Update plan.md and reset its status to draft when findings are plan-impacting
    • Do not apply backflow when upstream documents do not yet exist
  7. Perform final review and keep the file within 150 lines.
    • Remove repetition
    • Simplify wording
    • Ensure the decision is clearly stated with rationale
  8. In the completion message, suggest the next step.
    • If a spec does not yet exist: spec-specify
    • If a spec exists but no plan: spec-plan
    • If a plan exists and is approved: spec-implement
    • If more research is needed: continue spec-research

Success Criteria

  • The research question is clearly stated and answered.
  • Findings are backed by evidence or direct observation.
  • A decision is recorded with rationale and alternatives.
  • Impact on existing spec and plan documents is assessed.
  • Backflow is applied when approved documents are affected.

Completion Guidance

  • This is a utility skill; the next step depends on workflow context
  • Include the research topic, decision summary, and generated file path in the response

Keep looking

Skills are one crate of 328,083. 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.