PAI/USER/AI_WRITING_PATTERNS.md (shipped in v5.0.0 bootstrap) says:
The _WRITING skill (rewrite + detect modes) reads this list as its rule source.
No _WRITING skill ships in the release, and no issue or PR mentions it. The only repo-wide hit for _WRITING is the line above.
The underscore prefix is a documented convention in PAI (release tooling skips any skill name starting with _), so _WRITING is presumably meant to be user-instantiated. But that expectation isn't surfaced anywhere a new user would see it. The file presents itself as a working component while its stated consumer doesn't exist out of the box.
This isn't unique to _WRITING — from a fresh-install perspective, v5.0.0 has several features that ship in a half-wired state (dashboard areas rendering placeholder content, scheduling primitives that aren't connected, references to skills/tools that don't exist). Each one in isolation is a small confusion. Cumulatively, for a new user picking up PAI, the effect is mistrust: "what else doesn't actually work?" Frustration here is the failure mode that loses contributors before they ever start contributing.
Suggested fix
Two complementary directions:
-
Ship a minimal _WRITING skill stub. Frontmatter + rewrite and detect workflow placeholders that document themselves as starting points. The reference in AI_WRITING_PATTERNS.md resolves immediately, the user has a real artifact to extend, and the bootstrap is internally consistent.
-
Add a Known Issues / Limitations doc at the root of the repo, transparently listing features that ship-but-aren't-yet-functional. The _WRITING reference goes here. So do the dashboard placeholders, unwired cron, and anything else in flight. Updating this doc as features stabilize is the discipline; the value is letting new users calibrate expectations on day one instead of discovering gaps by stumbling into them.
Happy to PR either or both.
PAI/USER/AI_WRITING_PATTERNS.md(shipped in v5.0.0 bootstrap) says:No
_WRITINGskill ships in the release, and no issue or PR mentions it. The only repo-wide hit for_WRITINGis the line above.The underscore prefix is a documented convention in PAI (release tooling skips any skill name starting with
_), so_WRITINGis presumably meant to be user-instantiated. But that expectation isn't surfaced anywhere a new user would see it. The file presents itself as a working component while its stated consumer doesn't exist out of the box.This isn't unique to
_WRITING— from a fresh-install perspective, v5.0.0 has several features that ship in a half-wired state (dashboard areas rendering placeholder content, scheduling primitives that aren't connected, references to skills/tools that don't exist). Each one in isolation is a small confusion. Cumulatively, for a new user picking up PAI, the effect is mistrust: "what else doesn't actually work?" Frustration here is the failure mode that loses contributors before they ever start contributing.Suggested fix
Two complementary directions:
Ship a minimal
_WRITINGskill stub. Frontmatter +rewriteanddetectworkflow placeholders that document themselves as starting points. The reference inAI_WRITING_PATTERNS.mdresolves immediately, the user has a real artifact to extend, and the bootstrap is internally consistent.Add a Known Issues / Limitations doc at the root of the repo, transparently listing features that ship-but-aren't-yet-functional. The
_WRITINGreference goes here. So do the dashboard placeholders, unwired cron, and anything else in flight. Updating this doc as features stabilize is the discipline; the value is letting new users calibrate expectations on day one instead of discovering gaps by stumbling into them.Happy to PR either or both.