pickman: Run pipeline after review comment changes

Remove ci.skip from the push command in the review agent prompt. When
pushing changes after addressing review comments, a new pipeline should
run to verify the changes.

The ci.skip option is still used in gitlab_api.push_branch() for
initial MR creation, since the MR creation itself triggers a pipeline.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-developed-by: Claude <noreply@anthropic.com>

tools/pickman/README.rst

@@ -124,6 +124,35 @@ Pickman will add ``[skipped]`` to the MR title. Skipped MRs:
 - Don't block the ``step`` or ``poll`` commands from proceeding
 - Can be unskipped by commenting ``pickman unskip``
 
+CI Pipelines
+------------
+
+Pickman manages CI pipelines to avoid unnecessary runs while ensuring changes
+are properly verified.
+
+**Initial MR creation**
+
+When creating a new MR (via ``apply -p`` or ``step``), pickman pushes the
+branch with ``-o ci.skip``. This skips the push pipeline because GitLab
+automatically triggers an MR pipeline when the merge request is created.
+Without this, two pipelines would run: one for the push and one for the MR.
+
+**Review comment handling**
+
+When pushing changes after addressing review comments (via ``review``,
+``step``, or ``poll``), pickman does NOT skip the pipeline. A new pipeline
+is needed to verify that the changes made in response to review feedback
+are correct.
+
+**Summary**
+
+===============================  ================  =========================
+Action                           Pipeline Skipped  Reason
+===============================  ================  =========================
+Initial branch push for new MR   Yes               MR creation triggers one
+Push after review changes        No                Need to verify changes
+===============================  ================  =========================
+
 Usage
 -----
 

tools/pickman/agent.py

@@ -234,8 +234,8 @@ Steps to follow:
 4. Run 'buildman -L --board sandbox -w -o /tmp/pickman' to verify the build
 5. Create a local branch with suffix '-v2' (or increment: -v3, -v4, etc.)
 6. Force push to the ORIGINAL remote branch to update the MR:
-   git push -o ci.skip --force-with-lease {remote} HEAD:{branch_name}
-   (ci.skip prevents a duplicate pipeline; the MR pipeline will run automatically)
+   git push --force-with-lease {remote} HEAD:{branch_name}
+   (this triggers a new pipeline to verify the changes)
 7. Report what was done and what reply should be posted to the MR
 
 Important:
@@ -243,7 +243,6 @@ Important:
 - If a comment is unclear or cannot be addressed, note this in your report
 - Local branch: {branch_name}-v2 (or -v3, -v4 etc.)
 - Remote push: always to '{branch_name}' to update the existing MR
-- Always use -o ci.skip when pushing to avoid duplicate pipelines
 """