Best Claude prompts for project managers in 2026

Twelve Claude prompts working PMs use in 2026 — charters, RACI matrices, Jira stoplight summaries, risk-register hunting, dependency mapping, retro synthesis, agenda compression, stakeholder tone variants, scope-creep diagnostics, capacity rebalancing, post-mortems, and a 5-bullet executive recap. Each produces a named artifact, not a wall of prose. Strip customer and employee identifiers before pasting; treat every output as a first draft.

Sources behind the structure: PMI's 2024 Pulse of the Profession, the Asana 2024 State of Work report, the Atlassian Team Health Monitor, and Anthropic's prompt-engineering documentation.

→ **Generate a custom PM prompt with our builder** (free, no signup)

---

Marketing prompts reward creativity. Engineering prompts reward precision. PM prompts reward a third thing — *artifact discipline*. The output is rarely the prose; it's a deliverable a stakeholder scans in under sixty seconds: a charter, a RACI, a status email, a risk row.

The PMI 2024 Pulse of the Profession survey found high-performing PMOs spend 28% less time on status reporting than median PMOs — most of that delta is artifact reuse, not skill. The Asana 2024 State of Work report puts the average knowledge worker at 58% of the workday on "work about work." PMs sit at the center of that load.

Three rules sit underneath every prompt below:

- **Name the artifact explicitly.** Ask for "a one-page charter" or "a RACI table," not "help me plan." Specificity is the single biggest lever on output quality, per Anthropic's prompt-engineering guidance. - **Strip identifiers when pasting from real systems.** Replace names and accounts with `[STAKEHOLDER_A]` or `[CUSTOMER_X]` before pasting Jira, transcripts, or contracts. - **Force the failure mode into the prompt.** Tell Claude what bad output looks like ("do not invent dependencies you cannot see in the descriptions") and you halve back-end review time.

These prompts assume Claude 3.5 Sonnet or newer. Older models miss the structured reasoning, particularly the risk hunter (Prompt 4) and capacity rebalance (Prompt 10).

---

**When to use:** A sponsor drops a one-line ask in Slack and you need a charter draft on their desk before the first steering meeting.

``` Draft a one-page project charter from the brief below. Use this exact structure and do not add sections: 1. Project name (concrete, not aspirational). 2. Problem statement (two sentences — what hurts today, who feels it). 3. Objective and success metric (one objective, one metric, with a number and a date). 4. In-scope (bulleted, 3-7 items, concrete). 5. Out-of-scope (bulleted, 3-5 items — the things stakeholders will assume are included unless you call them out). 6. Key stakeholders and their stake (table — name/role, what they care about, what they fear). 7. Top three risks at kickoff (one sentence each, with a triggering signal). 8. First two milestones (with a target date relative to kickoff). 9. Decision rights (who approves scope changes, who approves budget, who approves go-live). Constraints: - Maximum 400 words total. - No hedging language ("we will try to," "approximately," "various"). - If the brief is missing data needed for a section, write "OPEN QUESTION:" and the specific question to ask the sponsor. Brief: [paste the one-line brief plus any Slack context] ```

**Sample output (excerpt):** _"Project name: Self-Serve Onboarding Reduction. Problem statement: New customers take 14 days median to complete onboarding; CS handles 62% of activation manually. Objective: cut median onboarding to 4 days by 2026-09-30. In-scope: account-setup wizard, sample-data import, in-app activation checklist. Out-of-scope: pricing changes, SSO redesign… OPEN QUESTION: who owns the activation checklist component in current architecture?"_

The "OPEN QUESTION" output is what makes this prompt earn its keep. It turns Claude into a brief-completeness checker, not just a drafter.

---

**When to use:** Kickoff is in two days, you have a stakeholder list and a workstream list, and you want a RACI that won't dissolve under questioning.

``` Build a RACI matrix for the project below. Use these rules strictly: - Every row (deliverable) must have exactly ONE Accountable. If two people seem accountable, the deliverable is wrong — split it. - Responsible can be multiple. Consulted and Informed can be multiple. - A person cannot be Accountable for more than 30% of rows. If they are, flag the over-concentration explicitly. - If a stakeholder appears in zero rows, flag it — they should not be on the project list. Output format: 1. The RACI table itself (rows = deliverables, columns = stakeholders, cells = R / A / C / I or blank). 2. A "Flags" section listing: any deliverable without an A, any over-concentrated A, any unused stakeholder, any deliverable where the R and A are the same person (acceptable, but call it out). 3. Three suggested questions to resolve at kickoff based on the flags. Deliverables list: [paste] Stakeholders list: [paste with role descriptions] ```

