Add complete_task usage rules to bundled factory-mcp skill

[warp-agent-staging]

Description

Adds concrete rules for when to call complete_task to the bundled
factory-mcp skill's "Completing a task" section (previously it only
described the tool's mechanics — idempotent, terminal, run_id /
factory_task_uid).

The section now states:

• A merged PR is the primary trigger — re-verify the merge yourself rather
  than trusting a notification, and require every linked PR that carries the
  work to have merged, not just one.
• Delivering the outcome without a merge is a secondary trigger — e.g. an
  answered question or a completed investigation.
• Never complete abandoned, rejected, superseded, or merely handed-off
  work — complete_task only ever writes the terminal COMPLETE stage and
  cannot express cancellation, and handing work off to a human (a PR out for
  review, an unanswered question) is not the same as finishing it.
• Call it once, near the end of close-out, and treat it as best-effort —
  idempotent but terminal, so completing too early is the real hazard; and the
  Factory MCP being disconnected must not block the rest of close-out.

The tools-at-a-glance bullet and the per-tool entry in
references/factory-mcp-tools.md now point at this section instead of
duplicating the rules.

Judgment call for reviewers: the requester was asked to define "perceived
as completed" (the non-merge trigger) and redirected to this task instead of
answering directly. Rules 2 and 3 above are my concrete reading of that
intent — please correct if this doesn't match what was meant.

Scope is intentionally limited to this bundled skill's text: it does not
touch the seeded factory defaults, the Factory MCP injection/feature flag, or
add a separate complete skill — those were explicitly deferred.

Linked Issue

QUALITY-1561: https://linear.app/warpdotdev/issue/QUALITY-1561

• Not a GitHub issue-tracked change; work is tracked in the Linear issue above.

Testing

Docs-only change to a bundled skill's markdown. No code paths, build, or
runtime behavior are affected, so no automated tests apply. Verified by hand:

• Frontmatter (name/description) is intact and the file still starts with
  a valid --- block.

• The new #completing-a-task anchor referenced from the tools-at-a-glance
  bullet and from references/factory-mcp-tools.md resolves to the section
  heading.

• Read the full skill and reference doc end-to-end for consistency between
  the three touch points (tools-at-a-glance bullet, "Completing a task"
  section, and the complete_task reference entry).

• I have manually tested my changes locally with ./script/run (not applicable — no runtime/UI change)

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

Conversation: https://staging.warp.dev/conversation/4e934d8d-d19a-4881-8abb-b79990e4d8bb
Run: https://oz.staging.warp.dev/runs/019ff223-3425-759b-8733-8d1bf5c97797

This PR was generated with Oz.

[warp-agent-staging]

Overview

Adds the missing "when to call it" rules for complete_task to the bundled factory-mcp skill, which previously described only the mechanics. The rules are sound and match the shipped tool contract; one boundary between them needs a human decision before this lands.

Concerns

• The two findings raised in review — an unactionable "verify the merge yourself" instruction and close-out ordering that assumed a factory-owned task — were addressed in 7df3a66. The remaining item is the inline question below, which needs a product decision rather than a code change.

Verdict

Checks: build n/a (docs-only), tests n/a, CI green (3 successful, 1 pending, rest skipped), visual proof n/a

Found: 0 critical, 0 important, 0 suggestions, 0 nits, 1 question

[warp-agent-staging]

Question — these two rules contradict each other for a common case. Rule 2 permits completing when "the work shipped by another route", while rule 3 forbids completing work that was "superseded, or closed without merging" — and a task whose implementation was replaced by a different PR is typically both. As written, an agent completes or abandons the same task depending on which paragraph it reads first, which either strands a delivered task in a non-terminal stage or marks rejected work complete.

This is the "perceived as completed" boundary that needs your call: when a task's requested outcome is delivered through a replacement PR or another route, is the original task COMPLETE, or does it stay uncompleted because its own work never landed? Once you decide, the exception should be stated in both rules rather than left implicit.