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 well-defined 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 clear 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
Connect the store. Start with evidence.
Connect your store, review the audit and choose the first change you want TaskerArmy to prepare in staging.