بنقرة واحدة
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