MySpec

Greenfield projects start from a blank slate - MySpec generates the full four-file bundle (constitution.md, requirements.md, solution.md, tasks.md) from your idea. Brownfield projects start from an existing codebase - MySpec analyzes what's already built, then walks through a change-focused interview and a proposal step before generating a requirements delta scoped to just that change.

Non-negotiable principles and constraints that guide all subsequent phases. This file acts as the project's 'supreme law', defining tech stack choices (e.g., 'Must use TypeScript'), architectural patterns, and coding standards that the AI must adhere to.

A detailed functional specification. We use the EARS+ (Easy Approach to Requirements Syntax) format to ensure requirements are unambiguous, testable, and complete. It defines 'what' the system does without prescribing 'how'.

A comprehensive solution design document. It translates the requirements into technical implementation details, including database schemas, API endpoints, component hierarchies, and system diagrams (Mermaid.js).

An implementation plan. It breaks down the approved design into granular, sequential tasks. Each task is scoped small enough to be easily completed by an AI coding agent or a human developer.

A change-request document generated for Brownfield projects. Instead of writing specs from scratch, proposal.md captures what's being added, changed, or removed in your existing codebase - the delta that the AI Architect then turns into a scoped requirements.md.

MCP (Model Context Protocol) is an open standard that lets AI apps like Claude Desktop, Claude Code, and Cursor connect directly to external tools and data. @myspec/mcp-server is MySpec's MCP server: run it with npx, sign in once (or use a personal API token), and your AI editor gets 31 tools to list, read, download, upload, and update your MySpec projects, spec files, attachments, spec sessions, and artifact bundles - no copy-pasting from the browser. A hosted HTTP variant at mcp.myspec.dev serves agents that have no filesystem, and `reverse` mode lets the cloud architect read your local codebase for brownfield work.

Three methodologies, four generate workflows. MySpec (greenfield: interview → constitution → requirements → solution → tasks; brownfield: interview → proposal → requirements delta → optional tasks), Spec Kit (greenfield: interview → constitution → specify → plan → tasks, written to specs/memory/ and specs/NNN-feature/), and OpenSpec (brownfield: explore → proposal → delta specs → design → tasks, written to openspec/changes/ /). Pick the methodology per session; an Edit workflow refines any existing bundle with reviewable diffs.

They are the file names other methodologies use. Spec Kit writes spec.md (prioritised user stories, FR-/SC- requirements) and plan.md (technical context, constitution gates, architecture, data model). OpenSpec writes one delta spec.md per capability (ADDED / MODIFIED / REMOVED / RENAMED requirements) plus an optional design.md (context, goals, decisions, risks). MySpec's solution.md was called design.md in older bundles - same file type.