| name | zl-debug |
| description | Zhulong systematic debugging workflow with spec evidence, code-map impact, verification, and evidence writeback. |
Zhulong Debug
Use this when the user invokes /zl-debug or asks to debug through Project
Intelligence Kit.
Treat the user text after /zl-debug as the request.
Required Flow
-
From the repository root, run:
{{ZL_CLI}} workflow run debug --target . "$ARGUMENTS"
If the current user message explicitly requests a fix, implementation,
patch, or repair, append --intent fix; otherwise keep diagnose-only.
-
Read the generated .planning/context/*debug*.md packet and handoff.
-
Establish expected behavior from the request, active records, source, and
tests. Query .planning/knowledge/ or local documents only when relevant
sources exist. Use RAG only when rag_backend is not none and approved.
-
Check code-map evidence before risky edits:
{{ZL_CLI}} graph status --target .{{ZL_CLI}} graph query --target . "<entry point or symbol>"
-
Follow core/workflows/debug.md and execute the debugging workflow inline
using the same packet and verification gates.
-
Default to diagnose-only. Implement only when the user explicitly asks for
a fix or a matching bounded-autonomy Goal permits debug_fix.
-
After verification, record durable evidence:
{{ZL_CLI}} evidence record --target . "<summary>" --command "<verification command>" --result "<result>" --writeback <active-record>
Keep the user-facing workflow name /zl-debug; mention GSD only as reference
design when needed. When suggesting next commands to the user, suggest
/zl-* commands, never /gsd-* commands.