**Sample output (excerpt):** _"Flags: 'Production cutover' has no Accountable assigned — recommend [STAKEHOLDER_B] (VP Eng) given decision rights. [STAKEHOLDER_D] is Accountable for 7 of 18 deliverables (38%) — recommend redistributing 'training material' and 'comms plan' to [STAKEHOLDER_F]. Stakeholder [STAKEHOLDER_G] appears in zero rows — confirm involvement is still required…"_

The single-Accountable rule is the one PMs most often violate and the one auditors catch first. Forcing Claude to enforce it surfaces political conversations early.

---

**When to use:** Friday afternoon, weekly status is due Monday morning, and you have a CSV export of 200 Jira tickets with status, owner, due date, and story points.

``` Summarize the Jira export below into a stoplight status report. Rules: - Roll up by Epic, not by individual ticket. - Use Green / Yellow / Red with these definitions: - Green: >=80% of points complete OR on-track to due date with no blockers. - Yellow: 50-79% complete OR one blocker open >3 days OR due date at risk by <2 weeks. - Red: <50% complete near deadline OR blocker open >7 days OR due date already missed. - For each epic, give: status color, one-sentence summary of why it's that color, the single biggest blocker or risk, and the named owner. - Do not include epic-level commentary on epics with zero activity in the period — list them in a separate "No movement" section. Then produce a top-of-report section with: - Overall portfolio color (worst of the major epics). - Three items that changed color this week (from Green to Yellow, etc). - One ask of the executive sponsor (the single decision needed this week). Do not invent owners or blockers. If a ticket has no owner, say so. Jira export: [paste CSV — strip customer names first] ```

**Sample output (excerpt):** _"Portfolio: Yellow. Changes this week: Epic ONBOARD-12 Green→Yellow (wizard QA blocker), Epic BILLING-7 Red→Yellow (Stripe webhook resolved), Epic ANALYTICS-3 Yellow→Red (data-eng dependency slipped). Sponsor ask: approve a 2-week scope cut on ANALYTICS-3 or escalate the data-eng dependency. Epic ONBOARD-12: Yellow. Wizard QA blocked on staging environment access since 2026-06-04 (4 days). Owner: [STAKEHOLDER_C]…"_

Per the Atlassian Team Health Monitor, the most-overlooked signal in weekly status is "items that changed color" — Claude is good at finding those if you ask.

---

**When to use:** Mid-project risk-register review, and you suspect there are risks living in Slack threads, retros, and ticket comments that never made it onto the register.

``` Hunt for project risks in the documents below that are NOT yet on the risk register I'm pasting. For each candidate risk: 1. Risk statement (one sentence — what could happen, what would it cause). 2. Source: exact quote or ticket ID where you spotted the signal. 3. Likelihood (Low / Medium / High) with a one-sentence rationale. 4. Impact (Low / Medium / High) with a one-sentence rationale. 5. Whether it overlaps a risk already on the register (yes/no — name it if yes). 6. A proposed mitigation owner (role, not name). Then produce a top section with the 3 highest-priority new risks ranked by Likelihood × Impact. Do not invent risks. If you cannot point to a specific source in the input, do not include the candidate. Existing risk register: [paste] Meeting notes / tickets / Slack threads: [paste — strip names] ```

**Sample output (excerpt):** _"New risk #1: Vendor SLA for the payments processor is silent on incident response during region outages. Source: ticket BILLING-204 comment thread, 2026-05-28. Likelihood: Medium. Impact: High. Overlap: partial — register risk R-7 covers payment failures, not vendor incident response. Proposed mitigation owner: VP Engineering. New risk #2: Test data for QA includes [PII pattern] visible in retro notes 2026-06-02 — compliance exposure if leaked. Source: retro doc paragraph 4…"_

Forcing source quotes separates a useful risk hunter from a hallucinated one. PMI's Pulse of the Profession 2024 shows traceable risk identification correlates with on-time delivery.

---

**When to use:** Multiple teams are working in parallel, you have a list of tickets with descriptions, and you suspect there are silent dependencies that will surface only at integration.

