docs(6856): the plugin's guidance and the docs say what a session may do in another project
CI & Build / Python lint (push) Successful in 2s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / TypeScript typecheck (push) Successful in 31s
CI & Build / Python tests (push) Failing after 1m29s
CI & Build / integration (push) Successful in 2m21s
CI & Build / Build & push image (push) Skipped
CI & Build / Python lint (push) Successful in 2s
CI & Build / Plugin hooks (push) Successful in 11s
CI & Build / TypeScript typecheck (push) Successful in 31s
CI & Build / Python tests (push) Failing after 1m29s
CI & Build / integration (push) Successful in 2m21s
CI & Build / Build & push image (push) Skipped
using-grimoire, which owns cross-project conduct, now says the one change to make toward another project is filing an issue with how it was found and the evidence, and that the plugin asks before anything more. The features page describes the fence. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -280,7 +280,12 @@ bound — confine the session to it:
|
||||
- **Only reference or offer work on the in-scope project.** Don't surface,
|
||||
suggest, or start work on other projects unless the operator explicitly widens
|
||||
scope.
|
||||
- If something clearly belongs to a *different* project, say so and **ask before
|
||||
- **Toward another project, the one change to make is filing an issue**:
|
||||
`create_task(project_id=<theirs>, kind="issue")`, carrying how you found it
|
||||
and the evidence. Editing its files, committing or pushing in its repo, and
|
||||
changing its other records are the operator's call, and the plugin asks them
|
||||
before any of those runs. Reading anything there is fine.
|
||||
- If the work itself belongs to a *different* project, say so and **ask before
|
||||
switching** — never silently operate cross-project.
|
||||
|
||||
## Read these when the moment comes
|
||||
|
||||
Reference in New Issue
Block a user