docs: restructure into navigable docs/ tree and add MCP user guide#35
Merged
Conversation
The README had grown to 307 lines covering features + architecture +
keybinds + config + project structure + roadmap, and the MCP integration
— the project's headline AI feature — had no user-facing guide. Other
substantial reference docs (ARCHITECTURE, PRD, ROADMAP, VISION,
VERSIONING) lived at the repo root, making the directory listing on
github.com noisy and hard to navigate.
Structure now:
Root keeps the four GitHub-conventional files (README, CHANGELOG,
CONTRIBUTING, LICENSE). README is a 95-line landing page: hero,
install, five-key quick start, MCP wiring snippet, Documentation
table linking into docs/.
docs/ is a navigable wiki. github.com renders docs/README.md as a
table-of-contents when you click into docs/. Every page has its own
anchor TOC and is focused on one topic.
New docs:
- docs/README.md documentation index
- docs/installation.md install paths + build-from-source
- docs/quick-start.md first-launch walkthrough
- docs/features.md capability tour grouped by area
- docs/keybindings.md full keymap + customization
- docs/configuration.md ~/.quil/config.toml reference
- docs/mcp.md the missing piece: how to wire Quil into
Claude Desktop / Claude Code / Cursor /
VS Code Copilot, every one of the 17
tools documented with input schemas
pulled directly from cmd/quil/mcp_tools.go,
redaction model, troubleshooting
- docs/troubleshooting.md daemon won't start, MCP not detected,
log file locations, force-stop, reset
Moved via git mv (history preserved):
- ARCHITECTURE.md → docs/architecture.md
- PRD.md → docs/prd.md
- ROADMAP.md → docs/roadmap.md
- VISION.md → docs/vision.md
- VERSIONING.md → docs/versioning.md
Cross-reference fixes:
- All internal MD links in moved files re-anchored to the new
docs/ layout (sibling links instead of repo-root paths;
../CHANGELOG.md for the one root file referenced).
- .claude/CLAUDE.md "Documents" section rewritten to reflect the new
tree.
- site/src/pages/docs.astro reorganized into five sections (Getting
started / Using Quil / Authoring & extending / Project context /
Future roadmap PRDs) with current paths.
- site/src/components/Footer.astro doc links updated; MCP guide
added.
- docs/plans/2026-03-09-m1-foundation.md "Reference:" pointers
updated to ../prd.md and ../vision.md.
CONTRIBUTING.md rewritten as a thin pointer-page: branch/commit
conventions, PR expectations, doc-maintenance checklist. Deep build
material moved into docs/installation.md (Build from source section).
Verification:
- astro check + astro build clean (0 errors, 0 warnings, 11 pages)
- Recursive grep for stale paths returns only historical CHANGELOG
entries and intentional "moved from root X.md" labels
- Custom link checker walks every relative MD link in docs/ — all
resolve
README went 307 → 95 lines; root MD count went 8 → 4.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
4 tasks
artyomsv
added a commit
that referenced
this pull request
Jun 5, 2026
…36) ## Summary Fixes the false-positive minor bump on PR #35 (docs restructure) that shipped **v1.13.0 with no user-visible changes**. The release pipeline was scanning both subject AND body of every commit since the last tag, hoping to catch type lines preserved in squash bodies when the subject was branch-name-derived. That heuristic produced this false positive: the #35 PR description contained the literal back-tick-wrapped reference > This PR is independent of #34 (`` `feat(tui): add Stop daemon action` ``). …and the regex `\bfeat[(:/]` matched the substring `feat(` inside the backticks just as readily as it would have matched a real `feat(tui):` commit. The release job classified the PR as `minor` and shipped v1.13.0 with nothing user-facing in it. ## Fix | What | Before | After | |---|---|---| | Type classification (feat/fix/perf/bang) | scans `%s%n%b` (subject + body) | scans `%s` (subject only) — the merger sets the squash subject explicitly and it IS the authoritative classification | | `BREAKING CHANGE` detection | matched anywhere in subject+body via `BREAKING CHANGE` | matches `^BREAKING[ -]CHANGE:` in body **anchored to line start with trailing colon** — the Conventional Commits footer form. Prose mentions like "this is not a BREAKING CHANGE" no longer match. | | Branch-name fallback (`feat/foo-bar`) | covered via body scan | still covered — the existing `[(:/]` regex on subjects accepts `feat/foo-bar` form natively | Diff is ~30 lines, all in `.github/workflows/release.yml`. ## Why this never bit before The body-scan was a defense-in-depth measure for branch-name-derived squash subjects. In practice, every merge in this repo's history has had a properly conventional subject set by the merger, so the body scan never had to do its intended job — it just sat there waiting to false-positive. PR #35 was the first PR whose description text contained a conventional-commit-style reference to another PR, and that's when the bug surfaced. ## Self-test Smoke-tested the new regex on the prose vs. footer distinction: ``` $ echo "BREAKING CHANGE: yes" | grep -qE '^BREAKING[ -]CHANGE:' → match (correct — real footer) $ echo "no BREAKING CHANGE here" | grep -qE '^BREAKING[ -]CHANGE:' → no match (correct — prose mention) $ echo "feat(api): add foo" | grep -qiE '\bfeat[(:/]' → match (correct — real subject) $ echo "ref to feat(api)" | grep -qiE '\bfeat[(:/]' → matches the regex but the body is no longer scanned for feat — irrelevant to the bump path now ``` ## Why this PR doesn't bump The PR is committed as `chore(ci):`, which falls through to the "skip release" branch in the workflow itself. No `v1.14.1` release will be cut by merging this; the next user-visible feature PR will bump as normal. ## Test plan - [x] Inspected the PR #35 squash body to confirm the matching string (`` `feat(tui)` `` inside backticks) - [x] Verified the new `^BREAKING[ -]CHANGE:` anchor matches the Conventional Commits footer form but not casual prose - [x] Confirmed `chore(ci):` does not match the bump regexes — this PR's own merge will skip the release job (no v1.14.1 will ship) - [x] Diff is small and reviewable (~30 lines, single file)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Restructures project documentation so that the GitHub repo browser is easy to navigate and the headline MCP feature finally has a user-facing guide.
Before — 8 markdown files at the repo root totalling 2735 lines; the README alone was 307 lines covering Features + Architecture + Quick start + Configuration + Project Structure + Roadmap. No user-facing MCP guide existed (only a PRD in
docs/roadmap/mcp-server.md).After — 4 files at the root (the GitHub-conventional set: README, CHANGELOG, CONTRIBUTING, LICENSE), everything else under
docs/as a navigable tree. README is a 95-line landing page. Newdocs/mcp.mddocuments all 17 MCP tools with input schemas pulled directly fromcmd/quil/mcp_tools.go, plus client wiring for Claude Desktop, Claude Code, Cursor, and VS Code Copilot.Structure
What changed by file
README.mdCONTRIBUTING.mddocs/installation.md.docs/README.mddocs/folderdocs/installation.mddocs/quick-start.mddocs/features.mddocs/keybindings.mddocs/configuration.md~/.quil/config.tomlwith defaults and effectsdocs/mcp.mddocs/troubleshooting.mdARCHITECTURE.md→docs/architecture.mdgit mvpreserves historyPRD.md→docs/prd.mdROADMAP.md→docs/roadmap.mddocs/roadmap/...links rewritten as sibling linksVISION.md→docs/vision.mdVERSIONING.md→docs/versioning.md.claude/CLAUDE.mdsite/src/pages/docs.astrosite/src/components/Footer.astrodocs/plans/2026-03-09-m1-foundation.mdReference:pointers updated to../prd.mdand../vision.mdWhy MCP got its own user guide
quil mcpis the project's headline AI feature — Quil becomes the bridge between your AI assistant and your terminal. But until this PR, the only MCP documentation wasdocs/roadmap/mcp-server.md, which is a PRD describing the architecture, not a user guide. A user could not figure out how to wire Quil into Claude Desktop or Cursor without reading the source code.docs/mcp.mdsolves that. It contains:quil mcpbridges MCP JSON-RPC over stdio to the daemon IPC over the Unix socketcmd/quil/mcp_tools.goso the docs cannot drift<<REDACT>>...<</REDACT>>marker contract + the regex-fallback layer (OpenAI keys, GitHub PATs, JWTs, BIP-32 extended keys) that catches secrets the AI forgot to wrapCross-reference verification
A custom relative-link checker was written for the new
docs/tree:All internal MD links resolve. The recursive grep for stale root-MD path mentions across the whole repo (excluding historical content under
docs/plans/,docs/roadmap/,docs/superpowers/) returns only:X.md" labels in CLAUDE.mddocs/roadmap/pane-notes.md(preserved for archaeology)Verification
astro check+astro buildagainstsite/— 0 errors, 0 warnings, 11 pages builtdocs/— all resolvegit mvpreserved file history for all 5 moved files (verify withgit log --follow docs/architecture.md).mdcount went 8 → 4Independence from other open PRs
This PR is independent of #34 (
feat(tui): add Stop daemon action). They touch disjoint files:Either can land first; merging order does not require re-basing.