docs(skill): add preflight guidance for parallel tasks

[xiyanjun]

What

Adds a preflight step to the Mandatory workflow for parallel-task scenarios, addressing the documentation layer of #132.

All sessions in a browser share one cookie jar. Two tasks hitting the same logged-in site will silently overwrite each other's login state — no error, hard to diagnose. This PR tells agents to check for domain overlap before running tasks in parallel.

Change

One paragraph added to the Mandatory workflow in both skill/SKILL.md and crates/bsk-cli/skill/SKILL.md (kept in sync):

• Run bsk session list + bsk tab list --session <id> --scope all --json to check domain overlap.
• If the target domain overlaps an active session's agent tab, run serially or start the new session on a different browser instance (bsk session start --browser <instance-id>).
• Ensure ≥ N active sessions for N parallel tasks.

Documentation only — no behavior change. This is the "SKILL.md workflow" option proposed in #132; the bsk preflight CLI subcommand and the cookie/storage isolation primitive remain open for discussion there.

Related to #132.

[iuyo5678]

Thanks for adding this guidance. The risk of shared login state across parallel tasks is worth documenting. I suggest continuing in this PR and updating it against the latest main so we can keep the context and discussion together.

Before merging, please address the following:

1. Adapt the change to the current skill structure.
   The root skill/ directory has been removed; the CLI skill is maintained in crates/bsk-cli/skill/. The current entry file is 6,804 bytes, and adding this paragraph brings it to 7,433 bytes, exceeding the 7,000-byte CI limit. Please keep a short pointer in SKILL.md and place the detailed guidance in references/tabs-and-profiles.md.
2. Make the conflict criteria more precise.
   Sessions within the same browser profile share relevant site state. Operations such as switching accounts or tenants can therefore interfere with other tasks. Domain overlap should be treated as a signal to assess that risk: independent reads under the same account, or tasks already using separate profiles, should not automatically require serialization.
3. Clarify how the preflight check works and what it can establish.
   tab list --scope all includes the requesting session’s Agent tabs and user tabs; it hides other sessions’ Agent Windows. Please explicitly describe using session list --json, filtering by the relevant browser instance, excluding the current task’s own session, and querying each relevant session with --scope agent.
   The guidance should also consider planned destinations. Tasks may still be on about:blank, start simultaneously, or navigate elsewhere after the check. An empty overlap result is therefore only a limited observation, not a guarantee of isolation.
4. Require a distinct session for each independent parallel task.
   Having at least N active sessions does not establish that N tasks use different sessions. Please replace the count-based rule with an explicit task-to-session requirement: each task retains its own session ID and consistently passes it to subsequent commands.
5. Clarify account and profile handling.
   Serial execution does not restore the previous login state, so each task should still verify the expected account or tenant. When using a separate profile, follow the existing profile-to-instance verification and explicit binding instructions, and preserve any profile requirement specified by the user.

This can remain a documentation-focused change. An automatic preflight command or runtime coordination mechanism can be discussed separately. If the guidance is intended to cover DSH as well, please account for its separate skill and plugin-owned session visibility; otherwise, making the CLI scope explicit is sufficient.

Please also run the existing skill bundle validation after updating the documents. These adjustments would make the guidance more actionable while avoiding unnecessary restrictions on normal parallel work.

[xiyanjun]

Thanks for the thorough review — agreed, I've kept this in the same PR and rebased onto the latest main.

Changes since your review:

1. Structure + budget: Removed the root skill/ copy; the guidance now lives in crates/bsk-cli/skill/references/tabs-and-profiles.md, with a one-line pointer in SKILL.md. The entry file is 6,872 bytes (6,996 under CRLF checkouts), under the 7,000-byte limit.

2. Conflict criteria: Domain overlap is now framed as a signal to assess risk, not an automatic serialization trigger. Independent reads under the same account, or tasks already in separate profiles, are not forced serial.

3. How the check works: Documented bsk session list --json → filter by browser_instance_id → drop the current session → bsk tab list --session <id> --scope agent --json. Noted that --scope all returns only the requesting session's Agent tabs plus user tabs (hides other sessions' Agent Windows), and that an empty result is a limited observation (about:blank, simultaneous starts, post-check navigation).

4. Task-to-session: Replaced the count-based rule with "each independent task keeps its own session ID and passes the same --session <id> to every later command".

5. Account/profile: Noted serial execution does not restore a previous login state, so each task verifies the expected account/tenant; separate profiles reuse the existing profile-to-instance verification and binding steps, preserving any user-required profile.

Scope is stated as the CLI skill only; the DSH plugin and a bsk preflight subcommand remain open in #132. Ran node scripts/check-skill-bundles.mjs — passes.

[iuyo5678]

LGTM