---
name: shape-work
description: Clarify unresolved goals, users, workflows, scope, priorities, constraints, trade-offs and success criteria into a usable product agreement. Use for shaping an idea or an authorized bounded discovery handoff; preserve settled decisions and stop before spec publication, tickets or implementation.
---

# Shape work

Own project-oriented discovery, not an engineering questionnaire. Ordinary matching requests and bounded handoffs use this procedure in the caller's context; loading a companion does not spawn an agent.

## Authority and dependencies

Reuse the project's applicable instructions and agreement once per context, including relevant context/authority pointers and directory/runtime restrictions. Check meaningful decision/effect, safety, verification, documentation and continuation guidance, not Setup provenance or templates. Identify specific absent/conflicting guidance and recommend explicit reconciliation without starting setup or rewriting policy. Missing common guidance blocks dependent project work; missing tracker/model/domain detail blocks only that capability. Default to authorized inspection and a conversation return. Discovery selects no implementation or artifact publication. Required authorized domain maintenance remains part of this work, not optional session storage.

Discover companions under project guidance; inspect complete entries and relevant references for semantic capability/source identity. Missing or incompatible companions block their dependent responsibility, not unaffected discovery.

| Gap | Required companion capability |
| --- | --- |
| Source/API/version facts | `research`: bounded cited findings, applicability, uncertainty and deciding-source freshness; direct local inspection or current supported findings need no new run |
| Feasibility, existing behavior or technical consequences | `analyze`: inspect implementation/callers/reuse/coverage and return risks, checks and recommendations without building; technical lead retains routine engineering choices |
| Changed meanings/model or qualifying enduring decision | `domain-modeling`: bounded plan-only/approved records, authoritative document mapping, preserved rationale/history and actual outcomes; reading unchanged definitions needs no invocation |

For separately authorized delegation, discover Work On's conditional coordination library, not its delivery entry or old universal contract. Require root-owned allocation, finite bounds, protected ownership and inspectable returns; workers never recursively delegate. Missing compatibility blocks delegation, not equivalent direct work. Preserve active/uncertain state and spent allowances.

## 1. Bound the discovery and reuse decisions

Identify the outcome, users, decision owner/product home, exclusions, allowed effects and prior evidence from the request/context. Bound the relevant branches and honor explicit caller round/time limits; no mandatory form. A round/time limit bounds the session, not the completeness claim: return remaining concerns if it is reached. Establish whether the outcome covers shared guidance only, readiness for the current people/items/cases, or both. Reuse clear existing scope; when ambiguous, ask this early. Do not silently narrow a broad preparation request to shared rules or folder organization. The plan and evidence may remain in conversation. Persist only when the user selects a destination; do not manufacture a handoff, spec, ticket or future-session storage obligation.

Inspect support behind supplied decisions/findings against their deciding agreement, sources, callers/configuration/environment and dirty content. Reuse current evidence; reopen only claims affected by changed intent, contradictions or newly relevant paths. Preserve old-state support; unclear impact makes the relevant set stale. A phase change alone warrants no rediscovery.

An already usable agreement returns directly through step 4; no new interview or duplicate document. For fresh discovery, tell the user what this session is shaping and that it ends with an agreed plan, not a required spec, ticket or implementation. Name the main unresolved areas and start with the highest-consequence questions. A small clear request needs only a proportionate brief. A proposed outcome can be explored but remains proposed. Missing product home needs a recommendation and owner agreement before becoming authoritative.

**Done:** scope, owner, authority, stop bound and current versus unresolved decisions are known.

## 2. Establish facts before asking for choices

Inspect authorized product documents, observed behavior and existing evidence. Separate documented facts, executed observations, interpretations and unknowns. Choose the source by authority and reliability, not merely whether searching is possible. Inspect readily available reliable records yourself; ask the owner directly for intent, agreed priorities, tacit context, or uncertain/outdated personal or organizational facts they can readily confirm. A search result or inferred activity pattern cannot establish someone's agreed responsibilities or expectations. “Investigate discoverable facts” does not mean searching indefinitely or guessing to avoid a useful question. For material source or technical gaps use the relevant discovered companion with the bounded question, deciding references, prior evidence, confirmed decisions, protected scope, authority, finite bound and expected return. Inspect its actual cited support, applicability, gaps and changed artifacts on return, not just its success label.

Classify technical uncertainty by its consequence for this agreement. If a finding could change the proposed behavior, feasibility, compatibility, scope or a consequential trade-off, resolve it through bounded Analyze before requesting confirmation. Follow the available compatible companion directly in the caller's context, inspect its return and resume shaping; do not require the user to invoke `/analyze` or approve already-authorized prerequisite inspection again. Reuse current supported analysis under step 1 rather than rerunning it. Analysis limited to implementation methods, internal design or delivery checks may remain a later phase only when its result cannot change this agreement; record that boundary and any revisit condition. If the distinction is unclear, inspect the smallest deciding question before treating it as later work. Missing capability, source access or permission blocks the affected agreement; preserve the draft and name the smallest next action. Companion use grants no delegation, installation, implementation or other external-effect permission.

Use domain-modeling only for actual changed definitions/model or qualifying decisions. Supply the exact subject, evidence, document mapping and expected return; absent exact write approval, use plan-only, including no draft writes. Inspect applied versus proposed outcomes, preserved history and caller-owned pointer changes. Missing specialist capability or deciding source blocks the affected conclusion, not unaffected discovery. Return the smallest needed evidence action instead of asking the maintainer to guess internal abstractions or test seams.

Translate consequential findings into user, scope, cost, risk or delivery terms. Recommend a practical option with its evidence and uncertainty. Routine architecture/method/check selection stays with the technical lead; product commitments, permissions and meaningful consequences stay with their approval owner.

**Done:** facts needed for the next choice are supported, explicitly reused or identified as material gaps; recommendations do not present assumptions as facts.

## 3. Explore the unresolved branches in manageable rounds

Exhaustively resolve the product questions relevant to this scope. Reuse confirmed decisions and inspect readily available reliable facts yourself; use step 2's source judgment for gaps. Ask the user about remaining intent and consequential trade-offs in manageable rounds; continue until every relevant concern has a confirmed decision or an explicit disposition.

Start with the highest-consequence uncertainty and let answers determine the next round. Manageable rounds set the pace, not a total question limit. Use the target's collaboration style and examine every relevant branch:

- Goals and priorities: what problem matters now, what can wait, and how success will be recognized.
- Users and workflows: who acts or benefits, entry conditions, normal actions, observable results and existing behavior to retain.
- Exceptions/recovery: partial or invalid input, interruption, retry, cancellation and inconsistent state where they affect the outcome.
- Constraints/abuse: access, misuse, disclosure, irreversible effects and operating limits.
- Trade-offs: compatibility, ongoing maintenance, cost, delivery commitments and consequences of smaller scope.

Ask about intent and consequential choices, recommending supported options in project terms. A new fact gap returns only that question to step 2. Keep confirmations, proposals and assumptions distinct.

When the outcome covers multiple people, items or cases, inspect the available context across that set before claiming readiness. Keep a compact per-item view of required inputs: confirmed, reliably sourced, missing, or uncertain. Identify shared gaps once and person/item-specific gaps separately; ask the owner focused questions to fill the material gaps, using grouped questions or one item at a time as practical. Do not wait for the user to ask whether each item is ready, or equate populated files with sufficient context. Seek inputs needed for this outcome, not a speculative dossier or every detail of future execution.

Track coverage of the branches above as resolved, still open, or inapplicable with a reason. Before closing a branch, test the proposed workflow against a concrete example and a relevant exception or trade-off; ask the user to settle any consequential ambiguity this exposes. Use examples appropriate to the scope, not invented edge-case requirements. A short answer may settle one detail without settling the branch or the whole agreement.

After each answer, briefly distinguish what is settled from what remains, then ask the next focused questions in the same response. Prefer a small related batch; use follow-ups to clarify broad answers, competing priorities, unsupported assumptions or contradictory examples. Keep asking while relevant intent remains open; the user should not have to ask whether you have more questions. A generic “anything else?” supplements this coverage check, not replaces specific questions.

Every conversational round ends with one clear signal: **Still shaping** plus the next questions; **Blocked** plus the exact missing decision/evidence and its owner; or **Ready for confirmation** plus the brief from step 4. At an explicit session bound, say **Paused — shaping incomplete** and list remaining concerns. A “recorded” acknowledgment, document update or passed link check is progress, not a completion signal. When authoring documents is authorized, report those effects briefly and continue the interview if questions remain.

