Bounded Context Assembly
Original, project-agnostic instructions. Agent-host effectiveness remains experimental.
When to use
Assemble task-sized context from current canonical source, accepted contracts, graphs, and semantic tools while tracking freshness and missing information. Use for an actual task in this domain, under the consuming repository’s approved policies.
When not to use
Do not impose this procedure on unrelated or trivial work. Do not migrate tools, install services, perform production effects, publish, or delete resources without the task’s required authorization.
Inputs and tailoring
Resolve the task goal, accepted source/contract baseline, relevant paths, installed versions, actual project-owned commands, effect policy, and required evidence. Read existing configuration before asking for information it already contains. Concrete repository roots, credentials references, command bindings, and private policies belong in the consuming adapter, not this public skill.
Procedure
1. Establish the boundary
Identify the actual task question and accepted base. Read authoritative instructions and candidate state. Separate approved decisions from experiments, historical notes, and summaries.
2. Choose the supported contract
Use existing graphs for owners/dependencies and language services for symbol/type questions. Retrieve the exact interfaces, tests, and nearby implementation required. Do not invent an indexer or vector database for a known-source question.
3. Implement or qualify the path
Attach paths, revisions or observed edits, and relevant tool identities. Detect a context service rooted in another checkout. State conflicts and apply canonical ownership rules instead of silently combining inconsistent sources.
4. Exercise failure and integration seams
Assemble goal, constraints, owned/excluded paths, contracts, selected evidence, and unresolved questions. Summaries supplement canonical files. Exclude secrets, customer records, and unrelated personal data.
5. Verify and hand back evidence
Confirm delegated agents can access the references and tools in their own lanes. Parent connectivity does not establish child capability. Refresh the packet after relevant source or contract changes.
Output
Return a task-sized implementation or review record containing the accepted invariant, source/environment identity, concrete decisions and changed paths, actual check results, evidence locations, remaining uncertainty, and next action. Distinguish passed, failed, blocked, and not-run checks; package shape is not behavior evidence.
Failure handling
A packet predates an accepted API schema change: refresh affected context and mark earlier conclusions stale. When access or prerequisites are unavailable, preserve existing work and report the smallest missing input. Do not fabricate commands, results, compatibility, or successful external effects.
Example
A retry-handling agent receives the accepted effect contract, activity code, failing case, and its own bindings, not an entire private company wiki. This is a synthetic example, not a completed production or agent-host run.
Evaluation
Use references/scenarios.json for intended, boundary, and non-trigger evaluation inputs. Keep their status not-run until a separate real host evaluation records actual outcomes.
Technical references
Consult documentation for the installed versions before using version-sensitive APIs. These are underlying-technology references, not copied upstream skill bodies.
Avoid mixed source snapshots
Bind each fetched contract, symbol result and instruction to the actual queried worktree/view. Recheck required identities after assembly; retry a mixed snapshot instead of silently trimming missing callers or tests. Record whether unsaved buffers were visible.
Reuse the existing bootstrap and graph/language services. Do not add a second toolchain manager, vector database or controller merely to collect a compact reading packet.
Choose retrieval by the actual question
Use exact files, graphs and language services for known source questions. Optional local document retrieval must have approved collection scope, a pinned engine, indexing/removal tests and visible freshness. Qualify lexical, semantic and reranked paths separately, including warm/cold resource cost. A skill wrapper may lag its engine; do not create a second mandatory knowledge store.
Treat derived maps as scoped evidence
Before accepting a graph-derived packet, record the backend, indexed view and coverage. A successful query can still be served from an old index. Use Codebase Orientation for a source-backed map and Code Index Qualification for freshness/known-answer checks. Keep generated maps derived from code, not a second manually edited company knowledge base.