df-product-owner
Skill4 starsChanged 2 months agoApache-2.0View on GitHub
Dark Factory Product Owner stage: define Vision, Requirements as data contracts plus validation rules, and Test Scenarios — the semantics every later stage derives from. Triggers on "product owner", "requirements", "acceptance criteria", "test scenarios", "data contract", "what should we build".
In this repository43 other files it gives its agents.
- skills/vercel-react-best-practices/AGENTS.mdAGENTS.md
- agent-notepadSkill
- architecture-reviewerSkill
- backend-service-auditorSkill
- channel-listenerSkill
- code-reviewerSkill
- coder-file-transferSkill
- cold-start-generatorSkill
- creating-skillsSkill
- critical-thinkingSkill
- dark-factory-buildSkill
- dependency-risk-auditorSkill
- df-adversary-gateSkill
- df-app-walkthroughSkill
- df-context-storeSkill
- df-data-transform-lensSkill
- df-dispatch-subagentsSkill
- df-infrastructureSkill
- df-observabilitySkill
- df-qaSkill
- df-solution-architectSkill
- df-tdd-developerSkill
- df-ui-verifySkill
- df-video-intakeSkill
- dx-maintainability-reviewerSkill
- frontend-auditorSkill
- handoffSkill
- microservices-architectSkill
- production-readiness-reviewerSkill
- repo-docsSkill
- requirements-discoverySkill
- sc-auditSkill
- sc-devSkill
- scope-initSkill
- scope-retireSkill
- security-threat-modelerSkill
- service-mapperSkill
- test-quality-gatekeeperSkill
- vercel-react-best-practicesSkill
- vinculum-loopSkill
- vinculum-mapSkill
- web-design-guidelinesSkill
- work-autonomouslySkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 39
Don't formalize schemas / Avro contracts / enforcement locus — that's the SA's job (df-solution-architect).
- Distinctive: line 40
Don't write scenarios that test screens instead of real work.
- Distinctive: line 41
Don't omit non-goals (the biggest scope-creep guard).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Dark Factory — Product Owner (define the semantics)
Overview
The PO turns messy intent into a self-contained, testable target. It produces three must-have outputs: Vision, Requirements, Test Scenarios. Through the data-transform lens (df-data-transform-lens): Requirements = data contracts + validation rules; Test Scenarios = those rules as cases. The PO owns the semantics (domain truth); the Solution Architect formalizes them.
When to use
Defining what to build, writing requirements/acceptance criteria, or assembling the package a cold Solution Architect will design from.
What the PO defines (with SMEs) — the semantics
Per capability, name the data and the rules over it:
| Field | What to capture |
| Data (schema) | the fields collected, conceptually |
origin | real-world source: web form · mobile · scanned doc · 3rd-party API · another service (for audit — never a trust signal) |
authority | who is system-of-record for this fact (a domain fact, e.g. "the bank owns balance") |
governance | PHI/PII class, retention, residency |
| Validation rules | the business predicate + its scope (holds within one record, or must agree across systems/time) |
| Effect? | does the acceptance criterion touch the outside world (send/charge/notify/write-external)? Flag it so SA assigns idempotency + compensation |
You state what must be true and who is authoritative; the SA decides where it's checked and how (the formal LOCAL/GLOBAL locus + mechanism is SA's call).
Instructions
- Vision — why / what / who / value, and the non-goals ("what this is not").
- Requirements — capabilities + testable acceptance criteria, each as a data contract + validation rule (use the table above).
- Test Scenarios — concrete real-life situations, not screen assertions. Frame each as a state change:
State 0 (precondition) → Trigger (input) → State 1 (end state), with happy path + edge + failure modes. These are the executable evidence standard downstream. - Label every claim Confirmed / Inferred / Assumption / Open — never silently invent product facts.
- Mark any outside-world trigger as an effect.
Exit gate (the cold-SA test)
Could a Solution Architect who knows nothing about the product design the right architecture from Vision + Requirements + Test Scenarios alone? Is there any way to build the wrong thing and still satisfy the package? If yes, clarify before handoff.
Don't
- Don't formalize schemas / Avro contracts / enforcement locus — that's the SA's job (
df-solution-architect). State the semantics; let the SA realize them. - Don't write scenarios that test screens instead of real work.
- Don't omit non-goals (the biggest scope-creep guard).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.