feat: work-on-goal auto-creates a missing goal on not_found

[bborbe]

Summary

Make /vault-cli:work-on-goal behave like /vault-cli:work-on-task on a miss: when the goal is not found in any source, it always creates the goal page (via Skill: vault-cli:create-goal) and then proceeds with work preparation, instead of erroring with "suggest creating the goal".

Changes

• agents/work-on-goal-assistant.md: emits a structured not_found: verdict (with Suggested goal name: — Jira summary when the input is a Jira key) and stops; the agent no longer holds the create path. Also finds existing goals by jira: frontmatter and resolves Jira summaries via mcp__atlassian__getJiraIssue.
• commands/work-on-goal.md: new Phase 4 — Handle not_found (always create) mirroring work-on-task Phase 4 (non-interactive gate, parse SUGGESTED_NAME, Skill: vault-cli:create-goal, re-invoke assistant on success). Added Skill/MODE parsing to the command.
• commands/work-on.md: note updated — the goal route now shares find-or-create.

Behavior

• /vault-cli:work-on-goal → create goal if needed
• /vault-cli:work-on-task → create task if needed (already existed)
• /vault-cli:work-on → create goal or task if needed (already existed for free text; unchanged)

make precommit passes (markdown-only change; no binary change).

[ben-s-pull-request-reviewer]

Now I have all the information needed. Let me do the in-session classify and adjudicate:

CLASSIFY (Step 4c-sel):

Changed files: CHANGELOG.md, agents/work-on-goal-assistant.md, commands/work-on-goal.md, commands/work-on.md

Candidates from Step 4b-i (matching triggers):

• agent-cmd/agent-frontmatter → trigger agents/**/*.md → applicable (modified agents/work-on-goal-assistant.md)
• agent-cmd/command-frontmatter → trigger commands/**/*.md → applicable (modified commands/work-on-goal.md, commands/work-on.md)
• agent-cmd/command-thin → trigger agents/**/*.md, commands/**/*.md → applicable (all three)
• agent-cmd/gap-driven-feedback → trigger agents/**/*.md, commands/**/*.md → applicable (all three)
• agent-cmd/no-user-prompts → trigger agents/**/*.md, commands/**/*.md → applicable (all three)
• agent-cmd/single-source-of-truth → trigger agents/**/*.md, commands/**/*.md → applicable (all three)
• changelog/conventional-prefix-required → trigger CHANGELOG.md → applicable (CHANGELOG.md modified)

ADJUDICATE (Step 4d-sel): No violations found except agent-cmd/command-thin.

Now let me produce the consolidated report and JSON verdict:

---

PR Review: feat: work-on-goal auto-creates a missing goal on not_found

Must Fix (Critical)

None.

Should Fix (Important)

• commands/work-on-goal.md — Phase 4 (Handle not_found) is ~25 lines of imperative logic embedded in the command that should live in the agent. This mirrors the exact command-thin anti-pattern: argument parsing, branching on assistant verdict, extracting SUGGESTED_NAME via regex, invoking Skill: vault-cli:create-goal, re-invoking the assistant. The agent (work-on-goal-assistant.md) already has the not_found: output format defined; it could emit the SUGGESTED_NAME as structured metadata rather than a prose line that requires fragile regex extraction. The command should be a thin orchestrator (~10 lines: parse mode, invoke agent, branch on not_found: vs Ready to work on this task., delegate Phase 3/4 to agent steps). (rule: agent-cmd/command-thin)

Nice to Have (Optional)

• agents/work-on-goal-assistant.md — The not_found: output format uses a prose Suggested goal name: line whose value is extracted via a simple regex in the calling command. This is fragile if the agent output format drifts (e.g., extra whitespace, different capitalization). Consider emitting SUGGESTED_NAME: <value> on its own line as a structured field to make extraction unambiguous and non-regex-based. (rule: agent-cmd/single-source-of-truth — no authoritative single source for name derivation; the command falls back to raw input when Jira is unavailable, and the extraction is implementation-sensitive)

Notes

• commands/work-on.md — The Notes section says "work-on-task.md and work-on-goal.md are functional aliases." This is slightly stale: work-on-goal.md now has Phase 4 (find-or-create) while work-on-task.md is unchanged. The note's substance is still correct (no code shared, each command is independent), but the "functional aliases" framing could mislead future editors. Suggest: "work-on-task.md and work-on-goal.md share the find-or-create pattern; work-on dispatches to the appropriate command."
• Security concern re: Jira MCP tools exposing sensitive data — reviewed the diff: mcp__atlassian__getJiraIssue is called only for Jira-key inputs and the summary is used for the suggested name. No credentials or tokens appear in assistant output. Concern addressed.
• Changelog bullet uses feat: prefix — correct per changelog/conventional-prefix-required.
• agent-cmd/no-user-prompts — Phase 4 creates goals via Skill: vault-cli:create-goal, which is interactive. The command correctly gates this behind MODE=non_interactive (skips create, prints info and stops). In interactive mode, the create-goal skill's own interactive prompts are the intended UX — this is not an unattended-flow violation. No finding.

Traceability (Selector Mode)

• Candidates: 7 rules matched by Step 4b-i glob filter
• Applicable: 7 rules selected by Step 4c-sel (all triggered by changed files)
• Skipped: none

---

Selector Mode Traceability

• Candidates: 7 rules matched by Step 4b-i glob filter
• Applicable: 7 rules selected by Step 4c-sel
• Skipped: none

{
  "verdict": "approve",
  "summary": "Feature is well-designed: Phase 4 find-or-create mirrors work-on-task's established pattern, the not_found verdict is structured, non-interactive mode is properly gated, and the Jira integration is correctly scoped. One should-fix: Phase 4's imperative logic (name extraction, skill invocation, re-invocation) should live in the agent rather than the command, per agent-cmd/command-thin. A nice-to-have: emit SUGGESTED_NAME as a structured field instead of a prose line requiring regex extraction.",
  "comments": [
    {
      "file": "commands/work-on-goal.md",
      "line": 30,
      "severity": "major",
      "message": "Phase 4 (Handle not_found, ~25 lines) is imperative logic embedded in the command that should live in the agent layer. The agent already defines the not_found verdict format; it could emit SUGGESTED_NAME as structured metadata and own the create-goal invocation, making the command a thin orchestrator (~10 lines: parse mode, invoke agent, branch on verdict). This is the canonical command-thin violation: detection logic in the command instead of the agent."
    },
    {
      "file": "agents/work-on-goal-assistant.md",
      "line": 202,
      "severity": "nit",
      "message": "The not_found block's Suggested goal name: is a prose field extracted via regex. If the agent output format drifts (whitespace, capitalization), extraction breaks silently. Consider emitting SUGGESTED_NAME as a dedicated structured field (e.g., SUGGESTED_NAME: <value>) for unambiguous, non-regex parsing by the calling command."
    }
  ],
  "concerns_addressed": [
    "correctness: Phase 4 not_found parsing and re-invocation flow reviewed — no partial state on cancel; failure path is clean",
    "correctness: SUGGESTED_NAME extraction via regex is fragile (raised as nit, not critical — create-goal skill provides safety net)",
    "security: Jira MCP tools — no credentials/tokens logged in assistant output; API calls are intentional feature"
  ]
}