``` Build a dependency map from the tickets below. For each pair of tickets where you see a dependency signal in the descriptions, output: - From-ticket (the one that is blocked or waiting). - To-ticket (the one that must be done first or in coordination). - Dependency type: - Hard (one must literally complete before the other can start). - Soft (one materially affects the other — e.g., API shape). - Coordination (must align on data model, schedule, or owner). - Confidence (High / Medium / Low — only High if both tickets explicitly reference the other or the same concrete component). - The signal phrase in the descriptions that revealed the dependency. Then produce: - A critical-chain section showing the longest dependency path. - A list of orphan tickets (no dependencies into or out of them) — these are either truly independent or under-described. - A list of dependency CLAIMS that cannot be verified from the inputs (e.g., the ticket says "blocked by infra" but no infra ticket is in the list). Do not invent dependencies. Low confidence is fine; fiction is not. Tickets: [paste with descriptions] ```

**Sample output (excerpt):** _"Hard dependency: ONBOARD-44 → IDP-12. Signal: ONBOARD-44 description says 'requires the SSO config endpoint from identity work.' Confidence: High. Soft dependency: BILLING-19 → ANALYTICS-5. Signal: both reference the 'subscription_event' schema. Confidence: Medium — schema isn't versioned in either ticket. Critical chain: IDP-12 → ONBOARD-44 → ONBOARD-51 → ONBOARD-60 (4 tickets). Orphan: REPORTING-3 — recommend description review…"_

The unverifiable-claims section is the high-leverage output. It surfaces tickets where the team thinks a dependency exists but hasn't named it concretely — the exact gaps that bite at integration.

---

**When to use:** Retro is over, you have a doc full of sticky-note text or a transcript, and you need themes + commitments by tomorrow.

``` Synthesize the sprint retro below into: 1. Three to five THEMES (a theme appears in at least two participants' inputs). For each theme: a name, one-sentence description, and a count of how many participants raised it. 2. For each theme, list: - The strongest single quote that captures it (verbatim, sourced to a participant role, not name). - Whether the theme is a continuation of last sprint's theme (use the prior-retro themes pasted below for comparison). - A proposed action item — concrete, with a named owner role and a two-week deadline. If no concrete action is possible, say "insight only, no action." 3. One pattern across themes — what is the meta-signal? Is the team stuck on process? On dependency clarity? On scope? On morale? 4. A "keep doing" list — three things participants explicitly said are working that should be protected. Constraints: - Do not editorialize. If participants disagree on a topic, surface the disagreement, do not flatten it. - Do not generate actions that no participant asked for. This sprint's retro: [paste] Prior sprint's retro themes: [paste short list] ```

**Sample output (excerpt):** _"Theme 1 — Dependency hand-offs are unclear (5/7 participants). Strongest quote: 'I waited three days for clarification on what shape the API would return — turns out nobody had decided.' Continuation: third sprint with this theme. Action: PM publishes a one-page interface-contract template by 2026-06-24… Meta-signal: the team is not stuck on capacity; they are stuck on interface clarity at hand-offs."_

The meta-signal output is what earns the retro its existence. Without it, themes feel like a list; with it, the team gets a single thing to fix.

---

**When to use:** The exec calendar shrank your steering meeting from 60 to 25 minutes and you have to cut without losing decisions.

``` Compress the 60-minute agenda below into 25 minutes. Rules: - Preserve every DECISION required (decisions cannot be cut). - Compress UPDATES aggressively — they should be read-ahead, not presented. Output a "read-ahead" section listing what should be sent 24h before the meeting. - Combine related agenda items only if the decision-owner is the same. - For each surviving agenda item, assign: minute budget, owner (role), decision needed (yes/no), and a one-sentence framing question. - Move any item without a clear decision and without a time-sensitive update to a "defer" list. Then output: - The compressed 25-minute agenda (sum of minutes must be <=22 — leave 3 minutes for spill). - The read-ahead list. - The defer list with a suggested owner for offline resolution. Original agenda: [paste] ```

**Sample output (excerpt):** _"Compressed agenda (22 min): (1) ANALYTICS-3 scope cut — 8 min, owner VP Eng, framing: 'cut scope to hit Q3 or extend 4 weeks?' (2) Vendor SLA escalation — 6 min, owner Procurement. (3) Go-live date — 5 min, owner Sponsor… Read-ahead: portfolio stoplight, sprint velocity, pilot feedback. Defer: roadmap discussion (no decision) — offline doc review."_

