Run any Skill in Manus with one click

doctor

Stars111

Forks24

UpdatedJuly 8, 2026 at 11:31

Run a read-only Blueprint health check for setup, onboarding, required files, tool adapters, commands, Blueprint visibility, ignore rules, planning readiness, overview freshness, and workflow drift. Use when the user runs /doctor, asks whether the Blueprint is installed correctly, wants a health check, setup check, doctor pass, or says something feels off before starting or resuming work.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

bradtraversy

bradtraversy/ai-blueprint

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

audit

bradtraversy/ai-blueprint

Read-only code quality audit for a Blueprint project. Reviews the active feature, changed files, a selected path, or the full project for maintainability issues such as duplication, dead code, DRY violations, inconsistent patterns, overgrown files or functions, unused exports, missing or disabled tests, standards drift, and obvious security or performance risks. Use when the user runs /audit, invokes $audit, asks to audit the code, review code quality, check for dead code, check for duplicates, clean up a vibe-coded project, or make sure the code still meets project standards.

2026-07-12111

autopilot

bradtraversy/ai-blueprint

Optional explicit Blueprint mode for one bounded spec/build/check/audit pass. It can pick or resume the current feature, write the spec when needed, create or reuse the branch, implement small steps, run build/tests/checks, create checkpoint commits after passing steps, audit changed code, repair confirmed high-severity findings, and stop with a review packet. It never completes, merges, pushes, deploys, publishes, sends, or performs destructive actions without explicit approval. Use only when the user explicitly runs /autopilot, invokes $autopilot, or directly asks for Autopilot.

2026-07-12111

overview

bradtraversy/ai-blueprint

Validate and, when needed, normalize the two planning docs before generating blueprint/context/project-overview.md from blueprint/project-plan.md and blueprint/build-plan.md. The overview is the single AI-facing source of truth that project instructions load every session. Use when the user runs /overview, invokes $overview, has just finished writing or editing the plans, asks to shape rough plans into the Blueprint format, or asks to regenerate the project overview.

2026-07-08111

release

bradtraversy/ai-blueprint

Prepare a Blueprint project for deployment to Render or Vercel. Reads the plans, project commands, app config, and current repo state; verifies build, start, output, env, health checks, and provider config; can create or update render.yaml or vercel.json when requested; and stops before any external deploy, service creation, remote env change, push, publish, or destructive action unless the user explicitly approves. Use when the user runs /release, invokes $release, asks for Render setup, Vercel setup, deploy readiness, deployment config, render.yaml, or vercel.json.

2026-07-08111

complete

bradtraversy/ai-blueprint

Wrap up a finished feature or fix. Runs a final safety pass, archives its spec to blueprint/history/features/ (feature) or blueprint/history/fixes/ (fix), checks features off the build plan, resets blueprint/context/current-feature.md to its stub, makes one feature-level commit, then squash-merges the branch to main and deletes it. Merges only with explicit approval, then asks separately before pushing main. Use when the user runs /complete, or asks to finish, wrap up, merge, or close out the current feature or fix after it's built and reviewed.

2026-07-08111

implement

bradtraversy/ai-blueprint

Build the feature or fix spec'd in blueprint/context/current-feature.md, one small reviewable step at a time. Creates the branch, implements each step, shows the diff and explains it in plain English, tests, and iterates until it works. After each approved step it offers an optional commit checkpoint on the branch; the feature-level commit, merge, and logging are /complete's job. Use when the user runs /implement, or asks to build, implement, or start the current feature or fix once its spec is ready.

2026-07-08111

name	doctor
description	Run a read-only Blueprint health check for setup, onboarding, required files, tool adapters, commands, Blueprint visibility, ignore rules, planning readiness, overview freshness, and workflow drift. Use when the user runs /doctor, asks whether the Blueprint is installed correctly, wants a health check, setup check, doctor pass, or says something feels off before starting or resuming work.

doctor - Blueprint health check

Where this sits in the workflow:

any time  ->  [doctor]  ->  reads setup + plans + workflow state + git
              (read-only)   prints health, warnings, and repair order

This skill answers one question: is this Blueprint project ready to use? It is the diagnostic pass for setup drift, incomplete onboarding, missing files, placeholder plans, stale generated context, Blueprint visibility, and confusing workflow state. It never changes anything: no edits, no commits, no installs, no builds, no branch changes.

Use /status when the user mainly wants progress and the next build action. Use /doctor when the user wants to know whether the workflow itself is healthy.

Input

None. /doctor takes no argument.

What it checks

Gather these, then summarize. Do not dump file contents.

