Loading
Use before substantial DeepChat code, configuration, documentation, test, build, feature, issue, refactor, or architecture changes that need a durable RFC and an explicit execution path. Skip trivial
The skill file stays in the publisher's repository.
Paste the copied command in a terminal. It installs this SKILL.md into that agent.
npx skills add ThinkInAIXYZ/deepchat --skill deepchat-sdd -a cursor -y
Use before substantial DeepChat code, configuration, documentation, test, build, feature, issue, refactor, or architecture changes that need a durable RFC and an explicit execution path. Skip trivial style fixes, small localized logic changes, routine docs edits, and simple bugs unless the developer asks for SDD. Use plan.md as the only separate tracker when needed, default to implementation-first validation, and ask before optional GitHub issue sync unless the developer explicitly requested sync.
Use before substantial DeepChat code, configuration, documentation, test, build, feature, issue, refactor, or architecture changes that need a durable RFC and an explicit execution path. Skip trivial style fixes, small localized logic changes, routine docs edits, and simple bugs unless the developer asks for SDD. Use plan.md as the only separate tracker when needed, default to implementation-first validation, and ask before optional GitHub issue sync unless the developer explicitly requested sync.
Use this skill before substantial DeepChat source code, configuration, tests, docs, build scripts, release workflows, or project structure changes that need shared context or a durable decision record.
Skip SDD for trivial or tightly localized work unless the developer explicitly asks for it:
If the scope is unclear, inspect first and then ask whether SDD is wanted instead of creating artifacts by default.
Create one kebab-case folder per goal:
docs/features/<goal>/docs/issues/<goal>/docs/architecture/<goal>/If one request contains multiple independent goals, split them into separate folders. Keep current architecture reference docs such as docs/architecture/agent-system.md in place; use subfolders for new architecture targets.
Treat a bug as SDD-worthy only when the root cause, blast radius, or fix path is complex enough that
future developers benefit from the written record. For simple style defects or obvious local logic
fixes, skip docs/issues/* and implement directly.
If a bug fix introduces a new user-visible capability, data migration, public contract, or cross-module redesign, classify the work as feature or architecture instead.
Feature and architecture goals use two artifacts:
spec.md: the normative RFC covering context, goals, non-goals, design, ownership, interfaces,
data flow, invariants, compatibility, acceptance criteria, and open questionsplan.md: ordered implementation steps and live completion state, followed by whole-change
review, validation selection, cleanup, and quality gatesDo not create tasks.md. The plan is the only execution tracker.
Complex bug goals normally use one file:
spec.md: issue description, impact, root cause or suspected location, fix design, concise
implementation checklist, validation outcome, and linked GitHub issue if one existsAdd plan.md only when a complex bug has multiple independently trackable implementation slices.
Never add tasks.md.
Resolve every [NEEDS CLARIFICATION] marker before implementation. If the requested change is tiny,
prefer skipping SDD over creating a token artifact.
Write spec.md as an RFC. It must explain enough implementation direction to constrain local code
decisions without becoming a file-by-file task list. Acceptance criteria describe observable
outcomes or independently verifiable contracts, not a test inventory.
Use plan.md as both plan and task tracker. Organize it into ordered checkbox sections whose steps
are coherent, reviewable implementation slices. Include the objective, ownership boundary,
essential guidance, dependencies when any, and completion condition. Reference the spec instead of
repeating its design.
Do not sync GitHub issues by default. Issue sync is a follow-up record, not a gate for local SDD or implementation.
Only create or link a GitHub issue when the developer explicitly asks, or after asking and getting approval once the SDD artifacts are written or the implementation is complete.
Eligible work:
If eligibility is unclear, ask the developer after the work is understood. Never self-authorize issue
creation just because local gh is installed and authenticated.
When approved:
[feature] label.[bug] label.gh has permission.gh is unavailable or unauthorized, continue local-only and note that no GitHub issue was
created only when sync was requested or approved.When creating a PR for linked work, include Closes #NNN in the PR body so GitHub closes the issue
automatically after merge.
shared/contracts/*api/*Clientspec.md if it is still a maintained contract.plan.md or the complex-bug spec checklist as coherent implementation slices land.pnpm run format, pnpm run i18n, pnpm run lint, and pnpm run typecheck before handoff
when app code, tests, i18n, or project docs changed.Implementation-first means finishing the planned implementation before deciding whether to author new tests. It does not prohibit running existing tests, type checking, linting, builds, or manual checks during development.
New test code before implementation is exceptional. Use it only when the developer requests TDD, a
minimal executable reproduction is required to understand a complex failure, or migration,
concurrency, recovery, or protocol compatibility needs characterization of current behavior. Record
the reason in one sentence in plan.md or the complex-bug spec.
After implementation, choose among:
Do not retain tests that mirror private control flow, assert incidental call order, duplicate the implementation through mocks, or exist only to increase coverage. Prefer no new test to a low-value implementation-coupled test.
deepchat-sdd-cleanup skill only when the developer explicitly asks to clean or
organize SDD documentation.tasks.md files as legacy and migrate them only when that goal is actively
updated. Merge remaining work into an existing plan.md; without one, keep a single-slice complex
bug checklist in spec.md and create plan.md for feature, architecture, or multi-slice bug work.
Do not perform a repository-wide migration during unrelated work.