Start with a useful request

This guide assumes an operator has configured Tom’s dependencies, sign-in, IQ access and project integrations. Ask the operator which stages this installation enables and where to open its dashboard. A source checkout alone does not establish a working installation.

1. Choose the right IQ project. Create a task there, or ask Tom to prepare one. Describe the problem and intended behavior, set the scope and list observable acceptance criteria.
2. Ask for a plan. For example: “Prepare a task to add a project filter. Users should select one project and clear the filter. Preserve sorting. Identify missing product decisions and propose acceptance checks.” This is an illustrative request, not a real task.
3. Read the next action. Check the task, dependencies, owner and any missing decision. Confirm that the proposed work matches your request. Readiness still depends on capacity, required inputs and authority.
4. Confirm the first result. A successful planning session gives you a task and a reasoned next step or a specific hold. It does not require launching a worker or publishing code.

Follow the task through the work

Tom is the coordinator. Descriptive specialist names identify responsibilities: pm-agent defines the problem, designer-agent shapes the experience, architect-agent addresses technical structure, developer-agent implements, tester-agent checks behavior, reviewer-agent independently reviews and release-agent coordinates authorized delivery. Researcher-agent investigates a bounded question. These names do not mean every specialist is always running.

UX changes need a design brief. Eligible, authorized implementation uses an isolated working copy to protect other work. Configured verification commands and independent review examine the proposed change; design acceptance and functional QA add the evidence required by the task. A failed or unavailable requirement holds delivery.

IQ remains the task queue. Code and pull requests live in GitHub; tools on the configured computer perform the work. The dashboard brings observations together. Release, when separately enabled and authorized, follows the project’s existing process and needs production verification of the exact deployed artifact.

In the dashboard, Home shows current focus and requests. Tasks and Activity lead to those sections. Needs attention shows the problem, recommendation, owner and recorded human question. Agents explains the roles. Expand Results and evidence for checks, reviews and technical details.

Read progress with its source and time

Ready to start means prepared for selection, subject to dependencies, capacity and authority. In progress may include waiting for another step. Needs attention calls for investigation or a decision; read the question and accountable owner.

Ready to release describes a deployable, merged task with recorded check, review and merge evidence. Live describes a deployment record with production identity and verification. Freshness is shown separately. Source checks alone do not establish that a feature is live.

Select the intended loop and check observation times. Refreshing the page alone does not refresh IQ; a configured bounded refresh can. Simulation uses labeled fictional tasks. An animated dashboard is not proof that a worker is running.

Answer a human question with the task and your choice. Tom should investigate engineering failures before asking you for a product decision or uncovered permission. Task text and status changes do not grant authority. If dashboard requests are enabled, Queued locally means saved for relay and Delivered means chat delivery was acknowledged. Neither means the task is complete.

Keep the candidate when work stops

Ask Tom to reconcile the IQ task, current attempt, proposed change and failed requirement. Ready work may be waiting on a dependency, capacity, required metadata or authorization. Retained candidates preserve work for recovery. Silence does not prove a worker stopped; ownership and processes need reconciliation before reassignment.

For stale dashboard data, check the selected loop, source and observation time, then ask the coordinator for a fresh observation. For uncertain request delivery, reconcile the existing request before retrying. An operator should investigate integration or setup failures.

Automatic cross-computer failover is unavailable. The repository does not establish a verified live deployment-provider setup. Confirm the enabled and exercised stages of your installation with its operator.

npm run schedule:plan
npm run monitor