菜单
Use before claiming any work is done, any bug is fixed, or any task is complete. Invoke before making success claims, before reporting completion to the user, or before handing off to jds-finish. Reasoning alone is not evidence - this skill requires running verification commands and showing concrete output.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when starting any conversation - establishes the JDS skill suite, requiring skill checks before ANY action including clarifying questions. Invoke this at session start to activate the JDS workflow.
Use when a confirmed implementation plan exists under docs/jds/plans/ and you need to execute it task by task using subagents with context isolation. Invoke after jds-plan completes, or when the user asks to execute or implement an existing plan.
Use before writing any code, asking clarifying questions, or taking any action on a task. This is the exploration, communication, and design gate — the most important skill in the suite. Every task that does not match a well-defined domain skill (per jds-bootstrap's Domain Skill Fast Track) passes through it, regardless of perceived simplicity. Invoke whenever implementation work is about to begin, when requirements are unclear, or when the user asks to build, add, fix, or change something. Also invoke for lightweight tasks that don't need a full design — jds-think scales down.
Use after a spec has been confirmed via jds-think, to translate it into an executable implementation plan. Requires a spec file to exist under docs/jds/specs/. Invoke when transitioning from design to implementation, or when the user asks to plan how to build something that already has a spec. Also invoke for Moderate tasks that skip the spec phase — jds-plan can work directly from jds-think's exploration context.
Use when encountering any bug, test failure, unexpected behavior, or error at any phase of development. Invoke before attempting any fix - this skill prevents symptom-patching by enforcing systematic root-cause analysis. Also use when a fix attempt has already failed and you need a structured approach.
Use when writing any code during implementation - enforces the RED-GREEN-REFACTOR TDD cycle. This is a rigid skill that cannot be adapted or skipped. Invoke whenever code is being written as part of a feature, bugfix, or any implementation task.
| name | jds-verify |
| description | Use before claiming any work is done, any bug is fixed, or any task is complete. Invoke before making success claims, before reporting completion to the user, or before handing off to jds-finish. Reasoning alone is not evidence - this skill requires running verification commands and showing concrete output. |
Type: Rigid — follow exactly. Claims of completion without evidence are the single most common failure mode in AI-assisted development.
The agent must provide observable, concrete evidence of success. "I believe this works because..." is not verification. Running the tests and showing the output is verification.
Every completion claim must be backed by all of the following:
Run the specific tests for the code you changed. Show the output — not a summary, the actual command and its output.
$ mvn test -pl auth-module -Dtest="AuthValidatorTest"
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
When_EmptyToken_Expect_AuthRejects ✓
When_ValidToken_Expect_AuthSucceeds ✓
When_ExpiredToken_Expect_AuthRejects ✓
If the task came from a plan, run the exact verification command specified in the plan. Not a similar command — the exact one. Show the output.
Run the full test suite (or the relevant module's test suite if the full suite is impractical). Show it passing.
If any pre-existing test fails, you have introduced a regression. Do not claim completion — route to jds-debug.
The verification section of your response must contain:
It must NOT contain:
Before accepting any completion claim, confirm all tracked tasks are done:
SELECT id, title, status FROM todos WHERE status != 'done';
If any non-done todos exist, verification fails. List the incomplete items and route back to jds-execute (for pending/in_progress tasks) or jds-debug (for blocked tasks).
This prevents tasks from being silently skipped during execution.
If any verification step fails:
| Mistake | Why It Matters |
|---|---|
| "I verified by reading the code" | Reading is not running. Code that looks correct fails all the time. |
| Summarizing test output instead of showing it | Summaries hide failures. Show the actual output. |
| Running a subset of tests | You need both specific tests (did the change work?) and broad tests (did anything break?) |
| Claiming "tests pass" without output | No evidence = no verification |
| Retrying silently after failure | Hides information the human needs to make decisions |