“Add CSV export” sounds like a clear software task until someone asks which rows, columns, permissions, and file format count as correct. A model can fill those gaps with plausible choices, but plausible is not the same as approved.
Useful AI prompts for project management bind an outcome to source material, constraints, authority, an expected output, and verification. These four software project prompts follow one example: adding CSV export to the filtered issue list in a support dashboard. They are author-designed, not claims about a completed benchmark or production test.
What a Useful Software Project Prompt Contains
A software project prompt should answer six questions:
- Outcome: What changes for the user or operator?
- Context: Which repository, module, current behavior, and source of truth are relevant?
- Constraints: What must remain unchanged?
- Authority: Is the request for analysis, a proposal, repository edits, or release action?
- Output: What artifact should come back?
- Acceptance: Which project acceptance criteria and evidence will show the artifact is usable?
This is stricter than asking a model to “act as a senior project manager.” Guidance on goals, instructions, examples, constraints, and output formats is a useful baseline. Software delivery also needs system boundaries, permission limits, and evidence.
Prompts You Can Adapt Across Delivery Stages
Each template separates inputs, output, and acceptance. Replace every bracketed field; write UNKNOWN rather than letting the model guess.
Define a Feature Goal and Acceptance Criteria
Use this before task planning to create a reviewable brief without choosing an implementation.
You are preparing a software feature brief. Do not write code or edit files.
Inputs
- User outcome: [what the user must be able to do]
- Context and sources: [product, repository, module, behavior, tickets, designs, schemas, policies, or paths]
- Scope: [allowed behavior and surfaces]
- Out of scope: [explicit exclusions]
- Fixed constraints: [security, compatibility, accessibility, performance, or release constraints]
- Authority: proposal only; do not modify repositories or external systems
- Unknowns: [known gaps, or UNKNOWN]
Expected output
1. Restate the feature goal in one sentence.
2. Separate scope, non-goals, assumptions, and unresolved questions.
3. Write acceptance criteria with a condition, behavior, and evidence.
4. Identify required decisions or permissions.
5. Do not invent requirements. Put unsupported choices under unresolved questions.
Acceptance method
- Every criterion can be demonstrated.
- Every behavior traces to an input or source.
- No unknown is silently converted into a requirement.For the example, use “download the currently filtered issue list as CSV.” Keep column order, export size, timezone, and access behavior unknown unless a source defines them.
Turn a Goal Into a Dependency-Aware Task Plan
AI task breakdown prompts should sequence an approved brief without disguising guesses as assignments or dates.
Create a dependency-aware implementation proposal from the approved feature brief below. Do not edit the repository.
Inputs
- Approved feature brief: [paste the goal, scope, non-goals, and acceptance criteria]
- Codebase evidence: [files, architecture notes, interfaces, and test commands]
- Constraints: [release, compatibility, review, and environment limits]
- Available roles: [roles or skills; use UNASSIGNED where ownership is not approved]
- Estimation basis: [team history, analogous task, or NONE]
Expected output
Return a table with: task ID, deliverable, criteria covered, dependencies, parallel-safe status, owner role, verification, and risk. Then give the critical path and blocking decisions.
Rules
- Trace every task to an acceptance criterion or delivery control.
- Do not assign named people, dates, or effort estimates without supplied evidence.
- Mark tasks that touch overlapping files, schemas, or contracts as not parallel-safe.
- Separate implementation, tests, documentation, review, and release preparation when needed.
Acceptance method
- Every criterion maps to a task and verification.
- Dependencies have no circular or missing references.
- Unassigned ownership and unsupported estimates remain visible.The CSV plan may separate the export contract, query behavior, authorization reuse, UI trigger, checks, and release notes. It should not assume a browser-only export or background job without codebase evidence.
Request a Status Update Backed by Evidence
Most project status prompts request a confident summary. This one separates completed work from reported work.
Prepare a project status update using only the evidence supplied below.
Inputs
- Approved plan and acceptance criteria: [paste or link]
- Reporting period: [start and end]
- Evidence: [commits, diffs, pull requests, tests, screenshots, logs, decisions]
- Blockers, owners, and audience: [list]
Expected output
1. Overall status: on track, at risk, blocked, or unknown, with a reason.
2. A table with plan item, claimed state, evidence, acceptance impact, blocker, owner, and next decision.
3. Scope, assumption, dependency, or risk changes.
4. The next actions and decisions.
Rules
- Use complete only when evidence shows the relevant acceptance criterion passed.
- Label unsupported claims not verified.
- Do not convert an estimate into a deadline commitment.
- Do not hide failed checks behind completion percentages.
Acceptance method
- Every completion claim points to evidence.
- Every blocker has an owner or `UNASSIGNED`.
- The update states what changed, not only what activity occurred.“UI button implemented” is activity. “Filtered rows exported in the agreed order; integration check export_filtered_issues passed” is evidence.
Check a Delivery Against the Original Request
Run this as a read-only acceptance review; it withholds permission to repair findings.
Audit the proposed delivery against the original request. This is a read-only review: do not edit files, run destructive commands, merge, deploy, or contact external systems.
Inputs
- Original feature brief: [paste]
- Acceptance criteria: [paste]
- Decisions and evidence: [approved changes, diff, changed files, tests, screenshots, logs, or artifact]
- Known limitations: [list]
Expected output
Return a table with criterion, status (pass, fail, or not verified), evidence, gap, and next action. Then list out-of-scope changes, regression risks, missing evidence, and reviewer questions.
Rules
- Evaluate the supplied delivery, not an imagined one.
- Do not pass a criterion without primary evidence.
- Do not fix failures unless separate write authorization is provided.
- Separate product acceptance, code quality, and release approval.
Acceptance method
- Every criterion appears exactly once in the traceability table.
- Every pass cites direct evidence.
- Every gap has a next action.This should catch a button that exports all issues instead of the active filter, or a unit test that never checks authorization.
Improve a Vague Prompt Without Inventing Requirements
Do not “improve” Add CSV export by inventing columns, limits, or dates. Split the request into confirmed, inferred, and missing information. Only confirmed facts enter the brief; missing decisions go to the outcome owner.
Request the smallest reviewable brief, not the largest plausible specification. Point the model to existing filter and permission behavior; prompting cannot manufacture stakeholder approval.
When Better Prompts Are Not Enough
A prompt cannot resolve conflicting decisions, grant access, restore a test environment, prove an unavailable vendor API, or turn absent delivery history into a reliable estimate.
Escalate when work depends on a product choice, credential, approval, external service, or release owner. Record what is missing, what can continue, who decides, and the evidence needed to resume.
Using Outcome-Based Prompts in Verdent
Verdent Manager is a specific case where users need not manually decompose work. Its current Manager workflow can take an outcome, create stages and dependency-aware subtasks, dispatch agents, and return deliverables and review context. It still recommends acceptance criteria; “state the outcome” does not mean “omit the boundary.”
Verdent's current configuration guidance routes clear tasks to Agent Mode, unfamiliar codebases to Plan Mode, and production or architectural work through Plan Mode before Agent Mode. That product choice is not a promise that any chat model will inspect a repository, preserve permissions, or execute a plan.
FAQ
Should project prompts contain API keys or customer records?
No. Reference an approved secret name, vault entry, fixture, or sanitized sample. State who may access the real system and use the organization's least-privilege process.
Can the brief and the codebase use different languages?
Yes. Name the languages for discussion, code, comments, identifiers, tests, and user-facing copy. Provide a terminology map and flag ambiguity.
How can I request an estimate without treating it as a deadline promise?
Ask for a range, evidence, assumptions, dependencies, confidence, and a re-estimation trigger. Without comparable work, require insufficient evidence. A deadline needs team acceptance.
What should I ask when a required vendor API is unavailable?
Request the failed dependency, observed evidence, safe parallel work, mock or contract-test options, retry owner, and resume condition. Do not invent a successful response or redesign the integration without approval.
How do I request a proposal without authorizing repository edits?
Use an authority line: “Analysis and proposal only. Do not edit files, create branches, run write commands, open pull requests, deploy, or contact external systems.” Define the proposal and review criteria. Planning and write permission are separate.
Save the Prompt Alongside Its Acceptance Criteria
Keep the approved prompt, acceptance criteria, plan, decisions, and evidence as one project record. Update it when scope changes. A prompt stays useful while the team can trace an outcome to an approved decision and a verifiable result.
