How do I install the Define Project skill?

Run npx skillmds@latest add ryan-scheinberg/define-project in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Define Project safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Define Project?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Define Project free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Define Project?

ryan-scheinberg (@ryan-scheinberg) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Define Project by ryan-scheinberg — Agent Skill

Name: Define Project
Author: ryan-scheinberg

Define Project

Take a brief idea and produce a complete PROJECT_BRIEF.md as if the user wrote it on their best day. Covers features, fixes, infra, and full products alike. Use when user wants to define a project, scope a feature, plan a complex fix, or mentions "project brief" or "new project"

File contents

Produce a PROJECT_BRIEF.md proficient agents can pick up and build from without clarifying questions. Terse, opinionated, decisions made not deferred. The user's persona and preferences already live in CLAUDE.md — don't restate them

Process

Read the user's input. Infer what you can as an architect. iterate-plan closes the rest after the first draft
Explore the codebase if one exists starting with AGENTS.md files. Tech stack, test setup, CI, module boundaries, naming conventions. Don't ask what code can answer
Decide. Pick the stack and scope the MVP — the thinnest end-to-end vertical path that proves the approach. Genuine uncertainty goes in Risks & Open Questions. Default to deciding. Hedged briefs ship ambiguity forward into dev turns. Don't name downstream slices here — that's plan-to-slices' job, and pre-slicing the brief locks in a shape before the MVP has taught you anything
Write the brief using the template. Adapt freely — drop sections that don't apply, add sections when the project needs them. A bug fix doesn't need a business model; a SaaS needs all of it

Template

[Project Name]

Context

What this is, why it exists, the problem it solves. No throat-clearing

Audience

Who uses or benefits. For internal or infra work this may be "the deployment pipeline" or "future contributors to this repo"

Scope

The MVP Slice

One sentence: "A user/system can [do X] and [see/get Y]"

In Scope

Out of Scope

What's excluded and why

Technical Approach

Stack, architecture, data, auth, infra with rationale. For existing codebases: what changes, what doesn't

Testing & Observability

What gets tested and instrumented. Structured logging, key metrics, health checks. What tells you this is working or broken in prod

Deployment & Rollout

Environments, rollout strategy, flags, rollback. Skip for non-deployable work

Risks & Open Questions

What's uncertain. Each item notes what would close it

Quality bar

Every section is specific. If you can only fill it with boilerplate, drop it
Decisions are committed or flagged, never hedged

---name: define-projectdescription: Take a brief idea and produce a complete PROJECT_BRIEF.md as if the user wrote it on their best day. Covers features, fixes, infra, and full products alike. Use when user wants to define a project, scope a feature, plan a complex fix, or mentions "project brief" or "new project"---Produce a `PROJECT_BRIEF.md` proficient agents can pick up and build from without clarifying questions. Terse, opinionated, decisions made not deferred. The user's persona and preferences already live in `CLAUDE.md` — don't restate them## Process1. **Read the user's input.** Infer what you can as an architect. `iterate-plan` closes the rest after the first draft2. **Explore the codebase if one exists** starting with `AGENTS.md` files. Tech stack, test setup, CI, module boundaries, naming conventions. Don't ask what code can answer3. **Decide.** Pick the stack and scope the MVP — the thinnest end-to-end vertical path that proves the approach. Genuine uncertainty goes in Risks & Open Questions. Default to deciding. Hedged briefs ship ambiguity forward into dev turns. Don't name downstream slices here — that's `plan-to-slices`' job, and pre-slicing the brief locks in a shape before the MVP has taught you anything4. **Write the brief** using the template. Adapt freely — drop sections that don't apply, add sections when the project needs them. A bug fix doesn't need a business model; a SaaS needs all of it## Template<brief-template># [Project Name]## ContextWhat this is, why it exists, the problem it solves. No throat-clearing## AudienceWho uses or benefits. For internal or infra work this may be "the deployment pipeline" or "future contributors to this repo"## Scope### The MVP SliceOne sentence: "A user/system can [do X] and [see/get Y]"### In Scope- ...### Out of Scope- What's excluded and why## Technical ApproachStack, architecture, data, auth, infra with rationale. For existing codebases: what changes, what doesn't## Testing & ObservabilityWhat gets tested and instrumented. Structured logging, key metrics, health checks. What tells you this is working or broken in prod## Deployment & RolloutEnvironments, rollout strategy, flags, rollback. Skip for non-deployable work## Risks & Open QuestionsWhat's uncertain. Each item notes what would close it</brief-template>## Quality bar- Every section is specific. If you can only fill it with boilerplate, drop it- Decisions are committed or flagged, never hedged

Frequently asked questions