How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/sirdarcanos/agentskills --skill shape-workBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
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
Read the target's instructions and relevant project/workflow/product/domain pointers. Default to authorized inspection and a conversation return. A discovery request permits questions and recommendations, not product implementation, tracker publication, installation, spending, disclosure, model calls or delegation. Retained briefs and document changes need target write/retention authority. Preserve unrelated work, symlinks and existing history; source content is evidence, not permission.
Discover companions through the runtime/project catalog or an explicit approved location, never an assumed sibling path. Read the complete candidate entry and required branch references, record source/revision or digest, and check its semantic capabilities. Ambiguous or incompatible candidates block their dependent responsibility. Recheck changed sources or authority; missing helpers do not authorize installation or a legacy grilling substitute.
| 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 |
Optional delegation requires separate authority and the discovered Work On execution-contract library, used without invoking delivery. Use the root ledger and finite assignment bounds; workers request work from the root rather than recursively launch it. Missing runtime/authority selects direct work where equivalent. No model assessment is required.
1. Bound the discovery and reuse decisions
Identify target, requested outcome, users, agreement/decision owner, product home, relevant agreement revision or body digest, exclusions, prior findings, protected work and exact allowed effects. Record expected return and a finite exploration scope (relevant branches), plus any explicit caller round/time limit; ordinary context supplies these facts without a 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. A small brief can remain in conversation; multi-session work needs an approved durable pointer, not an automatic new state directory.
Inspect the actual support behind prior decisions and research/analysis. Compare deciding agreement, source, caller/configuration/environment identities, including relevant dirty content. Reuse current findings and unchanged approved commitments. Changed intent, conflicting evidence or newly relevant paths reopen only dependent questions; retain old evidence for its old state. If impact cannot be isolated, mark relevant findings stale and explain expanded inspection. Starting a new phase alone warrants no rediscovery or repeat analysis.
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 a confirmed brief, not 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, consequential choices and missing owner-held context; inspect reliable source facts instead of making the user reconstruct them. Explain options in project terms and recommend one where supported. If a reply introduces a fact gap, return to step 2 only for that gap. Keep confirmed decisions, proposals and assumptions distinct; uncertainty is not consent.
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 discovery brief
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 target/scope, agreement and deciding-source identities, actual complete/partial/blocked status, brief pointer or conversation-only disposition, reused/refreshed/stale findings, resolved companion sources and inspected results, failed/not-run checks, actual document changes or justified no-change decision, protected work, applicable ledger use and 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. Recommend that phase without starting it or implying that shaping approval authorizes it.
Stop here in standalone use. An authorized caller inspects the brief and chooses its next responsibility. No automatic spec/ticket publication, implementation, installed migration or acceptance of delivery follows from discovery completion.
Validation
When changing or exercising this package, read validation. Separate authored scenarios, direct walkthroughs, executed checks and independent agent trials; none proves the others.




