docs: standardize command docs around workflow output

AGENTS.md

@@ -53,7 +53,8 @@ packages/opencode/.opencode/ # Generated OpenCode output for review
 - Author command definitions in `packages/core/commands/`; treat `packages/opencode/.opencode/commands/` as generated output only
 - Treat `packages/core/commands/index.ts`, `packages/core/lib/config.ts`, `kompass.schema.json`, the bundled `kompass.jsonc` files, and the relevant docs as a linked surface area; if one changes, verify the others still describe the same command set and config shape
 - Use `packages/core/commands/pr/create.md` as the canonical example for command structure and tone
-- Keep this section order in command docs unless a command has a strong reason not to: `## Goal`, `## Workflow`, `## Additional Context`, `## Output`
+- Keep this section order in command docs unless a command has a strong reason not to: `## Goal`, `## Additional Context`, `## Workflow`
+- Keep `### Output` as the final subsection inside `## Workflow`; do not use a separate top-level `## Output` section
 - Start `## Workflow` with a dedicated `### Arguments` subsection that stores the raw `$ARGUMENTS` value inside literal `<arguments>` tags before any normalization
 - Follow `### Arguments` with `### Interpret Arguments`, and normalize `<arguments>` into any additional named placeholders before execution steps
 - Use angle-bracket placeholders consistently for derived values and stored context, such as `<arguments>`, `<base>`, `<additional-context>`, `<pr-url>`, and define each placeholder before it is referenced later in the command
@@ -66,9 +67,9 @@ packages/opencode/.opencode/ # Generated OpenCode output for review
 - Use literal `<dispatch>` tags when the workflow must forward exact text as the next user message to a subagent session; `agent` is required, the block body is the exact rendered message to send, and slash commands belong on the first line of the body when needed
 - Do not use `<task>` blocks in command docs; author navigator delegation with `<dispatch>` blocks only
 - 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 output
-- Use `## Output` to define the exact user-facing response shape, including placeholders for generated values
-- Make success, blocked, and no-op outcomes explicit in `## Output` or the surrounding workflow so navigator-led flows report deterministic end states
+- Use `## Additional Context` for instructions about how optional guidance, related tickets, focus areas, or other stored context should influence analysis and response formatting
+- Use `### Output` as the final workflow step to define the exact user-facing response shape, including placeholders for generated values
+- Make success, blocked, and no-op 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.`
 - For one-off commands that do not orchestrate follow-up work, make every success, blocked, or no-op output explicitly terminal with that final line
 - Command-specific extra sections are fine, but they should support this core structure rather than replace it
@@ -80,6 +81,10 @@ Example command structure:
 
 Describe the command's purpose in one short paragraph.
 
+## Additional Context
+
+- Explain how optional guidance should influence planning or execution
+
 ## Workflow
 
 ### Arguments
@@ -122,11 +127,7 @@ Constraints: <additional-context>
 
 - STOP if implementation is blocked or incomplete
 
-## Additional Context
-
-- Explain how optional guidance should influence planning or execution
-
-## Output
+### Output
 
 - Define the exact success, blocked, and no-op response shapes
 - For terminal outcomes, end the output block with `No additional steps are required.`

packages/core/commands/ask.md

@@ -2,6 +2,11 @@
 
 Answer a question about the current project or codebase using the repository and available context.
 
+## Additional Context
+
+- Use `<additional-context>` to prioritize the most relevant files, subsystems, or concerns
+- Ask only when the question cannot be determined from `<arguments>` and the conversation
+
 ## Workflow
 
 ### Arguments
@@ -29,12 +34,7 @@ $ARGUMENTS
 - Include file references when they materially help the answer
 - Keep the response concise unless the question requires more detail
 
-## Additional Context
-
-- Use `<additional-context>` to prioritize the most relevant files, subsystems, or concerns
-- Ask only when the question cannot be determined from `<arguments>` and the conversation
-
-## Output
+### Output
 
 If the question cannot be determined, display:
 ```

packages/core/commands/branch.md

@@ -2,6 +2,10 @@
 
 Create and switch to a categorized branch whose name summarizes the current uncommitted work.
 
