Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

feat: inject decision tool instruction into system prompt

Chiusa Adatta ai principianti
#1,316 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

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

feature

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.md near 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.baseUrl is 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:

  1. Run /opsx:propose to generate a full proposal with specs and tasks
  2. Iterate on the design before any code is written
  3. 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 — the decision case in buildToolConfig() gates registration on runtimeOptions.decisionConfig?.baseUrl.
  • src/config/schemas/agent.js — DecisionSchema defines baseUrl (default ""), model, temperature.
  • config.yaml — agent.decision.baseUrl is "" by default (tool not registered).
  • tests/unit/prompts.test.js — existing tests for loadSystemPrompt(); 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) reads prompts/SYSTEM_PROMPT.md, strips YAML frontmatter, then appends memory context. This is the single place to do the token replacement. It already imports loadConfig() (used for cwd), so the config is available.
  • src/tools/index.js — the decision case in buildToolConfig() registers the tool only when runtimeOptions.decisionConfig?.baseUrl is truthy. decisionConfig is set from config?.agent?.decision. This is the exact same gate the prompt injection must mirror: enabled iff config.agent.decision.baseUrl is non-empty.
  • src/config/schemas/agent.js — DecisionSchema defines baseUrl (default ""), model (default "tev1:4b"), temperature (default 0). agent.decision defaults to {}, so config.agent.decision.baseUrl is undefined/"" when unset.
  • config.yaml — agent.decision.baseUrl is "" by default (tool not registered). Setting it to a real Ollama URL enables the tool.
  • src/agent/deepAgents.js — createDeepAgentsOrchestrator() calls loadSystemPrompt() at line 304 and appends AGENTS.md. The token replacement happens inside loadSystemPrompt(), 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 when agent.decision.baseUrl is set, (b) token removed (empty) when agent.decision.baseUrl is empty/unset.

Fix Steps

  1. 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.
  2. 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 decision tool does and when to use it.
  3. Wire the replacement — In src/memory/prompts.js, inside loadSystemPrompt(), read config.agent.decision.baseUrl. If it is non-empty, replace the token with the instruction; otherwise replace it with an empty string. Use String.prototype.replaceAll() or a regex to swap the token.
  4. Add unit tests — In tests/unit/prompts.test.js, add tests that:
    • Mock config with agent.decision.baseUrl set → assert the instruction text is present and the token is gone.
    • Mock config with agent.decision.baseUrl empty/unset → assert the token is removed and no instruction text remains.
  5. Verify — Run npm run test, npm run lint, and npm run coverage to 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

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di avoidwork/madz

Tutte le issue di avoidwork/madz

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.