Load essential spec workflow instructions to guide feature development from idea to implementation.

Instructions

Call this tool FIRST when users request spec creation, feature development, or mention specifications. This provides the complete workflow sequence (Requirements → Design → Tasks → Implementation) that must be followed. Always load before any other spec tools to ensure proper workflow understanding. Its important that you follow this workflow exactly to avoid errors.

Load guide for creating project steering documents.

Instructions

Call ONLY when user explicitly requests steering document creation or asks about project architecture docs. Not part of standard spec workflow. Provides templates and guidance for product.md, tech.md, and structure.md creation. Its important that you follow this workflow exactly to avoid errors.

Display comprehensive specification progress overview.

Instructions

Call when resuming work on a spec or checking overall completion status. Shows which phases are complete and task implementation progress. After viewing status, read tasks.md directly to see all tasks and their status markers ([ ] pending, [-] in-progress, [x] completed).

Manage approval requests through the dashboard interface.

Instructions

Use this tool to request, check status, or delete approval requests. The action parameter determines the operation:

• 'request': Create a new approval request after creating each document

• 'status': Check the current status of an approval request

• 'delete': Clean up completed, rejected, or needs-revision approval requests (cannot delete pending requests)

CRITICAL: Only provide filePath parameter for requests - the dashboard reads files directly. Never include document content. Wait for user to review and approve before continuing.

Record comprehensive implementation details for a completed task.

⚠️ CRITICAL: Artifacts are REQUIRED. This creates a searchable knowledge base that future AI agents use to discover existing code and avoid duplication.

WHY DETAILED LOGGING MATTERS

Future AI agents (and future you) will use grep/ripgrep to search implementation logs before implementing new tasks. Complete logs prevent:

• ❌ Creating duplicate API endpoints

• ❌ Reimplementing existing components

• ❌ Duplicating utility functions and business logic

• ❌ Breaking established integration patterns

Incomplete logs = Duplicated code = Technical debt

REQUIRED FIELDS

artifacts (REQUIRED - Object)

Contains structured data about what was implemented. Must include relevant artifact types:

apiEndpoints (array of API endpoint objects)

When new API endpoints are created/modified, document:

• method: HTTP method (GET, POST, PUT, DELETE, PATCH)

• path: Route path (e.g., "/api/specs/:name/logs")

• purpose: What this endpoint does

• requestFormat: Request body/query params format (JSON schema or example)

• responseFormat: Response structure (JSON schema or example)

• location: File path and line number (e.g., "src/server.ts:245")

Example:

components (array of component objects)

When reusable UI components are created, document:

• name: Component name

• type: Framework type (React, Vue, Svelte, etc.)

• purpose: What the component does

• location: File path

• props: Props interface or type signature

• exports: What it exports (array of export names)

Example:

functions (array of function objects)

When utility functions are created, document:

• name: Function name

• purpose: What it does

• location: File path and line

• signature: Function signature (params and return type)

• isExported: Whether it can be imported

Example:

classes (array of class objects)

When classes are created, document:

• name: Class name

• purpose: What the class does

• location: File path

• methods: List of public methods

• isExported: Whether it can be imported

Example:

integrations (array of integration objects)

Document how frontend connects to backend:

• description: How components connect to APIs

• frontendComponent: Which component initiates the connection

• backendEndpoint: Which API endpoint is called

• dataFlow: Describe the data flow (e.g., "User clicks → API call → State update → Re-render")

Example:

GOOD EXAMPLE (Include ALL relevant artifacts)

Task: "Implemented logs dashboard with real-time updates"

BAD EXAMPLE (Don't do this)

❌ Empty artifacts - Future agents learn nothing:

❌ Vague summary with no structured data:

Instructions

1. After completing a task, review what you implemented

2. Identify all artifacts (APIs, components, functions, classes, integrations)

3. Document each with full details and locations

4. Include ALL the information - be thorough!

5. Future agents depend on this data quality