一键导入
speq-ext-research
Search for external documentation and research triggered by speq-skills.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Search for external documentation and research triggered by speq-skills.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Audit a speq project's health — spec-library structure, feature/decision-log/plan validation, mission-to-spec sync, unrecorded plans, and gitignore hygiene — then guide fixes. Use when the user asks to audit, health-check, doctor, lint, or sanity-check the specs or repo, or after cloning or inheriting a speq project.
Code review tag taxonomy and findings output format — guardrail violations, dead code, obsolete tests, bad comments, optimizations, YAGNI/over-engineering. Triggered by code-reviewer.
Headless follow-up to speq-plan-pr. Continues on a plan's feat/plan-name branch, runs speq-implement, bumps the version, runs the real test suites, records only if green, then pushes and opens/updates a PR. Arg: plan name, PR number, or branch name.
Orchestrate implementation of reviewed plans according to the spec deltas. Arg: <plan-name>.
Create specs/mission.md via interactive interview. Detects brownfield vs greenfield.
Headless, non-interactive version of speq-plan. Plans a feature without a live interview, commits the result to a feat/plan-name branch, and opens a PR. If a decision genuinely needs a human, it persists the partial plan and open questions and asks in a PR comment instead of blocking. Arg — plan name, feature intent text, PR number, or branch name.
| name | speq-ext-research |
| description | Search for external documentation and research triggered by speq-skills. |
External documentation and research via Context7 and WebSearch.
| Source | Use For |
|---|---|
| Context7 | Library APIs, method signatures, usage examples |
| WebSearch | Design patterns, architecture decisions, best practices |
1. resolve-library-id
query: "<what you need>"
libraryName: "<library name>"
2. query-docs
libraryId: "<from step 1>"
query: "<specific question>"
1. WebSearch(query: "<design question>")
2. Extract relevant patterns
3. Apply to implementation
Apply an evidence hierarchy — primary documentation over secondary commentary:
Need library API details?
├─ Yes → Context7
└─ No → Need design guidance?
├─ Yes → WebSearch
└─ No → Proceed with existing knowledge
Adding rate limiting to Express API:
1. resolve-library-id
query: "Express.js rate limiting"
libraryName: "express-rate-limit"
2. query-docs
libraryId: "/nfriedly/express-rate-limit"
query: "middleware setup options"
3. Implement using verified current API