feat(instructions): fit the delivery fold — 2k server map, floor Systems reflex, write-time systems_hint
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 7s
CI & Build / integration (push) Successful in 18s
CI & Build / TypeScript typecheck (push) Successful in 32s
CI & Build / Python tests (push) Successful in 47s
CI & Build / Build & push image (push) Successful in 28s
CI & Build / Python lint (push) Successful in 3s
CI & Build / Plugin hooks (push) Successful in 7s
CI & Build / integration (push) Successful in 18s
CI & Build / TypeScript typecheck (push) Successful in 32s
CI & Build / Python tests (push) Successful in 47s
CI & Build / Build & push image (push) Successful in 28s
Claude Code injects only the first ~2,048 chars of an MCP server's instructions and silently cuts the rest mid-word (#2562, observed live): _INSTRUCTIONS was 20,002 chars, so ~90% — including all Systems tagging guidance — never reached any session. Rearchitect delivery around what each surface actually delivers: - _INSTRUCTIONS becomes a 1,997-char purpose-sorted map, with a header comment stating the budget and where detail belongs instead. - Tool docstrings keep the per-tool HOW (audit: nearly all displaced topics were already duplicated there); backfill the four gaps — enter_project session scoping + project bootstrap, create_rule entity-vs-rule test, create_design_system not-a-rulebook, create_system two-records test. - The plugin static context (the delivery floor) gains the tag-to-Systems reflex and a surfaces-layering statement; plugin 0.1.25 -> 0.1.26 so the executing cache refreshes (#2209). - create_task / create_note / create_snippet return a systems_hint when a record is created untagged in a project that has Systems — in-band at the exact write it applies to, fail-open like the dedup gate. - Guards: _INSTRUCTIONS length budget, floor-states-the-reflex, and a displaced-topics sweep asserting every cut topic still lives on a delivered surface. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -1,7 +1,7 @@
|
||||
{
|
||||
"name": "scribe",
|
||||
"description": "Scribe system-of-record for Claude Code: MCP tools over your notes/tasks/projects/rules, a session-start push channel that surfaces your always-on rules + active-project context, process-skills (writing-plans, systematic-debugging, verification, brainstorming, reusing-code), and your saved Scribe Processes auto-surfaced as skills (/scribe:sync). Replaces superpowers + file-memory with one app-backed plugin.",
|
||||
"version": "0.1.25",
|
||||
"version": "0.1.26",
|
||||
"author": { "name": "Bryan Van Deusen" },
|
||||
"mcpServers": {
|
||||
"scribe": {
|
||||
|
||||
@@ -37,6 +37,14 @@ 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.
|
||||
- **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 area it is about and pass `system_ids`; if the area has
|
||||
no System yet, create it with `create_system` (name + a one-paragraph
|
||||
charter) rather than leaving it unmodelled. A record about no particular
|
||||
area takes none — don't force it. Untagged writes in a project that has
|
||||
Systems come back with a `systems_hint` naming them — treat it as the tagging
|
||||
question asked at exactly the right moment, not as noise to skip past.
|
||||
- **Reuse before rebuilding** — before writing a new helper/utility/component,
|
||||
search recorded **snippets** (reusable code recorded once for recall) and
|
||||
reuse the prior art instead of re-solving it; when you build something
|
||||
@@ -51,6 +59,14 @@ for the operator's work, and as your own working memory across sessions.
|
||||
`/compact` (name what you logged). You can't run it yourself — surface the
|
||||
recommendation and let them decide. Suggest it at seams, not every turn.
|
||||
|
||||
**How the instruction surfaces divide the work:** this file carries the
|
||||
session-level reflexes (WHEN to reach for Scribe); each tool's own description
|
||||
carries its full contract (HOW to call it — read it when you load the tool);
|
||||
the bundled skills carry process arcs (planning, debugging, verification). The
|
||||
MCP server's instruction block is deliberately only a map — the client injects
|
||||
roughly its first 2,000 characters and silently cuts the rest, so nothing
|
||||
load-bearing lives below that fold.
|
||||
|
||||
**If two Scribe instruction surfaces disagree** — this file, the MCP server's
|
||||
tool instructions, the `using-scribe` skill — **follow the one that assumes
|
||||
least about its own delivery.** This file is the floor: it ships with the
|
||||
|
||||
Reference in New Issue
Block a user