@joshski/dust 0.1.42 → 0.1.44
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/agent-events.d.ts +5 -0
- package/dist/cli/types.d.ts +2 -0
- package/dist/dust.js +853 -102
- package/package.json +2 -3
- package/templates/agent-greeting.txt +0 -31
- package/templates/agent-implement-task.txt +0 -26
- package/templates/agent-new-goal.txt +0 -22
- package/templates/agent-new-idea.txt +0 -46
- package/templates/agent-new-task.txt +0 -29
- package/templates/agent-pick-task.txt +0 -7
- package/templates/agents-md.txt +0 -5
- package/templates/audits/dead-code.md +0 -30
- package/templates/audits/security-review.md +0 -30
- package/templates/audits/test-coverage.md +0 -29
- package/templates/claude-md.txt +0 -5
- package/templates/help.txt +0 -36
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@joshski/dust",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.44",
|
|
4
4
|
"description": "Flow state for AI coding agents",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"bin": {
|
|
@@ -19,7 +19,6 @@
|
|
|
19
19
|
"files": [
|
|
20
20
|
"dist",
|
|
21
21
|
"bin",
|
|
22
|
-
"templates",
|
|
23
22
|
"lib/istanbul/minimal-reporter.cjs"
|
|
24
23
|
],
|
|
25
24
|
"repository": {
|
|
@@ -35,7 +34,7 @@
|
|
|
35
34
|
"author": "joshski",
|
|
36
35
|
"license": "MIT",
|
|
37
36
|
"scripts": {
|
|
38
|
-
"build": "bun build lib/cli/run.ts --target node --outfile dist/dust.js && printf '%s\\n%s' '#!/usr/bin/env node' \"$(cat dist/dust.js)\" > dist/dust.js && bun build lib/workflow-tasks.ts --target node --outfile dist/workflow-tasks.js && bunx tsc --project tsconfig.build.json
|
|
37
|
+
"build": "bun build lib/cli/run.ts --target node --outfile dist/dust.js && printf '%s\\n%s' '#!/usr/bin/env node' \"$(cat dist/dust.js)\" > dist/dust.js && bun build lib/workflow-tasks.ts --target node --outfile dist/workflow-tasks.js && bunx tsc --project tsconfig.build.json",
|
|
39
38
|
"test": "vitest run",
|
|
40
39
|
"test:coverage": "vitest run --coverage",
|
|
41
40
|
"eval": "bun run ./evals/run.ts"
|
|
@@ -1,31 +0,0 @@
|
|
|
1
|
-
🤖 Hello {{agentName}}, welcome to dust!
|
|
2
|
-
|
|
3
|
-
CRITICAL: You MUST run exactly ONE of the commands below before doing anything else.
|
|
4
|
-
|
|
5
|
-
Determine the user's intent and run the matching command NOW:
|
|
6
|
-
|
|
7
|
-
1. **Pick up work from the backlog** → `{{bin}} pick task`
|
|
8
|
-
User wants to start working. Examples: "work", "go", "pick a task", "what's next?"
|
|
9
|
-
|
|
10
|
-
2. **Implement a specific task** → `{{bin}} focus "<task name>"`
|
|
11
|
-
User mentions a particular task by name. Examples: "implement the auth task", "work on caching"
|
|
12
|
-
|
|
13
|
-
3. **Capture a new task** → `{{bin}} new task`
|
|
14
|
-
User has concrete work to add. Keywords: "task: ..." or "add a task ..."
|
|
15
|
-
|
|
16
|
-
4. **Capture a new goal** → `{{bin}} new goal`
|
|
17
|
-
User has a higher-level objective to add. Keywords: "goal: ..." or "add a goal ..."
|
|
18
|
-
|
|
19
|
-
5. **Capture a vague idea** → `{{bin}} new idea`
|
|
20
|
-
User has a rough idea that might become work later. Keywords: "idea: ..." or "add an idea ..."
|
|
21
|
-
|
|
22
|
-
6. **Unclear** → `{{bin}} help`
|
|
23
|
-
If none of the above clearly apply, run this to see all available commands.
|
|
24
|
-
|
|
25
|
-
Do NOT proceed without running one of these commands.
|
|
26
|
-
{{#if agentInstructions}}
|
|
27
|
-
|
|
28
|
-
---
|
|
29
|
-
|
|
30
|
-
{{agentInstructions}}
|
|
31
|
-
{{/if}}
|
|
@@ -1,26 +0,0 @@
|
|
|
1
|
-
## Implement a Task
|
|
2
|
-
|
|
3
|
-
{{#if isClaudeCodeWeb}}Follow these steps. Use a todo list to track your progress.
|
|
4
|
-
{{/if}}{{#unless isClaudeCodeWeb}}Follow these steps:
|
|
5
|
-
{{/unless}}
|
|
6
|
-
1. Run `{{bin}} next` to identify the (unblocked) task the user is referring to
|
|
7
|
-
2. Run `{{bin}} focus "<task name>"` (so everyone knows you're working on it)
|
|
8
|
-
3. Run `{{bin}} check` to verify the project is in a good state
|
|
9
|
-
4. Implement the task
|
|
10
|
-
{{#unless hooksInstalled}}5. Run `{{bin}} check` before committing
|
|
11
|
-
6.{{/unless}}{{#if hooksInstalled}}5.{{/if}} Create a single atomic commit that includes:
|
|
12
|
-
- All implementation changes
|
|
13
|
-
- Deletion of the completed task file
|
|
14
|
-
- Updates to any facts that changed
|
|
15
|
-
- Deletion of the idea file that spawned this task (if remaining scope exists, create new ideas for it)
|
|
16
|
-
|
|
17
|
-
Use the task title as the commit message. Task titles are written in imperative form, which is the recommended style for git commit messages. Do not add prefixes like "Complete task:" - use the title directly.
|
|
18
|
-
|
|
19
|
-
Example: If the task title is "Add validation for user input", the commit message should be:
|
|
20
|
-
```
|
|
21
|
-
Add validation for user input
|
|
22
|
-
```
|
|
23
|
-
|
|
24
|
-
{{#unless hooksInstalled}}7.{{/unless}}{{#if hooksInstalled}}6.{{/if}} Push your commit to the remote repository
|
|
25
|
-
|
|
26
|
-
Keep your change small and focused. One task, one commit.
|
|
@@ -1,22 +0,0 @@
|
|
|
1
|
-
## Adding a New Goal
|
|
2
|
-
|
|
3
|
-
Goals are guiding principles that persist across tasks. They define the "why" behind the work.
|
|
4
|
-
|
|
5
|
-
{{#if isClaudeCodeWeb}}Follow these steps. Use a todo list to track your progress.
|
|
6
|
-
{{/if}}{{#unless isClaudeCodeWeb}}Follow these steps:
|
|
7
|
-
{{/unless}}
|
|
8
|
-
1. Run `{{bin}} goals` to see existing goals and avoid duplication
|
|
9
|
-
2. Create a new markdown file in `.dust/goals/` with a descriptive kebab-case name (e.g., `cross-platform-support.md`)
|
|
10
|
-
3. Add a title as the first line using an H1 heading (e.g., `# Cross-platform support`)
|
|
11
|
-
4. Write a clear description explaining:
|
|
12
|
-
- What this goal means in practice
|
|
13
|
-
- Why it matters for the project
|
|
14
|
-
- How to evaluate whether work supports this goal
|
|
15
|
-
5. Run `{{bin}} lint markdown` to catch any formatting issues
|
|
16
|
-
6. Create a single atomic commit with a message in the format "Add goal: <title>"
|
|
17
|
-
7. Push your commit to the remote repository
|
|
18
|
-
|
|
19
|
-
Goals should be:
|
|
20
|
-
- **Stable** - They rarely change once established
|
|
21
|
-
- **Actionable** - Tasks can be linked to them
|
|
22
|
-
- **Clear** - Anyone reading should understand what it means
|
|
@@ -1,46 +0,0 @@
|
|
|
1
|
-
## Adding a New Idea
|
|
2
|
-
|
|
3
|
-
Follow these steps:
|
|
4
|
-
|
|
5
|
-
1. Run `{{bin}} ideas` to see all existing ideas and avoid duplicates
|
|
6
|
-
2. Create a new markdown file in `.dust/ideas/` with a descriptive kebab-case name (e.g., `improve-error-messages.md`)
|
|
7
|
-
3. Add a title as the first line using an H1 heading (e.g., `# Improve error messages`)
|
|
8
|
-
4. Write a brief description of the potential change or improvement
|
|
9
|
-
5. If the idea has open questions, add an `## Open Questions` section (see below)
|
|
10
|
-
6. Run `{{bin}} lint markdown` to catch any issues with the idea file format
|
|
11
|
-
7. Create a single atomic commit with a message in the format "Add idea: <title>"
|
|
12
|
-
8. Push your commit to the remote repository
|
|
13
|
-
|
|
14
|
-
### Open Questions section
|
|
15
|
-
|
|
16
|
-
Ideas exist to eventually spawn tasks, so they start intentionally vague. An optional `## Open Questions` section captures the decisions that need to be made before the idea becomes actionable. Each question is an h3 heading ending with `?`, and each option is an h4 heading with markdown content explaining the trade-offs:
|
|
17
|
-
|
|
18
|
-
```markdown
|
|
19
|
-
## Open Questions
|
|
20
|
-
|
|
21
|
-
### Should we take our own payments?
|
|
22
|
-
|
|
23
|
-
#### Yes, take our own payments
|
|
24
|
-
|
|
25
|
-
Lower costs and we become the seller of record, but requires a merchant account.
|
|
26
|
-
|
|
27
|
-
#### No, use a payment provider
|
|
28
|
-
|
|
29
|
-
Higher costs but simpler setup. No merchant account needed.
|
|
30
|
-
|
|
31
|
-
### Which storage backend should we use?
|
|
32
|
-
|
|
33
|
-
#### SQLite
|
|
34
|
-
|
|
35
|
-
Simple and embedded. Good for single-node deployments.
|
|
36
|
-
|
|
37
|
-
#### PostgreSQL
|
|
38
|
-
|
|
39
|
-
Scalable but requires a separate server.
|
|
40
|
-
```
|
|
41
|
-
|
|
42
|
-
Rules:
|
|
43
|
-
- Questions are `###` headings and must end with `?`
|
|
44
|
-
- Options are `####` headings beneath a question
|
|
45
|
-
- Each question must have at least one option
|
|
46
|
-
- Options can contain any markdown content (paragraphs, lists, code blocks, etc.)
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
## Adding a New Task
|
|
2
|
-
|
|
3
|
-
{{#if isClaudeCodeWeb}}Follow these steps to create the task definition, then spawn a sub-agent for implementation.
|
|
4
|
-
|
|
5
|
-
Use a todo list to track your progress through these steps.
|
|
6
|
-
{{/if}}{{#unless isClaudeCodeWeb}}Follow these steps:
|
|
7
|
-
{{/unless}}
|
|
8
|
-
1. Run `{{bin}} ideas` to see all existing ideas
|
|
9
|
-
2. Determine which ideas (if any) should be:
|
|
10
|
-
- **Deleted** - if the new task fully covers the idea
|
|
11
|
-
- **Updated** - if the idea's scope changes as a result of the task
|
|
12
|
-
3. Research thoroughly to ensure the task will be clearly defined:
|
|
13
|
-
- Explore the codebase to understand existing patterns and relevant files
|
|
14
|
-
- Identify exactly which files need to change and how
|
|
15
|
-
- Resolve any ambiguities in the requirements before writing the task
|
|
16
|
-
- Gather specific technical details (function names, file paths, data structures)
|
|
17
|
-
- The goal is a task description with minimal ambiguity at implementation time
|
|
18
|
-
4. Create a new markdown file in `.dust/tasks/` with a descriptive kebab-case name (e.g., `add-user-authentication.md`)
|
|
19
|
-
5. Add a title as the first line using an H1 heading (e.g., `# Add user authentication`)
|
|
20
|
-
6. Write a comprehensive description starting with an imperative opening sentence (e.g., "Add caching to the API layer." not "This task adds caching."). Include technical details and references to relevant files.
|
|
21
|
-
7. Add a `## Goals` section with links to relevant goals this task supports (e.g., `- [Goal Name](../goals/goal-name.md)`)
|
|
22
|
-
8. Add a `## Blocked By` section listing any tasks that must complete first, or `(none)` if there are no blockers
|
|
23
|
-
9. Add a `## Definition of Done` section with a checklist of completion criteria using `- [ ]` for each item
|
|
24
|
-
10. Run `{{bin}} lint markdown` to catch any issues with the task format
|
|
25
|
-
11. Create a single atomic commit with a message in the format "Add task: <title>" that includes:
|
|
26
|
-
- The new task file
|
|
27
|
-
- Deletion of the idea file that spawned this task (if remaining scope exists, create new ideas for it)
|
|
28
|
-
{{#unless isClaudeCodeWeb}}12. Push your commit to the remote repository
|
|
29
|
-
{{/unless}}{{#if isClaudeCodeWeb}}12. **Start a sub-agent** to implement the task: "Run `{{bin}} implement task` and implement the task in `.dust/tasks/[task-file].md`"{{/if}}
|
package/templates/agents-md.txt
DELETED
|
@@ -1,30 +0,0 @@
|
|
|
1
|
-
# Dead Code
|
|
2
|
-
|
|
3
|
-
Find and remove unused code to improve maintainability and reduce bundle size.
|
|
4
|
-
|
|
5
|
-
## Scope
|
|
6
|
-
|
|
7
|
-
Focus on these areas:
|
|
8
|
-
|
|
9
|
-
1. **Unused exports** - Functions, classes, constants that are never imported
|
|
10
|
-
2. **Unreachable code** - Code after return statements, impossible conditions
|
|
11
|
-
3. **Orphaned files** - Files that are not imported anywhere
|
|
12
|
-
4. **Unused dependencies** - Packages in package.json not used in code
|
|
13
|
-
5. **Commented-out code** - Old code left in comments
|
|
14
|
-
|
|
15
|
-
## Goals
|
|
16
|
-
|
|
17
|
-
(none)
|
|
18
|
-
|
|
19
|
-
## Blocked By
|
|
20
|
-
|
|
21
|
-
(none)
|
|
22
|
-
|
|
23
|
-
## Definition of Done
|
|
24
|
-
|
|
25
|
-
- [ ] Ran static analysis tools to find unused exports
|
|
26
|
-
- [ ] Identified files with no incoming imports
|
|
27
|
-
- [ ] Listed unused dependencies
|
|
28
|
-
- [ ] Reviewed commented-out code blocks
|
|
29
|
-
- [ ] Created list of code safe to remove
|
|
30
|
-
- [ ] Verified removal won't break dynamic imports or reflection
|
|
@@ -1,30 +0,0 @@
|
|
|
1
|
-
# Security Review
|
|
2
|
-
|
|
3
|
-
Review the codebase for common security vulnerabilities and misconfigurations.
|
|
4
|
-
|
|
5
|
-
## Scope
|
|
6
|
-
|
|
7
|
-
Focus on these areas:
|
|
8
|
-
|
|
9
|
-
1. **Hardcoded secrets** - API keys, passwords, tokens in source code
|
|
10
|
-
2. **Injection vulnerabilities** - SQL injection, command injection, XSS
|
|
11
|
-
3. **Authentication issues** - Weak password handling, missing auth checks
|
|
12
|
-
4. **Sensitive data exposure** - Logging sensitive data, insecure storage
|
|
13
|
-
5. **Dependency vulnerabilities** - Known CVEs in dependencies
|
|
14
|
-
|
|
15
|
-
## Goals
|
|
16
|
-
|
|
17
|
-
(none)
|
|
18
|
-
|
|
19
|
-
## Blocked By
|
|
20
|
-
|
|
21
|
-
(none)
|
|
22
|
-
|
|
23
|
-
## Definition of Done
|
|
24
|
-
|
|
25
|
-
- [ ] Searched for hardcoded secrets (API keys, passwords, tokens)
|
|
26
|
-
- [ ] Reviewed input validation and sanitization
|
|
27
|
-
- [ ] Checked authentication and authorization logic
|
|
28
|
-
- [ ] Verified sensitive data is not logged or exposed
|
|
29
|
-
- [ ] Ran dependency audit for known vulnerabilities
|
|
30
|
-
- [ ] Documented any findings with severity ratings
|
|
@@ -1,29 +0,0 @@
|
|
|
1
|
-
# Test Coverage
|
|
2
|
-
|
|
3
|
-
Identify untested code paths and areas that need additional test coverage.
|
|
4
|
-
|
|
5
|
-
## Scope
|
|
6
|
-
|
|
7
|
-
Focus on these areas:
|
|
8
|
-
|
|
9
|
-
1. **Core business logic** - Functions that handle critical operations
|
|
10
|
-
2. **Edge cases** - Boundary conditions, error handling paths
|
|
11
|
-
3. **Integration points** - API endpoints, database operations
|
|
12
|
-
4. **User-facing features** - UI components, form validation
|
|
13
|
-
5. **Recent changes** - Code modified in the last few commits
|
|
14
|
-
|
|
15
|
-
## Goals
|
|
16
|
-
|
|
17
|
-
(none)
|
|
18
|
-
|
|
19
|
-
## Blocked By
|
|
20
|
-
|
|
21
|
-
(none)
|
|
22
|
-
|
|
23
|
-
## Definition of Done
|
|
24
|
-
|
|
25
|
-
- [ ] Identified modules with low or no test coverage
|
|
26
|
-
- [ ] Listed critical paths that lack tests
|
|
27
|
-
- [ ] Prioritized areas by risk and importance
|
|
28
|
-
- [ ] Created list of specific test cases to add
|
|
29
|
-
- [ ] Estimated effort for improving coverage
|
package/templates/claude-md.txt
DELETED
package/templates/help.txt
DELETED
|
@@ -1,36 +0,0 @@
|
|
|
1
|
-
💨 dust - Flow state for AI coding agents.
|
|
2
|
-
|
|
3
|
-
Usage: {{bin}} <command> [options]
|
|
4
|
-
|
|
5
|
-
Commands:
|
|
6
|
-
init Initialize a new Dust repository
|
|
7
|
-
lint markdown Run lint checks on .dust/ files
|
|
8
|
-
list List all items (tasks, ideas, goals, facts)
|
|
9
|
-
tasks List tasks (actionable work with definitions of done)
|
|
10
|
-
ideas List ideas (vague proposals, convert to tasks when ready)
|
|
11
|
-
goals List goals (guiding principles, stable, rarely change)
|
|
12
|
-
facts List facts (documentation of current system state)
|
|
13
|
-
next Show tasks ready to work on (not blocked)
|
|
14
|
-
check Run project-defined quality gate hook
|
|
15
|
-
agent Agent greeting and routing instructions
|
|
16
|
-
focus Declare current objective (for remote session tracking)
|
|
17
|
-
pick task Pick the next task to work on
|
|
18
|
-
implement task Implement a task
|
|
19
|
-
new task Create a new task
|
|
20
|
-
new goal Create a new goal
|
|
21
|
-
new idea Create a new idea
|
|
22
|
-
loop claude Run continuous Claude iteration on tasks
|
|
23
|
-
pre push Git pre-push hook validation
|
|
24
|
-
help Show this help message
|
|
25
|
-
|
|
26
|
-
🤖 Agent Guide
|
|
27
|
-
|
|
28
|
-
Dust is a lightweight planning system. The .dust/ directory contains:
|
|
29
|
-
- goals/ - Guiding principles (stable, rarely change)
|
|
30
|
-
- ideas/ - Proposals (convert to tasks when ready)
|
|
31
|
-
- tasks/ - Actionable work with definitions of done
|
|
32
|
-
- facts/ - Documentation of current system state
|
|
33
|
-
|
|
34
|
-
Workflow: Pick a task → implement it → delete the task file → commit atomically.
|
|
35
|
-
|
|
36
|
-
Run `{{bin}} agent` to get started!
|