versun/claude-code
1
0
Fork 0
mirror of https://github.com/claude-code-best/claude-code.git synced 2026-06-15 12:55:51 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #446 from claude-code-best/feature/prompt-cut-down

Browse Source 
feat: 大量系统提示词优化
This commit is contained in:
claude-code-best
2026-05-10 15:30:34 +08:00
committed by GitHub
parent 3f0f699ca4 2006ab25ff
commit 998890b469
16 changed files with 175 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
src/components/Messages.tsx
View File

@@ -1,5 +1,6 @@
import { feature } from 'bun:bundle';
import chalk from 'chalk';
import { SentryErrorBoundary } from './SentryErrorBoundary.js';
import type { UUID } from 'crypto';
import type { RefObject } from 'react';
import * as React from 'react';
@@ -890,7 +891,7 @@ const MessagesImpl = ({
);
return (
<>
<SentryErrorBoundary name="MessagesBoundary">
{/* Logo */}
{!hideLogo && !(renderRange && renderRange[0] > 0) && <LogoHeader agentDefinitions={agentDefinitions} />}
@@ -977,7 +978,7 @@ const MessagesImpl = ({
/>
</Box>
)}
</>
</SentryErrorBoundary>
);
};

38
src/components/SentryErrorBoundary.ts
View File

@@ -1,38 +0,0 @@
import * as React from 'react'
import { captureException } from 'src/utils/sentry.js'
interface Props {
children: React.ReactNode
/** Optional label for identifying which component boundary caught the error */
name?: string
}
interface State {
hasError: boolean
}
export class SentryErrorBoundary extends React.Component<Props, State> {
constructor(props: Props) {
super(props)
this.state = { hasError: false }
}
static getDerivedStateFromError(): State {
return { hasError: true }
}
componentDidCatch(error: Error, errorInfo: React.ErrorInfo): void {
captureException(error, {
componentBoundary: this.props.name || 'SentryErrorBoundary',
componentStack: errorInfo.componentStack,
})
}
render(): React.ReactNode {
if (this.state.hasError) {
return null
}
return this.props.children
}
}

62
src/components/SentryErrorBoundary.tsx Normal file
View File

@@ -0,0 +1,62 @@
import * as React from 'react';
import { Box, Text } from '@anthropic/ink';
import { captureException } from 'src/utils/sentry.js';
import { logError } from 'src/utils/log.js';
interface Props {
children: React.ReactNode;
/** Optional label for identifying which component boundary caught the error */
name?: string;
}
interface State {
hasError: boolean;
error: Error | null;
errorInfo: React.ErrorInfo | null;
}
export class SentryErrorBoundary extends React.Component<Props, State> {
constructor(props: Props) {
super(props);
this.state = { hasError: false, error: null, errorInfo: null };
}
static getDerivedStateFromError(error: Error): Pick<State, 'hasError' | 'error'> {
return { hasError: true, error };
}
componentDidCatch(error: Error, errorInfo: React.ErrorInfo): void {
this.setState({ errorInfo });
// Log to stderr so the diagnostic info is visible even in production builds
const boundary = this.props.name || 'SentryErrorBoundary';
const lines = ['', `[ErrorBoundary:${boundary}] React rendering error caught`, ` Message: ${error.message}`];
if (errorInfo.componentStack) {
lines.push(` Component stack:\n${errorInfo.componentStack}`);
}
// eslint-disable-next-line no-console -- intentional stderr diagnostic output
console.error(lines.join('\n'));
logError(error);
captureException(error, {
componentBoundary: boundary,
componentStack: errorInfo.componentStack,
});
}
render(): React.ReactNode {
if (this.state.hasError) {
return (
<Box flexDirection="column" paddingX={1} paddingY={1}>
<Text color="error" bold>
React Rendering Error
</Text>
<Text color="error">{this.state.error?.message}</Text>
{this.props.name && <Text dimColor>Boundary: {this.props.name}</Text>}
</Box>
);
}
return this.props.children;
}
}

16
src/constants/promptEngineeringAudit.runner.ts
View File

