contextSAFE

A knowledge workflow for engineering teams and their AI agents: turn code, documents and notes into reviewed, versioned knowledge with traceable evidence.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: context
description: Use when the user explicitly invokes Context, asks to reorganize an existing Context knowledge map or website navigation, or continues a Context workflow to build, inspect, update, recover or package knowledge. Do not auto-start for ordinary planning, design or coding.
allowed-tools:
  - Bash
---

# Context

Context turns selected sources into reviewed knowledge and packages for readers
and Agents. The CLI supplies the current workflow, commands and required
reading; use it for workspace writes.

## Start here

1. Confirm the request activates this entry ([When to activate](#when-to-activate)).
2. Understand the request and read any user-designated task brief before choosing
   the target workspace or initializing it ([Follow a brief from a file](#follow-a-brief-from-a-file)).
3. Send requests that belong to another entry there first: external associations,
   same-repository docs and Skills, project-scale planning or stuck-task recovery
   ([Route requests that use another entry](#route-requests-that-use-another-entry)).
4. Run `context entry` for that target and follow its `next_action.command`
   ([Enter the workspace](#enter-the-workspace)).
5. Match the request to the current work before registering anything
   ([Match the request to the current work](#match-the-request-to-the-current-work)).
6. Treat `workflow.current` as the current-step authority: read its required
   resources and execute its commands ([Follow the current Route](#follow-the-current-route)).
7. Decide Gates with the [Confirmation policy](#confirmation-policy) and report
   with the [progress format](#report-progress-and-outcomes).

## When to activate

Activate this entry only when the user invokes the Context command or Skill,
or explicitly starts a Context knowledge workflow in this conversation.
An explicit request to adjust an existing Context website's navigation or
knowledge map also activates this entry, including after production is complete.
Related follow-up requests need no repeated invocation. Ordinary planning,
design, coding, document editing or discussion of Context implementation does
not activate it. A workspace, source file, MR or matching phrase alone is not
an activation signal; unrelated work stays outside an active Context task.

Workspace knowledge queries and source attribution have a separate, explicitly
invoked `context-inspect-search` entry. Do not auto-launch it from production
progress or ordinary questions. When the user accepts its update suggestion,
use this production workflow's current Route and preserve existing work.

## Route requests that use another entry

### Knowledge, same-repository content and external content

Context handles content in three ways. Only knowledge produces new text; the
other two are entrances to originals maintained where they already live.

| Kind | What Context keeps | Entry |
| --- | --- | --- |
| knowledge | Reader-oriented articles produced from captured `sources`, each claim traceable to its original | This production workflow |
| repo-content | Registered locations and a symlink view of same-repository README, docs and authored Skills; no copied text | `context-repo-content` |
| imports | Name, purpose, version and link of other teams' knowledge, other repositories' material, external Skills or plugins | [imports](references/imports.md) |

Classify a request in this order:

1. Code is analyzed and indexed into knowledge as a source, including code from
   other repositories.
2. Material that must be reorganized around a reader task is captured into
   `sources` and produced as knowledge, wherever it lives.
3. Otherwise, README, docs and authored Skills in the same Git repository as the
   Context workspace are repo-content. "Same repository" is about Git, not the
   network or a local clone. Installed external Skills remain external even inside
   the repository, and docs or Skills of another repository are never repo-content.
4. Everything else is an import.

A registration or association is an entrance, not evidence: it does not show that
the content was read, verified or is usable by the reader. Links from knowledge to
imports are navigation; a conclusion that depends on external content requires
capturing that content into `sources`.

For long-term association of external knowledge, Skills or plugins, maintain
`imports.yaml` through [imports](references/imports.md); registration alone does
not enter production. Incidental reads do not register dependencies.

For creating, editing or registering same-repository docs and authored Skills,
use `context-repo-content` instead of starting production. Originals stay in their
project directories; registration/editing does not authorize knowledge updates.
During authorized onboarding, select only the current project's conventional
README/docs/Skill locations, with ownership and workspace boundaries from that
skill. Do not capture registered originals into sources merely to duplicate them
as knowledge. Explicit audience-oriented rewriting remains ordinary production.

### Project-scale work

For an authorized knowledge-production request involving more than 30 original
documents or at least two repositories needing substantive investigation, use
the installed `context-plan` Skill before registering the full request. Also use
it for multi-repository baseline updates and broad document-change scans. Count
the requested change, not all historical workspace sources; repositories used
only as existing reference material do not count as new investigation. A large
single repository or long document may warrant planning by module or chapter.
For a new knowledge project with unclear boundaries or several deliveries,
recommend that Skill. A new chat or cold sandbox alone is not a project-scale
trigger. Ordinary questions, capture-only requests and small bounded updates
retain their existing entry.

`context-plan` investigates authorized sources in temporary storage and creates
a hu

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (2)

AGENTS.md

packages/context-cli/AGENTS.md

Gates applied: no_behavioural_pass.