diff --git a/packages/core/agents/reviewer.md b/packages/core/agents/reviewer.md index 50c09c6..eafa384 100644 --- a/packages/core/agents/reviewer.md +++ b/packages/core/agents/reviewer.md @@ -12,6 +12,7 @@ Before reviewing, always check repository guidance: 1. **Load Changes**: Use `changes_load` to get the changed-file set and structured diffs - In CI or shallow clones, pass explicit base and head refs + - For branch comparisons, treat the returned commit list as the authoritative scope: review the commits ahead of base and use file diffs only as supporting context - Scan the summary first to understand scope, file states, and risk clusters - Never switch branches, create local review branches, or otherwise mutate `HEAD`; if a loader fails, prefer reporting the blocker over changing checkout state diff --git a/packages/core/commands/pr/create.md b/packages/core/commands/pr/create.md index 393e44a..2d4d8df 100644 --- a/packages/core/commands/pr/create.md +++ b/packages/core/commands/pr/create.md @@ -35,6 +35,7 @@ $ARGUMENTS - Store the loaded change result as `` - Store the current branch from `` as `` when it is available - Store the effective base branch as `` by preferring `` when it was provided, otherwise using the base branch implied by `.comparison` +- When `.comparison` is not `uncommitted`, describe the PR from the commits ahead of ``, not from the raw branch comparison string by itself ### Check Blockers @@ -123,6 +124,7 @@ Use `pr_sync` to create the pull request: - `## Checklist`, followed by the checklist items and any subsection headings - Use `` as the base branch when it is defined - Do NOT restate the full diff +- Do NOT rely on the branch diff alone to describe the PR; the description must match the commits ahead of `` - Keep it compact and directional - Store the returned URL as `` - If `pr_sync` reports that a PR already exists for the branch, treat the result as an existing PR diff --git a/packages/core/commands/review.md b/packages/core/commands/review.md index 046e9a4..96b1403 100644 --- a/packages/core/commands/review.md +++ b/packages/core/commands/review.md @@ -35,7 +35,7 @@ If `.comparison` is "uncommitted": - Store `uncommitted changes` as `` If `.comparison` is not "uncommitted": -- Treat as reviewing branch changes +- Treat as reviewing the commits ahead of base plus their resulting file diffs - If `` is defined and `` is available, store ` -> ` as `` - Otherwise, store `.comparison` as `` diff --git a/packages/core/commands/ticket/create.md b/packages/core/commands/ticket/create.md index 5eecb4c..f2f59b7 100644 --- a/packages/core/commands/ticket/create.md +++ b/packages/core/commands/ticket/create.md @@ -25,6 +25,7 @@ $ARGUMENTS <%~ include("@change-summary", { rules: "- If `` is defined: call `changes_load` with the `base` parameter set to ``\n- Otherwise: call `changes_load` with no parameters" }) %> - Store the loaded change result as `` +- When `.comparison` is not `uncommitted`, describe the ticket from the commits ahead of the resolved base branch, not from branch names alone ### Check Blockers diff --git a/packages/core/components/change-summary.md b/packages/core/components/change-summary.md index c826b39..852430b 100644 --- a/packages/core/components/change-summary.md +++ b/packages/core/components/change-summary.md @@ -3,12 +3,15 @@ <%= it.rules ?? "" %> - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") diff --git a/packages/core/components/changes-summary.md b/packages/core/components/changes-summary.md index db60885..1313bb3 100644 --- a/packages/core/components/changes-summary.md +++ b/packages/core/components/changes-summary.md @@ -1,4 +1,5 @@ - Reuse the same change themes, rationale, and reviewer-facing validation goals from the current summary work +- For branch comparisons, ensure every theme is supported by commits in `.commits`; use file diffs only as supporting context - Generate a concise title (max 70 chars) that reflects the delivered outcome - Generate a `description` that briefly describes what was accomplished and why it matters - Generate checklists with: diff --git a/packages/core/components/summarize-changes.md b/packages/core/components/summarize-changes.md index fc0cbb9..3226f56 100644 --- a/packages/core/components/summarize-changes.md +++ b/packages/core/components/summarize-changes.md @@ -1,6 +1,8 @@ ### Summarize Changes - Note the comparison mode, base branch, and current branch from the result +- If the comparison is not `uncommitted`, use only the commits in `.commits` as the branch-work scope - Review commit messages when they are available to understand the delivery narrative -- Read the most relevant changed source files to understand the changes +- Read the most relevant changed source files to understand the changes introduced by those commits +- Do not describe work that exists only on the base branch or that is outside the commits ahead of base - Group related changes into themes for the final summary diff --git a/packages/opencode/.opencode/agents/reviewer.md b/packages/opencode/.opencode/agents/reviewer.md index 2955d8b..76786b4 100644 --- a/packages/opencode/.opencode/agents/reviewer.md +++ b/packages/opencode/.opencode/agents/reviewer.md @@ -20,6 +20,7 @@ Before reviewing, always check repository guidance: 1. **Load Changes**: Use `kompass_changes_load` to get the changed-file set and structured diffs - In CI or shallow clones, pass explicit base and head refs + - For branch comparisons, treat the returned commit list as the authoritative scope: review the commits ahead of base and use file diffs only as supporting context - Scan the summary first to understand scope, file states, and risk clusters - Never switch branches, create local review branches, or otherwise mutate `HEAD`; if a loader fails, prefer reporting the blocker over changing checkout state diff --git a/packages/opencode/.opencode/commands/branch.md b/packages/opencode/.opencode/commands/branch.md index 9d4b7ac..38d5921 100644 --- a/packages/opencode/.opencode/commands/branch.md +++ b/packages/opencode/.opencode/commands/branch.md @@ -31,13 +31,16 @@ $ARGUMENTS - pass `uncommitted: true` to get uncommitted changes only - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") - Store the loaded change result as `` diff --git a/packages/opencode/.opencode/commands/commit-and-push.md b/packages/opencode/.opencode/commands/commit-and-push.md index 5d28ef8..b451bd2 100644 --- a/packages/opencode/.opencode/commands/commit-and-push.md +++ b/packages/opencode/.opencode/commands/commit-and-push.md @@ -31,13 +31,16 @@ $ARGUMENTS - pass `uncommitted: true` to get uncommitted changes only - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") - Store the loaded change result as `` diff --git a/packages/opencode/.opencode/commands/commit.md b/packages/opencode/.opencode/commands/commit.md index 5b3e49e..5db8e1d 100644 --- a/packages/opencode/.opencode/commands/commit.md +++ b/packages/opencode/.opencode/commands/commit.md @@ -31,13 +31,16 @@ $ARGUMENTS - pass `uncommitted: true` to get uncommitted changes only - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") - Store the loaded change result as `` diff --git a/packages/opencode/.opencode/commands/pr/create.md b/packages/opencode/.opencode/commands/pr/create.md index 22d5964..1764e4d 100644 --- a/packages/opencode/.opencode/commands/pr/create.md +++ b/packages/opencode/.opencode/commands/pr/create.md @@ -42,19 +42,23 @@ $ARGUMENTS - Never pass `uncommitted: true` in this command - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") - Store the loaded change result as `` - Store the current branch from `` as `` when it is available - Store the effective base branch as `` by preferring `` when it was provided, otherwise using the base branch implied by `.comparison` +- When `.comparison` is not `uncommitted`, describe the PR from the commits ahead of ``, not from the raw branch comparison string by itself ### Check Blockers @@ -74,8 +78,10 @@ $ARGUMENTS ### Summarize Changes - Note the comparison mode, base branch, and current branch from the result +- If the comparison is not `uncommitted`, use only the commits in `.commits` as the branch-work scope - Review commit messages when they are available to understand the delivery narrative -- Read the most relevant changed source files to understand the changes +- Read the most relevant changed source files to understand the changes introduced by those commits +- Do not describe work that exists only on the base branch or that is outside the commits ahead of base - Group related changes into themes for the final summary ### Resolve Ticket @@ -109,6 +115,7 @@ $ARGUMENTS When `` is `auto`, create the ticket before creating the PR: - Reuse the same change themes, rationale, and reviewer-facing validation goals from the current summary work +- For branch comparisons, ensure every theme is supported by commits in `.commits`; use file diffs only as supporting context - Generate a concise title (max 70 chars) that reflects the delivered outcome - Generate a `description` that briefly describes what was accomplished and why it matters - Generate checklists with: @@ -159,6 +166,7 @@ Use `kompass_pr_sync` to create the pull request: - `## Checklist`, followed by the checklist items and any subsection headings - Use `` as the base branch when it is defined - Do NOT restate the full diff +- Do NOT rely on the branch diff alone to describe the PR; the description must match the commits ahead of `` - Keep it compact and directional - Store the returned URL as `` - If `kompass_pr_sync` reports that a PR already exists for the branch, treat the result as an existing PR diff --git a/packages/opencode/.opencode/commands/review.md b/packages/opencode/.opencode/commands/review.md index 812e49c..35032eb 100644 --- a/packages/opencode/.opencode/commands/review.md +++ b/packages/opencode/.opencode/commands/review.md @@ -40,7 +40,7 @@ If `.comparison` is "uncommitted": - Store `uncommitted changes` as `` If `.comparison` is not "uncommitted": -- Treat as reviewing branch changes +- Treat as reviewing the commits ahead of base plus their resulting file diffs - If `` is defined and `` is available, store ` -> ` as `` - Otherwise, store `.comparison` as `` diff --git a/packages/opencode/.opencode/commands/ticket/create.md b/packages/opencode/.opencode/commands/ticket/create.md index ea27423..b663ffd 100644 --- a/packages/opencode/.opencode/commands/ticket/create.md +++ b/packages/opencode/.opencode/commands/ticket/create.md @@ -33,17 +33,21 @@ $ARGUMENTS - Otherwise: call `kompass_changes_load` with no parameters - Store the returned result as `` - Use `` as the source of truth; no additional git analysis commands are needed +- When `.comparison` is not `uncommitted`, treat `.commits` as the authoritative scope of work: only summarize commits that are ahead of the resolved base branch +- Do not infer scope from the branch names alone and do not describe work that exists only on the base branch #### Step 2: Analyze Files -- Review the paths, statuses, and diffs from `` +- Review the paths, statuses, and diffs from `` only as file-level context for the commits in scope - Identify the nature of changes (added, modified, deleted) - Note lines added/removed per file #### Step 3: Group and Summarize +- For branch comparisons, build the summary from `.commits` first and use file diffs only to verify or refine what those commits changed - Group related changes into logical themes - Summarize the "what" and "why" (not the "how") - Store the loaded change result as `` +- When `.comparison` is not `uncommitted`, describe the ticket from the commits ahead of the resolved base branch, not from branch names alone ### Check Blockers @@ -52,14 +56,17 @@ $ARGUMENTS ### Summarize Changes - Note the comparison mode, base branch, and current branch from the result +- If the comparison is not `uncommitted`, use only the commits in `.commits` as the branch-work scope - Review commit messages when they are available to understand the delivery narrative -- Read the most relevant changed source files to understand the changes +- Read the most relevant changed source files to understand the changes introduced by those commits +- Do not describe work that exists only on the base branch or that is outside the commits ahead of base - Group related changes into themes for the final summary ### Create Ticket Use `kompass_ticket_sync` with `refUrl` unset to create the ticket: - Reuse the same change themes, rationale, and reviewer-facing validation goals from the current summary work +- For branch comparisons, ensure every theme is supported by commits in `.commits`; use file diffs only as supporting context - Generate a concise title (max 70 chars) that reflects the delivered outcome - Generate a `description` that briefly describes what was accomplished and why it matters - Generate checklists with: