proposal-act

name: proposal-act description: 'Accept, defer, dismiss, or resolve a proposal. For accepted proposals, asks how to proceed: start implementing now, create a session task, or note for manual implementation. Activates on messages like "accept PROP-", "dismiss PROP-", "defer PROP-", "resolve PROP-".'

Proposal Act

Take action on a proposal: accept, defer, dismiss, or resolve.

Usage

/claude-code-hermit:proposal-act accept PROP-019
/claude-code-hermit:proposal-act defer PROP-015
/claude-code-hermit:proposal-act dismiss PROP-012
/claude-code-hermit:proposal-act resolve PROP-008

If no action or ID is provided, ask the operator which proposal and action.

Resolving a Proposal ID

Before reading any proposal file, resolve the operator's input to a filename using this algorithm:

1. Trim whitespace and uppercase the input.
2. Match against /^PROP-(\d+)(?:-(.+))?$/. If no match: error "Not a PROP id."
3. Zero-pad the integer to 3 digits (e.g. PROP-6 → PROP-006).
4. Build the glob pattern. Always anchor: never use bare PROP-NNN*.md (collides with 4-digit NNN files like PROP-0061.md once proposal counts cross 1000).
   • If no suffix (e.g. PROP-006): glob two anchored patterns and union the results: PROP-006.md (legacy exact match) plus PROP-006-*.md (new-format files with that integer).
   • If suffix present (e.g. PROP-006-103612 or PROP-006-capability-brainstorm-103612): glob PROP-006-*<suffix>*.md. The leading -* brackets the slug for timestamp-only inputs; the trailing wildcard catches the a/b/… collision-suffix variant. The disambiguation prompt resolves any over-matches.
5. Glob .claude-code-hermit/proposals/<pattern> (or each pattern in turn for the two-pattern no-suffix case, then union).
6. Count the matches:
   • 0 matches: error "No proposal matches [input]. Use /proposal-list to see available proposals."
   • 1 match: proceed with that file.
   • 2+ matches: show a disambiguation prompt:

     Multiple proposals match PROP-NNN:
       PROP-NNN-capability-brainstorm-103612 — [title of first match]
       PROP-NNN-session-cost-tracking-104207 — [title of second match]
     Reply with the full ID to continue.
     

     Re-resolve with the operator's reply.

Timestamp Convention

All timestamps in frontmatter and Operator Decision text use ISO 8601 with timezone offset (e.g., 2026-04-06T14:30:00+01:00). Use the timezone from config.json if set, otherwise UTC.

Accept Flow

When the operator accepts a proposal:

1. Resolve the proposal file using the resolution algorithm above, then read it.
2. Update the YAML frontmatter: set status to accepted, add accepted_date as timestamp. Do NOT set resolved_date — resolution happens when reflect confirms the pattern is gone. If the file uses old bullet-point metadata (- **Status:**), update that instead. 2b. First-response tracking: Check if the proposal's responded field is already true. If false: set responded: true in frontmatter, then append a responded event:

   bun ${CLAUDE_PLUGIN_ROOT}/scripts/append-metrics.ts .claude-code-hermit/state/proposal-metrics.jsonl '{"ts":"<now ISO>","type":"responded","proposal_id":"PROP-NNN","action":"accept"}'
   

   Then call bun ${CLAUDE_PLUGIN_ROOT}/scripts/generate-summary.ts .claude-code-hermit/state/. If responded is already true, skip the append (prevents double-counting).
3. Append a timestamp to the Operator Decision section:

   Accepted on 2026-04-06T14:30:00+01:00.
   

3a. Session tracking: Read state/runtime.json for session_id and session_state (both are used below). If session_id is non-null, set accepted_in_session to that session ID in the proposal's YAML frontmatter. If no session is active (session_id is null), leave accepted_in_session: null.

