Quick Ref / Command

Engineer Kit

/ak:sowat

Product Impact Priority Call

Reviews recent implementation and related issues like a product owner, turning evidence into a concise so-what judgment, priority correction, and at most three next steps.

01

Establish outcome

02

Connect only related work

03

Score candidates

04

Cut busywork

Rule 01

Outcome beats activity

Rule 02

Evidence beats contrarian performance

Rule 03

Recommend fewer, higher-impact next steps

Rule 04

Separate fact from inference and name missing evidence

Execution Map

Core lanes from input to output, aligned with the command's real execution path.

01

Start

Input, scope, route

  1. 1 Establish outcome Identify the intended user or business outcome and the strongest evidence of what was implemented, verified, shipped, and still open.
  2. 2 Connect only related work Bring in genuinely connected issues, blockers, regressions, dependencies, adoption risks, and follow-on opportunities.
02

Work

Agent / skill execution

  1. 3 Score candidates Judge actions by impact, urgency, confidence, effort, risk, dependency leverage, and learning or delivery value.
  2. 4 Cut busywork Deprioritize polish, internal elegance, or activity that does not change the user outcome.
03

Verify

Gate, review, validation

  1. 5 Correct priority If evidence supports it, state what the current focus gets wrong and what deserves attention instead.
  2. 6 Recommend next steps Return no more than three ordered actions, each with why now and an observable success signal.

Syntax, arguments, subcommands

How to invoke the skill: syntax, positional arguments, shared options, then each subcommand with its own syntax and outcome.

Syntax

/ak:sowat [recent-changes|issue|PR]

Arguments

[recent-changes|issue|PR]

Evidence focus

Optional focus for the product-owner read: recent implemented changes, one related issue, or a pull request. Omit it to let the skill pick the strongest nearby evidence. The token only scopes analysis; it does not authorize code or issue mutations.

/ak:sowat recent-changes

Subcommands

recent-changes Recent changes
/ak:sowat recent-changes

Read recently implemented work as the primary evidence, then connect only related issues, regressions, and adoption blockers.

Outcome: A so-what judgment of the recent implementation, optional priority correction, and at most three next steps with success signals.

/ak:sowat recent-changes
issue Related issue
/ak:sowat issue

Start from one related issue, blocker, or opportunity and judge whether it outranks the current focus.

Outcome: Issue-scoped impact judgment with a priority correction only when evidence shows a concrete trade-off.

/ak:sowat issue
PR Pull request
/ak:sowat PR

Use a pull request as the implemented-work evidence boundary, then score related follow-ons without mutating the PR.

Outcome: PR-bounded so-what, optional focus correction, and at most three ordered actions with observable success signals.

/ak:sowat PR

Sample Prompt

Concrete invocations for each flag, subcommand, mode, or route available in the live workflow.

Default priority call Recommended
/ak:sowat
Use when:
After implementation, when you need the product meaning of nearby work and what matters next.
Expected:
Picks the strongest nearby evidence of implemented, verified, shipped, and still-open work, then returns a brief so-what judgment with at most three ordered next steps and observable success signals.
Recent changes
/ak:sowat recent-changes
Use when:
The latest implementation should be the evidence boundary for the priority call.
Expected:
Treats recently implemented work as the primary evidence, connects only related issues or blockers, and deprioritizes polish that does not change the user outcome.
Related issue
/ak:sowat issue
Use when:
One related issue, blocker, or follow-on may deserve attention over the current focus.
Expected:
Starts from the related issue, scores impact versus the current focus, and corrects priority only when evidence shows a concrete trade-off.
Pull request evidence
/ak:sowat PR
Use when:
A pull request is the implemented-work evidence and you need the product so-what without mutating it.
Expected:
Uses the pull request as the evidence boundary, separates fact from inference, and returns at most three actions with why-now rationale and success signals.

Handled Scope

  • product impact
  • priority correction
  • issue triage
  • outcome framing
  • success signals

Next