Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Example task
A SaaS team says enterprise customers need an audit-log export API. Draft a technical PRD. Assume no direct access to API specs, schemas, tickets, analytics, customer interviews, security policy, or engineering systems unless the user provides data.
Without the bundle
Build an audit-log export API so enterprise customers can download logs. Add filters for user, date, and event type. The engineering team should create an endpoint and ship it next quarter. Success is customers using the export.
Using the bundle
Readiness Conditionally ready for discovery framing, not ready for implementation commitment. Source Note Used only the user-provided statement that enterprise customers need an audit-log export API. Missing sources: customer examples, existing audit-log schema, API standards, security/privacy policy, service owner input, rate-limit/versioning policy, support requirements, and launch constraints. PRD Skeleton - Problem: enterprise customers need a reliable way to export audit-log data for compliance, security review, or internal reporting. - Users: enterprise admins and security/compliance stakeholders; confirm actual personas from customer evidence.
Why this is better: The bundle-assisted output is stronger because it gives a direct readiness answer, includes a source note, separates assumptions from missing verification, avoids invented API details, names technical surfaces to inspect, and turns the request into a decision-ready discovery artifact. The baseline output is weaker because it fabricates implementation details and timeline commitments without source evidence.
Inspect this example in the repositoryRole guide
Technical Product Manager
Defines the scope and expected behavior of a Technical Product Manager agent.
Read the fileWorkflow
Map Technical Dependencies
Maps teams, systems, services, data flows, decisions, and blockers for a technical product initiative.
Read the fileWorkflow
Reconcile Product and Technical Risk
Resolves tension between product priority and technical feasibility or operational risk.
Read the fileWorkflow
Review API or Platform Change
Reviews API, integration, or platform changes for product value, compatibility, migration, and launch risk.
Read the fileIs this bundle right for your task?
Who it is for
- People performing or supporting Technical Product Manager work, plus teams reviewing its decisions and outputs
- Teams working in software, saas, digital-products
When to use it
- A Technical Product Manager task needs a structured plan, evidence checklist, or review-ready output.
- A recommendation needs its assumptions, owners, risks, dependencies, and success measures made explicit.
What you need to provide
- The task objective, intended audience, working context, constraints, source material, and decision owner.
- Relevant reports, exports, examples, policies, prior decisions, and success measures available for the task.
Tasks and expected outputs
Questions it helps answer
- draft technical product requirements
- review API and platform changes
- map technical dependencies and risks
- translate engineering constraints into product decisions
- align roadmap choices with technical feasibility
What it helps produce
- technical PRD
- API change brief
- dependency map
- feasibility memo
- launch readiness note
- technical decision memo
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Provide the task objective, intended audience, working context, constraints, source material, and decision owner. Ask the agent to approach Technical Product Manager work by producing technical PRD with a prioritized plan, evidence checks, owners, risks, and unresolved questions. Inspect Technical Product Manager before drafting.
Context path: bundles/roles/technical-product-manager
What the bundle includes
Tools
- Jira
- Linear
- Confluence
- Notion
- Figma
- FigJam
- Miro
- Postman
- OpenAPI
- GitHub
- GitLab
- LaunchDarkly
- Datadog
- Grafana
- Amplitude
- Mixpanel
- Productboard
- Aha!
Frameworks
- Jobs-to-be-Done
- RICE prioritization
- opportunity solution tree
- API-first design
- RFC
- ADR
- progressive delivery
- dependency mapping
- Scrum
- Kanban
- OKRs
Commands
/draft-technical-prd
/review-api-change
/map-dependencies
Evaluations
- technical-product-management-quality-check
Limitations and safe use
Do not use this for
- Treating the bundle as a substitute for organization-specific authority, firsthand evidence, or accountable review.
Known limitations
- Technical product management scope varies by organization; verify local ownership, decision rights, engineering process, and source-of-record artifacts.
- Does not replace accountable engineering, architecture, security, privacy, accessibility, legal, finance, medical, or regulated-domain review.
- Does not include tool-specific API automation or workspace-specific configuration details.
- Taxonomy mappings come from the reviewed generator candidate and should be treated as context, not a complete definition of modern technical product management.
Safety notes
- Confirm before modifying live product docs, tickets, repositories, API specs, analytics definitions, feature flags, release notes, roadmap systems, or customer communications.
- Treat source code, logs, incidents, customer data, product strategy, roadmap plans, technical designs, and telemetry as confidential unless the user confirms they are safe to use.
- Escalate legal, privacy, security, accessibility, medical, financial, employment, and regulated-industry requirements to appropriate experts.