3b. Routine proposals. If the proposal metadata contains Type: routine and a ## Config section with a JSON block: - Parse the JSON block. Validate: must have id, schedule, skill, enabled fields. - Check for duplicate id in existing config.json routines array — if found, update the existing entry instead of appending. - If no duplicate found, append the routine entry to config.json routines array. - Respond: "Routine '{id}' added to config. Run /claude-code-hermit:hermit-routines load to register it immediately." - Notify the operator. - Skip step 4 — no further implementation needed.

3c. Success signal (optional). Check whether the proposal body has a ## Success Signal section with a non-empty predicate line (ignore comment lines starting with <!--).

• If a non-empty predicate line is found, validate it:

  bun ${CLAUDE_PLUGIN_ROOT}/scripts/eval-success-signal.ts --validate "<predicate line>"
  

• Exit 0 → set success_signal: <predicate line> in the proposal's YAML frontmatter.
• Exit non-zero → log a one-line warning to SHELL.md Findings: PROP-NNN success_signal ignored: <reason printed by the script>. Leave success_signal: null.
• No ## Success Signal section, or the section is empty / comment-only → leave success_signal: null.
• Never block accept regardless of outcome.

4. Ask: "How should this be implemented?"

   • "Start implementing now" (default, typical answer): run the falsification gate, then handle session lifecycle, then execute in this turn. Falsification gate (runs first, before any session transition). Verify the proposal is actionable as written with a read-only pass. Skip only when the body contains ## Skill Improvement and /skill-creator:skill-creator is in the available-skills list (step (e) routes that to /skill-creator:skill-creator) — if ## Skill Improvement is present but skill-creator is absent, the proposal becomes a code-edit implementation, so the gate runs to produce a PROCEED file list for the dispatch. Also skip if the body contains ## Skill Draft — authoring is delegated to /skill-creator:skill-creator on accept, not a code-edit plan — but first check that the source_artifact path listed in ## Skill Draft exists and is readable (if the file is missing or unreadable, REJECT with code stale-paths — the procedure brief was removed or archived; the operator should re-run reflect to generate a fresh brief).

     Agent selection — check the harness's available-skills list (never claude plugin list or disk checks):

     • feature-dev:feature-dev in available-skills → use feature-dev:code-explorer as the subagent.
     • feature-dev:feature-dev absent → fall back to the native Plan agent. Read only the returned text; ignore any file it writes under ~/.claude/plans/.
     • If the agent errors → log a one-line warning to SHELL.md Findings and continue to the session-lifecycle branch. Never block.

     Invoke with the proposal's ## Context and ## Proposed Solution sections plus this fixed instruction:

     "You are a read-only falsification gate. Verify every cited path and symbol against the current code. Return line 1 as exactly: REJECT: <already-done | partially-done | stale-paths | nonexistent-symbols | too-vague> — <one-line evidence> or PROCEED (+ complete file list to modify). If REJECT, give file:line evidence. Do not produce a build plan for a rejected proposal. Do not write any files."

     Append the returned line-1 verdict to the proposal's ## Operator Decision section as provenance, then branch:

     • PROCEED → continue to the session-lifecycle branch below (step (a)). Use the agent's complete file list over any files mentioned in the proposal body.
     • REJECT (stop before any session transition — session_state and SHELL.md Task: stay untouched):
       • Interactive mode → surface to the operator: "Falsification gate: [verdict] — [evidence]. Proceed anyway? Y to override / N to re-scope the proposal first." Y → continue to the session-lifecycle branch below (step (a)). N → stop; status stays accepted. Operator re-scopes and re-runs /proposal-act accept PROP-NNN.
       • Autonomous mode → do not implement; notify via channel: "PROP-NNN: falsification check — [evidence]. Reply 'override PROP-NNN' to implement anyway." a. Use the session_state already read from state/runtime.json in step 3a to branch. b. Idle: delegate to claude-code-hermit:session-mgr to transition to in_progress and fill SHELL.md Task as "Implement PROP-NNN: