About DocsFab Workflows

DocsFab workflows are task guides that you use after setup to run one specific documentation or product-knowledge job. Each workflow keeps product evidence, runtime execution, quality checks, and write authority explicit. For more information, refer to Overview of DocsFab.

Before You Choose

Complete Install DocsFab before you run a workflow. Define one bounded product, repository revision, audience, and documentation target. A workflow can produce evidence, a model artifact, or a reviewable patch. It does not grant publication, deployment, or merge authority.

To create the first page or a short set for a new product or feature, start with the Runner Quickstart.

Choose a Workflow

Choose the task guide for the result you need:

Goal	Guides
Create, update, or restructure pages.	Create a Documentation Set, Update Beside a Change, Update a Page Set, Restructure a Set
Inspect existing documentation.	Baseline Documentation Health, Review Merge Request Impact, Audit Templates, Assess Readiness
Bind evidence to a job.	Select Sources, Bind a Commit Range, Bind a GitLab Change, Bind a GitHub Change, Bind a Release Range
Handle a specialized update.	Update One RST Page, Verify No Change
Work in a persistent conversation.	Attach Live Evidence, Edit Documentation, Deliver a Live-Agent Patch
Continue stopped work.	Supply Requested Work Products, Answer and Resume
Use an activated Slack project.	Review From Slack, Ask a Documentation Question, Continue a Hosted Review
Automate or deliver a result.	Run in CI, Automatic CI Proposals, Delegate a Local Task, Deliver a Draft MR
Inspect execution evidence.	Investigate Saved Runs, Diagnose a Failed Run

For the common execution steps, follow Run a Documentation Workflow. For first-pass source selection and stops, refer to First-Pass Knowledge. Exact stage order, fields, and authority rules remain in Workflow Contracts.

Gather Product Knowledge

When a documentation job stops because load-bearing product evidence is missing, contradictory, or stale, gather and reconcile that evidence before you resume the documentation work. Product-knowledge work does not replace a version-bound behavior check, an accountable intent decision, or a documentation-quality review.

Complete these stages in order when you start without a validated product model:

Run the knowledge-gathering workflow.
Conduct a product-model interview when attributable intent or participant knowledge is missing. You can skip the interview when registered evidence already covers the target.
Reconcile source threads and issue the next model version. You cannot skip reconciliation when selected source threads contain unresolved differences that affect the target.

Stop and preserve the open dependency when any of the following conditions apply:

The authoritative source or exact version is unavailable.
Retention, citation, access, or participant consent does not cover the proposed artifact.
A conflict requires behavior evidence or an accountable decision that is not available.
Provenance is lost, or an immutable source or model version would need to be overwritten.

Do not fill the gap with conversational memory or plausible prose. Keep the affected documentation target blocked until its load-bearing evidence is available.

Understand the Boundaries

The two workflow groups have the following responsibilities:

Product-knowledge workflows establish traceable inputs and readiness. They do not silently promote a participant statement or agent inference into product truth.
Documentation workflows bind pinned inputs to a fixed runtime job and quality policy. They do not broaden write or delivery authority from the wording of a request.

For the underlying authority model, refer to A Result Grants No Authority. For the intended product goals these journeys serve, refer to Use Cases.