feat: inject decision tool instruction into system prompt
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 76/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- javascript
- Ambito
- ai
Direzione di ricerca
Parti da src/memory/prompts.js in loadSystemPrompt(), che carica già la config e legge prompts/SYSTEM_PROMPT.md (frontmatter rimosso) — è l'unico punto per lo scambio del token. Inserisci un placeholder non numerato <!-- DECISION_TOOL_INSTRUCTION --> vicino all'inizio IDENTITY/OPERATING PRINCIPLES di prompts/SYSTEM_PROMPT.md, e rispecchia la gate di abilitazione usata dal caso decision in buildToolConfig() in src/tools/index.js (config.agent.decision.baseUrl non vuoto). Aggiungi i test in tests/unit/prompts.test.js per entrambi i casi, abilitato (istruzione presente, token assente) e disabilitato (token e istruzione assenti), poi esegui npm run test, npm run lint, npm run coverage. Nota la nota su OpenSpec: l'autore chiede approvazione prima di implementare, quindi conferma prima la proprietà.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
When the decision tool is enabled (config agent.decision.baseUrl is set), inject a conditional instruction block into the system prompt so the agent knows the tool exists and how to use it. When the tool is disabled, the instruction is removed entirely.
Motivation
The decision tool is config-gated: it only registers when agent.decision.baseUrl is set (see src/tools/index.js). But the system prompt (prompts/SYSTEM_PROMPT.md) never mentions it. So when the tool IS enabled, the agent has no guidance on when or how to use it — it may not reach for it at all, or may misuse it. Conversely, when the tool is disabled, the prompt must not reference it (a dangling mention of a tool that doesn't exist is noise and can mislead the model).
The fix is to make the system prompt conditional on config: inject the instruction when enabled, remove it when disabled.
Proposed Solution
Use a string-replace token in prompts/SYSTEM_PROMPT.md that loadSystemPrompt() swaps for either the instruction text (when the decision tool is enabled) or an empty string (when disabled).
- Add a placeholder token in
prompts/SYSTEM_PROMPT.mdnear the top of the prompt (e.g., in the IDENTITY or OPERATING PRINCIPLES area). - In
src/memory/prompts.js,loadSystemPrompt()reads the config, checks whether the decision tool is enabled (config.agent.decision.baseUrlis non-empty), and replaces the token with the instruction or removes it. - The instruction must NOT be a numbered directive. If it were numbered (e.g., "41. Use the decision tool..."), disabling the tool would leave a gap in the numbered list (e.g., 40, 42). It should be a standalone, unnumbered block that sits near the top.
Example token and replacement:
<!-- DECISION_TOOL_INSTRUCTION -->
When enabled, replace with a short block like:
**Decision tool:** A `decision` tool is available for fast, structured classification (routing, policy checks, rubric scoring). It accepts a `state` and a `questions` record, where each question has a `type` (`choice`, `noul`, or `score`), `instructions`, and optional `criteria`. Use it when you need a quick, deterministic judgment from a local model rather than reasoning it out yourself.
When disabled, replace with an empty string so no trace remains.
Alternatives Considered
- Hardcode the instruction always — Rejected: references a tool that may not be registered, misleading the model and adding noise.
- Inject via a separate prompt file — Rejected: adds indirection; a single token in the existing prompt is simpler and keeps the prompt self-contained.
- Numbered directive — Rejected: creates gaps in the numbered list when the tool is disabled.
OpenSpec Note
This project uses OpenSpec for feature development. If this request is approved, I will:
- Run
/opsx:proposeto generate a full proposal with specs and tasks - Iterate on the design before any code is written
- Follow the task-driven implementation workflow
Additional Context
Relevant files:
prompts/SYSTEM_PROMPT.md— the system prompt that needs the token.src/memory/prompts.js—loadSystemPrompt()reads the prompt and appends memory context; this is where the token replacement belongs.src/tools/index.js— thedecisioncase inbuildToolConfig()gates registration onruntimeOptions.decisionConfig?.baseUrl.src/config/schemas/agent.js—DecisionSchemadefinesbaseUrl(default""),model,temperature.config.yaml—agent.decision.baseUrlis""by default (tool not registered).tests/unit/prompts.test.js— existing tests forloadSystemPrompt(); new tests should cover token replacement when enabled and disabled.
Audit Findings (for Issue #1316)
- File:
prompts/SYSTEM_PROMPT.md— the system prompt is 149 lines. The IDENTITY block (top) and OPERATING PRINCIPLES section are the natural home for a conditional instruction. A good insertion point is near the top, after the IDENTITY block or as a standalone block in OPERATING PRINCIPLES, so it is not buried in a numbered list. src/memory/prompts.js—loadSystemPrompt(baseDir = cwd)readsprompts/SYSTEM_PROMPT.md, strips YAML frontmatter, then appends memory context. This is the single place to do the token replacement. It already importsloadConfig()(used forcwd), so the config is available.src/tools/index.js— thedecisioncase inbuildToolConfig()registers the tool only whenruntimeOptions.decisionConfig?.baseUrlis truthy.decisionConfigis set fromconfig?.agent?.decision. This is the exact same gate the prompt injection must mirror: enabled iffconfig.agent.decision.baseUrlis non-empty.src/config/schemas/agent.js—DecisionSchemadefinesbaseUrl(default""),model(default"tev1:4b"),temperature(default0).agent.decisiondefaults to{}, soconfig.agent.decision.baseUrlisundefined/""when unset.config.yaml—agent.decision.baseUrlis""by default (tool not registered). Setting it to a real Ollama URL enables the tool.src/agent/deepAgents.js—createDeepAgentsOrchestrator()callsloadSystemPrompt()at line 304 and appends AGENTS.md. The token replacement happens insideloadSystemPrompt(), so this caller needs no change.tests/unit/prompts.test.js— existing tests cover frontmatter stripping, context appending, and missing-file handling. New tests should cover: (a) token replaced with instruction whenagent.decision.baseUrlis set, (b) token removed (empty) whenagent.decision.baseUrlis empty/unset.
Fix Steps
- Add the token — In
prompts/SYSTEM_PROMPT.md, insert a placeholder token (e.g.,<!-- DECISION_TOOL_INSTRUCTION -->) near the top of the prompt, as a standalone unnumbered block. Do NOT make it a numbered directive — a numbered entry would leave a gap in the list when the tool is disabled. - Add the instruction text — Define the instruction block (the text that replaces the token when the tool is enabled). Keep it concise and unnumbered. It should describe what the
decisiontool does and when to use it. - Wire the replacement — In
src/memory/prompts.js, insideloadSystemPrompt(), readconfig.agent.decision.baseUrl. If it is non-empty, replace the token with the instruction; otherwise replace it with an empty string. UseString.prototype.replaceAll()or a regex to swap the token. - Add unit tests — In
tests/unit/prompts.test.js, add tests that:- Mock config with
agent.decision.baseUrlset → assert the instruction text is present and the token is gone. - Mock config with
agent.decision.baseUrlempty/unset → assert the token is removed and no instruction text remains.
- Mock config with
- Verify — Run
npm run test,npm run lint, andnpm run coverageto confirm everything passes and coverage is maintained.
- Lingua principale
- JavaScript
- Stelle
- 2
- Fork
- 0
- Merge medio
- 1h 17m
- PR unite (30g)
- 242
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di avoidwork/madz
-
feat: add config-driven MCP server tool registrationForse già presa @avoidwork l’ha presa oggi. Apertaapproved feature in progress
Difficoltà 5/5 Più di una settimana Idoneità per principianti 12/100
I maintainer di solito rispondono entro 1 giorno
-
feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di avoidwork/madz
Issue simili
-
`yarn vitest:update` (documented) throws locally; local Cypress scripts target an unserved portAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
rescript-lang/rescript-lang.org#1415 ·
I maintainer di solito rispondono entro 2 giorni
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
Deepak3699/Ai_Mentor#244 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
antithesishq/bombadil#361 ·
I maintainer di solito rispondono entro 1 giorno
-
ungroomed
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
dequelabs/axe-core#5455 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
DietrichGebert/ponytail#1072 ·
I maintainer di solito rispondono entro 3 giorni