Loading ToolBench
Manages the PRD→Spec→Plan cycle. Always check for duplicates before creating artifacts.
Server has 9 tools with mostly complete schemas and descriptions. Naming follows verb_noun convention (create_prd, get_workflow_status, etc.). Descriptions are present and substantive (avg ~150 chars), exceeding the 10-char minimum. However, several tools lack output schema documentation, parameter descriptions are sometimes generic, and error handling guidance is minimal. Tool composition is reasonable but some tools combine multiple concerns (ideate_prd does elicitation + LLM sampling + file persistence). No evidence of input validation or recovery guidance in error cases.
Runs a pre-PRD architectural discovery session. Gathers repository context, generates discovery questions via LLM sampling, collects user answers, and produces a consolidated Technical Context artifact. Returns the context filename for use in prd_from_idea prompt.
Consolidates architectural discovery answers into a structured Technical Context document. Takes a PRD draft and developer answers to architectural questions, produces a Markdown document with Summary, Architectural Decisions, Integration Points, Constraints & Risks, and Recommended Approach sections.
Creates a new Plan file in plans/. Name: plan-<feature-slug>.prompt.md. Updates index.md: changes plan_status to '🟢 Done'. Preserves implementation_status. spec_filename is required to locate the correct row in index.md.
Creates a new PRD file in prds/. Slugifies feature_name → prd-<slug>.md. Checks for duplicates before creating. Automatically registers the artifact in index.md after creation.
Creates a new Spec file in specs/. Name: spec-<prd-slug>-<feature-slug>.md. Updates index.md: fills spec_filename and changes plan_status to '🟡 Spec Draft'. Preserves the existing implementation_status.
ideate_prd and sync_index lack documented output schemas. LLMs cannot plan downstream calls or extract return values without knowing what fields to expect.
ideate_prd combines three concerns: elicitation, LLM sampling, and file persistence. Should split into separate tools (elicit_feature_details, generate_prd_draft, persist_prd) so agents can compose them independently.
No error handling guidance. Tools like create_prd mention 'checks for duplicates' but do not document what error is returned, whether it is retryable, or what the LLM should do next. Missing recovery guides per pattern:recovery-guide.
Parameter descriptions are generic. 'feature_name' is described as 'Human-readable name of the feature' but does not specify format constraints (length, allowed characters, case sensitivity). LLMs cannot validate input without explicit constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | <=2025-11-25 | v2 |
Returns the structured status from index.md. readOnlyHint=True — does not modify files.
Guides the user through a pre-PRD ideation journey using elicitation and LLM sampling. Interactively collects feature details via a two-step elicitation flow: title → structured details form. Then gathers workspace context and uses ``ctx.sample()`` to have the LLM generate an elaborated PRD draft with User Stories, Risks, Architecture suggestions and Open Questions. If the client does not support MCP sampling, falls back to a basic template-based PRD draft. The elaborated draft is automatically persisted as a PRD file when no duplicate is detected. On duplicate, returns ``saved=False`` with a ``reason`` so the orchestrating LLM can inform the user.
Reconciles filesystem artifacts with index.md. Pass 1 — PRD files not yet in index are inserted with default statuses (plan_status='⏳ Waiting for Spec', implementation='❌ Todo'). Pass 2 — Rows with an empty spec field are updated when a matching spec file exists on the filesystem; rows whose plan_status is not '🟢 Done' are updated when a matching plan file is found.
Manually upserts a row in index.md. Requires force=True. index.md is managed automatically by create_prd, create_spec, and create_plan. Only call this tool directly when correcting data, and only with force=True to confirm the intent.
update_index requires force=true but does not explain why or what happens if force=false. Confirmation patterns should guide the LLM on when to use this tool and what the consequences are.