Merge pull request #938 from jupyter-naas/fix-pretty-markdown

fix: improve markdown transformation handling in GitAgent

Author: FlorentRvl

libs/naas-abi-core/naas_abi_core/services/agent/Agent.py

@@ -865,6 +865,9 @@ def _pretty_display_markdown(
         self,
         response: BaseMessage,
     ) -> BaseMessage:
+        if len(response.content) > 0:
+            return response
+
         prompt = [
             SystemMessage(
                 content=(
@@ -896,7 +899,7 @@ def _pretty_display_markdown(
 - If the input is already well-formatted, make minimal changes."""
                 )
             ),
-            AIMessage(content=(f"Initial content:\n{response.content}")),
+            HumanMessage(content=(f"Initial content:\n{response.content}")),
         ]
 
         try:

libs/naas-abi-marketplace/naas_abi_marketplace/applications/git/agents/GitAgent.py

@@ -21,7 +21,7 @@ class GitAgent(Agent):
 - inspect the repository state (branch, status, staged diff, recent commits, whether the branch exists on origin)
 - generate a pull request description by invoking the PullRequestDescriptionAgent
 - commit staged changes
-- restore accidental working-tree changes (e.g. lockfile churn)
+- restore accidental working-tree changes and commit lockfile updates in a dedicated chore commit
 - push the branch (ONLY when explicitly requested)
 - find/create/update/view a GitHub pull request via `gh`
 
@@ -31,25 +31,24 @@ class GitAgent(Agent):
   - Do NOT require staged or unstaged changes. Commits already on the branch are enough. `pull_request_description` compares the branch to the base (e.g. `origin/main...HEAD`) and does not need a staged diff.
   - First check if a PR already exists for the current branch using `gh_pr_find_for_branch`.
   - If it exists: call `pull_request_description`, then update with `gh_pr_edit`, then show the PR via `gh_pr_view`.
-  - If it does not exist: call `git_remote_branch_exists`. If false, explain that the branch must be on origin before opening a PR; do NOT push unless the user explicitly asked to push (offer that they can ask you to push).
-  - If the branch is on origin (or after a user-requested push): call `pull_request_description`, then create with `gh_pr_create`, then `gh_pr_view`.
+  - If it does not exist: call `git_remote_branch_exists`. If false, automatically push the branch to origin using `git_push` (which sets the upstream), then proceed.
+  - Once the branch is on origin: call `pull_request_description`, then create with `gh_pr_create`, then `gh_pr_view`.
 - If the user asks to **open/update a PR** after or alongside committing: follow the commit workflow when they asked to commit; then apply the PR-only rules above for create/update/view.
-- If the user asks to open/update a PR but does NOT explicitly ask to push: you MUST NOT push.
-  - If a new PR cannot be created because the branch is not on origin, explain that pushing is required and stop (unless they explicitly asked to push).
+- Whenever a PR needs to be created/updated and the branch is not yet on origin, always push it automatically using `git_push` before attempting to create the PR.
 
 Standard workflow — pick the path that matches the user request:
 
 **Path PR-only** (user asked to open/update a PR and did NOT ask to commit new changes):
 1) Optionally call `git_status` or `git_log` for context.
 2) Call `pull_request_description` and use its output as the PR body (it reflects all commits on the branch vs base).
 3) If the branch name starts with digits (e.g. "123-fix-..."), ensure the PR body starts with: "This pull request resolves #123"
-4) `gh_pr_find_for_branch` → if a PR exists: `gh_pr_edit` with a sensible title/body; if not: ensure branch is on origin (`git_remote_branch_exists`), then `gh_pr_create` if possible → `gh_pr_view`.
+4) `gh_pr_find_for_branch` → if a PR exists: `gh_pr_edit` with a sensible title/body; if not: check `git_remote_branch_exists` — if false, call `git_push` to push the branch to origin first — then `gh_pr_create` → `gh_pr_view`.
 
 **Path commit** (user asked to commit):
 1) Call `git_status` and `git_diff_staged`. If nothing is staged, stop and explain that staging is required to commit.
 2) Draft a Conventional Commit message (type/scope/subject) based on the staged diff.
 3) Call `git_commit` with that message.
-4) Call `git_status` again; if only lockfiles changed by hooks/tooling (e.g. `uv.lock`) and are unrelated, call `git_restore` on them to keep the PR focused.
+4) Call `git_status` again; if lockfiles (e.g. `uv.lock`, `pnpm-lock.yaml`, `package-lock.json`) were modified by hooks/tooling and are unstaged, stage and commit them in a dedicated commit with message `chore: update lockfile`.
 5) If the user explicitly asked to push, call `git_push`.
 6) If the user also asked to open/update a PR, continue with **Path PR-only** steps 2–4.