One objective, one reviewable work record.
Sessions are not merely chat history. They preserve the store context, requested outcome, implementation evidence and decision that determine what happened to the work.
A session is the complete record for one engineering objective, from the initial request through the merchant's final decision.
Start from a connected store, capability or audit finding.
Choose the intended store and describe one bounded outcome. A precise request identifies the affected storefront area, desired behavior and constraints that must remain unchanged.
Use conversation for clarification and revisions.
The agent may ask questions before changing files. After a proposal is ready, use Request changes to return to the conversation with a revision prompt instead of approving an incomplete result.
Follow work from active session through build, testing, review and completion.
The Work lifecycle page groups recent sessions by active work, QA attention, merchant review, deployment readiness, completion and abandonment. An older session without a recent changeset remains an active session rather than receiving an invented state.
Use the session title to identify the business objective.
A useful title describes the result, such as Improve mobile sticky Add to Cart, rather than Untitled session or a raw prompt fragment. Store name and lifecycle state provide additional context.
The session retains changes, QA and the final decision.
A reviewable changeset includes the staging result, affected files, QA evidence and status. Closed work remains available as an audit trail rather than disappearing from the product.
Close unpublished work without pretending it was completed.
Use Close without implementing when the proposal is no longer needed. The session becomes abandoned, the history remains visible and the live theme is unchanged. A session containing published work cannot use this outcome.
Related TaskerArmy pages
Direct answers before installation
What does Active session mean?
It means the session is open but the recent changeset queue does not provide a more specific build, testing or review state.
Can I continue an abandoned session?
The history remains available. Start a new session when the objective becomes active again so the new scope and current store state are explicit.
Why do I see technical details?
The diff is evidence for technical reviewers, but it is secondary to the staging preview, plain-language summary and QA result.
Can a session contain multiple unrelated requests?
It is better to create separate sessions. One clear objective produces cleaner scope, QA, approval and audit history.
Connect the store. Start with evidence.
Run the connected-store audit, review prioritized findings and decide which bounded engineering job should move to staging first.