feat(409): the reporting reflex reaches every surface a session reads (#4012)
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 53s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m28s
CI & Build / Build & push image (push) Successful in 31s
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 12s
CI & Build / integration (push) Successful in 53s
CI & Build / TypeScript typecheck (push) Successful in 55s
CI & Build / Python tests (push) Successful in 1m28s
CI & Build / Build & push image (push) Successful in 31s
Step 3 of milestone 409 "Response shapes". Step 2's reporting-back skill only helps if it fires, and only exists in the Claude Code plugin. - scribe_static_context.md and using-scribe (new reflex 11) say: report back in a shape the operator can read, placed from the `placement` block rather than memory, and point at the reporting-back skill. using-scribe also lists it among the sibling process-skills. - update_task returns a one-line `report_back` cue when a task is closed (done or cancelled). A tool response is the only surface every MCP client sees, at the moment the report is about to be written. - _INSTRUCTIONS takes no line: there is no budget without trading out a session-start reflex. The decision is recorded in server.py's comment block so it is not re-litigated blind. - Guards: test_instruction_surfaces_agree pins the reflex and the placement pointer on both plugin surfaces; a tool test pins the cue on closing statuses and its absence on every other update. Plugin version minted. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -55,6 +55,12 @@ for the operator's work, and as your own working memory across sessions.
|
||||
moment it's complete. When you **fix** something — even in passing — record it
|
||||
as its own issue (`create_task(kind="issue")`), not as a work-log line on an
|
||||
unrelated open task.
|
||||
- **Report back in a shape the operator can read** — they were not there while
|
||||
you worked, so organise each reply around where the work stands rather than
|
||||
the order you did things in: which task or milestone it belongs to, what now
|
||||
works, what needs them, what comes next. Take the placement from the
|
||||
`placement` block task writes return, not from memory. The `reporting-back`
|
||||
skill holds the shape for each kind of reply.
|
||||
- **Tag to Systems as you write** — `enter_project` lists the project's
|
||||
Systems (its named subsystems/areas). When you create or meaningfully update
|
||||
a record, ask which areas it is about and pass `system_ids`; if an area has
|
||||
|
||||
Reference in New Issue
Block a user