Enforce project constraints from CLAUDE.md, AGENTS.md, and .cursorrules before AI-generated edits, commands, and commits. An AI Continuity Engine that remembers project context across sessions.
SpecLock presents 45 tools with acceptable naming conventions and descriptions, but exhibits systematic gaps in schema completeness, parameter documentation, and output schema clarity. All tool names follow verb_noun patterns (get_, set_, add_, check_, remove_, etc.), which is good. However, 60%+ of parameters lack depth in constraint documentation (format, ranges, enum values), and output schemas are not visibly documented in the source code provided. Tools are narrowly scoped (single responsibility), which is positive. Descriptions are generally adequate (50-150 chars), meeting the 10-1024 baseline, but lack LLM-optimized precision. The server appears to have good naming hygiene but poor schema rigor for an enterprise-grade tool.
Tools (45)
speclock_add_decisionwritesource verified76/100
Record an architectural or design decision.
speclock_add_lockwritesource verified78/100
Add a non-negotiable constraint (SpecLock). These are rules that must NEVER be violated during development.
speclock_add_notewritesource verified73/100
Add a free-form note to the project memory.
speclock_add_policy_rulewrite50/100
Add a policy rule to the project.
speclock_add_typed_lockwritesource verified74/100
Add a machine-enforceable typed constraint (numerical, range, state, temporal).
speclock_apply_templatewritesource verified75/100
Apply a rule template to the current project.
speclock_audit_staged_filesread only50/100
Audit staged git changes against active constraints.
Output schemas are not documented in source code. Tools return structured data (brain.json, events.log, etc.) but their response types are not visible in schema definitions, making it impossible for LLMs to plan downstream tool chains.
Parameter constraints are under-specified. Tools like speclock_add_lock, speclock_add_decision, speclock_add_note accept free-form 'tags' arrays and 'text' strings with only minLength validation. No enum constraints, format patterns, or range limits. LLMs will generate unbounded, inconsistent values.
Add explicit output schema definitions to all 45 tools. For example, speclock_get_context should document: 'Returns object { goal: string, locks: Lock[], decisions: Decision[], changes: Change[], notes: Note[], deployFacts: DeployFact[], reverts: Revert[], sessionHistory: Session[], lastSession: Session }' with field types.
Replace free-form tag and text parameters with structured enums where possible. Example: tags enum should constrain values to known categories (e.g. 'architecture', 'security', 'performance', 'stability'). Add minLength/maxLength to all text fields (e.g. text: { minLength: 5, maxLength: 2000 }).
Document error cases and recovery steps for conflict/audit tools. Example for speclock_check_conflict: 'If action conflicts with locks, returns { conflict: true, violatedLocks: Lock[], suggestion: string }. If no conflict: { conflict: false }. Common next steps: review violatedLocks via speclock_get_context, then override via speclock_override_lock if justified.'
Distinguish async vs sync variants. Either: (1) remove one variant and justify the remaining choice, or (2) add descriptions explaining when async is required (e.g. 'Use _async when patch size > 10MB or when timeout > 30s is acceptable').
THE KEY TOOL. Returns the full structured context pack including goal, locks, decisions, recent changes, deploy facts, reverts, session history, and notes. Call this at the start of every session or whenever you need to refresh your understanding of the project.
speclock_get_critical_pathsread only50/100
Identify critical paths in the codebase with highest risk.
speclock_get_enforcement_configread only50/100
Get the current enforcement configuration.
speclock_get_override_historyread only50/100
Get the history of lock overrides.
speclock_get_telemetry_summaryread only50/100
Get a summary of telemetry data.
speclock_import_policywrite50/100
Import policy rules from a file.
speclock_initwritesource verified82/100
Initialize SpecLock in the current project directory. Creates .speclock/ with brain.json, events.log, and supporting directories.
speclock_init_policywrite50/100
Initialize policy system for the project.
speclock_list_policy_rulesread only50/100
List all policy rules for this project.
speclock_list_templatesread only50/100
List available rule templates and frameworks.
speclock_log_changewritesource verified78/100
Record a significant change or completion in the project.
No documented error recovery guidance. Tools lack descriptions of expected error cases and recovery steps. For example, speclock_check_conflict and speclock_review_patch should document: what happens on conflict (does it block, warn, or suggest alternatives?). Current descriptions do not answer this.
Tool composition gaps. speclock_check_conflict, speclock_check_conflict_async, speclock_review_patch, and speclock_review_patch_async appear to duplicate functionality. No clear distinction of when to use async vs sync variants, forcing LLM to guess and pick suboptimally.
Parameters with implicit dependencies not documented. speclock_add_typed_lock accepts constraintType enum (numerical, range, state, temporal) but does not specify which fields (newValue, threshold, etc.) apply to each type. LLMs will pass incorrect combinations.
Missing descriptions for critical parameters. speclock_override_lock reason and durationMinutes parameters are documented, but context on enforcement behavior is vague. What happens when override expires? Does the lock auto-re-enable? Current description doesn't clarify.
Add per-tool success/failure indicators. For tools like speclock_audit_staged_files and speclock_verify_audit_chain, document return format: { auditsPassed: number, auditsFailed: number, details: AuditResult[] } so the agent knows what to expect.
Expand descriptions for enforcement tools (set_enforcement_mode, enforce_conflict_check, override_lock) to explain state transitions. Example: 'warn mode: logs conflicts but allows action. hard mode: blocks action immediately. Current mode: [returned by speclock_get_enforcement_config].'
Add pagination/limits documentation to discovery tools. speclock_list_templates, speclock_list_policy_rules, speclock_get_override_history should specify max results (e.g. 'Returns top 50 most recent rules; use cursor or offset for pagination').
Clarify idempotency guarantees. speclock_add_lock, speclock_add_decision, speclock_add_note should state: 'Idempotent if same text and tags passed; returns existing lock ID if duplicate detected.' This prevents LLM from creating duplicates on retry.
Document what speclock_protect does exactly. Current description 'Discover and enforce rules from CLAUDE.md, AGENTS.md, and .cursorrules' is vague. Add: 'Reads CLAUDE.md, AGENTS.md, .cursorrules files in project root; parses constraints; auto-creates locks via speclock_add_lock; returns { locksCreated: number, locksUpdated: number, parseErrors: Error[] }.'
For stateful tools (sessions, overrides, enforcement mode), clarify persistence scope. Do overrides persist across agent restarts? Is enforcement mode per-project or per-session? Add to descriptions or create a speclock_get_state tool.