A file distribution utility for deploying assets from registered sources to registered destinations Supports post-deploy transformation modules for asset-specific customization — such as Claude Code agents, dotfiles, or config files. Requirements:
- Scriptable and composable
- Extensible via installable modules
- Designed for single-user, local workflows
Node.js, Commander, Conf, simple-git, Chalk
The development documents are organized in the memory-bank dir:
detailed-spec: primarily focuses on specific feature implementation detailsgen-directives: content and code generation guidelines
- Code: match the architectural and stylistic conventions of the existing codebase
- Quality: production-grade — every line will be reviewed
- Markdown: compact, no linting compliance, formatting identical to this file
- Read a language-specific file in
gen-directivesonly when a coding task is requested - Read files in
detailed-speconly when required by the current task; scan filenames first and read file contents only if they are relevant to the task - NEVER update this file
- NEVER modify
*.mdfiles inmemory-bank(at any depth in the dir tree) without an explicit request - NEVER initiate any codebase modifications without an explicit request
- NEVER commit changes to Git history without explicit authorization
- Surface Uncertainty, Don't Guess Through It: When requirements are ambiguous, contradictory, or incomplete, stop and ask instead of assuming intent and proceeding silently. State assumptions explicitly; if multiple readings are viable, present them rather than picking one silently. Resolve intent up front — this is what makes autonomous execution safe afterward
- Plan Before Implementing: For non-trivial tasks, outline a brief approach before writing code so wrong directions surface early. For multi-step work, list the steps with a verification check for each
- Simplicity Over Abstraction: Write the simplest solution that meets the requirements. Avoid speculative features, abstractions for single-use code, unrequested configurability, and error handling for impossible cases. If a construction could be materially shorter without losing correctness, rewrite it — ask whether a senior engineer would call it overcomplicated
- Surgical Scope: Every changed line should trace directly to the current task. Match the surrounding style even where you'd choose differently. Remove imports, variables, and comments that your changes made obsolete, but never modify, reformat, or delete code or comments orthogonal to the task. If you notice unrelated dead code, mention it — don't delete it
- Drive Toward Success Criteria: Turn the task into checkable goals and work until they're met — e.g. "add validation" → write tests for invalid inputs, then make them pass; "fix the bug" → write a failing test that reproduces it, then make it pass. When the goal is well-defined, loop and self-verify independently rather than pausing for confirmation the criteria already answer. (This is the counterpart to Surface Uncertainty: clarify the goal before starting; do not re-open a settled goal mid-execution)