Skip to content

Latest commit

 

History

History

README.md

Tutorials

Six short, copy-paste runnable walkthroughs for the most-asked starter tasks. Each ends with explicit verification steps so you know it worked.

# Tutorial Time What you'll do
01 Add a new MCP tool to tapps-mcp ~15 min Wire a new @mcp.tool() end-to-end: handler, _record_call, checklist registration, AGENTS.md row, unit test.
02 Run the quality pipeline against a fresh Python project ~10 min Bootstrap with tapps_init, write a deliberately bad function, watch tapps_quick_check flag it, fix it, batch-validate, finish with the checklist.
03 Wire tapps-brain into a Claude Code session ~20 min Stand up the brain Docker service, set TAPPS_BRAIN_AUTH_TOKEN, save a memory in one session, recall it in the next.
04 NLT MCP session modes ~10 min Enable the right 1–3 NLT servers (Build / Memory / Linear / Docs) without loading all six.
05 Documentation refresh workflow ~2 hr Full DocsMCP-driven doc refresh: drift, links, API regen, CI gate.
06 Your first memory save and recall ~10 min Save and search via tapps-mcp memory CLI and nlt-memory MCP (post–v3.12.0).

Diataxis: why tutorials, not how-tos

These follow the Diataxis tutorial conventions: learning-oriented, runnable end-to-end, verified at each step. They're meant for someone whose mental model of the tool is empty — not for someone who already knows what they want and needs a recipe.

For task-specific reference (the "I know what I want, just remind me how") see docs/INDEX.md. For architectural decisions, see docs/adr/.

Suggested order

  1. 02 first if you've never used the tool — it's the shortest path to seeing the pipeline work.
  2. 04 if you need to configure NLT MCP servers in Cursor (Build / Memory / Docs).
  3. 01 next if you're going to extend tapps-mcp itself (vs. just consume it).
  4. 03 + 06 when you want cross-session memory. Optional — tapps-mcp works without it.
  5. 05 when refreshing project documentation with DocsMCP.