Skills
Skills Share
npx -y skills add frankshi1024/tcm-diagnosis-skill --skill skillsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
A diagnosis-first protocol inspired by Traditional Chinese Medicine (Observation, Listening, Inquiry, Pulse). Enforces structured requirement clarification and root-cause analysis before any implementation.
SKILL.md
4.0 KB, as published. Nobody here has run it
TCM Diagnosis Protocol
Core Rule
No implementation code until all four phases are complete. Phases 1-3 are purely diagnostic — questions, summaries, analysis. Phase 4 produces the plan, then code.
Phase 1: Observe (望)
Before doing anything, read the room.
- Scan open files, directory structure, and recent conversation history
- Check for CLAUDE.md or project conventions
- Identify: task type (bug fix? new feature? refactor? research?), domain, scope, impact radius
Output a structured observation report covering these dimensions:
[Observe]
- Task type & scope: ...
- Files / modules involved: ...
- What I know from context: ...
- What's still unclear: ... (to be filled in later phases)
Do this even if you know the project. It proves you've read the context, not just recalled it.
Phase 2: Listen (闻)
Restate the user's request in your own words. Surface implicit assumptions.
- "You're asking me to do X, is that correct?"
- "I assume this change affects A but not B — is that right?"
- If ambiguous, be explicit: "I see two possible interpretations: one is ..., the other is ..."
Wait for user confirmation before proceeding. If corrected, update your understanding. Don't argue.
Phase 3: Inquire (问)
Ask 1-4 targeted questions to close the gaps identified in Phases 1 & 2. Rules:
- No rhetorical questions. Every question must have a concrete purpose.
- No questions you can answer yourself (by reading files, docs, etc.).
- Prioritize constraints and boundaries over implementation details:
- "Under what conditions would this approach fail?"
- "How do you prioritize performance vs. maintainability vs. speed?"
- "Will this change affect other modules?"
- "Are there any approaches you won't accept?"
- Max 4 questions at a time — diagnosis is iterative, not exhaustive.
- Self-check: After drafting questions, ask yourself — "If the user answers this, will it change my approach?" If no, drop it.
Phase 4: Diagnose & Treat (切)
Only now do you produce a solution. Start with the diagnosis:
Diagnosis: Root cause is X (not symptom Y). Scope includes A, B. Does NOT include C, D.
Plan: ... (brief steps, each with a verification method)
Caveats: ... (known risks, unresolved boundaries)
Then ask for approval: "Shall I proceed with this plan? Anything to adjust?"
Only after approval, write code.
Follow-up (复诊)
After implementation, always end with:
Plan executed. You can:
- Review the diff — adjust if needed
- Share the actual result — I can iterate based on feedback
- If it doesn't match expectations, we return to the Inquire phase
Iteration limit: Max 2 follow-up rounds per task. If still off after 3 attempts, suggest a manual pause — the problem definition itself may be wrong.
When to Skip
- Typo fixes, trivial renames, one-line changes
- Pure information lookup ("what are the params of this API")
- One-off shell commands (run this, install that)
- If a diagnostic phase was already completed in the last 2 turns
Use judgment. The protocol is a tool, not a religion.
User Override
If the user explicitly asks to skip diagnosis ("just do it", "don't ask, just code"):
- Accept the override. Don't insist on the protocol. Don't lecture.
- One-line confirmation: "Skipping diagnosis, going straight to execution. Two quick confirmations first: ① ... ② ..." (max 2 must-know items required to proceed)
- Mark it: Prefix execution with
[Diagnosis skipped]so it's clear this task wasn't fully diagnosed. - No guarantees: If results don't match expectations, suggest returning to the Inquire phase to recover.