speky-workflow

Speky Workflow Guidelines

Speky organizes a project's detailed specification into requirements (what the system must do) and tests (how to verify it). Items are identified by short IDs like RF001, RN02, T003.

Tool selection

• Start with list_all_ids to get a full overview of available IDs before searching or fetching.
• Use get_requirement / get_test when you already know the ID — it's faster and returns full detail including cross-references.
• Use search_requirements only when filtering by tag or category. Use search_tests only when filtering by category or by requirement (tester_of). Do not call either with no filters as a substitute for list_all_ids.
• Use list_all_tags to discover available tags before filtering by one.
• Use list_references_to to find what depends on a given item (e.g., before modifying or deleting it).
• Use test_plan_coverage to find coverage gaps — it gives a project-wide summary without requiring manual inspection.
• Use least_tested_requirements to find where to write new tests — it ranks requirements by ascending test count and accepts tag, category, and count filters.

Reading results

• get_requirement returns tested_by (tests covering it) and referenced_by (requirements that depend on it). Read these before assessing coverage or impact.
• get_test returns ref (requirements it validates) and prereq (tests that must run first). Read these to understand test scope and ordering.
• Tags use a namespaced format: namespace:value (e.g., output:pdf, mcp:tools). When filtering by tag, use the exact full string.

Working with coverage

• A requirement is covered if it appears in at least one test's ref list (visible as tested_by on the requirement).
• Use test_plan_coverage for a project-wide summary before concluding anything about overall coverage.
• Use least_tested_requirements (with optional tag or category filter) to pinpoint the requirements most in need of new tests.
• Do not infer coverage from description alone — always check tested_by.