Cities2-MCP AGENTS.md

Agent rules

For maintaining the Cities2-MCP repo

Workspace safety

• Do not delete protected files, including .DS_Store, unless the user explicitly asks.
• Before editing, run git status --short --branch.
• Do not edit the main checkout for branch or PR work unless the user explicitly asks.
• Use the active client's native workspace or worktree mechanism when the maintainer needs in-client review tools. Fall back to manual Git worktrees only when no native mechanism is available.
• If the checkout is stale, detached, behind remote, or not the intended branch, stop and switch to the correct worktree before editing.
• Preserve touched files' existing line-ending style. If Git warns about line endings, check and normalize only touched files back to the repository/indexed style.

Commit and PR safety

• Do not commit or push unless the user explicitly asks for the current branch or PR.
• Preparing a diff is allowed. Committing and pushing require user agreement.
• After a pushed branch has an open PR, offer to update the PR description or metadata to reflect pushed changes unless the user has asked otherwise.
• When writing, editing, or commenting on a PR, append a co-author line naming the acting agent at the bottom on its own line, such as *Co-authored by Codex.* or *Co-authored by Claude.*.

Public-facing writing

• Public documentation, pull request text, release notes, changelogs, issue text, and user-facing messages must contain only information useful to their intended audience: product behavior, relevant context, decisions, instructions, limitations, and verification evidence.
• Do not publish agent inner monologue, reasoning traces, workflow narration, self-justification, conversational asides, or explanations of why the agent chose particular wording, labels, version numbers, or routine process steps unless that rationale is itself necessary for the audience to act correctly.

Merge and release gates

• Do not merge PRs, tag releases, publish packages, or perform irreversible release actions while a user-stated validation gate is pending.
• If the user has said they want to test, review, or verify something first, stop after preparatory work and report that the gate is still pending.
• Never merge to main unless a human explicitly directs that exact action.
• Never bump MCP server or plugin version numbers unless a human explicitly directs that exact action.
• Apply release:none to pull requests limited to repository policy, contributor guidance, or other changes that do not alter published package, plugin, server, corpus, or distribution artifacts. Do not use it for changes that affect shipped artifacts.
• Squash merging is the default for ordinary PRs.
• Merge commits are allowed for explicitly stacked PRs. A stacked PR must name its parent PR or branch in the PR description, using a line such as Stacked on: #123 or Stacked on: branch-name.
• Use a merge commit for a stacked PR when landing it with squash would force dependent branches to be restacked. For GitHub CLI merges, use gh pr merge <number> --merge.
• Do not squash a PR that has dependent open PRs unless the stack owner has already restacked them or explicitly asks for the squash.
• Unless a PR is explicitly marked as stacked, or the user requests a different allowed strategy, use gh pr merge <number> --squash.
• Do not manually delete branches unless asked.