Token导航 LogoToken导航TokenDH.com
研究检索敏感数据github未标认证来源可访问许可证需确认审计通过

sdd-yoloSDD yolo 搜索

Agent Skill

sdd-yolo 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

269

周安装

11

GitHub Stars

20

下载量

86
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:sdd-yolo(SDD yolo 搜索)
来源仓库:https://github.com/sivaprasadreddy/sdd-skills
仓库路径:skills/sdd-yolo
安装命令:
npx skills add https://github.com/sivaprasadreddy/sdd-skills --skill sdd-yolo
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/sivaprasadreddy/sdd-skills --skill sdd-yolo

简介

sdd-yolo 用于查找、检索和筛选相关信息。

  • 适合在 Codex、Claude、Cursor、Gemini CLI 中根据关键词、任务场景或来源线索快速定位候选结果。
  • 通过 npx skills add 命令从指定 GitHub 仓库安装,需结合原始 README 确认具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。
  • 注意该技能当前分类为研究检索,实际功能以来源仓库文档为准。

SKILL.md

SDD: YOLO Full Pipeline

You are running the full SDD workflow end-to-end with minimal interruptions. The pipeline is: analyse → plan → implement → review → archive.

There is exactly one confirmation gate: after the spec and plan are produced, before implementation begins. Everything else runs automatically.

Required Inputs

Before starting, collect these inputs. If any are missing, ask for them now — do not proceed without them.

InputDescriptionExample
feature_descriptionThe feature to build end-to-end"Add JWT authentication with refresh token support"

Steps

Step 0: Validate Inputs (ALWAYS DO THIS FIRST)

Check the conversation for feature_description and for docs/project.md.

  • If docs/project.md does not exist → stop and tell the user to run /sdd-init first.
  • If feature_description is present → proceed to Phase 1.
  • If feature_description is missing → ask: "What feature would you like to build?" Do NOT proceed until the user provides it.

Phase 1 — Analyse

Follow the full sdd-feature process:

  1. Read docs/project.md.
  2. Analyse the request: feature_description (collected in Step 0).
  3. Ask clarifying questions only for blockers — information without which you cannot write a correct spec. Skip questions about preferences or nice-to-haves. Maximum 3 questions.
  4. Write feature.md in the project root using the standard structure:
# Feature: <Feature Name>

## Summary
## User Stories
## Functional Requirements
## Acceptance Criteria
- [ ] AC-01: ...
## Technical Scope
## Non-Functional Requirements
## Out of Scope
## Open Questions
  1. Print a compact summary of the spec (3–5 bullet points, not the full file).

Phase 2 — Plan

Follow the full sdd-plan process immediately after Phase 1:

  1. Read feature.md and docs/project.md.
  2. Write plan.md in the project root with ordered implementation steps, specific file paths, checklist items, and an AC-to-test mapping table.
  3. Print a compact summary of the plan (step names only, not full detail).

Confirmation Gate

Present the following prompt and wait for the user's response before continuing:

## Ready to implement

Spec: feature.md ✓
Plan: plan.md ✓

[Compact spec summary — 3–5 bullets]
[Plan steps — numbered list of step names]

Type PROCEED to start implementation, or describe any changes you want first.
  • If the user types PROCEED (or equivalent confirmation): continue to Phase 3.
  • If the user requests changes: apply them to feature.md and/or plan.md, show what changed, then re-present the gate.
  • If the user aborts: stop and leave feature.md and plan.md in place for manual continuation.

Phase 3 — Implement

Follow the full sdd-implement process:

  1. Read plan.md, feature.md, and docs/project.md.
  2. Execute each step in plan.md in order.
  3. Compile and run tests after each layer. Fix failures before moving on — never carry failures forward.
  4. Do not introduce new dependencies without flagging them to the user.
  5. After all steps, run the full test suite and verify every AC against a passing test.
  6. Print the completion summary (files created/modified, AC pass/fail table).

If any AC is failing after implementation, stop here. Report what failed and ask the user to fix it before continuing.


Phase 4 — Review

Follow the full sdd-review process immediately after Phase 3:

  1. Run git diff main...HEAD --name-only to determine changed files.
  2. Review across all 8 dimensions (AC coverage, language best practices, framework conventions, security, duplication, design, performance, test quality, observability).
  3. Produce the full structured review report.

Phase 5 — Archive or Stop

Evaluate the review verdict:

If verdict is ✅ Ready to merge OR 🟡 Merge after minor fixes

Proceed automatically to archive:

  1. Follow the full sdd-archive process.
  2. Update docs/project.md (features list, architecture decisions, API surface, env config).
  3. Show the proposed project.md changes and ask for confirmation before writing.
  4. Move feature.md and plan.md to docs/specs-archive/<feature-name>/.
  5. Create docs/specs-archive/<feature-name>/README.md.

Then print the final pipeline summary:

## YOLO Pipeline Complete ✓

Feature: <Feature Name>
Archived to: docs/specs-archive/<feature-name>/

Phase results:
  Analyse     ✓
  Plan        ✓
  Implement   ✓  (N files created, M files modified)
  Review      ✓  (<verdict>)
  Archive     ✓

Next: commit docs/specs-archive/<feature-name>/ and docs/project.md to version control.

If verdict is 🟠 Requires fixes and re-review OR 🔴 Do not merge

Stop. Do not archive.

Print:

## YOLO Pipeline Stopped — Review issues require attention

Feature: <Feature Name>

Phase results:
  Analyse     ✓
  Plan        ✓
  Implement   ✓
  Review      ✗  (<verdict>)
  Archive     — (skipped)

Critical/Major findings must be resolved before archiving.
Fix the issues above, then run /sdd-review to re-review, and /sdd-archive when clean.

Leave feature.md and plan.md in the project root so the user can continue manually.

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

36.92%
按下载量换算32

Claude

31.97%
按下载量换算27

Cursor

19.58%
按下载量换算17

Gemini CLI

8.47%
按下载量换算7

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

敏感数据

该 Skill 可能接触密钥、Token、环境变量或敏感配置,应进入高风险复核队列,默认不自动发布。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills