mirror of
https://github.com/openprose/prose.git
synced 2026-09-19 05:55:05 +08:00
irl-dan
63c8ce4b23
Move the standard library (previously `github.com/openprose/std`) and
the company-as-prose library (previously local dir
`/Users/sl/code/openprose/company-as-prose`) into this repository
under `packages/std/` and `packages/co/` respectively.
Motivation: concentrate attention on one repository so stars,
discussions, and issues aggregate. `openprose/std` was a genuinely
useful asset nobody could find because ~50 stars on its own repo
told a much worse story than 1,106 stars on `openprose/prose`
would have. Same logic applies to co.
Layout choice: `packages/{std,co}/` rather than `std/` + `co/` at
the repo root. Root siblings accumulate over time, and a flat
top-level made future libraries (hub, kit, dev, etc.) compete with
spec infrastructure. `packages/` is bounded — new libraries land
there without cluttering root. Matches pnpm/Deno/monorepo tooling
conventions.
Changes:
- New: `packages/std/` (copied from openprose/std, `.git` excluded)
- New: `packages/co/` (copied from company-as-prose, README updated
for new name and location)
- `packages/std/README.md`: updated shorthand expansion reference
- `packages/co/README.md`: renamed "company-as-prose" to "co" in
self-references, added std-vs-co split heuristic, updated
`prose run` examples to use `co/` shorthand
- `skills/open-prose/deps.md`:
- `std/` shorthand now expands to
`github.com/openprose/prose/packages/std/`
- `co/` shorthand added, expands to
`github.com/openprose/prose/packages/co/`
- Both shorthands resolve into the same clone of
`openprose/prose` under `.deps/github.com/openprose/prose/`;
`packages/std/` and `packages/co/` are sibling subdirectories
- `prose.lock` format row updated to `host/owner/repo sha`
(matches the explicit-host resolution that landed in #35)
- `.deps/` directory structure example redrawn to show the
`{host}/{owner}/{repo}/packages/{std,co}/...` shape
- Error message and Interaction tables refreshed accordingly
- Resolution Algorithm step 1 now documents both shorthands
- `skills/open-prose/forme.md`: Step 2 resolution list updated to
include co/ shorthand and the host-keyed `.deps/` layout
- `skills/open-prose/help.md`: Q&A "How do dependencies work?"
rewritten to name both shorthands and the new explicit-host model
- `skills/open-prose/state/filesystem.md`: `.deps/` directory
tree re-drawn to include the `{host}/` layer with std/co as
sibling packages inside the clone
- `skills/open-prose/guidance/patterns.md`,
`skills/open-prose/guidance/antipatterns.md`: examples now use
the `std/` shorthand or explicit `github.com/...` rather than
the deprecated bare `openprose/std/` form
- `skills/open-prose/examples/registry-import/index.md`: sample
service reference switched to `std/evals/inspector`
- `README.md`: Stdlib badge replaced with internal `packages/std/`
link plus new `packages/co/` link; "Standard Library" section
rewritten as "Libraries" with both packages described
Out of scope for this PR (deliberately):
- Tooling changes to `prose install` and Forme's `.deps/` writer
to adopt the `{host}/{owner}/{repo}/` layout in practice — this
PR is spec-only. Existing tooling continues to work against
whatever layout it currently implements; the spec now describes
the target.
- Retiring the `openprose/std` GitHub repo. Delete that repo
separately after this merges.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
std/roles
Standard role definitions for OpenProse services. Each role is a reusable behavioral contract that defines what a service does, what it requires, and what it guarantees. Roles are the atoms -- everything else is molecules.
Roles by Category
Analysis
| Role | Description |
|---|---|
| classifier | Assign a category label to an input given a defined category set |
| critic | Evaluate a work product against quality criteria and render a subjective verdict |
| verifier | Check a result against formal constraints and report pass/fail for each |
Transformation
| Role | Description |
|---|---|
| extractor | Pull structured data from unstructured input given a target schema |
| summarizer | Compress content while preserving specified key information |
| formatter | Transform structured data into a specified output format with no information loss |
Creation
| Role | Description |
|---|---|
| researcher | Investigate a topic using available tools and return sourced, confidence-scored findings |
| writer | Produce a written artifact given requirements, audience, and constraints |
| planner | Produce an ordered plan with dependencies, decision points, and fallback paths |
Flow
| Role | Description |
|---|---|
| router | Select the best handler for an input from a set of candidates and explain the choice |
Decision Matrix
| When you need to... | Use |
|---|---|
| Label an input against a known taxonomy | classifier |
| Judge whether work meets a quality bar | critic |
| Check formal correctness against rules | verifier |
| Lift structured fields from raw text | extractor |
| Compress content without losing key points | summarizer |
| Reshape data into Markdown, JSON, HTML, CSV | formatter |
| Discover information via search or tools | researcher |
| Create a new document, report, or email | writer |
| Sequence work into an ordered plan | planner |
| Dispatch a request to the right handler | router |
Common Confusions
Classifier vs. Router. Classifier produces a label (data). Router selects a handler (action). A classifier says "this is a billing question." A router says "send this to the billing service."
Critic vs. Verifier. Critic renders subjective quality judgments ("is this analysis thorough?"). Verifier checks objective formal constraints ("does this JSON match the schema?"). A result can pass verification and fail criticism, or vice versa.
Extractor vs. Formatter. Extractor goes from unstructured to structured (raw text to schema). Formatter goes from structured to structured (data to Markdown). They point in opposite directions.
Summarizer vs. Writer. Summarizer compresses existing content. Writer creates new content. If the input already contains the information and you need less of it, use summarizer. If you need to synthesize, argue, or explain, use writer.
Researcher vs. Extractor. Researcher discovers new information using tools and search. Extractor lifts information already present in its input. If the data is in the input, extract. If the data needs to be found, research.