Commands and agents

The whole path a change takes, from the sentence you type to the commit, and what you are asked along the way.

The seventeen commands the toolkit installs, what each one is for, and which one to reach for instead.

Four kinds of change walked end to end, from the sentence you type to the commit, and what differs between them.

What happens between the moment you ask for a change and the moment it is committed, and what is still owed at the end.

What /vision writes down, why planning asks for it first, how it drafts the answers for you to confirm, and what its first run also corrects.

When the planning step earns its cost, what it asks you, what it leaves behind, and when planning would only cost you a conversation.

The eight specialists a command hands work to, what each one is responsible for, and why the split is there.

How the plans marked ready are worked through, what each status in the index means, where a question waits for your answer, and how a failed check gets corrected.

How /test walks a built plan in your real browser, how to read its table and its verdict, and where the correction it writes goes when something failed.

Where your plans, analyses, vision and pending findings live, how to browse them by branch, the generated index of the analysis folder, Delete finished, and how to add a document of your own.

Give one project commands of its own — built by talking to your assistant with /make-command, run with /call, and the same on every branch and every computer.

Create an API token, ask the toolkit for a document by project and path, and show the HTML it returns on a page of your own application.

The one file where your project keeps what a command noticed but was not asked to fix, how it is sorted, and who adds and removes a row.

How /design-catalog keeps your identity manual and its original files, shows you its proposal as drawings to choose from, writes plans /next can build side by side and has reviewed for design, and follows the queue until they are done.

How /coordinate takes a goal that needs changes in weblabor-base, weblabor-teams and your product, plans each part, follows every queue, brings each finished change down and checks the goal at the end.

Why code merged in from the repository your product descends from looks like your own, how a run decides whose a defect is, and what happens to your work while the fix is made there.

What to tell your assistant when the analyzer flagged correct code, missed wrong code, or a rule was not followed, and how /improve-toolkit fixes the cause in the toolkit and sweeps your project.