> ## Documentation Index > Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt > Use this file to discover all available pages before exploring further. # Skills in GreatBook workflows > How MCP skill profiles sit around the five agent graphs and the intake, posting, close, bank reconciliation, audit, and document lifecycles. # Skills in GreatBook workflows A skill may be a bounded read, one guarded decision in a longer flow, or a catalogue declaration for work that cannot start yet. The registry keeps those distinctions explicit: current action skills return review artifacts with `canonical_write_implied: false`, while blocked and queued profiles declare no usable execution path. This page is pinned to skills registry `1.0.0` and capability registry `1.14.1`. ## The five graph contracts The skills registry declares five versioned LangGraph owners. Their checkpoint contracts describe the stages they own; they do not make every similarly named skill executable through that graph. | Agent graph | Owning code | Checkpoint contract | Skill domains around the flow | | ------------------------ | -------------------------------------------------------- | ----------------------------------------------------------------- | ----------------------------------------------- | | `greatbook.clerk@1` | `langgraph_chat/agents/clerk/graph.py::build_graph` | classify → extract → validate → persist review | intake, files, document handoff | | `greatbook.bookkeeper@1` | `langgraph_chat/agents/bookkeeper/graph.py::build_graph` | load canonical intake → propose → await exact confirmation → post | posting, ledger events, business reversal | | `greatbook.auditor@1` | `langgraph_chat/agents/auditor/graph.py::build_graph` | scope → inspect read-only → report | audit runs, findings, assurance, tie-outs | | `greatbook.accountant@1` | `langgraph_chat/agents/accountant/graph.py::build_graph` | scope → analyze → stage workpaper → ready for review | close, accounting desk, adjustments, statements | | `greatbook.typewriter@1` | `langgraph_chat/agents/typewriter/graph.py::build_graph` | constrain → calculate → render preview → ready for review | document composition, approval, submission | Only `/new-document` declares direct graph execution, through `greatbook.clerk@1`, and it is blocked because its typed intake-review boundary is not released. The current profiles execute MCP tools directly; guarded action skills start a staged workspace rather than bypassing an agent checkpoint or canonical service. ## Intake and posting are one chain with two human boundaries The intake family begins with uploaded file references, classification, extraction, validation, and a persisted review state. `/new-document` and the intake queue, item, masters, audit, approve, reject, and resubmit profiles are all blocked, so none should be presented as a working MCP intake command. The Bookkeeper's posting flow begins from approved canonical intake, proposes balanced lines, waits for exact confirmation, and posts through its owning writer. The `/posting-review`, `/approve-posting`, and `/reject-posting` profiles are blocked. After a valid post exists, the current `/transactions` and `/transaction` reads can inspect canonical accounting events and lineage; they are observations of the result, not posting commands. ## Document lifecycle The Typewriter graph constrains and calculates document proposals and ends ready for review. The registry separates that proposal work from later state changes: 1. `/draft-document` and `/preview-document` are blocked, so MCP cannot currently start composition or preview as skills. 2. `/documents` is current and reads canonical Typewriter document records. 3. `/approve-document` is current but only stages a hash- and version-bound approval for review through `greatbook_workspace_create`. 4. `/submit-document` is current but only stages a hash- and version-bound submission for review through the same workspace boundary. 5. `/document-history` and `/export-document` remain blocked. Approval and submission therefore belong to a lifecycle; neither is a generic document writer and neither implies a canonical write at skill completion. ## Close and adjustments The Accountant graph reads and analyzes Close state, produces workpapers, and stages proposals ready for review. Current `/close-checklist`, `/close-readiness`, `/close-runs`, and `/fiscal-periods` skills are standalone reads of canonical Close records. Current `/allocations`, `/costing`, `/adjustments`, and `/workpaper` skills are standalone reads of the Accounting Desk's allocations, costing records, and adjustment workpapers. The action profiles are later steps, not replacements for analysis: * `/approve-adjustment` and `/reject-adjustment` stage one exact workpaper decision through the guarded workspace. * `/close-period` and `/reopen-period` stage an exact version-bound fiscal transition through the guarded workspace. * `/propose-adjustment`, `/close-adjustments`, `/create-fiscal-year`, `/run-close`, `/statutory-report`, and `/statements` are blocked or queued and cannot start. Each current action completes at `ready_for_review` with `canonical_write_implied: false`. The owning capability's canonical writer remains responsible for the eventual commit after authorization and exact confirmation. ## Bank reconciliation Bank reconciliation is a multi-step evidence and decision flow rather than one all-purpose call. 1. `/bank-statement-schema` describes the accepted evidence shape. 2. `/bank-evidence` reads bounded evidence, settlements, chains, and candidates. 3. `/bank-facets` reads procure-to-pay, order-to-cash, or float document-chain facets. 4. `/decide-bank-match` stages an accept, reject, or undo decision bound to the proposal UUID, candidate SHA-256, exact decimal amount, and currency. Those four profiles are current, subject to their distinct read or write roles. The broader `/reconcile-bank` and `/bank-workbench` profiles are queued, while statement import, handoff, proposal, manual match, unmatch, purpose classification, state, assurance, and matching-graph profiles remain blocked. The current decision skill is one guarded W3 step; it is not evidence that the whole W1–W7 workflow is available as a skill. ## Audit and assurance The Auditor graph scopes requests, reads or recomputes under a read-only boundary, and reports. Current `/audit-runs` and `/findings` inspect the resulting canonical audit-run and finding records and can return `inconclusive_read`. The job catalogue, manual run, retry, and finding acknowledgement profiles are blocked. That separation keeps reporting available without turning the Auditor into a mutation channel. ## Standalone calls versus workflow steps Read skills with completion state `complete` return non-committable pages or records and declare no canonical writer. They can still fail with `permission_denied`, `not_found`, `bound_exceeded`, or `inconclusive_read` as their profile specifies. Current action skills use `greatbook_workspace_create`, return a committable typed-action artifact, and stop at `ready_for_review` with no implied canonical write. The workspace adds revision, selection, validation, confirmation, and receipt stages before a closed adapter may call the canonical writer. Blocked and queued skills have no execution target and cannot join either path. ## Related * [Current MCP skills](/greatbook/skills/current) * [Queued and blocked MCP skills](/greatbook/skills/planned) * [Agent substrate](/greatbook/agents/substrate) * [GreatBook workspaces](/greatbook/guides/greatbook-workspaces)