| name | media-dopamine-package-standardization |
| description | Standardize and clean AaaS/media-dopamine content packages so final deliverables, publish state, review, and active assets stay visible while drafts and experiments move to archive. |
Media-Dopamine Package Standardization
Use this when working inside /home/yixian/Vault/AaaS/media-dopamine/packages/, especially when a package has accumulated drafts, platform variants, render experiments, and stale process files.
When to use
- A package root is cluttered with
request.md, strategy.md, deliverable.md, draft variants, and render outputs
- The real final article/post exists, but is buried under
drafts/ or similar folders
- A package serves multiple platforms and needs a consistent structure
- You need to convert an old package/template to the newer "final / publish / review / assets / archive" model
Target package shape
A clean package should converge toward:
packages/<slug>/
├── index.md
├── final.md
├── publish.md
├── review.md
├── assets/
│ ├── README.md
│ ├── <platform>-final.*
│ ├── <platform>-publish-kit.*
│ ├── shared-*.*
│ ├── selected card/image dirs
│ └── _archive/
└── _archive/
└── YYYY-MM-DD-<cleanup-name>/
Boundary
This skill only handles package-internal cleanup and convergence toward the standard shape.
It does NOT own:
- top-level taxonomy changes like moving packages between
longform / shortform / notes / profile
- Vault-wide state sync across
ToDo.md, Daily Reflections, Direction/, or project pages
- converting user reflection into publish-ready notes
- platform publishing operations such as WeChat draft creation or XHS renderer governance
If the task is about taxonomy migration, use media-dopamine-package-reclassification.
If the task is about syncing real-world progress into Vault state or turning reflection into publishable note packages, use vault-state-sync-and-note-publishing.
If the task is about multi-platform publishing workflow or WeChat draft operations, use media-dopamine-package-and-wechat-workflow.
Current taxonomy note
The package root shape in this skill should now be read as:
packages/<type>/<slug>/
not the older flat packages/<slug>/ form.
Recommended cleanup procedure
1. Inspect the package before editing
Use Hermes file/search tools to map the package and identify:
- current final article/post
- active publish/review files
- root-level process files
- active assets actually referenced by
publish.md
- stale draft folders and render experiment outputs
2. Preserve before removing from view
Do not hard-delete by default. Move stale items into:
- package-level
_archive/YYYY-MM-DD-package-cleanup/
- asset-level
assets/_archive/YYYY-MM-DD-.../
This keeps history while clearing the working surface.
3. Promote the actual final deliverable
If the real final article is buried under something like longform-drafts/final.md, move it to root as final.md.
Then update references in:
index.md
publish.md
review.md
assets/README.md
4. Rewrite index.md as a navigation page
index.md should:
- state current phase succinctly
- list current main files
- list archives/history separately
- avoid carrying legacy production-stage wording after the package is already published/stabilized
5. Align publish.md with reality
publish.md should:
- reference
final.md as the active production source unless there is a good reason otherwise
- point asset refs to currently used files/directories
- record real publication state (e.g. XHS published, waiting for data backfill)
- avoid stale text implying the package is still only in outline/draft mode
6. Align review.md with reality
review.md should:
- reference
final.md in content_path
- keep publish/review metadata in frontmatter
- reflect actual state, not outdated pre-publication wording
- continue serving as preflight + post-publication review, without duplicating the full正文
7. Simplify assets/
Keep only currently referenced assets in active assets/, for example:
- platform finals
- publish kits
- first comment files
- selected render input
- selected card directory
- shared keyword/title/angle helpers
Move everything else to archive.
Multi-platform rule of thumb
Default: single-core multi-platform
If one core argument is adapted across platforms:
- root keeps one
final.md as the shared main draft/master
- platform-specific finals and publish kits live in
assets/
Exception: truly separate finished works
Only use multiple root-level finals (e.g. final-xhs.md, final-wechat.md) when platform versions have become genuinely separate works, not simple rewrites.
Template migration pattern
When modernizing packages/_TEMPLATE/:
- add
final.md
- update
publish.md and review.md to point to final.md
- rewrite
index.md around current main files vs archive
- keep old template files under
_archive/legacy-template-files/
- replace old asset helper names with cleaner shared/platform-prefixed names where possible
Good signs after cleanup
- Opening the package root immediately shows the current final content and operational pages
- There is only one obvious main deliverable at root
- Platform materials are easy to find in
assets/
- Old drafts and experiments are preserved but no longer distract from the active workflow
Pitfalls
- Don’t leave stale status text after publication state changes
- Don’t keep both
final.md and buried drafts/final.md references alive
- Don’t duplicate the same final正文 across root, publish, review, and assets
- Don’t hard-delete historical materials unless explicitly asked