Install
$ agentstack add skill-vunm-io-passdown-passdown-intake ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Passdown Intake
Turn raw captured notes into properly planned work. Weak capture tools (chat apps, quick notes) only need to drop a markdown file into an inbox; this skill is where a capable agent applies judgment.
Configuration (read first)
Build the effective passdown configuration root-to-nearest:
- Start with every applicable
AGENTS.mdfrom the workspace/repository root
down to the current directory.
- If a thin
AGENTS.mdexplicitly points to a parent file outside the Git
root, read that parent too.
- Merge
## passdownkeys from root to nearest; a nearer value overrides only
the same key and inherits all omitted keys.
- Resolve relative config paths against the directory containing the
AGENTS.md that declared that value, not against an arbitrary current directory.
The effective configuration should contain:
## passdown
- inbox:
- planning: openspec |
- targets: , , ... # known target repos for routing
If a required key is still missing, ask the user for that value and suggest adding it to the appropriate AGENTS.md.
Inbox note contract
Notes are markdown files with minimal frontmatter. Never demand more structure from capture tools than this:
---
status: new # new | processed | discarded
target: unknown # target repo if the author could guess it
---
#
A malformed note is still a valid note — it is raw material, not an artifact.
Process
- Scan the inbox for notes with
status: new(treat missing frontmatter
as new). List them briefly for the user.
- For each note, in order:
- Read it fully. Cross-check existing knowledge/specs in the workspace if
relevant.
- If intent is unclear, ask the user — one question at a time.
- Before writing, resolve the inbox, target repo, planning directory, and
schema paths. Verify that the current host has read access to inputs and write access to every intended output. Cross-repo work often needs the parent workspace opened as a workspace root or an explicit permission grant.
- If sandbox, permission, or network policy blocks a required path, stop and
report the blocked path and operation. Do not redirect HOME, create substitute caches, or edit project/tool configuration as a workaround.
- Decide the disposition:
- Actionable work → determine the target repo (use
target:hint,
the routing rules in AGENTS.md, or ask). Create the planning artifact in the target repo using the workspace's planning convention. For planning: openspec, use the portable openspec new change CLI path; a host-specific command such as /opsx:propose may be used only when that host actually provides it. The artifact must be self-contained: an executor must be able to work from it without reading this conversation.
- Knowledge, not work → refile into the workspace's knowledge
location per its conventions.
- Obsolete/noise → mark
status: discardedafter confirming with
the user.
- Close the loop: update the note's frontmatter to
status: processed
and append a link to the created change/refiled location. The note stays where it is — it becomes the permanent record of where the idea came from.
Rules
- The inbox repo stores material and provenance; it never hosts task
execution. Planning artifacts always live in the target repo.
- Custom OpenSpec schemas (e.g.
openspec new change --schema passdown) must
exist as a real directory — openspec/schemas// in the target repo, or user-level ~/.local/share/openspec/schemas//. Symlinked schema directories fail with "Unknown schema" (openspec CLI 1.5.0). If the schema is missing and the target repo is writable, prefer the repo-local copy from its source repo before creating the change (for passdown: install.sh --into ). A user-level install writes outside the project and may require explicit approval.
- A discussion note is not an implementation request. Intake produces
plans, never code changes.
- Do not batch-guess: when a note's disposition is ambiguous, ask.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: vunm-io
- Source: vunm-io/passdown
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.