release onboarding and cs-foundations packages - #202
Conversation
…ion (#201) * fix: align creative strategy package with production * chore: set creative strategy package version to 2 --------- Co-authored-by: Giselle Rogers <85512909+gbrogers@users.noreply.github.com>
Confidence Score: 5/5Safe to merge — no executable logic is introduced and the agent-facing instruction sequences are internally consistent. The change removes legacy Python scripts and Markdown payloads and adds two well-structured schema-v1 packages. The post-install orchestration, guard-merge logic, idempotency rules, and skill resource mappings all check out. Two minor documentation issues were found: MIGRATION.md groups the new permanent package alongside a temporary compatibility directory in a way that could mislead future maintainers, and a stale reference to an uninstallable path persists in one of the onboarding documents. Neither affects runtime behavior. Files Needing Attention: MIGRATION.md (misleading 'temporary compatibility set' grouping) and meta-and-voc-onboarding/meta/meta-account-context-brain-onboarding-package.md (stale building-integrations path reference in the Activation section).
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| { | ||
| "schemaVersion": 1, | ||
| "id": "meta-and-voc-onboarding", | ||
| "name": "Meta and Voice of Customer Onboarding", | ||
| "version": "1", | ||
| "description": "INSTALLER: the moment this package installs, read /agent/brain/meta-and-voc-onboarding/post-install.md and execute its install-time sequence in the installing conversation - installing is the trigger; do not wait to be asked. The Meta and Voice of Customer onboarding package. Manual install only (installPolicy: manual): an agent installs it with one explicit package install call of its GitHub source. Stages the onboarding docs and ready-made guard blocks into /agent/brain/meta-and-voc-onboarding/, plus the voc-data-pull, voc-audit, meta-ad-performance-analysis, and onboarding-walkthrough skills into the skills root. Post-install first quotes the Default workspace line from the conversation's Motion context verbatim - the workspace the runtime bound the conversation to, never one recalled from folders, rosters, routines, or memory - and states the name, workspaceId, and slug taken from it, then runs the reachability check, creates one daily VoC sync routine per reachable platform per workspace - each pinned to a human-confirmed platform account, since accounts are org-level and ownership is never inferred (files land under /agent/brain/<workspace>/data-sources/voc/<platform>/) - merges the four guard blocks into /agent/user.md, runs the Meta account-context autofill silently, and records the workspace in the runneth:meta-voc-onboarded roster in /agent/user.md; it ends by asking 'Are you ready to begin your onboarding?' - the walkthrough presentation fires only on a human's yes, via the onboarding-walkthrough skill. The first complete VoC backfill offers the manual Voice of Customer Audit; the audit runs only on a person's yes and saves a compiled page for validation and future customer-side WHY questions. Outside those human-gated runs, nothing self-runs. Meta only, one workspace at a time. Everything the package produces is scoped to that workspace's own folder, /agent/brain/<workspace>/, so a second workspace in the same org onboards additively without touching the first. The staged guard files are workspace-agnostic and merged verbatim - nothing in them is substituted at install time; they resolve the workspace folder per conversation.", | ||
| "installPolicy": "manual", | ||
| "updatePolicy": "auto", | ||
| "uninstallPolicy": "allowed", | ||
| "resources": [ | ||
| { | ||
| "id": "readme", | ||
| "type": "file", | ||
| "sourcePath": "README.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/README.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "creative-attributes-playbook", | ||
| "type": "file", | ||
| "sourcePath": "meta/meta-creative-attributes-playbook.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/meta-creative-attributes-playbook.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "account-context-brain-package", | ||
| "type": "file", | ||
| "sourcePath": "meta/meta-account-context-brain-onboarding-package.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/meta-account-context-brain-onboarding-package.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "meta-validation-package", | ||
| "type": "file", | ||
| "sourcePath": "meta/meta-validation-onboarding-package.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/meta-validation-onboarding-package.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "motion-cli-data-query-guide", | ||
| "type": "file", | ||
| "sourcePath": "meta/motion-cli-data-query-guide.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/motion-cli-data-query-guide.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "cacheth-command-reference", | ||
| "type": "file", | ||
| "sourcePath": "meta/cacheth-command-reference.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/cacheth-command-reference.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "knoweth-organize-package", | ||
| "type": "file", | ||
| "sourcePath": "knoweth/knoweth-organize-onboarding-package.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/knoweth-organize-onboarding-package.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "post-install", | ||
| "type": "file", | ||
| "sourcePath": "post-install.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/post-install.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "guards", | ||
| "type": "directory", | ||
| "sourcePath": "guards", | ||
| "executablePaths": [], | ||
| "target": { | ||
| "root": "agent_brain", | ||
| "path": "meta-and-voc-onboarding/guards" | ||
| } | ||
| }, | ||
| { | ||
| "id": "voc-data-pull-skill", | ||
| "type": "directory", | ||
| "sourcePath": "voc-data-pull", | ||
| "executablePaths": [], | ||
| "target": { | ||
| "root": "agent_skills", | ||
| "path": "voc-data-pull" | ||
| } | ||
| }, | ||
| { | ||
| "id": "voc-audit-skill", | ||
| "type": "directory", | ||
| "sourcePath": "voc-audit", | ||
| "executablePaths": [], | ||
| "target": { | ||
| "root": "agent_skills", | ||
| "path": "voc-audit" | ||
| } | ||
| }, | ||
| { | ||
| "id": "meta-ad-performance-analysis-skill", | ||
| "type": "file", | ||
| "sourcePath": "meta-ad-performance-analysis/SKILL.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_skills", | ||
| "path": "meta-ad-performance-analysis/SKILL.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "onboarding-walkthrough-skill", | ||
| "type": "file", | ||
| "sourcePath": "onboarding-walkthrough/SKILL.md", | ||
| "executable": false, | ||
| "target": { | ||
| "root": "agent_skills", | ||
| "path": "onboarding-walkthrough/SKILL.md" | ||
| } | ||
| }, | ||
| { | ||
| "id": "activation", | ||
| "type": "package_instruction", | ||
| "sourcePath": "instructions/activation.md" | ||
| } | ||
| ] | ||
| } |
There was a problem hiding this comment.
packageManagerVersion present in index but absent from manifest
The package-index.json entry for this package carries "packageManagerVersion": 1, but the meta-and-voc-onboarding/package.json manifest (and creative-strategy-foundations/package.json) do not include that field. If the schema-v1 validator treats packageManagerVersion as required in the on-disk manifest, both packages will fail validation at install time. Worth verifying whether packageManagerVersion is an index-only field or one the manifest must also declare.
| detected" is decoder detail; say "provisional naming decode written" and stop), no | ||
| field reads, and never the question text itself - naming even one question here | ||
| burns the walkthrough's opening. If a part is waiting on a person, name the topic in | ||
| two or three words ("targets and thresholds"), not the question and not a count of | ||
| questions. The same discipline covers the whole closing stretch of the turn: the | ||
| progress narration around the report must not surface metrics, findings, or flags | ||
| either ("average ROAS is 0.88" belongs in the brain file, never in this turn's | ||
| visible text). The report's shape is literal: | ||
|
|
||
| > meta-and-voc-onboarding - install complete for <workspace> | ||
| > - VoC sync: <per-platform status, one line total> | ||
| > - Voice of Customer Audit: waits for backfill completion and a person's yes | ||
| > - Guards: merged | ||
| > - Creative Attributes: done | ||
| > - Account Context Brain: done - remaining gaps wait for the walkthrough | ||
| > | ||
| > Are you ready to begin your onboarding? | ||
|
|
||
| Fill only the angle-bracket slots; append nothing else to any bullet. The workspace | ||
| name in the header is identity, not a finding - it is the one detail that belongs there, | ||
| because a VM can hold several onboarded workspaces. "Creative | ||
| Attributes: done" is the entire line - naming what was detected, the convention's name |
There was a problem hiding this comment.
Step 6 instructs the agent to compose /agent/user.md from "its current contents — current as of this moment in the turn" and to build on "the exact payload that Write sent" in step 3 if step 3 ran this turn. If the agent re-reads the stale system-prompt copy instead of the in-turn payload (a plausible failure mode in long install turns), step 6 silently drops all four guard blocks that step 3 just merged. Adding an explicit pre-write assertion — confirm that all four guard sentinels appear in the composed payload before issuing the Write — would surface this corruption rather than silently hiding it.
| "resources": [ | ||
| { "id": "analyzing", "type": "directory", "sourcePath": "skills/analyzing", "target": { "root": "agent_brain", "path": "skills/creative-strategy-foundations/analyzing" }, "executablePaths": [] }, | ||
| { "id": "briefing", "type": "directory", "sourcePath": "skills/briefing", "target": { "root": "agent_brain", "path": "skills/creative-strategy-foundations/briefing" }, "executablePaths": [] }, | ||
| { "id": "creative-generation", "type": "directory", "sourcePath": "skills/creative-generation", "target": { "root": "agent_brain", "path": "skills/creative-strategy-foundations/creative-generation" }, "executablePaths": [] }, |
There was a problem hiding this comment.
agent_brain instead of agent_skills
All three skill resources use "root": "agent_brain" and install to agent_brain/skills/creative-strategy-foundations/<name>/. This is documented in core-creative-skills.md and appears intentional. However, every skill shipped by meta-and-voc-onboarding uses "root": "agent_skills". If any future tooling or skill-discovery mechanism assumes all skills live under agent_skills, these three will be invisible to it. A brief comment in the manifest or index entry explaining the deliberate agent_brain placement would help future maintainers.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
4 participants
No description provided.