Part 21. Qwen Code workflow for DataLakeHouse

Now the workflow can be shaped as a Qwen workflow:

/sdd:profile -> /sdd:contract -> /sdd:build -> /sdd:verify -> /sdd:release

The main idea: a single command should not run the entire workflow. In banking data it is dangerous when the agent profiles the source by itself, decides the contract by itself, writes SQL by itself, and reviews itself.

Project commands

The example includes:

.qwen/commands/sdd/profile.md
.qwen/commands/sdd/contract.md
.qwen/commands/sdd/build.md
.qwen/commands/sdd/verify.md
.qwen/commands/sdd/release.md

Commands are split at human confirmation checkpoints:

• profile collects source facts;
• contract formulates or verifies the promise;
• build changes dbt models;
• verify runs checks and looks for drift;
• release assembles an evidence package.

Skills and subagents

data-contract-review stores the review checklist. data-profiler reads sources and returns a manifest without writing models. The generator and the reviewer must be different roles. Otherwise the agent checks its own guesses.

The reviewer in read-only mode is especially important after /clear: if they cannot understand a change

from the repository files, it means the author left the meaning in the chat.

Hooks

A hook can block writing to models/marts/ if the change adds a pii_ field or changes the contract YAML without a confirmation label. In the training example the hook is described conceptually; it should be written after the first practical checkpoint, when the team already understands which violations keep recurring.

Minimum output

Assemble a workflow map:

/sdd:profile -> Schema Manifest
/sdd:contract -> update of ODCS/ODPS
/sdd:build -> change of dbt model
/sdd:verify -> dbt build + verification facts
/sdd:release -> evidence package
data-contract-review -> reviewer's report

If a team leaves no artifact, it is not needed on the first pass.

Breakdown for the reader

Qwen commands in this chapter should not turn into a magical control panel. Their meaning lies in separating responsibility. /sdd:profile observes the source. /sdd:contract formulates the promise. /sdd:build changes models. /sdd:verify looks for discrepancies. /sdd:release gathers evidence. If a single command does everything, it erases human confirmations and turns SDD into autopilot again.

Skills and subagents are useful when they narrow the role. The data-profiler should not write marts. The contract reviewer should not fix SQL. The generator should not approve its own change as safe. This separation seems formal until an error appears. After an error, it is precisely the role that shows who was supposed to notice the problem and which artifact was supposed to catch it.

Hooks are the next level of discipline, but they should not be written before the process. If the team does not yet understand which violations keep recurring, the hook will be either weak or annoying. A good hook blocks a known dangerous class of changes: PII in models/marts/, contract YAML without an approval marker, grain change without an impact note. It does not replace review; it stops an obvious error from reaching it.

This chapter connects the entire volume into a working cycle. After it the reader should be able to say which command to use to collect source facts, which to verify the contract, which to build the model, which to run checks, and which to prepare a release. If this separation does not exist, the agent again gains too broad power over the data.

Practice

Run the same request in two roles: author and reviewer. The author may

suggest changes; the reviewer must work in read-only mode. Compare which comments appear only after the role separation.

Typical mistake

Creating a single /sdd:do-everything command. It is convenient in a demo, but dangerous in banking data: human confirmation disappears, and contract drift is detected too late.

Review questions

1. Why shouldn't a command run the entire process without stops?
2. How does a skill differ from a subagent?
3. Where should human confirmation be placed?