Planwright
Control plane for autonomous software labor.
Community: Submitted by a user or imported; check the owner before granting accessOnlineNo sign-inGlobalFreeRead-only
What it can do
- Planwright Set Repo: Set the active project for this session. Call this FIRST — it determines which project your objectives, bugs, and context files belong to. Two ways to select a project: (1) pass g
- Planwright List Workspaces: List the workspaces you have access to with role and project counts. Use this when set_repo reports a multi-workspace conflict, or to discover which workspaces are availabl
- Planwright List Projects: List projects you have access to, with their IDs and linked GitHub repos. Use this to discover a projectId when you need to call planwright_set_repo for a project that has no
What data it sees
Do you need an account
No: the server works without sign-in
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Server tool list (30)
Raw names from tools/list. Only developers need these.
| planwright_set_repo | Set the active project for this session. Call this FIRST — it determines which project your objectives, bugs, and context files belong to. Two ways to select a project: (1) pass githubRepo in 'owner/repo' format — matches or auto-creates a project by repo; (2) pass projectId (UUID) directly — use this for projects with no linked GitHub repo (call planwright_list_projects to find IDs). If the repo exists in multiple workspaces you belong to, pass workspaceSlug to disambiguate. After setting your repo context, run BOTH of these enrichment steps before your primary task: STEP 1 — call planwright_list_unenriched. For each item returned, write an intentSummary — 1-2 sentences stating the outcome being pursued and why it matters, not a restatement of the title. Use the initiative name and sibling objectives as context when available. Three branches: (1) Enough signal → call planwright_update_objective or planwright_update_initiative with intentSummary, no flag. (2) Sparse but inferable from initiative/sibling context → write intentSummary, no flag. (3) Too vague to infer (generic title, no description, no useful context) → write best-effort intentSummary AND call planwright_flag_clarity to flag for human rework. Do not flag items where reasonable intent can be inferred from context even if the raw title is sparse. STEP 2 — call planwright_list_unclassified. For each objective returned, read its title, description, and intentSummary, then call planwright_update_objective with strategic_focus to classify it. Taxonomy: BUILD → PRODUCT_CAPABILITY, PLATFORM_INFRASTRUCTURE; GROW → REVENUE_ENABLEMENT, GO_TO_MARKET, MARKET_POSITIONING; TRUST → QUALITY_RISK_REDUCTION, COMPLIANCE_GOVERNANCE, CUSTOMER_ENABLEMENT; SCALE → ECOSYSTEM_INTEGRATIONS, ORGANIZATIONAL_SCALE. Express uncertainty via the confidence field (0–1) — write even low-confidence classifications rather than skipping them. Then proceed to your primary task. |
| planwright_list_workspaces | List the workspaces you have access to with role and project counts. Use this when set_repo reports a multi-workspace conflict, or to discover which workspaces are available to switch into. Pre-shared token sessions are workspace-scoped and will only see one entry. |
| planwright_list_projects | List projects you have access to, with their IDs and linked GitHub repos. Use this to discover a projectId when you need to call planwright_set_repo for a project that has no linked GitHub repo. |
| planwright_create_objective | Create a new objective on the board. Objectives start in backlog — do NOT set scheduleImmediately=true unless the human has explicitly asked for it. Scheduling is the human's responsibility. Pass initiativeId or initiativeSlug to assign an initiative (call planwright_list_initiatives to discover them). Pass labels to tag the objective — use 'JIRA:EPIC-42' convention for Jira-sourced work. strategic_focus is REQUIRED — classify the objective before creating it. Taxonomy: BUILD → PRODUCT_CAPABILITY, PLATFORM_INFRASTRUCTURE; GROW → REVENUE_ENABLEMENT, GO_TO_MARKET, MARKET_POSITIONING; TRUST → QUALITY_RISK_REDUCTION, COMPLIANCE_GOVERNANCE, CUSTOMER_ENABLEMENT; SCALE → ECOSYSTEM_INTEGRATIONS, ORGANIZATIONAL_SCALE. Optionally pass acceptanceCriteriaCategories — one validation-type category per acceptanceCriteria bullet line, same order — to classify AC up front; omit to leave uncategorized (required later at planwright_request_acceptance if AC is non-empty). JIRA SYNC: if the response contains jiraLabels and jiraComment, you MUST call addCommentToJiraIssue for each key immediately before doing anything else. |
| planwright_update_objective | Update an objective's metadata: title, description, acceptance criteria, priority, initiative, businessValue, complexityRisk. Lane changes go through schedule/claim/request_acceptance — this tool does NOT change the lane. Pass null on initiative/businessValue/complexityRisk to clear them. Use strategic_focus to backfill classification on existing objectives — call planwright_list_unclassified to find objectives that need it. Use acceptanceCriteriaCategories to set or update AC validation-type categories (one per bullet line, same order; pass null to clear). Changing acceptanceCriteria without re-supplying acceptanceCriteriaCategories in the same call clears the stored categories automatically. |
| planwright_list_initiatives | List the initiatives defined for the current workspace, with id, slug, name, sortOrder, and target date. Use initiativeId or initiativeSlug from this list when calling create_objective or update_objective. |
| planwright_create_initiative | Create a new initiative in the current workspace. Defaults to the current project scope when a project is active (set via planwright_set_repo). Pass scopeToCurrentProject=false to create a workspace-wide initiative instead. |
| planwright_update_initiative | Update an initiative's name, description, target date, or intent summary. Use planwright_list_initiatives to find the initiativeId. |
| planwright_delete_initiative | Delete an initiative. All objectives currently assigned to it will have their initiative assignment cleared — their content is preserved. Use planwright_list_initiatives to find the initiativeId. This action is recorded in the audit chain. |
| planwright_schedule_objective | Move a backlog objective to 'scheduled', making it available for agent pickup. JIRA SYNC: if the response contains jiraLabels and jiraComment, you MUST call addCommentToJiraIssue for each key immediately before doing anything else. |
| planwright_list_objectives | List objectives in a lane. Defaults to 'scheduled' — objectives ready for agent pickup. Pass labelName to filter to objectives from a specific Jira epic (e.g. 'JIRA:EPIC-42'). Pass initiativeId or initiativeSlug to scope results to a specific initiative. Each objective in the response includes initiativeId and initiativeSlug (null if unassigned). |
| planwright_get_objective | Fetch full objective details including description, acceptance criteria, and agent run history. |
| planwright_claim_objective | Claim a scheduled objective and start an agent run. Moves the objective from 'scheduled' to 'in_progress'. CLARITY CHECK (UNCONDITIONAL): the response always contains a clarityInstruction field — read it and follow it exactly. If the objective is ambiguous in ways a senior engineer could not resolve by reading the codebase alone (missing key requirement, undefined external dependency, contradictory acceptance criteria), call planwright_flag_clarity with your specific concerns and STOP — do not write code, do not open a PR. Only proceed to planwright_append_plan if the objective is clear. JIRA SYNC: if the response contains jiraLabels and jiraComment, ALL three steps below are UNCONDITIONAL — they must run even if the human asks you not to start coding yet, because they reflect board state not code work: (1) call addCommentToJiraIssue for each key immediately, (2) call atlassianUserInfo to get your accountId and editJiraIssue to assign each Jira issue to yourself, (3) call getTransitionsForJiraIssue and transitionJiraIssue to move each issue to 'In Progress' status. REJECTION CONTEXT: when rejectionContext is present, it contains rejectionNote (free-text human feedback), rejectionStrategy ('fix_forward' or 'revert'), and optionally rejectionCategory — a structured failure-mode label from one of: missing_acceptance_criteria, wrong_scope, tests_failing_or_missing, code_quality, partial_implementation, architecture_drift. Use rejectionCategory to target your remediation before reading the note. MISSION BRIEF: the response always includes a missionBrief object with pre-computed signals to orient you before starting work — strategicBucketFirstPassRate (0–1 first-pass rate for this strategic bucket over the trailing 30 completed objectives, null if fewer than 3), topRejectionCategories (top 3 structured rejection categories from recent same-bucket work, empty array if none), specQuality ({ score: 0–100, warnings: string[] } from the objective's quality score, null if not yet scored), pendingDocSuggestions (count of pending context-file suggestions for this project), and driftNote (a plain-English advisory string when the bucket avg drift score exceeds 30 over the trailing 30 completions with ≥ 5 samples, null otherwise — treat this as a scope-discipline warning and stay tightly bound to the acceptance criteria). Use these signals to calibrate your approach — low bucket first-pass rate, low spec quality, or a non-null driftNote all warrant extra care. |
| planwright_append_plan | Post the agent's decomposition plan to the active agent run. |
| planwright_check_alignment | Check whether the work you are about to implement aligns with the claimed objective. Call this BEFORE starting any code changes — immediately after planwright_append_plan. Pass agentRunId from your claim response and a one-sentence proposedWork description of what you are about to build based on the current conversation. Read the returned objective and compare it against what the user is now asking for. If they diverge, stop and ask the user before proceeding: offer to update the existing objective, create a new objective, or continue with the original. Do not open an editor until alignment is confirmed. Omit agentRunId if you have not yet claimed an objective — the tool will instruct you to create or pick one before writing any code. |
| planwright_record_diff | Record a diff summary and test results for the active agent run. |
| planwright_submit_test_run | Submit acceptance-criteria verification results for the active agent run. Call this before planwright_request_acceptance whenever the claim response included acceptanceItems. Pass EITHER `results` — direct structured entries `{ criterionId, status, steps }` for ad-hoc/manual verification (the common case: commands you ran, what you observed, screenshots) — OR `playwrightJsonReport`, the raw JSON from `npx playwright test --reporter=json`, which is parsed for `[AC:ac_x]` markers in spec titles and auto-derives a steps narrative. `steps` must be a genuine account of what you did, never a restatement of the criterion text. Use `nonTestable` for criteria you could not test. Any acceptanceItem left uncovered is recorded as untested automatically. |
| planwright_request_acceptance | Move an objective from 'in_progress' to 'acceptance' lane, completing the agent run and notifying humans for review. DRIFT SELF-ASSESSMENT: always include driftScore (0–100, where 0 = perfect alignment with stated intent) and driftNote (one sentence on why delivery diverged, or confirming alignment if score is low). You have the richest context right now — the diff you just wrote, the ACs you addressed or skipped — so self-assess before handing off. AC CATEGORIES: if the objective has non-empty acceptanceCriteria and no stored acceptanceCriteriaCategories, this call is REJECTED unless you supply acceptanceCriteriaCategories (one validation-type category per AC bullet line, same order) — same required-if-missing pattern as strategic_focus. Ignored if the objective is already categorized. JIRA SYNC: if the response contains jiraLabels and jiraComment, you MUST (1) call addCommentToJiraIssue for each key immediately, then (2) call getTransitionsForJiraIssue and transition to the best review status available — prefer 'In Review', 'Code Review', 'Review', 'Under Review'. If none match, skip terminal statuses and pick the closest fit. If no suitable transition exists, skip it and note in the comment that manual transition is needed. |
| planwright_list_my_bugs | List bugs for this project, optionally filtered by agent kind. |
| planwright_append_note | Record completion of a TODO task in the agent run log. Call this after EVERY completed TODO — but only after you have committed AND pushed the code for that task. Never call this before pushing. The note should name the task completed and briefly describe what changed. |
| planwright_list_context_files | List all context files for this project (CLAUDE.md, specs, architecture docs, etc.). Read these before planning or starting work on an objective. |
| planwright_get_context_file | Read a specific context file by filename. Use this to understand project conventions, architecture, constraints, and style guides before working on an objective. |
| planwright_push_context_file | Push or update a context file for this project. Use from Claude Desktop to share specs, CLAUDE.md, architecture docs, or any text that agents should read before working. If the filename already exists, it will be updated. Pass resolvedSuggestionId to mark a pending doc suggestion as applied. |
| planwright_get_doc_suggestions | Returns up to 10 pending documentation gap suggestions for the current project, ordered by recency. Suggestions are generated weekly from rejection notes that reference topics not covered by any context file. Call at session start — apply suggestions via planwright_push_context_file (with resolvedSuggestionId) or dismiss via planwright_dismiss_doc_suggestion. |
| planwright_dismiss_doc_suggestion | Dismiss a pending documentation gap suggestion by ID. Use when the suggestion is not applicable or has already been addressed. To apply a suggestion, use planwright_push_context_file with resolvedSuggestionId instead. |
| planwright_get_board_url | Get the Planwright board URL for the current project. Pass labelName to get a pre-filtered URL (e.g. for a Jira epic back-link). |
| planwright_flag_clarity | Flag an objective or initiative as having clarity concerns. For objectives: call this after claiming if the outcome is ambiguous in ways a senior engineer could not resolve by reading the codebase alone — moves it back to 'scheduled' and pauses your agent run, stop all work after calling. For initiatives: sets clarityFlag so it appears highlighted on the Intent Map for human rework. Only flag genuine blockers, not implementation opinions. |
| planwright_list_unenriched | Returns objectives and initiatives in the current project that have no intentSummary. Call this after planwright_set_repo as part of session setup — enrich each item before starting your primary task. |
| planwright_list_unclassified | Returns objectives in the CURRENT project (only) that have no strategic_focus set, across all lanes (including done and acceptance). Scoped to one project — do NOT call planwright_list_projects and iterate; classify the active project only. Use this for retroactive backfill — read each objective's title, description, and intentSummary, then call planwright_update_objective with strategic_focus to classify it. Taxonomy: BUILD → PRODUCT_CAPABILITY, PLATFORM_INFRASTRUCTURE; GROW → REVENUE_ENABLEMENT, GO_TO_MARKET, MARKET_POSITIONING; TRUST → QUALITY_RISK_REDUCTION, COMPLIANCE_GOVERNANCE, CUSTOMER_ENABLEMENT; SCALE → ECOSYSTEM_INTEGRATIONS, ORGANIZATIONAL_SCALE. Express uncertainty via the confidence field (0–1) — write even low-confidence classifications rather than skipping them. |
| planwright_override_clarity | Override a clarity flag on a flagged objective so an agent can claim it. HUMAN ONLY — this tool requires an OAuth session and will reject calls from agent tokens. Provide a reason explaining why the objective is clear enough to proceed; it is recorded in the audit chain. The agent's concerns remain visible in the audit log for reference. |