Cutting agenda time is the lowest-status, highest-leverage PM move. Per Asana's State of Work data on meeting load, the average meeting is 22 minutes longer than the decisions inside it require.

---

**When to use:** Same project status, three audiences — the exec sponsor, the engineering leads, the customer success team — and you need three versions without doing it three times by hand.

``` Rewrite the project update below in three tone variants. Same facts, different register. Strict rules: Variant A — Executive sponsor (CEO/CFO level): - Maximum 120 words. - Lead with the financial or commitment impact. - One decision-ask, italicized. - No jargon, no ticket IDs, no team names. Variant B — Engineering leads: - Maximum 250 words. - Lead with the dependency or technical blocker. - Include ticket IDs and component names. - One coordination ask, bolded. Variant C — Customer success team: - Maximum 180 words. - Lead with the customer-facing impact and timing. - Translate any technical change into what the customer will notice. - One commitment about what CS can promise to customers this week, and one thing they should NOT promise yet. Constraints across all three: - Same underlying facts. If a fact appears in one variant it must be consistent with the others — no version-shopping the truth. - No hedge language ("hopefully," "we'll try to"). - Date all commitments. Underlying facts: [paste raw update] ```

**Sample output (excerpt):** _"VARIANT A — Sponsor: Onboarding redesign on track for 2026-09-30; we cut analytics scope to protect the date. Trial-to-paid up 7 points in pilot. *Decision needed: approve the cut by Friday or we lose two weeks to re-planning.* VARIANT B — Engineering: ANALYTICS-3 cut accepted; reassigning two engineers to ONBOARD-44. IDP-12 → ONBOARD-44 dependency still open; blocker is SSO config, target 2026-06-20…"_

The cross-variant consistency rule prevents the most common PM communication failure — saying one thing to the sponsor and a slightly different thing to engineers, then having that gap surface in a hallway.

---

**When to use:** You sense the project has drifted from its original charter but you cannot point at the moment it happened.

``` Diagnose scope creep on this project by comparing the original charter to the current state. Output: 1. SCOPE DELTA TABLE (three columns: original charter scope item, current state, delta type). Delta types: - As-charted: in charter, still in scope, unchanged. - Expanded: in charter, but now larger than chartered. - Added: not in charter, now in scope. - Dropped: in charter, not in current scope. 2. For each Expanded and Added row: - When did it enter the project (if you can date it from inputs)? - Who requested it (role)? - Was a trade-off explicitly made (something else dropped or timeline shifted)? - If no explicit trade-off, this is the scope-creep evidence — flag it. 3. Three highest-cost scope additions and a recommendation for each: - Keep, with documented trade-off. - Defer to phase 2. - Cut. 4. A pattern observation — is creep coming from one stakeholder, one workstream, or one type of pressure (customer escalations, new competitive feature, exec request)? Original charter: [paste] Current state (sprint contents, recent decisions, change log): [paste] ```

**Sample output (excerpt):** _"Added (no trade-off documented): 'multi-currency support' — entered project 2026-05-18 via customer-success request, no offsetting cut documented. This is scope-creep evidence. Pattern: 5 of 6 scope additions originated from customer-escalation requests routed through CS, not from sponsor or product. Recommendation: establish a CS-to-product intake gate for project additions, otherwise creep will continue at the current rate (~1 addition every 2 weeks)."_

Per PMI's research on scope-management practices, 52% of projects experience scope creep, and the most predictive cause is undocumented trade-offs — exactly what this prompt surfaces.

---

**When to use:** One workstream is red, another is green with slack, and you need a defensible reallocation proposal before the next steering meeting.

