How do I install the Cs Research skill?

Run npx skillmds@latest add matrixx0070/cs-research in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Cs Research safe to use?

SkillMD's automated safety review verdict for this skill is PASS. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Cs Research?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Cs Research free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Cs Research?

Matrixx0070 (@matrixx0070) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Cs Research by matrixx0070 — Agent Skill

Name: Cs Research
Rating: 4.2 (5 reviews)
Author: Matrixx0070

File contents

When to use

Use this when a customer asks something you cannot answer from memory — how a feature behaves, whether a limit exists, if a bug is known, or what changed in a release. Build a cited answer instead of guessing.

Not for: questions you already know cold (just reply), turning a solved issue into docs (cs-kb-article), or open-ended web research unrelated to the product. If no internal source can settle it, escalate rather than infer.

Method

Restate the question with the customer's plan, version, and platform pinned. A "does X work" answer often depends on these.
Search authoritative sources in order: official docs/help center → changelog/release notes → engineering tickets and known-issue lists → prior resolved tickets. Prefer newest and most authoritative.
Cross-check each claim against at least two sources. Decision point: if sources conflict, favor the one closest to current product state (dated release notes beat old docs) and note the conflict.
Label each finding as documented behavior or observed/anecdotal, with source and date.
Decision point: if no source confirms it, mark "unconfirmed — needs eng verification" and stop — do not reason your way to an answer.
Draft for the customer's level, then attach the internal source trail so a teammate can re-verify.

Example

Q: Can Business-plan users export more than 10k rows? (v3.2, web) A: Yes — the 10k cap was raised to 100k for Business and above. Confidence: High. Sources: Changelog 2026-05-12 "Export limit raised to 100k (Business+)"; Docs → Exports → Limits (updated 2026-05-14). Both agree. Gap: none.

Pitfalls

Answering from one source — a single stale doc is how wrong answers ship.
Blending documented and anecdotal behavior without labels.
Guessing to avoid saying "unconfirmed" — a wrong confident answer costs more than a delay.
Dropping the source trail, so no one can verify or reuse your work.

Output format

Question: <restated + plan/version/platform>
Answer: <concise, customer-ready>
Confidence: High / Medium / Low
Sources:
  - <claim> → <title, date, link>
Conflicts / gaps: <or "none">
Next step if unconfirmed: <who verifies>

---name: cs-researchdescription: Research a customer question across docs, changelogs, and past tickets, then answer with source attribution, a confidence rating, and honest gaps.---## When to useUse this when a customer asks something you cannot answer from memory — how a feature behaves, whether a limit exists, if a bug is known, or what changed in a release. Build a cited answer instead of guessing.**Not for:** questions you already know cold (just reply), turning a solved issue into docs (cs-kb-article), or open-ended web research unrelated to the product. If no internal source can settle it, escalate rather than infer.## Method1. Restate the question with the customer's plan, version, and platform pinned. A "does X work" answer often depends on these.2. Search authoritative sources in order: official docs/help center → changelog/release notes → engineering tickets and known-issue lists → prior resolved tickets. Prefer newest and most authoritative.3. Cross-check each claim against at least two sources. **Decision point:** if sources conflict, favor the one closest to current product state (dated release notes beat old docs) and note the conflict.4. Label each finding as documented behavior or observed/anecdotal, with source and date.5. **Decision point:** if no source confirms it, mark "unconfirmed — needs eng verification" and stop — do not reason your way to an answer.6. Draft for the customer's level, then attach the internal source trail so a teammate can re-verify.## Example> **Q:** Can Business-plan users export more than 10k rows? (v3.2, web)> **A:** Yes — the 10k cap was raised to 100k for Business and above.> **Confidence:** High.> **Sources:** Changelog 2026-05-12 "Export limit raised to 100k (Business+)"; Docs → Exports → Limits (updated 2026-05-14). Both agree.> **Gap:** none.## Pitfalls- Answering from one source — a single stale doc is how wrong answers ship.- Blending documented and anecdotal behavior without labels.- Guessing to avoid saying "unconfirmed" — a wrong confident answer costs more than a delay.- Dropping the source trail, so no one can verify or reuse your work.## Output format```Question: <restated + plan/version/platform>Answer: <concise, customer-ready>Confidence: High / Medium / LowSources: - <claim> → <title, date, link>Conflicts / gaps: <or "none">Next step if unconfirmed: <who verifies>```

Frequently asked questions

Cs Research