Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

feat: inject decision tool instruction into system prompt

Cerrado Apto para principiantes
#1,316 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
76/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript
Área
ai

Línea de trabajo

Empieza en src/memory/prompts.js en loadSystemPrompt(), que ya carga la configuración y lee prompts/SYSTEM_PROMPT.md (frontmatter eliminado) — ese es el único lugar para el intercambio del token. Inserta un marcador de posición sin numerar <!-- DECISION_TOOL_INSTRUCTION --> cerca de la parte superior de IDENTITY/OPERATING PRINCIPLES de prompts/SYSTEM_PROMPT.md, y refleja la compuerta de habilitación que usa el caso decision en buildToolConfig() en src/tools/index.js (config.agent.decision.baseUrl no vacío). Añade pruebas en tests/unit/prompts.test.js para los casos habilitado (instrucción presente, token ausente) y deshabilitado (token e instrucción ausentes), y luego ejecuta npm run test, npm run lint, npm run coverage. Ten en cuenta la nota de OpenSpec: el autor pide aprobación antes de implementar, así que confirma primero la autoría.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
JavaScript
Estrellas
2
Forks
0
Merge medio
1 h 17 min
PR fusionados (30 d)
242

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de avoidwork/madz

Todos los issues de avoidwork/madz

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.