使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/aicodeking/deepseek-stack --skill ds-unstick開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
ds-unstick
When two fixes fail the same way, the problem is usually a wrong belief, not a wrong edit. Find that belief and test it.
Steps
- Stop editing. Do not try a third variation of the same fix.
- Write down each failed attempt in one line: what you changed and what happened. Include the exact error text.
- Write the assumption that all of those attempts shared. Typical examples: "this file is the one that runs", "the config is loaded", "the function receives a string", "the cache is cleared", "the error comes from my code". Name one, in one sentence.
- Test that assumption directly with the cheapest probe that gives a yes or no answer: a print statement, a log line, a
whichor--version, a grep for the real call site, a minimal script, or a read of the docs for the exact version installed. Paste the result. - If the assumption is false, you have found the real problem. Plan the fix from the new fact.
- If the assumption holds, list 3 different approaches. "Different" means another mechanism, library, layer or data path, not a tweak of the same edit. Give each approach one line on cost and risk.
- Pick one approach and say why in one sentence.
- Restart from a clean state if the failed attempts left debris: revert them with git (
git stashorgit checkout -- <files>), then apply only the chosen approach. - Record the false assumption or the chosen approach in PROGRESS.md (see ds-context-reset) so a later session does not repeat the attempts.
- Return to ds-verify-loop with the new approach.
Stop when
- The probe in step 4 explains the failure, or the new approach passes its check.
- Two rounds of this skill have failed. Stop and report to the user: the attempts, the assumptions you tested, and the evidence. Ask for direction.
Rules
- Do not repeat a fix that has already failed, even with small changes.
- Evidence beats reasoning. If a probe takes a minute, run it.
- Keep the failed-attempt list, because it is the most useful part of the report.
- Use a clean state before a new approach, so that old edits cannot hide the result.
