The learning loop's index files are currently hand-authored per repo (ai-flow#13, dev#58, cellbound-3d#150), and a /learn run on an unseeded repo forces the agent to improvise the file — without the canonical front matter (alwaysApply: true), an improvised index is never loaded always-on: written, gated, merged, and never read (see d3mlabs/ai-flow#33).
Scaffolding is materialization, which is dev's role in the four-role model (see the org-architecture skill). Proposal:
dev learnings init [--org]
- Repo tier (bare): writes the canonical empty repo-tier scaffold —
.cursor/rules/learnings-index.mdc with front matter (description + alwaysApply: true), the capture/curation preamble, soft-cap text, and org-tier trailer; no entries.
- Org tier (
--org): writes the knowledge-repo layout — root index.md with the fixed section structure (## Invariants (always-on) / ## Knowledge (on-demand) + domain sections) that dev knowledge sync parses, plus the skills/ directory. For a new org adopting ai-flow; the adoption guide cites this as one step.
- Idempotent: refuses (or no-ops with a message) when the target index already exists — the scaffold is write-once-committed; humans and capture passes own it afterward.
- Help text states the write-once-committed semantics.
Dev::Learnings::Layout
Introduce the canonical layout owner as part of this work: a module declaring both tiers' paths (repo: .cursor/rules/learnings-index.mdc + .cursor/skills/learnings/<slug>/SKILL.md; org: index.md + skills/<slug>/SKILL.md) and backing the scaffold templates. Everything in dev that touches the layout (init, the invariants renderer, future subcommands) reads from it. ai-flow's ProposalChecks::INDEX_PATHS / Learn::INDEX_PATH mirror these paths as data with a pointer comment — dev is the owner, ai-flow follows.
Consumers
Command family context: this lands under the consolidated dev learnings family (see the companion family/distribution issue); tier appears in the interface only here, where the operation genuinely branches between two templates.
The learning loop's index files are currently hand-authored per repo (ai-flow#13, dev#58, cellbound-3d#150), and a
/learnrun on an unseeded repo forces the agent to improvise the file — without the canonical front matter (alwaysApply: true), an improvised index is never loaded always-on: written, gated, merged, and never read (see d3mlabs/ai-flow#33).Scaffolding is materialization, which is dev's role in the four-role model (see the org-architecture skill). Proposal:
dev learnings init [--org].cursor/rules/learnings-index.mdcwith front matter (description +alwaysApply: true), the capture/curation preamble, soft-cap text, and org-tier trailer; no entries.--org): writes the knowledge-repo layout — rootindex.mdwith the fixed section structure (## Invariants (always-on)/## Knowledge (on-demand)+ domain sections) thatdev knowledge syncparses, plus theskills/directory. For a new org adopting ai-flow; the adoption guide cites this as one step.Dev::Learnings::LayoutIntroduce the canonical layout owner as part of this work: a module declaring both tiers' paths (repo:
.cursor/rules/learnings-index.mdc+.cursor/skills/learnings/<slug>/SKILL.md; org:index.md+skills/<slug>/SKILL.md) and backing the scaffold templates. Everything in dev that touches the layout (init, the invariants renderer, future subcommands) reads from it. ai-flow'sProposalChecks::INDEX_PATHS/Learn::INDEX_PATHmirror these paths as data with a pointer comment — dev is the owner, ai-flow follows.Consumers
/learnshells out todev learnings initwhen the index is missing (/learn: shell out to dev learnings init when the learnings index is missing ai-flow#33).ProposalChecks#index_contentstops erroring on proposals from unseeded repos once capture always scaffolds first.Command family context: this lands under the consolidated
dev learningsfamily (see the companion family/distribution issue); tier appears in the interface only here, where the operation genuinely branches between two templates.