diffcat-cli 0.2.1 → 0.3.0

package/plugins/diffcat/skills/diffcat/references/knowledge.md

@@ -0,0 +1,40 @@
+# Business knowledge and diagnosis
+
+Use the packaged knowledge graph for feature explanations, module guidance, workflow descriptions, and troubleshooting. It is versioned independently from the internal project wiki and contains only end-user business knowledge.
+
+## Load knowledge progressively
+
+After the mandatory login check succeeds:
+
+1. Run `diffcat --profile <name> --pretty knowledge search "<user question>" --limit 5`.
+2. Select the best topic by title, summary, and matched headings. If several topics fit materially different meanings, ask one business-language clarification.
+3. Run `diffcat --profile <name> --pretty knowledge get <topic-id>` only for selected topics. Follow related topics only when they answer part of the request.
+4. Use `knowledge outline` when the request is broad or search terms are unknown. Do not load every topic at once.
+
+Static `outline`, `search`, and `get` validate the active login on every call. They do not require `knowledge.flows.read` or another business capability.
+
+## Route three common question types
+
+### Current workflow
+
+Load the matching document topic first. Then inspect and, when needed, request the narrowly scoped `knowledge.flows.read` capability. Run `knowledge flow <flow-code-or-entity-name>` and explain the returned published version, ordered nodes, labeled branches, node responsibilities, policies, and assignee display names.
+
+Responsibility text is merged in this order: current published node remark, packaged node guidance, generic node-type guidance. Preserve the reported source when confidence matters. Never expose raw conditions, actions, internal configuration, snapshots, or assignee IDs.
+
+If the capability or matching menu is unavailable, answer from the static topic only and say plainly that the current published version, actual assignees, and latest branches could not be confirmed.
+
+### Module usage
+
+Load the matching module topic. Explain, in this order: where to enter, what master data or prior records are needed, the main actions, important states, downstream effects, and related modules. Use live reads only when the user asks about their own records or current configuration.
+
+### Troubleshooting and correction
+
+If the user says an order or document is wrong but gives no number, ask for the document number before querying. Once provided:
+
+1. Query until exactly one document is identified, then load its detail.
+2. Use `auth status` subject data to compare the current user with the creator, department, role, and possible handlers.
+3. Inspect status, `myFlowTasks`, edit/withdraw/resubmit flags when present, and relevant downstream documents.
+4. Load `troubleshooting.document-correction` and the matching document topic.
+5. Recommend the least disruptive valid route: edit a draft; withdraw and edit when explicitly allowed; have the current handler reject or return it; resubmit after rejection/withdrawal; preserve the old document and rebuild; or handle downstream reversal/adjustment first.
+
+Provide diagnosis and suggested steps only. Do not call edit, withdraw, cancel, rebuild, reverse, or other write behavior unless a separately registered live capability explicitly supports that operation and the user clearly asks for it. The current release does not add those write capabilities.