@papi-ai/server 0.2.0-alpha.2

package/package.json

@@ -0,0 +1,53 @@
+{
+  "name": "@papi-ai/server",
+  "version": "0.2.0-alpha.2",
+  "description": "PAPI MCP server — AI-powered sprint planning, build execution, and strategy review for software projects",
+  "type": "module",
+  "main": "./dist/index.js",
+  "bin": {
+    "papi-server": "./dist/index.js"
+  },
+  "files": [
+    "dist",
+    "skills",
+    "README.md"
+  ],
+  "scripts": {
+    "build": "tsup",
+    "start": "node dist/index.js",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "prepack": "rm -rf dist && npm run build"
+  },
+  "keywords": [
+    "mcp",
+    "model-context-protocol",
+    "sprint-planning",
+    "project-management",
+    "ai",
+    "claude",
+    "anthropic",
+    "devtools"
+  ],
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/cathalos92/papi-ui.git",
+    "directory": "packages/server"
+  },
+  "engines": {
+    "node": ">=18.0.0"
+  },
+  "dependencies": {
+    "@anthropic-ai/sdk": "^0.78.0",
+    "@modelcontextprotocol/sdk": "^1.27.1",
+    "js-yaml": "^4.1.0"
+  },
+  "devDependencies": {
+    "@types/js-yaml": "^4.0.9",
+    "@types/node": "^22.0.0",
+    "tsup": "^8.0.0",
+    "typescript": "^5.5.0",
+    "vitest": "^4.0.18"
+  }
+}

package/skills/next-task.md

@@ -0,0 +1,33 @@
+---
+name: next-task
+description: >
+  Pick the next task to build and start working on it.
+  Use when the user says /next-task, "what should I build next",
+  "start building", "pick a task", or "next".
+invocable: true
+---
+
+# /next-task — Pick and Start Next Task
+
+Find the highest-priority unstarted task and begin the build.
+
+## Steps
+
+1. **Run `build_list`** — get the list of tasks with BUILD HANDOFFs.
+
+2. **Pick the next task:**
+   - If any task is **In Progress**, resume that one (don't start a new one).
+   - Otherwise, pick the first **Backlog** task from the list (already priority-sorted).
+
+3. **Show the user what you're picking** — task ID, title, and effort estimate. Ask for confirmation: "Starting task-XXX: [title] (effort: M). Go ahead?"
+
+4. **On confirmation, run `build_execute`** with the task ID to start the build. This creates a feature branch and returns the BUILD HANDOFF with scope, acceptance criteria, and files to touch.
+
+5. **Read the BUILD HANDOFF carefully** and begin implementation. Follow the scope — don't exceed it.
+
+6. **After implementation, run `build_execute` again** with the report fields (completed, effort, estimated_effort, surprises, discovered_issues, architecture_notes) to complete the build.
+
+## Notes
+
+- If the build list is empty, tell the user: "No tasks with handoffs. Run `plan` to create the next sprint."
+- If all tasks are In Review or Done, suggest running reviews or release instead.

package/skills/quick-review.md

@@ -0,0 +1,38 @@
+---
+name: quick-review
+description: >
+  Review and accept/reject completed builds.
+  Use when the user says /quick-review, "review builds", "accept reviews",
+  "check reviews", or after completing a batch of builds.
+invocable: true
+---
+
+# /quick-review — Review Completed Builds
+
+Check for builds pending review and process them.
+
+## Steps
+
+1. **Run `review_list`** — shows tasks that are In Review with their build reports.
+
+2. **If no tasks are pending review**, tell the user: "No builds pending review." Suggest the next action (build more tasks, or release if all are done).
+
+3. **For each task pending review**, show:
+   - Task ID and title
+   - Effort (estimated vs actual)
+   - Scope accuracy
+   - Surprises or discovered issues
+   - Brief summary of what was built
+
+4. **Ask the user:** "Accept all N reviews, or review individually?"
+
+5. **On acceptance, run `review_submit`** for each task with verdict "accept". Include a brief comment summarising the build.
+
+6. **After all reviews are processed**, check if the sprint is complete:
+   - If all sprint tasks are Done: "Sprint complete. Run `release` to merge and tag."
+   - If tasks remain: "N tasks still to build. Use `/next-task` to continue."
+
+## Notes
+
+- If the user wants to reject or request changes on a specific task, run `review_submit` with the appropriate verdict and comments.
+- Reviews are lightweight — the build report has the details. The user just needs to confirm the work is acceptable.

package/skills/sprint-status.md

@@ -0,0 +1,33 @@
+---
+name: sprint-status
+description: >
+  Show current sprint health, board state, and recommended next action.
+  Use when the user says /sprint-status, "what's the status", "where are we",
+  "sprint health", or at the start of a session to orient.
+invocable: true
+---
+
+# /sprint-status — Sprint Health Check
+
+Run the PAPI health and build list tools to give the user a complete picture of where things stand.
+
+## Steps
+
+1. **Run `health`** — the PAPI MCP tool that returns sprint number, board state, strategy review cadence, Active Decisions summary, velocity, and estimation accuracy.
+
+2. **Run `build_list`** — shows tasks with BUILD HANDOFFs ready for execution, prioritised by status (In Progress first, then Backlog).
+
+3. **Summarise clearly:**
+   - "You're on Sprint N. X tasks to build, Y builds pending review."
+   - Or: "Sprint N is complete — ready for the next plan."
+   - Flag any issues: stale In Progress tasks, strategy review due, orphaned branches.
+
+4. **Suggest the next action:**
+   - If tasks are In Review: "Run `review_submit` to accept/reject pending reviews."
+   - If tasks are in Backlog: "Pick a task to build — use `/next-task` to start."
+   - If all tasks are Done: "All tasks complete. Run `plan` to create the next sprint."
+   - If strategy review is due: mention it before suggesting plan.
+
+## Output format
+
+Keep it concise. Lead with the status line, then a brief board summary, then the recommended next action.