+## Additional Context
+
+Use `<branch-context>` to steer the branch category and slug while keeping the final name short, descriptive, and aligned with the change type.
+
 ## Workflow
 
 ### Arguments
@@ -36,11 +40,7 @@ $ARGUMENTS
 - If that name already exists, retry once with a short numeric suffix
 - Store the checked-out branch as `<new-branch>`
 
-## Additional Context
-
-Use `<branch-context>` to steer the branch category and slug while keeping the final name short, descriptive, and aligned with the change type.
-
-## Output
+### Output
 
 If there is nothing to branch from, display:
 ```

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

@@ -2,6 +2,10 @@
 
 Create a commit and immediately push it to the remote repository.
 
+## Additional Context
+
+Consider `<additional-context>` when analyzing changes and writing the commit message.
+
 ## Workflow
 
 ### Arguments
@@ -36,11 +40,7 @@ $ARGUMENTS
 - Store the successful destination as `<push-target>`
 - If push fails, STOP and report the push error
 
-## Additional Context
-
-Consider `<additional-context>` when analyzing changes and writing the commit message.
-
-## Output
+### Output
 
 If there is nothing to commit, display:
 ```

packages/core/commands/commit.md

@@ -2,6 +2,10 @@
 
 Create a commit with an appropriate message summarizing the uncommitted changes.
 
+## Additional Context
+
+Consider `<additional-context>` when analyzing changes and writing the commit message.
+
 ## Workflow
 
 ### Arguments
@@ -29,11 +33,7 @@ $ARGUMENTS
 <%~ include("@commit") %>
 - Store the created commit hash as `<hash>`
 
-## Additional Context
-
-Consider `<additional-context>` when analyzing changes and writing the commit message.
-
-## Output
+### Output
 
 If there is nothing to commit, display:
 ```

packages/core/commands/dev.md

@@ -2,6 +2,10 @@
 
 Implement a feature or fix based on a ticket or request, then prepare for PR creation.
 
+## Additional Context
+
+Use `<additional-context>` to refine priorities, scope, and tradeoffs while implementing `<request-context>`.
+
 ## Workflow
 
 ### Arguments
@@ -46,11 +50,7 @@ $ARGUMENTS
 - Store the current branch name as `<branch>`
 - Do not create the pull request in this command; stop when the branch is ready for `pr/create`
 
-## Additional Context
-
-Use `<additional-context>` to refine priorities, scope, and tradeoffs while implementing `<request-context>`.
-
-## Output
+### Output
 
 When the implementation is ready for PR creation, display:
 ```

packages/core/commands/learn.md

@@ -2,6 +2,13 @@
 
 Extract non-obvious learnings from this session and document them appropriately.
 
+## Additional Context
+
+- Document non-obvious discoveries only
+- 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
+
 ## Workflow
 
 ### Arguments
@@ -57,14 +64,7 @@ $ARGUMENTS
 - Report which files were created or updated and how many learnings were added to each
 - Store those summary lines as `<file-update-lines>` in the format `- <file-path>: <learning-count> learnings`
 
-## Additional Context
-
-- Document non-obvious discoveries only
-- 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
-
-## Output
+### Output
 
 When the documentation update is complete, display:
 ```

packages/core/commands/pr/create.md

@@ -2,6 +2,15 @@
 
 Create a pull request for the current branch, handling the entire workflow from change detection to PR submission.
 
+## Additional Context
+
+Consider `<additional-context>` when analyzing changes and writing the PR description.
+- 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.
+- Mark checklist validation items as completed if validation was performed.
+- Uncommitted changes and being on the base branch block PR creation entirely.
+
 ## Workflow
 
 ### Arguments
@@ -117,16 +126,7 @@ Use `pr_sync` to create the pull request:
 - If `pr_sync` reports that a PR already exists for the branch, treat the result as an existing PR
 - Track whether the branch was pushed during this run and report that status in the final response
 
-## Additional Context
-
-Consider `<additional-context>` when analyzing changes and writing the PR description.
-- 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.
-- Mark checklist validation items as completed if validation was performed.
-- Uncommitted changes and being on the base branch block PR creation entirely.
-
-## Output
+### Output
 
 If PR creation stops because there is nothing to include, display:
 ```