``` Suggest a capacity rebalance across the workstreams below. Inputs: - Each workstream's planned vs actual story points. - Each workstream's team members and their nominal capacity. - Each workstream's dependencies (which workstreams need outputs from which). Output: 1. CURRENT STATE TABLE: workstream / planned / actual / variance / capacity utilization / dependency role (provider, consumer, both). 2. THE REBALANCE PROPOSAL: - Source workstream (where capacity comes from). - Destination workstream (where it goes). - Specific person/role moving and for how long. - The skill match (why is this person useful in the destination). - The risk to the source workstream and the offset. 3. WHAT YOU WILL NOT DO: - Moves that break dependencies. - Moves that put any workstream below 1 person. - Moves where the skill match is poor (call it out — a senior backend engineer rarely fixes a UX-research bottleneck). 4. The ALTERNATIVE if rebalance is not feasible: - Specific scope cuts on the underwater workstream. - Specific timeline extensions. - The trade-offs honestly stated. Do not propose moves you cannot justify with the data provided. Workstream data: [paste] ```

**Sample output (excerpt):** _"Proposal: move [STAKEHOLDER_E] (senior frontend) from Workstream B (green, 65% utilization, no critical dependencies for next two weeks) to Workstream A (red, frontend bottleneck blocking checkout flow) for 10 working days. Skill match: high — Workstream A's blocker is React form-state work, [STAKEHOLDER_E]'s primary domain. Risk to Workstream B: pilot-feature polish slips ~3 days, acceptable per pilot timeline. Alternative if not feasible: cut workstream A's 'guest checkout' scope, saves ~15 frontend points, ship without it…"_

The alternative section is the underrated output. It gives the sponsor a clean choice rather than asking them to argue with the rebalance.

---

**When to use:** Something missed (a date, a launch, a customer commitment) and you need a post-mortem the team will actually read and reuse.

``` Write a blameless post-mortem for the missed commitment described below. Structure: 1. WHAT WAS COMMITTED (the specific commitment, dated). 2. WHAT ACTUALLY HAPPENED (factual, no causal language yet). 3. THE TIMELINE (a five-to-ten-line sequence: date / what happened / what was known to whom at that moment). 4. THE TECHNICAL OR PROCESS CAUSES (the proximate causes — what broke at each layer: requirements, design, build, test, release, operate). 5. THE CONTRIBUTING FACTORS (the system-level factors — staffing, dependencies, decision-making, prioritization). 6. WHAT WENT RIGHT (at least three items — the team will dismiss a post-mortem that reads as pure failure). 7. CHANGES PROPOSED (three changes maximum — more than three is a wishlist, not a plan; each must name an owner and a date). 8. WHAT THIS POST-MORTEM IS NOT (one sentence — not a performance review, not a root-cause-singular hunt, not a budget request). Constraints: - No blame language. Replace "X failed to do Y" with "Y did not happen." - Distinguish proximate causes from contributing factors. - The three proposed changes must address contributing factors, not just proximate causes. Incident or miss description: [paste] ```

**Sample output (excerpt):** _"What was committed: customer-facing GA on 2026-05-30. What actually happened: GA delayed to 2026-06-13 (14 days). Timeline: 2026-05-12 dependency on identity team's SSO endpoint identified but not added to risk register… Contributing factors: dependency on identity team was tracked informally in a Slack thread and never surfaced to the steering committee. Changes proposed: (1) PM template adds 'cross-team dependencies' as a required steering review item, owner = program manager, in place by 2026-06-24. (2) Identity team adds a public commitment calendar…"_

The "what this is not" section is the line that earns the team's attention. Most post-mortems fail not because the analysis is wrong but because readers don't know what to do with them. Telling readers what the document is *not* clarifies what it *is*.

---

**When to use:** Friday afternoon, the sponsor or CEO needs a 30-second read of the project's week, every week, without fail.

``` Write a 5-bullet weekly executive recap from the inputs below. Strict rules: - Exactly five bullets. No more, no fewer. - Each bullet starts with a verb in past tense ("shipped," "unblocked," "surfaced," "escalated," "closed"). - Each bullet is one sentence and includes a number (a date, a percent, a count, a dollar figure, a points completed). - One bullet must be a risk or open question — never an all-green recap. - One bullet must be the single specific ask of the executive this week — even if the ask is "no action needed, FYI." - No jargon, no acronyms the executive does not already use. - No ticket IDs. Then, below the bullets, add a one-line "watch next week" pointing at the single biggest thing the executive should expect to hear about. Inputs (raw week summary, stoplight from Prompt 3, decision log, blocker list): [paste] ```