@@ -424,8 +424,8 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
test('includes anti-postamble guidance', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('Do not restate')
expect(prompt).toContain('the user can read the diff')
expect(prompt).toContain("don't restate")
expect(prompt).toContain('report the outcome')
})
test('discourages offering unchosen approach', async () => {
@@ -505,19 +505,18 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
describe('#11 Formatting discipline', () => {
test('prompt contains prose-first guidance (existing)', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('direct answer in prose')
expect(prompt).toContain('prose paragraphs')
})
test('discourages over-formatting', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('over-formatting')
expect(prompt).toContain('natural language')
expect(prompt).toContain('simple answers')
})
test('bullet points must be 1-2 sentences, not fragments', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('1-2 sentences')
expect(prompt).toContain('not sentence fragments')
})
})
@@ -613,7 +612,8 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
describe('#15 Conversation end respect', () => {
test('discourages "anything else?" appendages', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('the user will ask if they need more')
expect(prompt).toContain('Do not append')
expect(prompt).toContain('Is there anything else?')
})
})
@@ -656,7 +656,7 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
test('no-machinery-narration: describe in user terms', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain("Don't narrate internal machinery")
expect(prompt).toContain('Describe the action in user terms')
expect(prompt).toContain('describe the action in user terms')
})
test('tool_discovery: search before saying unavailable', async () => {
@@ -669,7 +669,7 @@ describe('Opus 4.7 Prompt Engineering Audit', () => {
test('false-claims mitigation: report outcomes faithfully', async () => {
const prompt = await getFullPrompt()
expect(prompt).toContain('Report outcomes faithfully')
expect(prompt).toContain('report the outcome')
})
test('CYBER_RISK_INSTRUCTION: allows security testing', async () => {

41
src/constants/prompts.ts
View File

@@ -380,41 +380,29 @@ function getSessionSpecificGuidanceSection(
// (upstream ant-only version). The short "Output efficiency" fallback was a
// placeholder for external users; the detailed version produces better UX.
function getOutputEfficiencySection(): string {
return `# Communicating with the user
When sending user-facing text, you're writing for a person, not logging to a console. Assume users can't see most tool calls or thinking - only your text output. Before your first tool call, briefly state what you're about to do. While working, give short updates at key moments: when you find something load-bearing (a bug, a root cause), when changing direction, when you've made progress without an update.
return `# Communication style
Write for a person, not a console. Assume users can't see most tool calls or thinking — only your text output. Before your first tool call, briefly state what you're about to do. While working, give short updates at key moments: when you find something load-bearing, when changing direction, or when you've made progress without an update.
Don't narrate internal machinery. Don't say "let me call Grep", "I'll use SearchExtraTools", "let me snip context", or similar tool-name preambles. Describe the action in user terms ("let me search for the handler", "let me check the current state"), not in terms of which tool you're about to invoke. Don't justify why you're searching — just search. Don't say "Let me search for that file" before a Grep call; the user sees the tool call and doesn't need a preview.
Don't narrate internal machinery. Don't say "let me call Grep" or "I'll use SearchExtraTools" — describe the action in user terms, not in tool names. Don't justify why you're searching — just search.
When making updates, assume the person has stepped away and lost the thread. They don't know codenames, abbreviations, or shorthand you created along the way, and didn't track your process. Write so they can pick back up cold: use complete, grammatically correct sentences without unexplained jargon. Expand technical terms. Err on the side of more explanation. Attend to cues about the user's level of expertise; if they seem like an expert, tilt a bit more concise, while if they seem like they're new, be more explanatory.
When making updates, assume the person has stepped away and lost the thread. Write so they can pick back up cold: complete sentences, no unexplained jargon, expand technical terms. Err on the side of more explanation; attend to the user's expertise level.
Write user-facing text in flowing prose while eschewing fragments, excessive em dashes, symbols and notation, or similarly hard-to-parse content. Only use tables when appropriate; for example to hold short enumerable facts (file names, line numbers, pass/fail), or communicate quantitative data. Don't pack explanatory reasoning into table cells -- explain before or after. Avoid semantic backtracking: structure each sentence so a person can read it linearly, building up meaning without having to re-parse what came before.
Write in flowing prose. Avoid over-formatting: simple answers get prose paragraphs, not headers and bullet lists. Only use bullet points for genuinely independent items that are harder to follow as prose — and each bullet should be at least 1-2 sentences.
What's most important is the reader understanding your output without mental overhead or follow-ups, not how terse you are. If the user has to reread a summary or ask you to explain, that will more than eat up the time savings from a shorter first read. Match responses to the task: a simple question gets a direct answer in prose, not headers and numbered sections. While keeping communication clear, also keep it concise, direct, and free of fluff. Avoid filler or stating the obvious. Get straight to the point. Don't overemphasize unimportant trivia about your process or use superlatives to oversell small wins or losses. Use inverted pyramid when appropriate (leading with the action), and if something about your reasoning or process is so important that it absolutely must be in user-facing text, save it for the end.
After creating or editing a file, state what you did in one sentence — don't restate the contents or walk through changes. After running a command, report the outcome — don't re-explain what it does. Don't offer unchosen approaches unless asked.
Avoid over-formatting. For simple answers, use prose paragraphs, not headers and bullet lists. Inside explanatory text, list items inline in natural language: "the main causes are X, Y, and Z" — not a bulleted list. Only reach for bullet points when the response genuinely has multiple independent items that would be harder to follow as prose. When you do use bullet points, each bullet should be at least 1-2 sentences — not sentence fragments or single words.
When the task is done, report the result. Do not append "Is there anything else?" or "Let me know if you need anything else."
After creating or editing a file, state what you did in one sentence. Do not restate the file's contents or walk through every change — the user can read the diff. After running a command, report the outcome; do not re-explain what the command does. Do not offer the unchosen approach ("I could have also done X") unless the user asks — select and produce, don't narrate the decision.
If you need to ask the user a question, limit to one question per response. Address the request first, then ask.
When the task is done, report the result. Do not append "Is there anything else?" or "Let me know if you need anything else" — the user will ask if they need more.
If asked to explain something, start with a one-sentence high-level summary. If the user wants more depth, they'll ask.
If you need to ask the user a question, limit to one question per response. Address the request as best you can first, then ask the single most important clarifying question.
Only use emojis if the user explicitly requests it.
Avoid making negative assumptions about the user's abilities or judgment. When pushing back, do so constructively — explain the concern and suggest an alternative.
When referencing code, include file_path:line_number. For GitHub issues/PRs, use owner/repo#123 format.
Do not use a colon before tool calls — "Let me read the file:" should be "Let me read the file." with a period.
If asked to explain something, start with a one-sentence high-level summary before diving into details. If the user wants more depth, they'll ask.
These user-facing text instructions do not apply to code or tool calls.`
}
function getSimpleToneAndStyleSection(): string {
const items = [
`Only use emojis if the user explicitly requests it. Avoid using emojis in all communication unless asked.`,
// Warm tone (#12): constructive pushback, no condescension
`Avoid making negative assumptions about the user's abilities or judgment. When pushing back on an approach, do so constructively — explain the concern and suggest an alternative, rather than just saying "that's wrong."`,
`When referencing specific functions or pieces of code include the pattern file_path:line_number to allow the user to easily navigate to the source code location.`,
`When referencing GitHub issues or pull requests, use the owner/repo#123 format (e.g. anthropics/claude-code#100) so they render as clickable links.`,
`Do not use a colon before tool calls. Your tool calls may not be shown directly in the output, so text like "Let me read the file:" followed by a read tool call should just be "Let me read the file." with a period.`,
].filter(item => item !== null)
return [`# Tone and style`, ...prependBullets(items)].join(`\n`)
These instructions do not apply to code or tool calls.`
}
export async function getSystemPrompt(
@@ -532,7 +520,6 @@ ${CYBER_RISK_INSTRUCTION}`,
: null,
getActionsSection(),
getUsingYourToolsSection(enabledTools),
getSimpleToneAndStyleSection(),
getOutputEfficiencySection(),
// === BOUNDARY MARKER - DO NOT MOVE OR REMOVE ===
...(shouldUseGlobalCacheScope() ? [SYSTEM_PROMPT_DYNAMIC_BOUNDARY] : []),

2
src/context.ts
View File

@@ -17,7 +17,7 @@ import { getBranch, getDefaultBranch, getIsGit, gitExe } from './utils/git.js'
import { shouldIncludeGitInstructions } from './utils/gitSettings.js'
import { logError } from './utils/log.js'
const MAX_STATUS_CHARS = 2000
const MAX_STATUS_CHARS = 1000
// System prompt injection for cache breaking (ant-only, ephemeral debugging state)
let systemPromptInjection: string | null = null

103
src/memdir/memoryTypes.ts
View File

@@ -43,63 +43,22 @@ export const TYPES_SECTION_COMBINED: readonly string[] = [
'<type>',
' <name>user</name>',
' <scope>always private</scope>',
" <description>Contain information about the user's role, goals, responsibilities, and knowledge. Great user memories help you tailor your future behavior to the user's preferences and perspective. Your goal in reading and writing these memories is to build up an understanding of who the user is and how you can be most helpful to them specifically. For example, you should collaborate with a senior software engineer differently than a student who is coding for the very first time. Keep in mind, that the aim here is to be helpful to the user. Avoid writing memories about the user that could be viewed as a negative judgement or that are not relevant to the work you're trying to accomplish together.</description>",
" <when_to_save>When you learn any details about the user's role, preferences, responsibilities, or knowledge</when_to_save>",
" <how_to_use>When your work should be informed by the user's profile or perspective. For example, if the user is asking you to explain a part of the code, you should answer that question in a way that is tailored to the specific details that they will find most valuable or that helps them build their mental model in relation to domain knowledge they already have.</how_to_use>",
' <examples>',
" user: I'm a data scientist investigating what logging we have in place",
' assistant: [saves private user memory: user is a data scientist, currently focused on observability/logging]',
'',
" user: I've been writing Go for ten years but this is my first time touching the React side of this repo",
" assistant: [saves private user memory: deep Go expertise, new to React and this project's frontend — frame frontend explanations in terms of backend analogues]",
' </examples>',
" <description>The user's role, goals, preferences, responsibilities, and knowledge. Use these to tailor your behavior to the user.</description>",
'</type>',
'<type>',
' <name>feedback</name>',
' <scope>default to private. Save as team only when the guidance is clearly a project-wide convention that every contributor should follow (e.g., a testing policy, a build invariant), not a personal style preference.</scope>',
" <description>Guidance the user has given you about how to approach work — both what to avoid and what to keep doing. These are a very important type of memory to read and write as they allow you to remain coherent and responsive to the way you should approach work in the project. Record from failure AND success: if you only save corrections, you will avoid past mistakes but drift away from approaches the user has already validated, and may grow overly cautious. Before saving a private feedback memory, check that it doesn't contradict a team feedback memory — if it does, either don't save it or note the override explicitly.</description>",
' <when_to_save>Any time the user corrects your approach ("no not that", "don\'t", "stop doing X") OR confirms a non-obvious approach worked ("yes exactly", "perfect, keep doing that", accepting an unusual choice without pushback). Corrections are easy to notice; confirmations are quieter — watch for them. In both cases, save what is applicable to future conversations, especially if surprising or not obvious from the code. Include *why* so you can judge edge cases later.</when_to_save>',
' <how_to_use>Let these memories guide your behavior so that the user and other users in the project do not need to offer the same guidance twice.</how_to_use>',
' <body_structure>Lead with the rule itself, then a **Why:** line (the reason the user gave — often a past incident or strong preference) and a **How to apply:** line (when/where this guidance kicks in). Knowing *why* lets you judge edge cases instead of blindly following the rule.</body_structure>',
' <examples>',
" user: don't mock the database in these tests — we got burned last quarter when mocked tests passed but the prod migration failed",
' assistant: [saves team feedback memory: integration tests must hit a real database, not mocks. Reason: prior incident where mock/prod divergence masked a broken migration. Team scope: this is a project testing policy, not a personal preference]',
'',
' user: stop summarizing what you just did at the end of every response, I can read the diff',
" assistant: [saves private feedback memory: this user wants terse responses with no trailing summaries. Private because it's a communication preference, not a project convention]",
'',
" user: yeah the single bundled PR was the right call here, splitting this one would've just been churn",
' assistant: [saves private feedback memory: for refactors in this area, user prefers one bundled PR over many small ones. Confirmed after I chose this approach — a validated judgment call, not a correction]',
' </examples>',
' <description>Guidance from the user about how to approach work — what to avoid and what to keep doing. Record from failure AND success. Include *why* so you can judge edge cases later. Structure content as: rule/fact, then **Why:** and **How to apply:** lines.</description>',
'</type>',
'<type>',
' <name>project</name>',
' <scope>private or team, but strongly bias toward team</scope>',
' <description>Information that you learn about ongoing work, goals, initiatives, bugs, or incidents within the project that is not otherwise derivable from the code or git history. Project memories help you understand the broader context and motivation behind the work users are working on within this working directory.</description>',
' <when_to_save>When you learn who is doing what, why, or by when. These states change relatively quickly so try to keep your understanding of this up to date. Always convert relative dates in user messages to absolute dates when saving (e.g., "Thursday" → "2026-03-05"), so the memory remains interpretable after time passes.</when_to_save>',
" <how_to_use>Use these memories to more fully understand the details and nuance behind the user's request, anticipate coordination issues across users, make better informed suggestions.</how_to_use>",
' <body_structure>Lead with the fact or decision, then a **Why:** line (the motivation — often a constraint, deadline, or stakeholder ask) and a **How to apply:** line (how this should shape your suggestions). Project memories decay fast, so the why helps future-you judge whether the memory is still load-bearing.</body_structure>',
' <examples>',
" user: we're freezing all non-critical merges after Thursday — mobile team is cutting a release branch",
' assistant: [saves team project memory: merge freeze begins 2026-03-05 for mobile release cut. Flag any non-critical PR work scheduled after that date]',
'',
" user: the reason we're ripping out the old auth middleware is that legal flagged it for storing session tokens in a way that doesn't meet the new compliance requirements",
' assistant: [saves team project memory: auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup — scope decisions should favor compliance over ergonomics]',
' </examples>',
' <description>Information about ongoing work, goals, initiatives, bugs, or incidents not derivable from code or git history. Convert relative dates to absolute dates when saving (e.g., "Thursday" → "2026-03-05").</description>',
'</type>',
'<type>',
' <name>reference</name>',
' <scope>usually team</scope>',
' <description>Stores pointers to where information can be found in external systems. These memories allow you to remember where to look to find up-to-date information outside of the project directory.</description>',
' <when_to_save>When you learn about resources in external systems and their purpose. For example, that bugs are tracked in a specific project in Linear or that feedback can be found in a specific Slack channel.</when_to_save>',
' <how_to_use>When the user references an external system or information that may be in an external system.</how_to_use>',
' <examples>',
' user: check the Linear project "INGEST" if you want context on these tickets, that\'s where we track all pipeline bugs',
' assistant: [saves team reference memory: pipeline bugs are tracked in Linear project "INGEST"]',
'',
" user: the Grafana board at grafana.internal/d/api-latency is what oncall watches — if you're touching request handling, that's the thing that'll page someone",
' assistant: [saves team reference memory: grafana.internal/d/api-latency is the oncall latency dashboard — check it when editing request-path code]',
' </examples>',
' <description>Pointers to external systems where information can be found (e.g., Linear projects, Slack channels, Grafana dashboards).</description>',
'</type>',
'</types>',
'',
@@ -107,71 +66,27 @@ export const TYPES_SECTION_COMBINED: readonly string[] = [
/**
* `## Types of memory` section for INDIVIDUAL-ONLY mode (single directory).
* No <scope> tags. Examples use plain `[saves X memory: …]`. Prose that
* only makes sense with a private/team split is reworded.
* No <scope> tags. Prose that only makes sense with a private/team split is reworded.
*/
export const TYPES_SECTION_INDIVIDUAL: readonly string[] = [
'## Types of memory',
'',
'There are several discrete types of memory that you can store in your memory system:',
'',
'<types>',
'<type>',
' <name>user</name>',
" <description>Contain information about the user's role, goals, responsibilities, and knowledge. Great user memories help you tailor your future behavior to the user's preferences and perspective. Your goal in reading and writing these memories is to build up an understanding of who the user is and how you can be most helpful to them specifically. For example, you should collaborate with a senior software engineer differently than a student who is coding for the very first time. Keep in mind, that the aim here is to be helpful to the user. Avoid writing memories about the user that could be viewed as a negative judgement or that are not relevant to the work you're trying to accomplish together.</description>",
" <when_to_save>When you learn any details about the user's role, preferences, responsibilities, or knowledge</when_to_save>",
" <how_to_use>When your work should be informed by the user's profile or perspective. For example, if the user is asking you to explain a part of the code, you should answer that question in a way that is tailored to the specific details that they will find most valuable or that helps them build their mental model in relation to domain knowledge they already have.</how_to_use>",
' <examples>',
" user: I'm a data scientist investigating what logging we have in place",
' assistant: [saves user memory: user is a data scientist, currently focused on observability/logging]',
'',
" user: I've been writing Go for ten years but this is my first time touching the React side of this repo",
" assistant: [saves user memory: deep Go expertise, new to React and this project's frontend — frame frontend explanations in terms of backend analogues]",
' </examples>',
" <description>The user's role, goals, preferences, responsibilities, and knowledge. Use these to tailor your behavior to the user.</description>",
'</type>',
'<type>',
' <name>feedback</name>',
' <description>Guidance the user has given you about how to approach work — both what to avoid and what to keep doing. These are a very important type of memory to read and write as they allow you to remain coherent and responsive to the way you should approach work in the project. Record from failure AND success: if you only save corrections, you will avoid past mistakes but drift away from approaches the user has already validated, and may grow overly cautious.</description>',
' <when_to_save>Any time the user corrects your approach ("no not that", "don\'t", "stop doing X") OR confirms a non-obvious approach worked ("yes exactly", "perfect, keep doing that", accepting an unusual choice without pushback). Corrections are easy to notice; confirmations are quieter — watch for them. In both cases, save what is applicable to future conversations, especially if surprising or not obvious from the code. Include *why* so you can judge edge cases later.</when_to_save>',
' <how_to_use>Let these memories guide your behavior so that the user does not need to offer the same guidance twice.</how_to_use>',
' <body_structure>Lead with the rule itself, then a **Why:** line (the reason the user gave — often a past incident or strong preference) and a **How to apply:** line (when/where this guidance kicks in). Knowing *why* lets you judge edge cases instead of blindly following the rule.</body_structure>',
' <examples>',
" user: don't mock the database in these tests — we got burned last quarter when mocked tests passed but the prod migration failed",
' assistant: [saves feedback memory: integration tests must hit a real database, not mocks. Reason: prior incident where mock/prod divergence masked a broken migration]',
'',
' user: stop summarizing what you just did at the end of every response, I can read the diff',
' assistant: [saves feedback memory: this user wants terse responses with no trailing summaries]',
'',
" user: yeah the single bundled PR was the right call here, splitting this one would've just been churn",
' assistant: [saves feedback memory: for refactors in this area, user prefers one bundled PR over many small ones. Confirmed after I chose this approach — a validated judgment call, not a correction]',
' </examples>',
' <description>Guidance from the user about how to approach work — what to avoid and what to keep doing. Record from failure AND success. Include *why* so you can judge edge cases later. Structure content as: rule/fact, then **Why:** and **How to apply:** lines.</description>',
'</type>',
'<type>',
' <name>project</name>',
' <description>Information that you learn about ongoing work, goals, initiatives, bugs, or incidents within the project that is not otherwise derivable from the code or git history. Project memories help you understand the broader context and motivation behind the work the user is doing within this working directory.</description>',
' <when_to_save>When you learn who is doing what, why, or by when. These states change relatively quickly so try to keep your understanding of this up to date. Always convert relative dates in user messages to absolute dates when saving (e.g., "Thursday" → "2026-03-05"), so the memory remains interpretable after time passes.</when_to_save>',
" <how_to_use>Use these memories to more fully understand the details and nuance behind the user's request and make better informed suggestions.</how_to_use>",
' <body_structure>Lead with the fact or decision, then a **Why:** line (the motivation — often a constraint, deadline, or stakeholder ask) and a **How to apply:** line (how this should shape your suggestions). Project memories decay fast, so the why helps future-you judge whether the memory is still load-bearing.</body_structure>',
' <examples>',
" user: we're freezing all non-critical merges after Thursday — mobile team is cutting a release branch",
' assistant: [saves project memory: merge freeze begins 2026-03-05 for mobile release cut. Flag any non-critical PR work scheduled after that date]',
'',
" user: the reason we're ripping out the old auth middleware is that legal flagged it for storing session tokens in a way that doesn't meet the new compliance requirements",
' assistant: [saves project memory: auth middleware rewrite is driven by legal/compliance requirements around session token storage, not tech-debt cleanup — scope decisions should favor compliance over ergonomics]',
' </examples>',
' <description>Information about ongoing work, goals, initiatives, bugs, or incidents not derivable from code or git history. Convert relative dates to absolute dates when saving (e.g., "Thursday" → "2026-03-05").</description>',
'</type>',
'<type>',
' <name>reference</name>',
' <description>Stores pointers to where information can be found in external systems. These memories allow you to remember where to look to find up-to-date information outside of the project directory.</description>',
' <when_to_save>When you learn about resources in external systems and their purpose. For example, that bugs are tracked in a specific project in Linear or that feedback can be found in a specific Slack channel.</when_to_save>',
' <how_to_use>When the user references an external system or information that may be in an external system.</how_to_use>',
' <examples>',
' user: check the Linear project "INGEST" if you want context on these tickets, that\'s where we track all pipeline bugs',
' assistant: [saves reference memory: pipeline bugs are tracked in Linear project "INGEST"]',
'',
" user: the Grafana board at grafana.internal/d/api-latency is what oncall watches — if you're touching request handling, that's the thing that'll page someone",
' assistant: [saves reference memory: grafana.internal/d/api-latency is the oncall latency dashboard — check it when editing request-path code]',
' </examples>',
' <description>Pointers to external systems where information can be found (e.g., Linear projects, Slack channels, Grafana dashboards).</description>',
'</type>',
'</types>',
'',

9
src/replLauncher.tsx
View File

@@ -18,11 +18,14 @@ export async function launchRepl(
renderAndRun: (root: Root, element: React.ReactNode) => Promise<void>,
): Promise<void> {
const { App } = await import('./components/App.js');
const { SentryErrorBoundary } = await import('./components/SentryErrorBoundary.js');
const { REPL } = await import('./screens/REPL.js');
await renderAndRun(
root,
<App {...appProps}>
<REPL {...replProps} />
</App>,
<SentryErrorBoundary name="RootREPLBoundary">
<App {...appProps}>
<REPL {...replProps} />
</App>
</SentryErrorBoundary>,
);
}

6
src/services/api/claude.ts
View File

@@ -1391,12 +1391,14 @@ async function* queryModel(
.sort()
.join('\n')
if (deferredToolList) {
// Append to the end of the messages array (not prepend) so it
// never抢占 <project-instructions> (CLAUDE.md) at the front.
messagesForAPI = [
...messagesForAPI,
createUserMessage({
content: `<available-deferred-tools>\n${deferredToolList}\n</available-deferred-tools>\nTo invoke any tool listed above, use ExecuteExtraTool with {"tool_name": "<name>", "params": {...}}. This is the ONLY way to call deferred tools — do not read source code or analyze implementation, just call ExecuteExtraTool directly.`,
content: `<system-reminder>\n<available-deferred-tools>\n${deferredToolList}\n</available-deferred-tools>\nTo invoke any tool listed above, use ExecuteExtraTool with {"tool_name": "<name>", "params": {...}}. This is the ONLY way to call deferred tools — do not read source code or analyze implementation, just call ExecuteExtraTool directly.\n</system-reminder>`,
isMeta: true,
}),
...messagesForAPI,
]
}
}

39
src/utils/api.ts
View File

@@ -452,19 +452,36 @@ export function prependUserContext(
return messages
}
return [
createUserMessage({
content: `<system-reminder>\nAs you answer the user's questions, you can use the following context:\n${Object.entries(
context,
)
.map(([key, value]) => `# ${key}\n${value}`)
.join('\n')}
// Extract claudeMd as a dedicated high-weight user message so it isn't
// buried inside the generic <system-reminder> with the "may or may not be
// relevant" disclaimer, which would degrade its instructional weight.
const { claudeMd, ...rest } = context
const result: Message[] = []
if (claudeMd) {
result.push(
createUserMessage({
content: `<project-instructions>\n${claudeMd}\n</project-instructions>\n`,
isMeta: true,
}),
)
}
const restEntries = Object.entries(rest)
if (restEntries.length > 0) {
result.push(
createUserMessage({
content: `<system-reminder>\nAs you answer the user's questions, you can use the following context:\n${restEntries
.map(([key, value]) => `# ${key}\n${value}`)
.join('\n')}
IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.\n</system-reminder>\n`,
isMeta: true,
}),
...messages,
]
isMeta: true,
}),
)
}
return [...result, ...messages]
}
/**