Prompt library for product documentation
This is not an agency or a client delivery model — just named perspectives (PM, business, UX, engineering) that make drafts of specs and docs easier to review in my own work.
Layers in the prompt library page
The separate "prompt roles" page is a structured index of the same metaphorical roles — useful if you want to see how I separate concerns when writing specs for myself.
Product and commercial context
Scope, trade-offs and stakeholder language.
Experience and UI
Flows, clarity and consistency.
Engineering and quality
Architecture, implementation risk and testing.
Content (PL)
Native PL copywriter — ensures marketing and email content reads naturally in Polish, not as translation from English.
Role descriptions (prompts)
Product manager
Keeps scope, trade-offs and stakeholder language coherent.
Business Strategist
Voice of market viability. Validates business models and ROI.
Commercial perspective
Challenges whether the problem is worth solving in the current commercial window.
UX Designer
Champion of user needs. Creates flows, wireframes, and usability.
UI Designer
Voice of visual excellence. Maintains design system consistency.
Software Architect
Guardian of technical strategy. Designs scalable architecture.
Fullstack Developer
The builder. Implements frontend and backend with MVP speed.
AI Engineer
Specialist for AI/LLM features. Handles prompt engineering and RAG.
QA Engineer
Quality gatekeeper. Defines test strategy and ensures readiness.
Polish Copywriter
Native PL editor. Reviews grammar, orthography, punctuation, and detects English calques before mass send.
What actually matters
The useful part is not the number of prompts — it is the habit of separating concerns and reviewing outputs.
Review beats volume
More generated text is not better. Smaller, checkable chunks are easier to ship safely.
Stay close to sources
Case studies and CV anchors should match each other — this site is not a separate fiction.
Use the lightest tool
Sometimes a checklist beats a model. I pick the smallest thing that reduces ambiguity.
From idea to a safe change
A simplified view of how I approach changes to this codebase when I have time outside core job delivery.
Capture intent
One sentence problem statement and acceptance criteria.
Scope the smallest diff
Prefer one concern per change where possible.
Implement and check
Run the app, read the page, fix obvious regressions.
Publish
Merge when the site reads credibly for hiring readers.
I iterate on this portfolio over time — the real artefact is the shipped work, not role metaphors alone.