feat: add additional-context-priority component

AGENTS.md

@@ -70,6 +70,7 @@ packages/opencode/.opencode/ # Generated OpenCode output for review
 - Do not restate `command_expansion` or `task` mechanics inside command docs; navigator owns that execution flow
 - When a command can pause for approval or loop over repeated work, describe the resume condition and the exact cases that must STOP without mutating state
 - Use `## Additional Context` for instructions about how optional guidance, related tickets, focus areas, or other stored context should influence analysis and response formatting
+- When a command uses `<additional-context>`, say explicitly that it overrides conflicting built-in command guidance unless higher-priority safety or instruction layers forbid it
 - Use `### Output` as the final workflow step to define the exact user-facing response shape, including placeholders for generated values
 - Make success, blocked, no-op, waiting, and resume-required outcomes explicit in `### Output` or the surrounding workflow so navigator-led flows report deterministic end states
 - For terminal command outcomes, prefer an explicit final line inside the output block: `No additional steps are required.`

kompass.jsonc

@@ -51,6 +51,7 @@
   },
 
   "components": {
+    "additional-context-priority": { "enabled": true },
     "align-pr-branch": { "enabled": true },
     "change-summary": { "enabled": true },
     "changes-summary": { "enabled": true },

kompass.schema.json

@@ -215,6 +215,9 @@
       "type": "object",
       "additionalProperties": false,
       "properties": {
+        "additional-context-priority": {
+          "$ref": "#/$defs/componentConfig"
+        },
         "align-pr-branch": {
           "$ref": "#/$defs/componentConfig"
         },
@@ -246,15 +249,15 @@
           "type": "array",
           "items": {
             "type": "string",
-            "enum": ["align-pr-branch", "change-summary", "changes-summary", "commit", "dev-flow", "load-pr", "load-ticket", "skill-authoring", "summarize-changes"]
+            "enum": ["additional-context-priority", "align-pr-branch", "change-summary", "changes-summary", "commit", "dev-flow", "load-pr", "load-ticket", "skill-authoring", "summarize-changes"]
           },
           "uniqueItems": true,
           "deprecated": true
         },
         "paths": {
           "type": "object",
           "propertyNames": {
-            "enum": ["align-pr-branch", "change-summary", "changes-summary", "commit", "dev-flow", "load-pr", "load-ticket", "skill-authoring", "summarize-changes"]
+            "enum": ["additional-context-priority", "align-pr-branch", "change-summary", "changes-summary", "commit", "dev-flow", "load-pr", "load-ticket", "skill-authoring", "summarize-changes"]
           },
           "additionalProperties": {
             "type": "string"

packages/core/commands/ask.md

@@ -5,6 +5,7 @@ Answer a question about the current project or codebase using the repository and
 ## Additional Context
 
 - Use `<additional-context>` to prioritize the most relevant files, subsystems, or concerns
+<%~ include("@additional-context-priority") %>
 - Ask only when the question cannot be determined from `<arguments>` and the conversation
 
 ## Workflow

packages/core/commands/commit-and-push.md

@@ -5,6 +5,7 @@ Create a commit and immediately push it to the remote repository.
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the commit message.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/commit.md

@@ -5,6 +5,7 @@ Create a commit with an appropriate message summarizing the uncommitted changes.
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the commit message.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/dev.md

@@ -5,6 +5,7 @@ Implement a feature or fix based on a ticket or request, then prepare for PR cre
 ## Additional Context
 
 Use `<additional-context>` to refine priorities, scope, and tradeoffs while implementing `<request-context>`.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/learn.md

@@ -8,6 +8,7 @@ Extract non-obvious learnings from this session and document them appropriately.
 - Skip obvious facts, standard behavior, and already-documented items
 - Avoid verbose explanations and session-specific details
 - Use `<focus-scope>` and `<additional-context>` to decide where to look more closely
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/merge.md

@@ -5,6 +5,7 @@ Merge a provided branch into the current branch, defaulting to the repo base bra
 ## Additional Context
 
 Consider `<additional-context>` when choosing between competing conflict resolutions.
+<%~ include("@additional-context-priority") %>
 - Default to preserving both sides when the intent is clear and the merged result remains coherent.
 - When a confident manual merge is not obvious, prefer the incoming `<merge-source>` version to keep the command moving.
 - Do not create a merge commit if any conflicts remain unresolved.

packages/core/commands/pr/create.md

@@ -5,6 +5,7 @@ Create a pull request for the current branch, handling the entire workflow from
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the PR description.
+<%~ include("@additional-context-priority") %>
 - Always include the `Ticket`, `Description`, and `Checklist` sections in that order.
 - Use the literal `SKIPPED` when ticket mention was skipped.
 - Keep the description focused on intent, not implementation details.

packages/core/commands/pr/fix.md

@@ -5,6 +5,7 @@ Address feedback on a pull request by making fixes and responding to review thre
 ## Additional Context
 
 Use `<additional-context>` when prioritizing which review feedback to address first and when deciding how much scope to take on in this pass.
+<%~ include("@additional-context-priority") %>
 - Default `/pr/fix` behavior is review-first: show the proposed fix, gather feedback, and loop until the user approves before committing, pushing, or replying on the PR.
 - Treat `/pr/fix auto` as the explicit opt-in to skip the approval loop and proceed directly from passing validation to commit, push, and PR replies.
 

packages/core/commands/pr/review.md

@@ -5,6 +5,7 @@ Review a GitHub pull request and publish findings as a formal review with inline
 ## Additional Context
 
 Use `<ticket-context>` and `<additional-context>` to judge whether the PR meets its stated intent without over-indexing on stylistic preferences.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/review.md

@@ -5,6 +5,7 @@ Review code changes and provide actionable feedback with a grade and risk assess
 ## Additional Context
 
 Use `<additional-context>` to prioritize specific risks, feature areas, or related concerns while reviewing `<changes>`.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/rmslop.md

@@ -5,6 +5,7 @@ Remove AI-generated code slop and inconsistencies from the branch changes.
 ## Additional Context
 
 Use `<additional-context>` to decide which kinds of slop to prioritize and which areas should remain untouched.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/ship.md

@@ -5,6 +5,7 @@ Ship the current work by dispatching branch creation, commit creation, and PR cr
 ## Additional Context
 
 Use `<branch-context>` to steer delegated branch naming. Use `<additional-context>` to refine the delegated commit and PR summaries. Pass `<base>` through to PR creation when it was provided.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/skill/create.md

@@ -6,6 +6,7 @@ Create a new Agent Skill from project context and user direction, producing a fo
 
 - Favor creation over revision: create the smallest correct first version of the skill from the gathered context
 - Only add support files during creation when they clearly improve execution on day one
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/skill/optimize.md

@@ -6,6 +6,7 @@ Improve an existing Agent Skill so it triggers more reliably, stays lean, and pr
 
 - Favor targeted iteration over full rewrites; keep what already works and change only the parts blocking activation or execution quality
 - Prefer optimization grounded in real prompts, evals, reviewer feedback, transcripts, or repeated failures over speculative cleanup
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/ticket/ask.md

@@ -5,6 +5,7 @@ Load a ticket and its discussion, answer the user's question, and post that answ
 ## Additional Context
 
 - Use `<additional-context>` to shape tone, depth, and focus for `<ticket-answer>`
+<%~ include("@additional-context-priority") %>
 - Keep the posted answer grounded in the actual ticket discussion; do not invent missing facts
 - Ask only when the ticket source or question cannot be determined reliably
 

packages/core/commands/ticket/create.md

@@ -5,6 +5,7 @@ Create a ticket that summarizes the work returned by the current change comparis
 ## Additional Context
 
 Consider `<additional-context>` when analyzing the work and writing the ticket title and body.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/ticket/dev.md

@@ -5,6 +5,7 @@ Implement a ticket by orchestrating development, branching, commit-and-push, and
 ## Additional Context
 
 Use `<additional-context>` to refine scope, sequencing, and tradeoffs across the delegated `/dev`, `/branch`, `/commit-and-push`, and `/pr/create` steps.
+<%~ include("@additional-context-priority") %>
 
 ## Workflow
 

packages/core/commands/ticket/plan-and-sync.md

@@ -8,6 +8,7 @@ Create a scoped implementation plan from a request or ticket, then capture that
 - Use the current request to determine `<planning-objective>`.
 - Earlier comments remain in force when they add operative constraints, business rules, technical decisions, migration rules, exact labels or renames, ordering rules, or scoping rules.
 - Use `<additional-context>` to emphasize the most important constraints, dependencies, or focus areas.
+<%~ include("@additional-context-priority") %>
 - For technical tickets, repo inspection is expected unless the request is clearly non-technical or repository context is unavailable.
 - If technical details provided in the conversation are good, keep them.
 - If those details are incomplete, validate and improve them.

packages/core/commands/ticket/plan.md

@@ -8,6 +8,7 @@ Create a scoped implementation plan from a request or ticket and present it dire
 - Use the current request to determine `<planning-objective>`.
 - Earlier comments remain in force when they add operative constraints, business rules, technical decisions, migration rules, exact labels or renames, ordering rules, or scoping rules.
 - Use `<additional-context>` to emphasize the most important constraints, dependencies, or focus areas.
+<%~ include("@additional-context-priority") %>
 - For technical tickets, repo inspection is expected unless the request is clearly non-technical or repository context is unavailable.
 - If technical details provided in the conversation are good, keep them.
 - If those details are incomplete, validate and improve them.

packages/core/commands/todo.md

@@ -8,6 +8,7 @@ Work through a todo file one pending item at a time by planning, getting approva
 - Do not merge separate todo items unless the file explicitly frames them as one task
 - If implementation reveals scope that materially changes the approved plan, pause and re-plan before marking the task complete
 - Use `<additional-context>` to prioritize tradeoffs, constraints, or validation expectations during planning and implementation
+<%~ include("@additional-context-priority") %>
 - Delegate planner and worker steps through literal `<delegate>` blocks and use the delegated results as the source of truth for planning, implementation, and commit steps.
 
 ## Workflow

packages/core/components/additional-context-priority.md

@@ -0,0 +1,2 @@
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.

packages/core/kompass.jsonc

@@ -51,6 +51,7 @@
   },
 
   "components": {
+    "additional-context-priority": { "enabled": true },
     "align-pr-branch": { "enabled": true },
     "change-summary": { "enabled": true },
     "changes-summary": { "enabled": true },

packages/core/lib/config.ts

@@ -48,6 +48,7 @@ export const DEFAULT_COMMAND_NAMES = [
 export const DEFAULT_AGENT_NAMES = ["worker", "navigator", "planner", "reviewer"] as const;
 
 export const DEFAULT_COMPONENT_NAMES = [
+  "additional-context-priority",
   "align-pr-branch",
   "change-summary",
   "changes-summary",
@@ -130,6 +131,7 @@ export interface KompassConfig {
     ticket_load?: ToolConfig;
   };
   components?: {
+    "additional-context-priority"?: ComponentConfig;
     "align-pr-branch"?: ComponentConfig;
     "change-summary"?: ComponentConfig;
     "changes-summary"?: ComponentConfig;
@@ -445,6 +447,7 @@ const defaultAgentPlanner: AgentDefinition = {
 };
 
 const defaultComponentPaths: Record<string, string> = {
+  "additional-context-priority": "components/additional-context-priority.md",
   "align-pr-branch": "components/align-pr-branch.md",
   "change-summary": "components/change-summary.md",
   "changes-summary": "components/changes-summary.md",

packages/opencode/.opencode/commands/ask.md

@@ -10,6 +10,8 @@ Answer a question about the current project or codebase using the repository and
 ## Additional Context
 
 - Use `<additional-context>` to prioritize the most relevant files, subsystems, or concerns
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 - Ask only when the question cannot be determined from `<arguments>` and the conversation
 
 ## Workflow

packages/opencode/.opencode/commands/commit-and-push.md

@@ -10,6 +10,8 @@ Create a commit and immediately push it to the remote repository.
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the commit message.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/commit.md

@@ -10,6 +10,8 @@ Create a commit with an appropriate message summarizing the uncommitted changes.
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the commit message.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/dev.md

@@ -10,6 +10,8 @@ Implement a feature or fix based on a ticket or request, then prepare for PR cre
 ## Additional Context
 
 Use `<additional-context>` to refine priorities, scope, and tradeoffs while implementing `<request-context>`.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/learn.md

@@ -13,6 +13,8 @@ Extract non-obvious learnings from this session and document them appropriately.
 - Skip obvious facts, standard behavior, and already-documented items
 - Avoid verbose explanations and session-specific details
 - Use `<focus-scope>` and `<additional-context>` to decide where to look more closely
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/merge.md

@@ -10,6 +10,8 @@ Merge a provided branch into the current branch, defaulting to the repo base bra
 ## Additional Context
 
 Consider `<additional-context>` when choosing between competing conflict resolutions.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 - Default to preserving both sides when the intent is clear and the merged result remains coherent.
 - When a confident manual merge is not obvious, prefer the incoming `<merge-source>` version to keep the command moving.
 - Do not create a merge commit if any conflicts remain unresolved.

packages/opencode/.opencode/commands/pr/create.md

@@ -10,6 +10,8 @@ Create a pull request for the current branch, handling the entire workflow from
 ## Additional Context
 
 Consider `<additional-context>` when analyzing changes and writing the PR description.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 - Always include the `Ticket`, `Description`, and `Checklist` sections in that order.
 - Use the literal `SKIPPED` when ticket mention was skipped.
 - Keep the description focused on intent, not implementation details.

packages/opencode/.opencode/commands/pr/fix.md

@@ -10,6 +10,8 @@ Address feedback on a pull request by making fixes and responding to review thre
 ## Additional Context
 
 Use `<additional-context>` when prioritizing which review feedback to address first and when deciding how much scope to take on in this pass.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 - Default `/pr/fix` behavior is review-first: show the proposed fix, gather feedback, and loop until the user approves before committing, pushing, or replying on the PR.
 - Treat `/pr/fix auto` as the explicit opt-in to skip the approval loop and proceed directly from passing validation to commit, push, and PR replies.
 

packages/opencode/.opencode/commands/pr/review.md

@@ -10,6 +10,8 @@ Review a GitHub pull request and publish findings as a formal review with inline
 ## Additional Context
 
 Use `<ticket-context>` and `<additional-context>` to judge whether the PR meets its stated intent without over-indexing on stylistic preferences.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/review.md

@@ -10,6 +10,8 @@ Review code changes and provide actionable feedback with a grade and risk assess
 ## Additional Context
 
 Use `<additional-context>` to prioritize specific risks, feature areas, or related concerns while reviewing `<changes>`.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow
 

packages/opencode/.opencode/commands/rmslop.md

@@ -10,6 +10,8 @@ Remove AI-generated code slop and inconsistencies from the branch changes.
 ## Additional Context
 
 Use `<additional-context>` to decide which kinds of slop to prioritize and which areas should remain untouched.
+- When `<additional-context>` conflicts with the command's built-in guidance, treat `<additional-context>` as the higher-priority user instruction unless that would violate system, developer, repository, or tool safety rules.
+- Use the built-in command guidance only to fill gaps that `<additional-context>` does not override.
 
 ## Workflow