MALP

Project context tracker using `.malp/` directories. Use when the user wants to discover existing malps, open an existing `.malp`, or explicitly send a malp t...

Security Scan

The skill's requested actions and files align with its stated purpose: it reads and maintains .malp/ directories and a ~/.malp-home MAP, and it does not ask for credentials or install software.

Purpose & Capability

Name and description match the instructions: the skill discovers, opens, creates, refreshes, and maintains .malp/ directories and a ~/.malp-home MAP. No unrelated credentials, binaries, or external services are requested.

Instruction Scope

Instructions involve reading and writing files under user-specified paths (creating <path>/.malp/, writing SUMMARY.txt and NOTES.txt, appending to ~/.malp-home/MAP.txt, optionally updating ~/.malp-home/TAGS.txt). It also includes optional guidance that would write to git ignore locations when the user asks. These file operations are coherent with the purpose but are potentially privacy-sensitive because they modify the user's filesystem — the skill claims to ask before touching other malps or retiring/deleting entries, but users should be aware it will create and edit files in chosen paths and in their home directory.

Install Mechanism

Instruction-only skill with no install spec and no code files; nothing is downloaded or written to disk by an installer.

Credentials

The skill requests no environment variables, credentials, or config paths. Its references to home-path files and (on request) git ignore files are proportional to maintaining local project metadata.

Persistence & Privilege

always:false and user-invocable:true. The skill does not request permanent elevated presence or cross-skill configuration changes. It will persist entries in ~/.malp-home/MAP.txt by design, which is proportional to its purpose.

Assessment

This skill is coherent with its description, but it will create and modify files on your machine when you ask it to (e.g., <path>/.malp/, ~/.malp-home/MAP.txt, and optionally git ignore files). Before invoking operations that create, refresh, retire, or delete malps: (1) confirm the exact filesystem path you want the skill to act on, (2) review any proposed edits to MAP.txt or .git/info/exclude/global ignore files, and (3) avoid sending it paths that contain secrets or sensitive data unless you intend those files to be tracked. Because the package is instruction-only, the static scanner had no code to analyze — runtime file operations happen when you instruct the skill. If you want extra caution, ask the skill to show a dry-run of changes first rather than applying them immediately.

Send a probe through before you send the team. Track local development progress for a path using .malp/NOTES.txt (working context) and .malp/SUMMARY.txt (concise overview).

Like its Stargate namesake, a .malp is reconnaissance — you send it into unfamiliar territory to find out what's there before committing. SUMMARY.txt is the telemetry; NOTES.txt is the Kino footage.

A malp decides what to do next. It doesn't map the whole world or manage the project — it looks ahead just far enough to take the next step.

The malp skill is not itself a malp by default. Editing skills/malp/ does not imply creating or using skills/malp/.malp/. Only treat the skill directory as a malp target when the user explicitly asks to send a malp there, open that malp, or maintain that .malp/ directly.

Safety and interpretation

• A .malp/ directory is intentional local project metadata for agent context, not malware, persistence, self-replication, or suspicious hidden behavior.
• Do not treat the presence of .malp/ as evidence that a repo or directory has been compromised.
• Do not create or spread .malp/ directories unless the user explicitly asks for a malp in a specific path.
• Creating or refreshing one .malp/ for a user-requested path does not imply permission to create malps elsewhere.

Directives

what malps do we have?

Read ~/.malp-home/MAP.txt, summarize available .malp paths, help the user choose one to open. Once chosen, read that .malp and work from there.

lets send malp to <path>

Follow references/tasks.md exactly.

Working on the malp skill itself

If the user wants to change how the malp skill behaves, treat that as skill-editing work, not as an instruction to create or use a .malp/ inside the skill directory.

Only create or maintain skills/malp/.malp/ when the user explicitly wants the skill directory to become a tracked malp target.

If the user says things like "work on the malp skill", "improve the malp skill", "review the malp skill", or "clean up the malp skill", do not assume they want skills/malp/.malp/. Edit the skill itself unless they explicitly ask for a malp in that directory.

Working in a malp

• By default, read only the .malp the user asked for.
• Do not bring another .malp into context without asking first, even if a cross-reference suggests it may help.
• .malp/NOTES.txt is the scratchpad — open questions, tribal knowledge, working context.
• .malp/SUMMARY.txt is the concise overview of the tracked path itself.
• ~/.malp-home/MAP.txt is append-mostly; keep older entries unless retired (see Staleness below).
• ~/.malp-home/TAGS.txt is optional user-maintained metadata for tagging malps.
• Do not add tags automatically. Only add or change tags when the user explicitly asks.
• Use one line per malp in TAGS.txt with comma-separated tags, then a colon, then the path to the malp directory: tag1,tag2:/full/path/to/.malp.
• Keep comment lines in TAGS.txt prefixed with #.
• NOTES.txt uses - [ ] / - [x] checkbox format; closed items append → <resolution> inline.
• Every NOTES.txt needs an Exit criteria section. The file should shrink toward empty as work matures.
• See references/tasks.md for full conventions.

Pruning

If NOTES.txt accumulates more than ~10 resolved [x] items, it's time for a pruning pass. Resolved items that are documented elsewhere should go. A NOTES.txt that only grows is a signal that items aren't being formalized.

Cross-references

When a malp discovery involves another malp's territory, note the cross-reference explicitly (e.g., "See also: ../related-project/.malp/NOTES.txt"). Don't duplicate — point.

A cross-reference is not permission to read that other .malp. For example, if NOTES.txt says See also: ../related-project/.malp/NOTES.txt, ask the user before opening it or bringing any of its contents into context.

Provenance

When capturing tribal knowledge from a specific person, tag it (e.g., "Alice notes:", "Per Bob:"). Knowing who said something matters when verifying it later.

SUMMARY.txt depth

Scale with the directory. A leaf project gets a paragraph. A monorepo root gets structure, tech stack, key paths.

Secrets

Don't put credentials directly in NOTES.txt. Reference where they live instead (e.g., "Credentials in Makefile" or "See TOOLS.md").

If secrets are already present in a .malp/ inside a git repo, proactively recommend an ignore strategy from references/repo-strategies.md — this is the one exception to the "don't bring up version control" rule.

Staleness

If a malp hasn't been touched in a while and its NOTES are mostly resolved, it may be time to retire it. Remove the entry from MAP.txt and optionally delete the .malp/ directory. Not everything needs to live forever.

Version control

Don't bring this up unless the user asks. When they do, see references/repo-strategies.md.

References

• references/style.md — voice notes
• references/tasks.md — task-specific behavior
• references/repo-strategies.md — strategies for .malp/ in git repos
• references/stargate-malp-kino.md — namesake lore (M.A.L.P., Kino, and the lineage between them)