Required Blueprint files
- Confirm AGENTS.md, blueprint/, blueprint/project-plan.md, blueprint/build-plan.md, and blueprint/context/ exist.
- Confirm blueprint/context/coding-standards.md, blueprint/context/ai-interaction.md, blueprint/context/current-feature.md, and blueprint/context/project-overview.md exist.
- Confirm blueprint/history/features/ and blueprint/history/fixes/ exist.
- If .gitignore marks Blueprint workflow files as local-only, still require the files to exist on disk. Ignored but present is healthy; ignored and missing means the local workflow needs to be restored.
Tool adapters
- Confirm at least one adapter exists: .agents/skills/ for Codex or .claude/skills/ for Claude Code.
- If both adapters are present, say that is healthy when both tools are used.
- If both adapters are present, compare their skill folder names. Warn about missing skills on either side.
- If git shows changes under .agents/skills/ or .claude/skills/, check the matching adapter file too. Warn when workflow behavior was updated in one adapter but not the other.
- If only one tool is used, mention the unused adapter can be deleted. Do not treat extra adapters as an error.
- If CLAUDE.md exists and still starts with # Project Name, flag that /onboard probably has not finished.
Commands and project setup
- Check whether root README.md is still the copied Blueprint workflow doc by looking for # AI Coding Blueprint or opening text that describes the Blueprint workflow instead of the app. If so, warn that /onboard should move it to blueprint/README.md and create a project README before publishing.
- If blueprint/README.md exists, treat that as the expected home for the copied workflow doc inside a consumer project.
- Check whether AGENTS.md has a ## Commands section with dev and build commands.
- Report missing lint or test commands as informational unless the project has real lint or test scripts elsewhere that are not reflected in AGENTS.md.
- If package.json exists, compare its scripts against AGENTS.md at a high level. Do not require every script to be documented.
Ignore rules
- Check obvious ignore patterns for the detected stack. For Node or Astro, look for node_modules, .env, dist, and framework cache folders such as .astro or .next when relevant.
- Detect local-only Blueprint mode if .gitignore ignores .agents/, .claude/, blueprint/, or CLAUDE.md. Report it as a visibility choice, not a failure, when the local files exist.
- In local-only mode, check whether tracked AGENTS.md still describes the Blueprint workflow, points to blueprint/README.md, lists hidden adapter paths, or exposes the core skill list. If so, warn that /onboard should make AGENTS.md public-safe.
- If local-only mode is active but those paths are already tracked by git, warn that .gitignore does not hide tracked files and the user must approve any git rm --cached cleanup separately.
- Keep this conservative. If uncertain, report "review" instead of failure.
Planning readiness
- Check whether blueprint/project-plan.md and blueprint/build-plan.md look filled in or still template-like. Treat obvious TODO, TBD, example-only text, or empty required sections as not ready.
- Check whether blueprint/build-plan.md is a numbered checkbox list. Raw bullets are allowed as a first draft, but they should be normalized by /overview before the build loop starts.
- Count checked and unchecked leaf items in blueprint/build-plan.md.
Overview freshness
- Check whether blueprint/context/project-overview.md exists and looks generated from the current plans.
- If either planning file appears newer than the overview by filesystem time, call the overview possibly stale and suggest /overview before feature work.
Current workflow state
- Check whether blueprint/context/current-feature.md is the reset stub or an active feature or fix spec.
- If a spec is active, report checked and unchecked implementation steps.
- If current-feature.md is the reset stub but git has source or workflow changes, warn that work is happening without an active spec.
- Flag active spec on main, all spec steps checked but no completion, or a mismatch between the active spec and the next unchecked build-plan item.
Git
- Report current branch, clean vs dirty working tree, rough changed-file count, last commit subject, and whether the branch is ahead of upstream.
- If the directory is not a git repo, report that as a setup issue and keep going.

Output

Print a compact health report with these labels:

Health: Pass | Needs attention | Blocked
Setup: ...
Adapters: ...
Visibility: ...
Plans: ...
Workflow: ...
Git: ...
Watch: ...
Repair order: ...

Use Watch: only when there are warnings. Use Repair order: for the exact next steps, in order. Keep it short and practical.

Choose the repair order in this priority:

Required Blueprint files missing -> overlay the Blueprint again, or use /adopt for a brownfield app.
No git repo -> initialize git before using the build loop.
No tool adapter -> restore .agents/skills/ or .claude/skills/ for the tool being used.
Onboarding incomplete -> run /onboard.
Root README is still the Blueprint workflow doc -> run /onboard or move it to blueprint/README.md before publishing.
Local-only visibility selected but ignored Blueprint files are missing -> reinstall or restore the Blueprint files locally.
Local-only visibility selected but Blueprint paths are tracked -> ask whether to untrack them with git rm --cached while keeping local files.
Local-only visibility selected but AGENTS.md still exposes the workflow -> run /onboard to make AGENTS.md a lightweight public project guide.
Commands or ignore rules need review -> update the files or run /onboard if this is an early project.
Plans are placeholders -> fill blueprint/project-plan.md and blueprint/build-plan.md.
Overview missing or stale -> run /overview.
Active spec has unchecked steps -> run /status or /implement, depending on whether the user wants orientation or action.
Active spec is done but not closed -> run /check, then /complete.
Everything is healthy -> say so, then suggest /status for progress or /feature for the next planned feature.

Rules

Read-only, always. This skill never writes files, never commits, never runs installs, never runs builds or tests, and never switches branches.
Diagnose, then order repairs. Do not just list problems. End with the smallest ordered sequence that gets the project back to a healthy state.
Do not over-police adapters. Extra adapters are optional clutter, not a failure.
Be conservative with stack-specific checks. If a command or ignore pattern is uncertain, mark it for review instead of inventing a hard failure.
Stay concise. A doctor pass should feel like a checklist, not an audit.

Formatting

Format the output to match the project's conventions in blueprint/context/ai-interaction.md: concise, scannable markdown, with lists for enumerations and tables for matrices rather than dense paragraphs.