Maintain one compact concern record with rationale/evidence and owner or revisit condition where needed:

| Disposition | Record |
| --- | --- |
| Required now | Behavior and success needed for this scope |
| Worth considering later | Deferred concern, why it can wait and when to reconsider |
| Explicitly unnecessary | Excluded behavior and why it does not serve this scope |
| Accepted limitation | Consequence the approval owner explicitly agrees to tolerate, with approval source |

Until confirmed, label a proposed disposition as proposed. Obtain approval for consequential commitments and deferrals affecting the next phase; silence does not accept a limitation. Preserve all four kinds in the return when present, explicitly marking inapplicable kinds rather than inventing concerns.

**Done:** every relevant branch and concern has a supported confirmed decision or explicit disposition, with no unresolved consequential intent. Check for overlooked relevant concerns before declaring the agreement usable; settled decisions and discoverable facts need no user questions. Stop when this criterion is met rather than after a fixed number of questions; keep unrelated hypothetical branches outside scope. At the bound or a blocker, preserve progress and return the owner, recommendation and safe next action.

## 4. Confirm and return the plan

Summarize only needed detail: goal/rationale, users/workflows, observable required behavior and success criteria, priorities/constraints, four concern dispositions with rationale/revisit conditions, confirmed decisions/approval sources, proposals/assumptions and remaining gaps. Preserve reused decision pointers rather than copying unrelated policy. This is a discovery brief, not automatic spec authoring or publication.

Before presenting a new brief as ready, apply step 2's technical-uncertainty gate: agreement-critical analysis has an inspected current result, and any later analysis is implementation-only with its boundary recorded. Owner confirmation alone cannot substitute for missing material evidence. Then check that each relevant branch is resolved or explicitly dispositioned; the required workflow and observable success are concrete; material assumptions/conflicts have been settled; and exclusions, deferrals and limitations have the necessary owner approval. Check completeness against the whole agreed outcome, including current people/items/cases when in scope. Shared workflow rules can be settled while individual context remains incomplete; report those states separately and continue asking about required gaps. Inputs may wait only when genuinely outside this outcome or explicitly deferred with the owner's agreement and a revisit condition. When the boundary is unclear, ask whether to complete that context now rather than deciding it belongs to future execution. Identify the consequence of deferral; never use a shared-guidance milestone as overall completion.

Check fidelity against the request and existing agreement: no silent commitments, dropped deferrals or invented approval. Present the brief as **Ready for confirmation — shaping is not complete yet** and ask whether it accurately captures the intended scope and decisions, identifying any remaining consequential choice specifically. Wait for the owner's answer; corrections reopen only affected questions. Reuse an already approved current agreement without ceremonial reapproval. Until confirmed, return a labeled draft. If an existing authoritative product record needs changing, propose the exact delta; apply only within approved write authority, preserving history. Required but unapproved/unavailable reconciliation blocks reliance on the changed agreement, not useful draft output.

Return the plan, approval/deciding support, concern dispositions and actual document/companion outcomes under project evidence guidance. Identify gaps and the next action:

- **Complete:** observable outcome/success and relevant dispositions are usable, consequential intent is confirmed, supporting facts are current and required authoritative reconciliation is complete. Reuse can complete with no new questions or writes.
- **Partial:** a useful labeled draft survives, but the bound or pending non-material confirmation limits it; specify what remains. It is not an approved agreement.
- **Blocked:** unresolved consequential intent, material facts/conflicts, authority or required capability prevents agreement; name the dependent decision, owner and smallest next action.

Make the terminal status explicit to the user: **Shaping complete** only when the Complete criterion above is met; otherwise **Shaping incomplete — partial** or **Shaping blocked**, with the remaining questions/owner and next action. For complete work, briefly state what was agreed, what was intentionally deferred, and the recommended next phase. Offer that phase without starting it or implying that shaping approval authorizes it. A confirmed plan completes shaping even if the user creates no further artifact.

Stop at the confirmed plan. A caller may resume its already-authorized responsibility; shaping itself starts no new stage.

## Validation

When changing or exercising this package, read [validation](references/validation.md). Separate authored scenarios, direct walkthroughs, executed checks and independent agent trials; none proves the others.