Give your agentbetter brief. Design what it knows, what it can use, and what it hands back. Leave with a context plan you can actually build from.
Open the workbench ↗ Free to use. Your draft stays in this browser.
CONTEXT / DESIGN STUDY 001
01 / INTENT One clear outcome.
LOAD FIRST Instructions
RETRIEVE NEXT Evidence
02 / CONTINUITY A useful handoff. ↗
LESS GUESSWORK. MORE CONTEXT THAT COUNTS.
The workbench / v1.0
Start with a real decision. Choose a synthetic example, then make it yours. Describe sources and rules; keep private records and credentials out of the brief.
01 A coding change Repository → change → handoff ↗ 02 Answers from documents Question → evidence → answer ↗ 03 A workflow handoff Case → proposed action → review ↗
Switching scenarios keeps your edits in this tab. Download your drafts before leaving or reloading.
01 Define the outcome What should happen, and what must remain true?
Intended outcome Be specific about the task and the behavior you want to preserve.
Proposed action mode Read and answer Prepare a draft Make external changes
This describes the design. It does not grant access to a tool or system.
Approval and ownership Name who decides before a consequential action, and where that decision is enforced.
02 Place your sources Load the essentials. Retrieve the rest with purpose.
Add a source + Up to eight sources. For operational data that changes within a day, specify a fresh read at the point of use.
03 Plan the difficult cases Make uncertainty and failure part of the design.
When the agent should stop or hand back Describe the response to missing, stale, conflicting, or unauthorized information.
Cases you will evaluate One case per line. Include the normal task and a failure or boundary case.
04 Leave a useful handoff The next session should not have to reconstruct the work.
What must survive the session Include decisions, source versions, evidence, unfinished work, and the next owner.
Design coverage
Your design decisions are recorded 10 of 10 completeness checks documented
These rules check what you have recorded. They do not run a model, verify access, or measure performance.
✓ A specific outcome Recorded Describe the task and the behavior that should remain unchanged. At least 20 characters is a completeness check, not a judgment of quality.
✓ Named sources Recorded Include at least one source and give each included source a useful name.
✓ A stated access boundary Recorded Every included source needs a declared access basis. A scoped choice still requires real authorization in the system that retrieves it.
✓ A refresh rule Recorded Record a maximum age from 1 to 365 days for each included source. For fast-changing data, refresh it at retrieval time; this daily rule is only a planning aid.
✓ Instructions separated from evidence Recorded Untrusted material placed in the initial context needs review. Retrieved material also remains untrusted; retrieval does not make it an instruction.
✓ An identified authority Recorded Identify at least one owner-approved task or policy source. This tool records your designation; it cannot verify that the source is authoritative.
✓ A decision before external changes Recorded If the proposed agent can make changes, name who approves consequential actions and where that decision is enforced.
✓ A useful way to stop Recorded Describe what happens when information is absent, stale, conflicting, or outside the allowed scope.
✓ More than a happy path Recorded Write at least two concrete cases, one per line. Include a failure or boundary case; the tool checks their presence, not whether they are good tests.
✓ A next-session handoff Recorded Name the decisions, evidence, unfinished work, and next owner that must survive a session reset.
Download your brief ↓ Copy Markdown Download JSON
Your draft is not saved when you leave this page.
Read the complete brief # Context design brief
Schema version: 1.0
A user-authored design brief. No model execution, authorization verification, benchmark, or security certification.
## Intended outcome
Add a delivery-status filter to a synthetic order dashboard, preserving existing access rules and keyboard navigation.
## Actions and approval
Proposed action mode: draft
A repository maintainer reviews the diff and acceptance evidence before merging or deploying.
## Sources
### Task brief and acceptance criteria
- Authority: authoritative
- Delivery: initial
- Declared access: public
- Maximum age: 1 days
### Relevant source files and access-control tests
- Authority: authoritative
- Delivery: retrieve
- Declared access: scoped
- Maximum age: 1 days
### Issue comments and external examples
- Authority: untrusted
- Delivery: retrieve
- Declared access: public
- Maximum age: 7 days
## Fallback
Stop at a proposed change if the access contract or expected filter behavior is unclear. Record the missing decision for the maintainer.
## Evaluation cases
- An authorized user sees only orders they can access.
- An unauthorized order never appears in results.
- The filter works by keyboard and the existing default view is preserved.
## Handoff
Record the branch and commit, changed files, commands and results, unresolved decisions, and the next smallest action. Link evidence instead of copying entire logs.
## Transparent design checks
- A specific outcome: documented. Describe the task and the behavior that should remain unchanged. At least 20 characters is a completeness check, not a judgment of quality.
- Named sources: documented. Include at least one source and give each included source a useful name.
- A stated access boundary: documented. Every included source needs a declared access basis. A scoped choice still requires real authorization in the system that retrieves it.
- A refresh rule: documented. Record a maximum age from 1 to 365 days for each included source. For fast-changing data, refresh it at retrieval time; this daily rule is only a planning aid.
- Instructions separated from evidence: documented. Untrusted material placed in the initial context needs review. Retrieved material also remains untrusted; retrieval does not make it an instruction.
- An identified authority: documented. Identify at least one owner-approved task or policy source. This tool records your designation; it cannot verify that the source is authoritative.
- A decision before external changes: documented. If the proposed agent can make changes, name who approves consequential actions and where that decision is enforced.
- A useful way to stop: documented. Describe what happens when information is absent, stale, conflicting, or outside the allowed scope.
- More than a happy path: documented. Write at least two concrete cases, one per line. Include a failure or boundary case; the tool checks their presence, not whether they are good tests.
- A next-session handoff: documented. Name the decisions, evidence, unfinished work, and next owner that must survive a session reset.
Created with Context Harness, a public resource by LockedIn Labs.
https://contextharness.ai/
From the field notebook
The thinking behind the tool. Practical notes by Sam M. Sweilem . Clear sources, worked examples, and an opinion about what makes the next decision easier.
FIELD NOTE / 01 6 min
Context design
Give an agent a way to find the right evidence, and a clear reason to stop looking.
↗ FIELD NOTE / 02 6 min
Practical evaluation
A successful answer tells you less than a carefully chosen case the system must refuse, qualify, or hand back.
↗ FIELD NOTE / 03 5 min
Continuity
Leave enough information for the next session to resume the work without guessing about its current state.
↗ Take the plan into practice
A brief is the beginning. Use AI SDLC to connect the design to delivery, Training to build the skills, and FDE Benchmark to practice evaluating your work. For an enterprise implementation, talk to LockedIn Labs .
