القائمة
Use when all tasks in a plan are marked done and jds-verify has passed. This skill handles final verification and cleanup of JDS working artifacts. It does NOT commit, push, or create PRs - those actions belong to the caller or the developer.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | jds-finish |
| description | Use when all tasks in a plan are marked done and jds-verify has passed. This skill handles final verification and cleanup of JDS working artifacts. It does NOT commit, push, or create PRs - those actions belong to the caller or the developer. |
Type: Rigid — follow exactly. This is the final gate before handing control back.
This skill's only job is final verification and cleanup of JDS working artifacts. It does not commit, push, or create PRs. Those actions are the responsibility of the calling skill or the developer directly.
Only run the full test suite if jds-verify has NOT already done so in this session. If jds-verify ran and the full suite passed, skip to Step 2.
If tests fail at any point: stop. Do not proceed. Route to jds-debug + jds-verify.
Delete JDS working artifacts unconditionally:
docs/jds/specs/ if it exists.docs/jds/plans/ if it exists.docs/jds/ directory if it is now empty (including parent docs/ if also empty and was created by JDS).These are AI working artifacts. They served their purpose during implementation and should not persist.
This step runs before documentation update intentionally — docs/jds/ must be gone before Step 3 scans for project docs, so it cannot be touched by mistake.
Check whether any existing documentation needs updating based on what the plan changed.
docs/) that reference those areas — by name, path, or concept. docs/jds/ has already been deleted and must not appear here.The final report (Step 6) notes whether docs were updated or no changes were needed.
Clear the SQL tracking state since all work has been verified complete:
DELETE FROM todo_deps;
DELETE FROM todos;
This prevents stale tracking data from interfering with future sessions. The completion count should be included in the final report (Step 6).
Record the count before deletion for the completion report:
SELECT count(*) as completed_tasks FROM todos WHERE status = 'done';
Confirm that no files under docs/jds/ are staged or committed in git.
git status and check for any docs/jds/ files in the staged or untracked sections.docs/jds/ files are staged, unstage them immediately with git reset HEAD docs/jds/.docs/jds/ is listed in .gitignore..gitignore was modified by JDS (to add docs/jds/), that change IS appropriate to keep — it prevents future accidental commits of JDS artifacts.Report what was accomplished. Keep it brief and factual:
"Implementation complete. [N] tasks executed, all tests passing. Documentation: [updated / no changes needed]. JDS working artifacts cleaned up. Ready for commit/PR when you are."
Do not present commit/push/PR options. Do not ask what the user wants to do next with git. Those decisions are not owned by this skill.
If this skill was invoked by a calling skill or workflow, return control to it.
| Mistake | Why It Matters |
|---|---|
| Running full test suite when jds-verify already did | Wastes time — skip to cleanup |
| Creating new documentation | This step patches existing docs only — new docs are out of scope |
| Rewriting accurate documentation | If it's still correct, leave it alone |
| Leaving spec/plan files behind | They clutter the project and may confuse future sessions |
| Committing docs/jds/ files | AI artifacts do not belong in version control |
| Offering to commit or create a PR | Not owned by this skill — overstepping responsibility boundaries |
| Proceeding when tests fail | The implementation is broken — fix first |
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.