**Sample output (excerpt):** _"• Shipped self-serve onboarding wizard to 40% of new sign-ups; activation rate up 7 points week-over-week. • Unblocked the SSO dependency with the identity team after 4 days; checkout flow back on the critical path. • Surfaced a vendor SLA gap on payment processing — recommend a Tuesday review with procurement. • Cut the analytics scope by 12 story points to protect the September 30 commit date — sponsor approval needed by Wednesday. • Closed the May pilot cohort; trial-to-paid up to 19% from 12%. Watch next week: the production cutover dry-run on June 18 — first read on whether the September date holds."_

The single-ask rule is the line that makes the executive read it. When a recap has no ask, it gets archived; when it has one specific ask, it gets answered.

---

---

A Jira export commonly contains customer names in ticket titles, employee names as assignees, contract terms in descriptions, and revenue figures in scope notes. The Anthropic commercial terms confirm enterprise and team-plan inputs are not used for training by default, but customer and employee confidentiality remains your obligation.

Five rules I follow:

1. **Strip identifiers before pasting.** Replace customer names, account numbers, and employee names with placeholders. Output quality does not depend on real names. 2. **Use Claude's team or enterprise plan for project work.** Verify the no-training default is on in workspace settings. 3. **Never paste full contracts or full salary data.** Paste the section relevant to the question. 4. **Document AI use in the project charter.** A two-sentence note saying "this project uses Claude for status synthesis, retro analysis, and meeting prep, with these data-handling rules" is a defensible position with security and audit. 5. **For SOC 2 or regulated data**, get sign-off from security on which data categories may be pasted before you start.

If you would not paste it in a public forum, prep it before pasting it into Claude.

→ **See our full prompt library for project and program workflows**

---

Each prompt went through the iteration protocol in our 7-point prompt grading rubric guide. Specificity and constraint-compliance were the dimensions that lifted PM prompts most — generic prompts produce a generic plan; constrained prompts produce an artifact the team can use without rework.

Structure draws on Anthropic's prompt engineering guidance — role assignment, structured outputs, explicit reasoning steps. PM-discipline framing comes from PMI's PMBOK and Pulse of the Profession research, the Atlassian Team Health Monitor, and Asana's State of Work research.

→ **Try our prompt builder to adapt these for your program**

---

### Are these prompts safe to use with real project data?

Only after you strip identifiers and confirm your Claude account's data-handling settings. Customer names, employee assignees, and contract terms should be replaced with placeholders before pasting.

### Will Claude replace a project manager?

No. Claude drafts artifacts; PMs negotiate the political and capacity decisions those artifacts surface. PMI 2024 Pulse data shows AI-augmented PMs reclaim time on the ceremony layer and reinvest it in stakeholder and delivery risk.

### Which Claude model works best for project-management work?

Claude 3.5 Sonnet or newer. Older models miss the structured reasoning, particularly the risk hunter (Prompt 4) and capacity rebalance (Prompt 10). For high-stakes outputs, run the prompt twice and compare — divergence signals genuine ambiguity worth a conversation.

### Do these prompts work for non-software projects?

Yes, with minor adjustments. Swap Jira for your tracking system (Smartsheet, Monday, MS Project, Airtable) and "story points" for your unit of work. The structure carries across construction, marketing-campaign, hardware-launch, and regulatory-program work.

### How do I keep stakeholders from learning a different version of the truth from different prompt outputs?

Prompt 8 (three-tone variant) forces cross-version fact consistency. Use it as the canonical pattern any time you fan the same update out to multiple audiences — facts must match; only the register changes.

### How do I prove these prompts saved time?

Track time-to-artifact on the first three uses and compare to your historical baseline. The table above gives per-use ranges. Most PMs reclaim 6-10 hours per week after a month of regular use, concentrated in status (Prompt 3), retros (Prompt 6), and the executive recap (Prompt 12).

### What if my organization has not approved AI use for project data?

Use the prompts on de-identified or synthetic data first. Take one anonymized example through your security team's review to establish what data categories are clearable. The structure of a RACI or stoplight is the same regardless of whose name is in the cell.

---

- PMI — Pulse of the Profession 2024 - PMI — PMBOK and project management standards - Asana — Anatomy of Work / State of Work research - Atlassian — Team Health Monitor framework - Atlassian — Retrospective and ceremony plays - Anthropic — Prompt engineering overview - Anthropic — Commercial terms and data handling - Anthropic — Use cases for structured analysis

→ **Start with our prompt builder — free, no signup**