菜单
Use at the beginning of a new task. Ensures you fully understand the requirements, boundaries, and acceptance criteria before writing code.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/gootf/software-agent-sop --skill task-intake命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Methodology for designing, building, and validating an AI-agent skill workflow — the design principles behind production workflow graphs (routing/evidence/synthesis/gates/recovery/knowledge loops), a 7-phase build loop with a pass/fail gate on every phase, and the anti-patterns that break workflows. Use when the user wants to build or restore a multi-skill agent workflow ("fill this workflow with skills", "build skills for this graph", "design an agent workflow"), or when asked how to systematically assemble and verify a skill system for a domain.
This skill should be used when the user asks to "create AGENTS.md", "update AGENTS.md", "maintain agent docs", "set up CLAUDE.md", or needs to keep agent instructions concise. Enforces research-backed best practices for minimal, high-signal agent documentation.
Deeply analyze codebase architecture and dependencies. Use when understanding system design, finding patterns, or mapping how components interact.
正在显示 SKILL.md
| name | task-intake |
| description | Use at the beginning of a new task. Ensures you fully understand the requirements, boundaries, and acceptance criteria before writing code. |
Never start implementing blindly. When you receive a new task, you must force clarification of boundaries and expected outcomes.
Do not say "I will now fix the bug." and immediately edit files. Instead, use a repo-map or grep to confirm the files exist, then state your understanding of the problem. If the user's instruction is ambiguous, explicitly pause and ask them a clarifying question.
When the user says "redo this project" (refactor/rewrite), the old project's tech stack is not a requirement. Technology selection must happen AFTER requirements are confirmed — choosing the stack first is deciding for the user. Real correction case: rebuilding an existing project, the assistant wrote the README and .gitignore for the old stack without confirming requirements; the user corrected: "We don't necessarily need the old stack. Choose based on requirements. You haven't even confirmed my requirements."
Correct order (the user expects you to run a SOP, not guess):
interview-me: one question at a time — confirm scope / target platform / constraints / success criteria / out-of-scope, until confidence ≥95% with an explicit yesspec-driven-development: write a spec (tech-stack choice goes in the spec with rejected alternatives and reasons)Trigger: the user says "stack is up to you / you pick / find the best" = authorization to decide the stack, but requirements still come first.