Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/rand/mnemosyne/feature-clarifygit clone --depth 1 https://github.com/rand/mnemosyneWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00015 | $0.01808 |
| Opus 5 | $0.00008 | $0.00904 |
| Sonnet 5 | $0.00003 | $0.00362 |
| Haiku 4.5 | $0.00002 | $0.00181 |
Grade A, and why
feature-clarify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 215 lines — stays where its author put it; the contents beside it link to each section on GitHub.
I will help you clarify ambiguities in a feature specification through structured question and answer sessions.
Usage:
/feature-clarify <feature-id>- Start clarification for a spec/feature-clarify --auto <feature-id>- Auto-detect ambiguities/feature-clarify --show <feature-id>- Display existing clarifications
Instructions for me:
-
Load feature spec:
- Read
.mnemosyne/artifacts/specs/<feature-id>.md - If not found: "Error: Feature spec '' not found. Use /feature-specify first."
- Parse YAML frontmatter to get spec memory_id
- Read
-
Check for existing clarifications:
- Look for
.mnemosyne/artifacts/clarifications/<feature-id>-clarifications.md - If exists: Load and display summary
- Count pending vs. resolved questions
- Look for
-
Auto-detect ambiguities (if
--autoflag or no existing clarifications):Use DSPy ReviewerModule for semantic detection:
cd src/orchestration/dspy_modules uv run python3 specflow_integration.py ../../.mnemosyne/artifacts/specs/<feature-id>.md --ambiguities-only --jsonParse JSON output for ambiguities array:
location: Section where ambiguity was foundterm: Ambiguous term or phrasequestion: Suggested clarifying questionimpact: Why this matters
Fallback to pattern-based detection if DSPy unavailable:
- Vague quantifiers: "fast", "slow", "easy", "hard", "secure", "scalable" without metrics
- Missing acceptance criteria: Scenarios with <3 criteria
- Underspecified requirements: Performance/security requirements without numbers
- Unclear dependencies: References to external systems without details
- Open questions: Explicit "?" or "TBD" markers
Limit to top 3 most critical ambiguities (prioritize by location: P0/P1 scenarios first).
-
Interactive clarification (max 3 questions per session): For each ambiguity:
a) Present question:
Question Q00X: [Clear, specific question] Context: [Why this needs clarification] Found in: [Spec section] Impact: [What this blocks or affects]b) Gather answer:
- Ask user for decision
- Ask for rationale (why this choice?)
- Ask which spec sections need updating
- Validate answer is concrete and measurable
c) Record clarification item:
## Q00X - Question [Question text] ### Context [Background and why this needs clarification] ### Decision [User's decision] **Rationale**: [Why this decision was made] **Spec Updates**: - [Section to update with new information] - [Another section to update] -
Format clarifications document:
--- type: clarification id: <feature-id>-clarifications name: <feature-name> Clarifications feature_id: <feature-id> version: 1.0.0 created_at: <ISO 8601 timestamp> updated_at: <ISO 8601 timestamp> memory_id: <will be filled> references: [<spec-memory-id>] --- # Clarifications: <feature-name> **Status**: [X resolved, Y pending] ## Q001 - Question [Question text] ### Context [Context] ### Decision [Decision text or *Pending*] **Rationale**: [Rationale if decided] **Spec Updates**: - [Update 1] - [Update 2] ## Q002 - Question ... -
Write clarifications file:
- Create/update
.mnemosyne/artifacts/clarifications/<feature-id>-clarifications.md - Ensure directory exists
- If updating: Preserve existing questions, add new ones with incremented IDs
- Create/update
-
Store memory entry:
- Use Mnemosyne CLI:
mnemosyne remember - Arguments:
- Content: "Clarifications for : Q001: , Q002: ..., X resolved, Y pending"
- Namespace:
project:<project-name> - Importance: 7 (clarifications are important)
- Type: clarification
- Tags: clarification,,ambiguities
- Context: "Clarification questions and answers for "
- Capture memory_id
- Use Mnemosyne CLI:
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 215 lines · 15 tokens per session scan A eac945ea4e2b
feature-clarify is a command published in the GitHub repository rand/mnemosyne (84 stars, last pushed 9mo ago), licensed MIT. It adds 15 tokens to every session and 1,808 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
hatch3r-bug-plan
Diagnose a complex incident -- reproduce the symptom, rank root-cause hypotheses, design the fix path, and emit regression coverage items as a board-ready investigation.
hatch3r-debug
Standalone debug-and-fix workflow — add strategic debug logging, collect runtime logs from the user, perform root cause analysis, implement the fix, and clean up all debug artifacts.
hatch3r-feature-plan
Design a new capability -- draft user stories, acceptance criteria, data model, API surface, and sub-issue breakdown as an epic-shaped todo.md for greenfield features.
story-6.1.4
Story ID: 6.1.4 Epic: Epic-6.1 - Agent Identity System Wave: Wave 1 (Foundation) Status: 📋 Ready to Start Priority: 🔴 Critical Owner: Dev (Dex) Created: 2025-01-14 Updated: 2025-01-17 (v4 - Unified System Integration) Duration: 2.5 days (20 hours) Investment: $250.00.
hatch3r-bug-pipeline
Run a known-cause bug fix through a 3-phase test-first pipeline -- reproduce + root-cause, regression-test + fix together, then root-cause-depth review -- with full sub-agent delegation.
hatch3r-incident-response
Drive a live production incident through a structured lifecycle -- triage + topology, bounded-autonomy mitigation, stakeholder communication, then a blameless post-mortem with runbook -- via delegated sub-agents.