light-project-structure
Audit, plan, scaffold, and safely migrate research project structures across greenfield, existing Git/non-Git repositories, and monorepo subroots. Use for project folders, repository cleanup, source inventory, move maps, naming and storage policy, Python/R/mixed/LaTeX profiles, template provenance, conflict review, applied-move evidence, or rollback. Existing projects are read-only until the user authorizes exact action IDs bound to a plan digest. Preserve uncommitted and untracked work, symlinks, submodules, and memory-pm's .light content. This is an off-DAG local tool: do not emit findings o
npx skills add Light0305/Light-skills --skill light-project-structure --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Project structure lifecycle Own the **visible project tree** and its migration evidence. Do not mistake a tidy directory for reproducible research. Read [`references/project-lifecycle-resource-map.md`](references/project-lifecycle-resource-map.md) before an existing-repository migration. It defines artifacts, policy, access levels, provenance, and cross-skill ownership. Use [`references/structure-profiles.json`](references/structure-profiles.json) for small profile minima and [`templates/project-policy.template.json`](templates/project-policy.template.json) for explicit project/file policy. Use `scripts/structure_governance_gate.py` before delivery to validate profile choice, existing-project read-only safety, template residuals, secret scan, environment doctor, authorization binding, applied-manifest binding, and rollback evidence. ## Non-negotiable boundary 1. Treat inventory as read-only access, not authorization to move. 2. Never overwrite, delete, run `git rm --cached`, initialize DVC, rewrite configuration, or move a symlink automatically. 3. Never use `--force` as consent. The lifecycle has no force bypass. 4. Preserve all `.light/` content. `memory-pm` alone creates or ed
- Non-negotiable boundary
- Choose the mode
- Phase 1 — Intake and requirements
- Phase 2 — Review the dry-run
- Phase 3 — Bind authorization
- Phase 4 — Apply, verify, rollback, reapply
- Greenfield scaffold
- Ownership handoff
- Validation
What does the light-project-structure skill do?
Audit, plan, scaffold, and safely migrate research project structures across greenfield, existing Git/non-Git repositories, and monorepo subroots. Use for project folders, repository cleanup, source inventory, move maps, naming and storage policy, Python/R/mixed/LaTeX profiles, template provenance, conflict review, applied-move evidence, or rollback. Existing projects are read-only until the user authorizes exact action IDs bound to a plan digest. Preserve uncommitted and untracked work, symlinks, submodules, and memory-pm's .light content. This is an off-DAG local tool: do not emit findings o
How do I install it?
Run `npx skills add Light0305/Light-skills --skill light-project-structure --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From Light0305/Light-skills, a repository with 505 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.