원클릭으로 Manus에서 모든 스킬 실행

시작하기

ds-project-map

스타14

포크4

업데이트2026년 7월 13일 01:48

Map the current repository into a durable project description at `.project/PROJECT.md`.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

gleicon

gleicon/devskills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Process

Create .project/ if it does not exist.
Establish facts efficiently — locate before reading. Lean on cheap signals first: the file tree, manifests (package.json, go.mod, etc.), and entry points. Search to find the major pieces; read scoped regions, not whole files. Read enough to be accurate, no more — the map is identifiers and one-liners, not a digest of every file.
Write .project/PROJECT.md with these sections:
- Overview — one paragraph: what the project is and who it's for.
- Stack — languages, runtime, key dependencies, build/test commands.
- Repo map — a short table of the top-level directories and what each holds.
- Constraints — hard rules the project must respect (perf, compatibility, forbidden approaches), if any are evident or already recorded.
If .project/PROJECT.md already exists, treat it as partly human-authored. Refresh the code-derived sections (Stack, Repo map) to match the current source — but before overwriting, compare what you would generate against what's already there. Anything present that you would not re-derive from the code — a manually-added project truth, a constraint or rule not visible in the source, a custom section, hand-written Overview prose — is human-added knowledge. List those items and ask whether to keep, update, or drop each one before you write. Never silently discard them; default to keeping.

Rules

Facts only — derive everything from the code, not from assumptions.
Keep it short. This is a map, not documentation. Reference real files and dirs by path.
Do not record current state or tasks here — that lives in .project/PLAN.md.
On a rerun, human edits win by default. Code-derived sections are refreshed freely, but anything you can't re-derive from the code is preserved unless the user agrees to change it — and when something would be lost, ask rather than assume.

Output

Display the path and a one-line summary of what changed (created, or which sections were refreshed).

이 저장소의 다른 Skills

같은 저장소

ds-blueprint

gleicon/devskills

Design a target architecture for a new system — module boundaries, dependency rules, seams, and build order — from its requirements. Reports a blueprint; changes nothing.

2026-07-1414

ds-architecture-plan

gleicon/devskills

Analyze an existing codebase's architecture and produce a sequenced refactoring plan — assess module boundaries, dependency structure, and layering, then lay out ordered, risk-tagged steps. Language-agnostic. Reports a plan; changes nothing.

2026-07-1414

ds-roadmap

gleicon/devskills

Turn a goal or another command's output into an ordered task roadmap.

2026-07-1414

ds-debug

gleicon/devskills

Find the root cause of a failure with the scientific method — reproduce, isolate, fix, then prove it.

2026-07-1414

ds-grill-me

gleicon/devskills

Interview the user relentlessly about a plan or design until reaching shared understanding.

2026-07-1414

ds-code-quality-review

gleicon/devskills

Run an extremely strict maintainability + single-source-of-truth review of code changes — abstraction quality, file sprawl, spaghetti-condition growth, and duplicate/competing implementations. Reports findings by default; `--fix` applies the mechanical, unambiguous ones — structural/code-judo restructurings rest on judgment and stay reported.

2026-07-1414

name	ds-project-map
description	Map the current repository into a durable project description at `.project/PROJECT.md`.
disable-model-invocation	true

Process

Create .project/ if it does not exist.
Establish facts efficiently — locate before reading. Lean on cheap signals first: the file tree, manifests (package.json, go.mod, etc.), and entry points. Search to find the major pieces; read scoped regions, not whole files. Read enough to be accurate, no more — the map is identifiers and one-liners, not a digest of every file.
Write .project/PROJECT.md with these sections:
- Overview — one paragraph: what the project is and who it's for.
- Stack — languages, runtime, key dependencies, build/test commands.
- Repo map — a short table of the top-level directories and what each holds.
- Constraints — hard rules the project must respect (perf, compatibility, forbidden approaches), if any are evident or already recorded.
If .project/PROJECT.md already exists, treat it as partly human-authored. Refresh the code-derived sections (Stack, Repo map) to match the current source — but before overwriting, compare what you would generate against what's already there. Anything present that you would not re-derive from the code — a manually-added project truth, a constraint or rule not visible in the source, a custom section, hand-written Overview prose — is human-added knowledge. List those items and ask whether to keep, update, or drop each one before you write. Never silently discard them; default to keeping.

Rules

Facts only — derive everything from the code, not from assumptions.
Keep it short. This is a map, not documentation. Reference real files and dirs by path.
Do not record current state or tasks here — that lives in .project/PLAN.md.
On a rerun, human edits win by default. Code-derived sections are refreshed freely, but anything you can't re-derive from the code is preserved unless the user agrees to change it — and when something would be lost, ask rather than assume.

Output

Display the path and a one-line summary of what changed (created, or which sections were refreshed).