Human–Agent–Compass Workflow
From a customer signal
to a change that matters.
Follow the arrows. People make the calls, agents carry the work forward, and Compass keeps the evidence connected.
Hover or focus a step for its trigger. Click or tap to keep its instructions and skill links open.
Example prompts assume the skills are installed and your product’s pm-config.md is configured. Jobs and event triggers below are supported patterns, not a report of what is running in your workspace. Setup guide ↗
Scroll across the map to follow all three lanes.
Separate approvals: rank → commit capacity → approve design → build.
Build authorization: approve one versioned package through a tested PR. Release still needs its own approval.
Browse all step instructions and invocation examples
Lookup recipes reflect Compass discovery improvements #166, merged September 7, 2026. Verify your connected catalog exposes these tools and parameters; older sessions may need their connector refreshed. This is a source-verified contract, not a live workspace audit. Status narrows candidates; evidence and authority determine whether they can advance.
You start a conversation
Choose the outcome
What to review
Cycle: ACTIVEActive OKR cycles, their objectives and KRs, and the configured desired outcome. Review baseline, target, dates, and current progress; resolve competing active cycles with the human.
How to begin
Open your product’s agent session. If it has no pm-config.md, begin with pm-setup. Bring the customer problem, baseline, target, and time horizon; choose the outcome with pm-coach and record it with okr-workflow.
Example request to your agent
Usepm-coachandokr-workflowto find our active outcomes, show current progress, and help me choose the customer outcome to focus on.
What moves it forward
After you agree on the outcome and boundaries, provide research or ask for a synthesis of the connected feedback sources. Nothing runs on a timer merely because a skill is installed.
Compass lookup & coverage
How the agent finds candidates
list_okr_cycles(workspaceId) → filter ACTIVE → get_okr_cycle(cycleId). Resolve the workspace by configured slug or list_workspaces; carry discovered IDs internally.
Coverage / missing capabilities
Cycle listing has no status filter. Current progress does not establish a metric trend; use check-in history or the connected analytics source where needed.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Invoked skill · optional scheduled triage
Find the opportunity
What to review
Feedback: OPENFeedback: UNDER_REVIEWOpportunity: EXPLORING / VALIDATINGUntriaged feedback plus existing exploring/validating opportunities for deduplication. Include UNDER_REVIEW feedback when resuming unfinished triage; do not reprocess it as new.
How to begin
Use pm-signal-synthesis for interviews or a batch of signals. For OPEN Compass feedback, compass-feedback-triage can be invoked manually or by a configured workspace job with an empty-queue gate.
Example request to your agent
Use compass-feedback-triage to review untriaged feedback, resume unfinished reviews, and match signals to existing opportunities. Tell me if the tool cannot cover the whole queue. What moves it forward
The agent links or proposes opportunities and surfaces focus decisions. A triage job does not authorize delivery. Weekly synthesis is a suggested cadence, not an automatically installed job.
Compass lookup & coverage
How the agent finds candidates
Start list_feedback(status: OPEN, updatedSince: scan start); follow nextCursor with the same workspace/status, omitting updatedSince on cursor calls, until hasMore is false. Retain asOf for the next incremental scan. Review UNDER_REVIEW separately and list opportunities for deduplication.
Coverage / missing capabilities
Cursor scan mode is snapshot-bound and ordered by updatedAt plus ID. A full initial scan needs an early starting timestamp. Legacy calls without updatedSince/cursor remain a bounded vote-ranked list; they do not prove queue exhaustion. Deduplicate overlapping scans and recheck current state before updates.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Provider calls inside the active skill
Connect the evidence
What to review
Opportunity: EXPLORING / VALIDATING / PRIORITIZED / ACTIVEOpportunities touched by new signals, their linked KRs, solutions, assumptions, and evidence. Check source independence, missing links, and contradictions before claiming readiness.
How to begin
The agent resolves the authoritative providers through integration-routing, then uses compass-workflow for capabilities routed to Compass. Compass stores the links; it is not another autonomous worker.
Example request to your agent
Use compass-workflow to find opportunities with fresh signals or missing evidence links. Show the evidence gaps and connect the records where the sources support it. What moves it forward
The same session or triage run presents the evidence for your focus decision. There is no separate “connect evidence” scheduled job required.
Compass lookup & coverage
How the agent finds candidates
list_opportunities(workspaceId, optional status/squadId) → get_opportunity for candidates → list_evidence(nodeType, nodeId). Use discovered IDs for the detail reads.
Coverage / missing capabilities
No evidence-completeness or linked-KR filter is exposed on opportunity listing. Its KR summary contains titles, not the stable KR ID; get_opportunity supplies the detail. No general product full-text search is exposed; search_help searches documentation only.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Your decision · session or routed review
Worth pursuing?
What to review
Opportunity: VALIDATING / PRIORITIZED / ACTIVEDecision: PENDINGEvidence-backed VALIDATING candidates and existing PRIORITIZED/ACTIVE commitments. Check at least two independent sources, customer-need framing, KR alignment, and current focus before proposing a change.
How to begin
Review the cited customer evidence and choose focus, more research, or park. In a live session, state the opportunity ID and decision. For an asynchronous request, follow its review link and record the decision there.
Example request to your agent
Use ost-workflow to find opportunities that have enough evidence for a focus decision. Compare them with our current priorities and recommend a named shortlist for me to review. What moves it forward
In a live session the agent can continue within your instruction. A tracking-only Compass Decision records the answer but dispatches nothing: explicitly resume the workflow, or use a separately authorized action-capable continuation.
Compass lookup & coverage
How the agent finds candidates
list_opportunities by status → get_opportunity and list_evidence. If review is routed to Compass Decisions, list_decisions(state: PENDING, subjectType: OPPORTUNITY), then get_decision for exact scope.
Coverage / missing capabilities
No “ready for focus” filter combines evidence and portfolio context. The agent assembles a named shortlist; newest-first ordering is not product priority. A score is supporting evidence, not a focus decision.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Invoked skill or continuation of discovery
Propose a small test
What to review
Solution: IDEAAssumption: UNTESTEDExperiment: DESIGNING / RUNNINGPRIORITIZED/ACTIVE opportunities with IDEA solutions and high-risk UNTESTED assumptions. Check existing DESIGNING/RUNNING experiments before proposing another test.
How to begin
pm-coach explores solution directions; experiment-workflow turns the riskiest assumption into a test with success and kill conditions. Ask for a brief before authorizing customer exposure or spend.
Example request to your agent
Use experiment-workflow to find the riskiest untested assumptions under our current focus. Check for existing tests, then propose the smallest useful next experiment. What moves it forward
The agent creates the experiment brief and pauses at the test-authorization gate. Designing a test does not start recruitment, launch a prototype, or spend money.
Compass lookup & coverage
How the agent finds candidates
list_assumptions(status: UNTESTED, riskLevel: HIGH, solutionStatus: IDEA, opportunityStatus: ACTIVE); inspect PRIORITIZED separately. list_solutions filters status and parent opportunity status/squad. Use returned ancestry IDs and experimentCount to inspect evidence and existing tests.
Coverage / missing capabilities
These are candidate queries, not investment or test-approval decisions. Experiment counts alone do not show whether an existing test covers the same hypothesis; inspect linked experiments before proposing another.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Your approval of a specific test
Approve the test?
What to review
Experiment: DESIGNINGDecision: PENDINGDESIGNING experiments with a complete brief and any pending experiment reviews. Check audience, spend, timebox, method, success threshold, and kill condition; distinguish approval-ready briefs from incomplete drafts.
How to begin
Review the experiment ID/version, method, audience, budget, timebox, and kill condition. Approve that exact test in the active session or the linked human-review request; ask for revisions if any boundary is unclear.
Example request to your agent
Find experiments ready for my approval using experiment-workflow. Show each test’s audience, budget, timebox, success and kill conditions, and its exact review request. What moves it forward
A directly authorized session can continue. For tracking-only review, resume the agent explicitly; the review record does not launch the test. This approval does not admit the solution to NEXT or NOW.
Compass lookup & coverage
How the agent finds candidates
list_experiments(status: DESIGNING) → get_experiment. For compass_decisions routing: list_decisions(state: PENDING, subjectType: EXPERIMENT) → get_decision.
Coverage / missing capabilities
No “brief complete and awaiting approval” query. Match the exact review scope/version in details. Compass-native list_review_requests is a different review surface; use it only when routing selects that provider.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Authorized experiment work · results supplied
Run it. Read the evidence.
What to review
Experiment: RUNNING / COMPLETE / KILLEDRUNNING experiments with logged results, elapsed timeboxes, or unmet collection needs; also COMPLETE/KILLED experiments whose downstream learning has not been reconciled. Results present does not necessarily mean sufficient evidence.
How to begin
Carry out the approved method with the agent and any named human owners. Interviews, recruitment, and data collection may require human work or connected tools. Return observed results to experiment-workflow; a skill is not a background data collector.
Example request to your agent
Use experiment-workflow to find running experiments ready to assess or overdue for results. Compare the evidence with the agreed thresholds and bring me any proceed, iterate, or kill decisions. What moves it forward
The agent records results and the warranted conclusion. Compass conclude_experiment updates the linked assumption. Ambiguous strategic judgments return to you; iteration requires a revised test and any necessary approval.
Compass lookup & coverage
How the agent finds candidates
list_experiments(status: RUNNING, hasResults: true) finds result-bearing candidates; updatedSince supports incremental reads including new results. Query endBefore separately for recorded end dates. Summaries include result counts, latest-result time, lifecycle dates, and ancestry IDs; get_experiment supplies the evidence.
Coverage / missing capabilities
hasResults does not mean enough evidence. endBefore filters a recorded end date, not a universally defined deadline; experiments without end dates need their approved timeboxes checked separately. Do not intersect result and date filters when the intended queue is their union.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Conclusion followed by roadmap workflow
Preserve the learning
What to review
Experiment: COMPLETE + PROCEEDAssumption: VALIDATEDSolution: VALIDATEDRoadmap: LATERCOMPLETE experiments with a PROCEED conclusion, linked assumptions and solution state, plus all existing roadmap horizons for deduplication. Preserve a candidate only when the evidence warrants solution validation.
How to begin
After the evidence warrants validation, ask roadmap-workflow to preserve one linked, deduplicated LATER candidate. The agent writes the warranted solution and roadmap state through the resolved providers.
Example request to your agent
Use roadmap-workflow to find validated solutions that have no roadmap candidate. Verify their experiment evidence and existing links, then preserve eligible candidates in LATER. What moves it forward
LATER is a candidate, not a promise. You must rank and commit it through separate gates, or approve an exact build package under an enabled policy.
Compass lookup & coverage
How the agent finds candidates
list_solutions(status: VALIDATED, hasRoadmapItem: false) finds unlinked candidates directly. Inspect returned opportunityId and experiment evidence; list_roadmap_items returns stable solutionId/opportunityId/experimentId for existing placements.
Coverage / missing capabilities
hasRoadmapItem counts links to archived roadmap items too; those solutions are intentionally excluded from the unlinked queue. Review archived placements explicitly before recreating candidates. A VALIDATED status still requires supporting evidence.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Two separate human decisions
Rank, then commit
What to review
Solution: VALIDATEDRoadmap: LATER / NEXT / NOWDecision: PENDINGValidated LATER candidates, the full ordered NEXT queue, and current NOW commitments. Review rank, capacity limits, dependencies, owner, target date, and any displacement in two separate admission/commitment decisions.
How to begin
First review the ordered queue and approve an exact NEXT rank, capacity slot, and any displacement. Separately commit NOW capacity, delivery owner, and target date. Queue position alone is not approval.
Example request to your agent
Use roadmap-workflow to show validated candidates ready for a NEXT decision, with rank, capacity, and tradeoffs. Separately identify NEXT items ready for a NOW commitment. What moves it forward
Once the actual commitment and execution authority are established, a manual session or configured resolver can prepare delivery. Tracking-only review responses need an authorized session or worker to apply the approved changes.
Compass lookup & coverage
How the agent finds candidates
list_roadmap_items for LATER, NEXT, NOW (or all). list_decisions(state: PENDING, subjectType: ROADMAP_ITEM) → get_decision. Read policy and linked source detail before recommending admission.
Coverage / missing capabilities
Roadmap summaries now provide stable linked IDs, sortOrder, timestamps, and commitment provenance. They still do not establish present capacity, dependency readiness, or sufficient approval: join the current policy and exact human decision before advancing.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Invoked design skill · resolver preparation
Prepare the design
What to review
Roadmap: NOWSolution: VALIDATEDDecision: PENDINGCommitted NOW work with validated solutions and no current approved implementation plan. Inspect existing plans, pending design decisions, tasks, and PRs before preparing a new plan.
How to begin
design-before-code inspects implementation context and proposes a design. A configured compass-resolver can also prepare the Solution Plan for eligible NOW work and route a design-direction review.
Example request to your agent
Use design-before-code to find committed work that still needs an implementation design. Check existing plans and reviews, then prepare the next eligible plan for my decision. What moves it forward
The agent pauses for approval of the current plan. An unattended resolver returns AWAITING_DECISION; a later authorized run must re-read the exact response and plan version before implementation.
Compass lookup & coverage
How the agent finds candidates
list_roadmap_items(horizon: NOW) → use returned solutionId → list_solution_comments. list_decisions(subjectType: SOLUTION) and get_decision establish plan review context; list_tasks(linkedType, linkedId) checks existing work.
Coverage / missing capabilities
No “NOW missing approved plan” filter. A PLAN entry or its latest summary does not prove approval. Read the full plan/revision and exact human decision; unresolved linkage is a blocker.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Your approval of the current plan
Approve the design?
What to review
Roadmap: NOWDecision: PENDINGDecided outcome: REQUEST_CHANGESPending design-direction decisions for committed work, matched to the current Solution Plan. Include REQUEST_CHANGES decisions only after the plan has been revised; stale decisions cannot approve a new version.
How to begin
Read the plan, tradeoffs, scope, and test strategy. Name the plan version you approve in the session or linked design-direction request.
Example request to your agent
Use human-review-workflow to find implementation designs awaiting my decision. Show the current plan, tradeoffs, scope, and exact approval request for each. What moves it forward
The active agent continues under your instruction. A scheduled resolver may resume only if its pre-existing delivery authority covers the approved plan; the tracked decision alone grants no execution authority.
Compass lookup & coverage
How the agent finds candidates
list_decisions(state: PENDING, subjectType: SOLUTION), optionally reviewerId/query → get_decision → list_solution_comments. Page through results; filter design-direction semantics in the returned detail.
Coverage / missing capabilities
Decision queries support subject type, reviewer, text, state, and outcome, but not a dedicated design-gate or plan-version filter. The agent must verify the current plan and request together.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Invoked build-authorization skill · policy required
Package the proposed build
What to review
Solution: VALIDATEDRoadmap: LATER / NEXT / NOWDecision: PENDING / DECIDEDValidated, uncommitted candidates eligible under an enabled build policy, plus pending or already-approved packages and the current ordered NOW inventory. Check for a reusable package before drafting another.
How to begin
For a project explicitly opted into build_authorization_policy, the agent prepares one versioned package covering scope, design, investment, queue impact, owner, execution limits, and tests. Ask it to check policy before preparing the request.
Example request to your agent
Use build-authorization to find validated candidates eligible for a build package. Check the enabled policy, existing requests, and capacity before preparing a package for review. What moves it forward
The complete package is presented for your decision. Preparing it does not enable policy or approve work; absent policy, use the separate approvals path.
Compass lookup & coverage
How the agent finds candidates
list_roadmap_items → resolve solution evidence; list_decisions(query: build-authorization-v1) as a candidate search → get_decision. Inspect policy and runtime receipts separately.
Coverage / missing capabilities
A text match is only a discovery hint, not a typed package query or completeness guarantee. Read paginated decisions and verify package purpose/version; policy, leases, and execution receipts belong to the configured runtime.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Your decision on the exact build package
Authorize this package?
What to review
Decision: PENDINGPending build-authorization requests for this project, with their current immutable package revision. Exclude ordinary approvals, superseded packages, and requests outside the activated policy.
How to begin
Open the linked build-authorization request and approve its exact package revision using its specified decision contract. Review scope, capacity displacement, expiry, and allowed actions. A generic approval or old plan decision does not satisfy this gate.
Example request to your agent
Find build packages awaiting my decision using build-authorization. Show their exact scope, capacity impact, limits, and current decision links. What moves it forward
The separately authorized serialized executor reads the recorded approval and rechecks policy and capacity. Compass Decisions do not dispatch it. If no executor is configured, approval alone will not start a build.
Compass lookup & coverage
How the agent finds candidates
list_decisions(state: PENDING, optional reviewerId/query) → get_decision. Verify build-authorization-v1 purpose, workspace/repository, package digest, limits, and policy activation.
Coverage / missing capabilities
There is no dedicated pending-build-packages tool or purpose filter. The agent must inspect request semantics and policy, then show a named review list rather than ask you to remember request IDs.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Configured serialized executor · scheduled or resumed
Recheck capacity and claim
What to review
Decision: DECIDED + APPROVEExecutor result: READY / RESUME / IN_REVIEWDECIDED/APPROVE build packages with no completed execution, plus unfinished receipts to resume. Recheck expiry, revocation, scope, capacity, active claims, and existing PRs.
How to begin
The enabled build policy names the executor and receipt store. It verifies the exact human decision, checks scope/expiry/capacity, acquires a durable claim, and admits or resumes only the approved work. The opt-in job must check approved packages, not just NOW count.
Example request to your agent
Use build-authorization to find approved packages awaiting execution or safe resumption. Verify the exact decisions and receipts, then let the configured serialized executor advance eligible work. What moves it forward
READY admits work; RESUME continues the same execution; IN_REVIEW returns the existing PR. Missing authority, capacity, provenance, or claim safety blocks execution with a specific reason.
Compass lookup & coverage
How the agent finds candidates
list_decisions(state: DECIDED, outcome: APPROVE) → get_decision; join with policy, receipt store, serialized executor, current roadmap, and GitHub PR state.
Coverage / missing capabilities
No “approved and unclaimed” atomic search or claim tool is exposed in Compass. READY/RESUME are evaluator results, not Compass statuses. The configured executor must provide durable serialization and receipts; generic approvals never satisfy this contract.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Authorized session · optional resolver job
Build → test → review
What to review
Roadmap: NOWTask: TODO / IN_PROGRESS / BLOCKED / IN_REVIEWLegacy: approved, unclaimed NOW items with validated solutions and current design approval. Inspect TODO/IN_PROGRESS/BLOCKED/IN_REVIEW tasks and existing PRs. Opt-in: use the approved-package and receipt queue instead.
How to begin
compass-resolver can run manually or as a workspace schedule. The legacy job filters approved, unclaimed NOW work; the opt-in path uses build-authorization. It implements in an isolated worktree, runs test-first and verification, and creates a linked PR.
Example request to your agent
Use compass-resolver to find the highest-priority eligible work under our configured approval model. Verify authority, claims, plan, and existing PRs before advancing it through a tested PR. What moves it forward
The resolver stops at IN_REVIEW. If nothing is eligible, it reports the missing gate or an empty queue. A schedule must be configured explicitly; it never supplies merge or release approval.
Compass lookup & coverage
How the agent finds candidates
list_roadmap_items(horizon: NOW) in returned rank order → verify approval and plan details → list_tasks(linkedType: ROADMAP_ITEM, linkedId: discovered ID); get_task/list_task_links and GitHub check claims and PRs.
Coverage / missing capabilities
No eligible-for-delivery filter. Roadmap linked IDs and commitment provenance support reliable joins, but rank and task state do not prove authority or an exclusive claim. Read the decision, plan, and configured claim/receipt store.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Release review, followed by your go/no-go
Approve merge & release?
What to review
Task: IN_REVIEWGitHub PR: OPENIN_REVIEW tasks and their open PRs with current CI/review results, conflicts, and release scope. Review launch/version decisions separately where needed.
How to begin
Ask release-manager for the concrete PR merge order, CI/review status, conflicts, and rollout plan. Review and authorize that exact plan in the release session; provide the version choice when a distributable release requires it.
Example request to your agent
Use release-manager to find reviewed work ready for a merge decision. Show the named PRs, checks, conflicts, merge order, and release plan for my approval. What moves it forward
After your explicit approval, the release workflow executes the authorized plan. The completion watcher only observes merge/deployment evidence; it never merges. Neither a tested PR nor build authorization includes this decision.
Compass lookup & coverage
How the agent finds candidates
list_tasks(status: IN_REVIEW) → list_release_runs(taskId: discovered ID) or get_task/list_task_links → inspect linked GitHub PRs and checks. Release-run records include exact PR/head SHA, task IDs, and dispatch metadata; release-manager can also discover scoped open PRs directly.
Coverage / missing capabilities
Compass cannot filter by GitHub CI or mergeability and is not proof of release readiness. GitHub and deployment/release providers supply those facts; missing stable PR links must be repaired or surfaced.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Authorized release workflow · configured event watcher
Ship and verify in production
What to review
Task: IN_REVIEW / BLOCKEDGitHub PR: MERGEDChanged or stale IN_REVIEW tasks, merged PRs lacking production proof, and BLOCKED verification cases whose external conditions changed. Recheck the approved release scope and feature smoke results.
How to begin
release-manager verifies the deployment or release after the authorized merge. delivery-completion-watcher can react to PR, check, merge, or deployment events, with a daily catch-up scan when configured. It collects feature-specific production proof.
Example request to your agent
Use delivery-completion-watcher to find merged work still awaiting production verification. Check real deployment and smoke-test evidence, and report what is waiting or blocked. What moves it forward
A preview is not production proof. The watcher waits or blocks if checks or evidence are missing; a passing snapshot allows policy-based completion. Webhooks and the catch-up schedule require setup.
Compass lookup & coverage
How the agent finds candidates
list_tasks(status: IN_REVIEW, updatedBefore: stale cutoff) finds unchanged candidates; use updatedSince separately for changed tasks, and BLOCKED for retry. list_release_runs supports taskId/state/updatedSince and returns stable PR links. Inspect external merge, deployment, checks, and smoke evidence.
Coverage / missing capabilities
Task updatedAt is not time spent IN_REVIEW. External GitHub/deployment changes may not update Compass tasks, so combine event-driven runs with catch-up scans. Release-run ledger state and dispatch records never prove merge or production success.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Completion watcher applies verified state
Record what actually shipped
What to review
Task: IN_REVIEW / DONERoadmap: NOW / LAUNCHING / SHIPPEDSolution: IN_DELIVERY / SHIPPEDVerified delivery with incomplete lifecycle updates or partial receipts, plus LAUNCHING items with unfinished launch work. Do not equate DONE tasks with a fully shipped solution.
How to begin
The watcher updates linked tasks and roadmap/solution state through the authoritative providers, then writes a receipt. Configured launch work may keep the roadmap in LAUNCHING; unsupported updates are reported explicitly.
Example request to your agent
Use delivery-completion-watcher to find verified releases with unfinished state updates or launch work. Reconcile only what the evidence permits and report remaining gaps. What moves it forward
Retries reuse the receipt. Leaving NOW emits a capacity-change event for portfolio review, not automatic promotion of the next item. Passing-with-follow-up creates linked feedback for later discovery.
Compass lookup & coverage
How the agent finds candidates
list_tasks by state/change window and list_roadmap_items by horizon → stable links, list_release_runs, get_launch_checklist, and completion receipts. list_solutions(status: SHIPPED / IN_DELIVERY) supports solution-state checks in separate calls.
Coverage / missing capabilities
No partially-reconciled or missing-receipt query. The runtime must preserve receipts for retries; Compass status alone cannot reconstruct completed side effects or prove production success.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Human review cadence · optional scheduled synthesis
Did the outcome improve?
What to review
Roadmap: SHIPPED / LAUNCHEDSolution: SHIPPEDCycle: ACTIVEFeedback: OPEN / UNDER_REVIEWShipped solutions and roadmap work, ACTIVE KRs with fresh measurements, new feedback, and still-active opportunities. Compare outcomes with baseline and look for contradictory evidence or follow-up needs.
How to begin
Bring product metrics and production feedback back to pm-coach, okr-workflow, and signal synthesis. The playbook suggests weekly synthesis and monthly outcome checks; you can configure reminders or a recurring agent for these.
Example request to your agent
Useokr-workflowandpm-coachto review recent releases against our active outcomes. Find new feedback, compare measured impact with baseline, and bring me decisions about continuing, iterating, or stopping.
What moves it forward
You reassess the outcome and priorities. A shipped change does not prove customer impact, and a weekly synthesis job does not make strategic decisions for you.
Compass lookup & coverage
How the agent finds candidates
list_roadmap_items by shipped/launched horizon; list_solutions(status: SHIPPED); list_okr_cycles → get_okr_cycle. Use list_feedback(updatedSince: release window) with cursor continuation, then join release receipts and analytics for impact.
Coverage / missing capabilities
Feedback updatedSince includes older feedback edited since the cutoff, not just new submissions or feedback caused by the release. Inspect createdAt and source context. Shipped horizon queries return only ACTIVE roadmap records; archived history and causal outcome evidence need authoritative sources.
Based on merged Compass #166 · September 7, 2026. IDs are discovered by the agent. Verify the connected catalog, paginate supported scans, and resolve exact records before updates. If tools are missing, refresh the connector or report the capability gap.
Read the skill instructions
Explore the operating rules and exact state transitions
Operating contract
Judgment, execution, and state have different owners
pm-config.md; it never supplies authority.Shared loop
Discover and validate
Human
Set the outcome and boundaries
Choose the measurable outcome, investment ceiling, and authority the agent may use.
Rules and handoff
The human owns strategic intent, budget, priority, and the definition of acceptable evidence.
Agent
Resolve providers before acting
Read pm-config.md, resolve each capability, and confirm exactly one authoritative provider.
Rules and handoff
Discovery, roadmap, experiments, delivery, review requests, and decision records resolve independently. Never assume one stack owns all state.
Compass
Return the current product snapshot
Expose OKRs, feedback, opportunities, solutions, assumptions, experiments, and roadmap state for capabilities routed to Compass.
Rules and handoff
Compass is authoritative only for capabilities explicitly resolved to it. Secondary notes are inboxes, exports, caches, or snapshots.
Key Compass operations: get_workspace_summary · list_okr_cycles · list_opportunities · list_experiments · list_roadmap_items · list_feedback
Agent
Synthesize signals into an opportunity
Cluster evidence, preserve customer language, link sources, deduplicate, and connect the opportunity to an active Key Result.
EXPLORING → VALIDATING
Rules and handoff
EXPLORING has a signal but fewer than two independent sources. VALIDATING means evidence collection is active and at least one strong signal is logged.
Human
Confirm the opportunity is worth attention
Review the evidence and decide whether it earns focus—not whether a feature should be built.
Rules and handoff
Priority remains a human product judgment. Weak evidence stays visible instead of being rounded up to confidence.
Compass
Promote the evidence-backed opportunity
Persist the opportunity and its links as evidence and focus mature.
PRIORITIZED → ACTIVE
Rules and handoff
PRIORITIZED requires two or more independent sources, customer-voice framing, and a link to an active KR. ACTIVE means solution discovery or experiments are underway.
Key Compass operations: create_opportunity · update_opportunity_status · link_feedback_to_opportunity
Agent
Explore solutions and assumptions
Generate at least three directions, map desirability, viability, feasibility, usability, and ethical assumptions, then identify the riskiest one.
Rules and handoff
A solution begins as IDEA. It becomes VALIDATED only after its riskiest assumption survives an appropriate test.
Agent
Design the smallest falsifiable test
Write the hypothesis, method, success threshold, and kill condition before launch.
DESIGNING · Assumption UNTESTED
Rules and handoff
DESIGNING means the method exists but the kill condition is not yet written or approved.
Key Compass operations: create_experiment
Human
Authorize the test
Approve the test budget, exposure, and kill condition. Silence never means approval.
Rules and handoff
This approval authorizes only the stated validation work. It does not change roadmap horizon or authorize delivery.
Compass
Track the experiment and conclusion
Link it to the assumption, capture evidence, and record PROCEED, KILL, or ITERATE.
RUNNING → COMPLETE / KILLED · Assumption UNTESTED → TESTING → VALIDATED / INVALIDATED · Solution IDEA → VALIDATED / KILLED
Rules and handoff
RUNNING requires an approved kill condition. COMPLETE requires result and conclusion. KILLED preserves the reason and learning. conclude_experiment automatically updates the linked assumption; assumption status is not manually updated. The warranted product decision then validates or kills the solution.
Key Compass operations: create_experiment · log_experiment_result · conclude_experiment
Choose one route
Commit and deliver
Default
Separate human gates
Validation, NEXT, NOW, design, and build remain discrete decisions.Agent
Preserve the validated candidate
Keep or create one deduplicated roadmap candidate without promising delivery.
LATER
Rules and handoff
LATER is a preserved possibility. Validation approval does not promote it.
Key Compass operations: list_roadmap_items · promote_to_roadmap · update_roadmap_item
Human
Rank and admit the candidate
Compare it with every queued item, choose an exact rank, and name any displacement.
LATER → NEXT
Rules and handoff
NEXT requires a VALIDATED solution and an available next_limit slot. If rank or capacity is missing, keep LATER.
Human
Make a separate delivery commitment
Confirm a current now_limit slot, target date, delivery owner, and capacity evidence.
NEXT → NOW
Rules and handoff
NOW is committed delivery. Admission to NEXT never implies commitment to NOW.
Agent
Prepare the implementation design
Explore options, document tradeoffs and constraints, and present the exact proposed design.
Rules and handoff
No production code begins until the design is reviewed for the committed scope.
Human
Approve the implementation design
Choose the approach and confirm that its interfaces, tradeoffs, and scope match the commitment.
Rules and handoff
This design approval is separate from NEXT admission, NOW commitment, merge, and release.
Agent
Build and verify
Claim the approved work, implement test-first, run QA, obtain code review, and open a PR.
TODO → IN_PROGRESS → IN_REVIEW
Rules and handoff
The resolver may claim eligible, explicitly authorized NOW work. It opens a tested PR but never merges or force-pushes.
Key Compass operations: create_task · move_task_status · roadmap/solution/task linking
Opt-in
Bounded build authorization
One versioned package may cover admission and execution through a tested PR.Agent
Prepare a versioned build package
Bundle exact scope, investment case, design, capacity impact, checks, and execution limits.
Rules and handoff
The package is bounded and versioned so the approved object cannot silently change after review.
Human
Approve the exact package once
Authorize its stated investment, design, capacity-aware admission, and execution through a tested PR.
Rules and handoff
This opt-in path must be enabled by policy. It never grants merge, release, security, billing, or destructive authority.
Agent
Serialize admission, claim, and execution
Re-read every gate, persist receipts, admit the exact item, claim it durably, implement, verify, and open the PR.
LATER → NOW · IN_DELIVERY → IN_REVIEW
Rules and handoff
A tracking-only decision record is not the executor. An action-capable worker acts only inside its pre-existing authority and the approved package.
Compass
Keep linked product and delivery state current
Persist roadmap, opportunity, solution, task, claim, and review links when those capabilities resolve to Compass.
Rules and handoff
Delivery may instead resolve to Compass Tasks, Linear, or Jira. Stable IDs preserve the chain across providers.
Key Compass operations: promote_to_roadmap · create_task · move_task_status · roadmap/solution/task linking
Both paths converge at IN_REVIEW. Neither path authorizes merge or release.
Shared loop
Release, verify, and learn
Agent
Present the merge plan
Triage open PRs, order safe merges, report CI and conflicts, and wait at the release gate.
IN_REVIEW
Rules and handoff
Passing checks are evidence, not permission. The release manager pauses before merge and never treats review comments as a merge event.
Human
Authorize merge and release
Make the separate go/no-go decision after reviewing scope, checks, risk, and rollout plan.
Rules and handoff
Human merge is a hard boundary. Build authorization does not include it.
Agent
Verify production behavior
Observe the human merge, required checks, production deployment, and a feature-specific smoke test.
Rules and handoff
A preview is not production proof. A merged PR without a successful production deployment is not shipped.
Compass
Close the delivery loop
Record release evidence and move linked work only after production proof.
Task DONE · Roadmap SHIPPED · Solution SHIPPED
Rules and handoff
The completion watcher writes an idempotent receipt and dispatches a capacity-change event when an item leaves NOW.
Key Compass operations: move_task_status · update_roadmap_item · provider-exposed solution lifecycle update · record completion receipt
Agent
Route learning back into discovery
Capture production feedback, link it to shipped work and its opportunity, and surface contradictions or new signals.
Rules and handoff
Passing-with-follow-up creates one deduplicated feedback item. Blocking findings do not produce a shipped claim.
Human
Reassess the opportunity and portfolio
Use outcomes and new evidence to continue, iterate, stop, or change priority.
Rules and handoff
The loop returns to customer truth and the desired outcome—not automatically to another feature.
Production feedback closes the loop. New evidence returns to signal synthesis and may strengthen, contradict, or create an opportunity.