An example of a real-world PRD in action: https://github.com/yournextstore/new.store/blob/main/docs/new-store-prd.md
NOTE: That PRD is deeply thorough and far more comprehensive than your typical PRD; it's been optimized for vibe coding where LLMs are like junior, chaotic engineers that require a lot of detail and handholding to yield good results.
| ❯ llm --cid 01h8f03gxe1bept7sz4yww2t8t -t qa-steps-to-json "" | |
| Traceback (most recent call last): | |
| File "/opt/homebrew/bin/llm", line 8, in <module> | |
| sys.exit(cli()) | |
| ^^^^^ | |
| File "/opt/homebrew/Cellar/llm/0.8/libexec/lib/python3.11/site-packages/click/core.py", line 1157, in __call__ | |
| return self.main(*args, **kwargs) | |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ | |
| File "/opt/homebrew/Cellar/llm/0.8/libexec/lib/python3.11/site-packages/click/core.py", line 1078, in main | |
| rv = self.invoke(ctx) |
| class A1 { | |
| String f1(String x) { return x; } | |
| String f2(String x) { return x; } | |
| . | |
| . | |
| String f100(String x) { return x; } | |
| } |
| val resolvedParents = new util.ArrayList[Type]() | |
| var remainingParents = tmpl.parents | |
| while (remainingParents.nonEmpty) { | |
| val parent = remainingParents.head | |
| val resolved = resolveTypeTree(parent, lookupScope) | |
| // this is awkard and highly repetitive pattern | |
| resolved match { | |
| case CompletedType(tpe) => resolvedParents.add(tpe) | |
| case _: IncompleteDependency | NotFound => return resolved | |
| } |
| sealed trait Result[T] | |
| case class CompletedResult[T](value: T) extends Result[T] | |
| case class IncompleteDependency(dep: Symbol) extends Result[T] | |
| // completer is: | |
| () => Result[T] |
| // Ensure constructor is completed so that any parameter accessors | |
| // which have type trees deriving from its parameters can be | |
| // completed in turn. Note that parent types access such parameter | |
| // accessors, that's why the constructor needs to be completed before | |
| // the parent types are elaborated. | |
| index(constr) | |
| annotate(constr :: params) | |
| symbolOfTree(constr).ensureCompleted() |
| | Tydzień | Dystans km | Przyrost % | Przyrost 7% = km | | |
| |---------|------------|------------|------------------| | |
| | 1 | 30 | 7% | 2,1 | | |
| | 2 | 32,1 | 7% | 2,24 | | |
| | 5 | 36,75 | 7% | 2,57 | | |
| | 10 | 59 | 7% | 4,13 | | |
| | 15 | 82,77 | 7% | 5,79 | | |
| | 20 | 116 | 7% | 8,12 | | |
| |------------------------------------------------------| | |
| | 25 | 162,82 | 7% | 11,39 | |
Recently, I found myself in need to precisely understand Scala's core typechecking rules. I was particulary interested in understanding rules responsible for typechecking signatures of members defined in classes (and all types derived from them). Scala Language Specification (SLS) contains definition of the rules but lacks any examples. The definition of the rules uses mutual recursion and nested switch-like constructs that make it hard to follow. I've written down examples together with explanation how specific set of rules (grouped thematically) is applied. These notes helped me gain confidence that I fully understand Scala's core typechecking algorithm.
Let's quote the Scala spec for As Seen From (ASF) rules numbered for an easier reference:
| ### Keybase proof | |
| I hereby claim: | |
| * I am gkossakowski on github. | |
| * I am grek (https://keybase.io/grek) on keybase. | |
| * I have a public key whose fingerprint is F784 54E6 6DA3 D66C 89D2 C01E 287A 9033 977D BF9C | |
| To claim this, I am signing this object: |