packages/core/commands/pr/fix.md

@@ -2,6 +2,12 @@
 
 Address feedback on a pull request by making fixes and responding to review threads.
 
+## 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.
+- 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.
+
 ## Workflow
 
 ### Arguments
@@ -113,13 +119,7 @@ pr_sync refUrl="<pr-context.pr.url>" commitId="<commit-sha>" review={"comments":
 Confirm which feedback was addressed and which was intentionally not followed.
 - Store the number of resolved threads as `<threads-resolved>`
 
-## 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.
-- 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.
-
-## Output
+### Output
 
 When waiting for approval or revision feedback, display:
 ```

packages/core/commands/pr/review.md

@@ -2,6 +2,10 @@
 
 Review a GitHub pull request and publish findings as a formal review with inline comments.
 
+## Additional Context
+
+Use `<ticket-context>` and `<additional-context>` to judge whether the PR meets its stated intent without over-indexing on stylistic preferences.
+
 ## Workflow
 
 ### Arguments
@@ -95,11 +99,8 @@ For multi-line: add `startLine`. For deleted lines: use `side: "LEFT"`.
 
 If `pr_sync` returns a review URL, store it as `<review-url>`.
 
-## Additional Context
-
-Use `<ticket-context>` and `<additional-context>` to judge whether the PR meets its stated intent without over-indexing on stylistic preferences.
+### Output
 
-## Output
 <% if (it.config.shared.prApprove === true) { -%>
 When approved:
 ```

packages/core/commands/review.md

@@ -2,6 +2,10 @@
 
 Review code changes and provide actionable feedback with a grade and risk assessment.
 
+## Additional Context
+
+Use `<additional-context>` to prioritize specific risks, feature areas, or related concerns while reviewing `<changes>`.
+
 ## Workflow
 
 ### Arguments
@@ -49,11 +53,7 @@ While reading files:
 - For deleted files, inspect prior contents from git because `changes_load` does not provide full deleted-file contents
 - Use a helper agent only if the changed-file set is too large to review comfortably in one session after the changed paths are already known
 
-## Additional Context
-
-Use `<additional-context>` to prioritize specific risks, feature areas, or related concerns while reviewing `<changes>`.
-
-## Output
+### Output
 
 When the review is complete, display:
 ```

packages/core/commands/rmslop.md

@@ -2,6 +2,10 @@
 
 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.
+
 ## Workflow
 
 ### Arguments
@@ -61,11 +65,7 @@ $ARGUMENTS
 - Create a focused commit describing the cleanup
 - Store the created commit hash as `<hash>`
 
-## Additional Context
-
-Use `<additional-context>` to decide which kinds of slop to prioritize and which areas should remain untouched.
-
-## Output
+### Output
 
 If there is no branch work to clean up, display:
 ```

packages/core/commands/ship.md

@@ -2,6 +2,10 @@
 
 Ship the current work by delegating branch creation, commit creation, and PR creation.
 
+## 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.
+
 ## Workflow
 
 ### Arguments
@@ -56,11 +60,7 @@ Additional context: <additional-context>
 - If `<pr-result>` says there is nothing to include in a PR, STOP and report that there is nothing to ship
 - Otherwise, continue with the created or existing PR
 
-## 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.
-
-## Output
+### Output
 
 If there is nothing to ship, display:
 ```

packages/core/commands/ticket/ask.md

@@ -2,6 +2,12 @@
 
 Load a ticket and its discussion, answer the user's question, and post that answer back to the ticket.
 
+## Additional Context
+
+- Use `<additional-context>` to shape tone, depth, and focus for `<ticket-answer>`
+- 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
+
 ## Workflow
 
 ### Arguments
@@ -35,13 +41,7 @@ $ARGUMENTS
   - `comments: [<ticket-answer>]`
 - Store the returned ticket URL as `<ticket-url>`
 
-## Additional Context
-
-- Use `<additional-context>` to shape tone, depth, and focus for `<ticket-answer>`
-- 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
-
-## Output
+### Output
 
 If the ticket context or question cannot be determined, display:
 ```