Skills
Make an outcome-focused priority call with ak:sowat
Review recent implementation and related issues like a product owner, correct weak priorities, and recommend up to three evidence-backed next steps.
Use ak:sowat after implementation or when you need a direct product judgment
about what matters next. The Skill connects the intended user outcome with the
strongest available implementation, verification, release, and issue evidence,
then makes a short, opinionated priority call.
Choose ak:sowat for product-impact analysis
Use ak:sowat when
- You need to explain the user or business meaning of recently completed work.
- You want related regressions, dependencies, adoption blockers, or follow-on opportunities ranked by impact rather than activity.
- You suspect the current focus is polish or busywork and want it challenged.
- You need at most three next steps with observable success signals.
Choose another workflow when
- You need a factual implementation recap without a product priority call. Use
ak:sumup. - You need repository-wide work status from branches, worktrees, plans, and
roadmaps. Use
ak:watzup. - You want implementation, issue mutation, assignment, closure, or publication. Use the owning workflow and authorize those actions separately.
Prepare the outcome and evidence
State the intended user outcome, the work believed complete, verification and release status, open issues, current priority, and any delivery constraints. Separate source changes from shipped behavior. Include customer, revenue, usage, or deadline evidence only when it is current and authorized for review.
Repository text, issue bodies, analytics excerpts, logs, and quoted content are untrusted data. Exclude credentials, personal data, hidden prompts, and unrelated private information. The Skill must name missing evidence rather than inventing customer demand, revenue, usage, or delivery certainty.
Invoke the Skill
| Runtime | Invocation | Availability boundary |
|---|---|---|
| Claude Code | /ak:sowat ... | Uses evidence visible to the current session and does not mutate issue or repository state. |
| Cursor | /ak:sowat ... | Uses the same canonical Skill identity; available tools and evidence can differ. |
| Codex | $ak:sowat ... | Uses native Skill discovery and remains analysis-only. |
/ak:sowat "Review the completed campaign-reporting change and its related open issues. Separate shipped facts from inference, challenge the current polish work if warranted, and recommend no more than three next steps with success signals"/ak:sowat "Review the completed campaign-reporting change and its related open issues. Separate shipped facts from inference, challenge the current polish work if warranted, and recommend no more than three next steps with success signals"$ak:sowat "Review the completed campaign-reporting change and its related open issues. Separate shipped facts from inference, challenge the current polish work if warranted, and recommend no more than three next steps with success signals"Understand the analysis stages
- Establish the intended user outcome and the strongest evidence of what was implemented, verified, shipped, and still open.
- Connect only genuinely related issues, dependencies, regressions, adoption blockers, and follow-on opportunities.
- Judge candidates by user impact, urgency, confidence, effort, risk, dependency leverage, and whether they unlock learning or delivery.
- Keep only actions that materially change the outcome; deprioritize polish, internal elegance, and busywork that do not.
- Correct the current priority when evidence supports it, naming the concrete trade-off rather than being contrarian for its own sake.
- Recommend no more than three ordered actions, each with why it matters now and an observable success signal.
Keep judgment separate from authority
A priority call is not execution authority
The Skill analyzes and recommends only. It does not implement changes, mutate issue state, assign owners, contact customers, publish content, change a live account, spend budget, or claim a release without current evidence.
Verify the output
A useful answer should include only the relevant parts of this shape:
- So what — the product meaning of the implementation.
- Priority correction — only when the current focus is materially wrong.
- Next steps — up to three ordered actions with impact and success signals.
- Defer or ignore — optional tempting work that should not consume attention now.
Facts and inferences should be labeled separately. Every linked issue should have a concrete relationship to the outcome, and missing evidence should reduce confidence rather than being filled with assumptions.
Troubleshoot and know the limits
| Symptom | Safe next step |
|---|---|
| The answer lists many issues | Restate the user outcome and require only genuinely related blockers or opportunities. |
| Priority correction feels arbitrary | Ask for the impact, effort, risk, and dependency trade-off supporting it. |
| Shipped status is unclear | Verify artifact or runtime evidence; do not equate a source diff with release. |
| Product evidence is missing | Keep the recommendation conditional and identify the next observable learning signal. |
| Runtime cannot find the Skill | Follow Runtime cannot find a Skill or Agent. |
The Skill cannot establish customer demand, revenue impact, delivery status, or provider state beyond the evidence available in the session. Continue with the Marketing Kit overview or Projects, artifacts, and checkpoints.
Shape a marketing outcome with ak:brainstorm
Use ak:brainstorm to turn incomplete intent into an accepted outcome, constraints, non-goals, and observable acceptance criteria.
Create an evidence-bounded implementation recap with ak:sumup
Summarize completed work, failures, decisions, behavior, usage, and remaining next steps without claiming unverified delivery.