syntaur 0.3.3 → 0.4.0
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/README.md +26 -3
- package/dist/index.js +650 -155
- package/dist/index.js.map +1 -1
- package/package.json +8 -2
- package/platforms/claude-code/.claude-plugin/plugin.json +1 -5
- package/platforms/claude-code/agents/syntaur-expert.md +30 -18
- package/platforms/claude-code/commands/complete-assignment/complete-assignment.md +20 -0
- package/platforms/claude-code/commands/create-assignment/create-assignment.md +20 -0
- package/platforms/claude-code/commands/create-project/create-project.md +20 -0
- package/platforms/claude-code/commands/grab-assignment/grab-assignment.md +20 -0
- package/platforms/claude-code/commands/plan-assignment/plan-assignment.md +20 -0
- package/statusline/statusline.sh +133 -0
- package/vendor/syntaur-skills/LICENSE +21 -0
- package/vendor/syntaur-skills/README.md +43 -0
- package/vendor/syntaur-skills/skills/complete-assignment/SKILL.md +146 -0
- package/vendor/syntaur-skills/skills/create-assignment/SKILL.md +72 -0
- package/vendor/syntaur-skills/skills/create-project/SKILL.md +56 -0
- package/vendor/syntaur-skills/skills/grab-assignment/SKILL.md +158 -0
- package/vendor/syntaur-skills/skills/plan-assignment/SKILL.md +137 -0
- package/vendor/syntaur-skills/skills/syntaur-protocol/SKILL.md +119 -0
- package/vendor/syntaur-skills/skills/syntaur-protocol/references/file-ownership.md +67 -0
- package/vendor/syntaur-skills/skills/syntaur-protocol/references/protocol-summary.md +82 -0
- package/platforms/claude-code/hooks/statusline.sh +0 -110
- package/platforms/claude-code/skills/complete-assignment/SKILL.md +0 -155
- package/platforms/claude-code/skills/create-assignment/SKILL.md +0 -67
- package/platforms/claude-code/skills/grab-assignment/SKILL.md +0 -202
- package/platforms/claude-code/skills/plan-assignment/SKILL.md +0 -156
- package/platforms/claude-code/skills/syntaur-protocol/SKILL.md +0 -86
- package/platforms/codex/skills/complete-assignment/SKILL.md +0 -64
- package/platforms/codex/skills/create-assignment/SKILL.md +0 -49
- package/platforms/codex/skills/grab-assignment/SKILL.md +0 -73
- package/platforms/codex/skills/plan-assignment/SKILL.md +0 -61
- package/platforms/codex/skills/syntaur-protocol/SKILL.md +0 -102
|
@@ -1,156 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: plan-assignment
|
|
3
|
-
description: Create an implementation plan for the current Syntaur assignment
|
|
4
|
-
argument-hint: "[focus area or notes]"
|
|
5
|
-
allowed-tools:
|
|
6
|
-
- Bash
|
|
7
|
-
- Read
|
|
8
|
-
- Write
|
|
9
|
-
- Edit
|
|
10
|
-
- Glob
|
|
11
|
-
- Grep
|
|
12
|
-
---
|
|
13
|
-
|
|
14
|
-
# Plan Assignment
|
|
15
|
-
|
|
16
|
-
Create a detailed implementation plan for your current Syntaur assignment.
|
|
17
|
-
|
|
18
|
-
## Arguments
|
|
19
|
-
|
|
20
|
-
Optional notes from the user: $ARGUMENTS
|
|
21
|
-
|
|
22
|
-
## Step 1: Load Context
|
|
23
|
-
|
|
24
|
-
Read `.syntaur/context.json` from the current working directory.
|
|
25
|
-
|
|
26
|
-
If the file does not exist, tell the user: "No active assignment found. Run `/grab-assignment <project-slug>` first to claim an assignment."
|
|
27
|
-
|
|
28
|
-
Extract from the context file:
|
|
29
|
-
- `projectSlug` -- the project slug
|
|
30
|
-
- `assignmentSlug` -- the assignment slug
|
|
31
|
-
- `assignmentDir` -- absolute path to the assignment folder
|
|
32
|
-
- `projectDir` -- absolute path to the project folder
|
|
33
|
-
- `workspaceRoot` -- absolute path to the workspace (may be null)
|
|
34
|
-
|
|
35
|
-
## Step 1.5: Load Playbooks
|
|
36
|
-
|
|
37
|
-
Read all playbook files from `~/.syntaur/playbooks/` — these contain user-defined behavioral rules you must follow:
|
|
38
|
-
|
|
39
|
-
```bash
|
|
40
|
-
ls ~/.syntaur/playbooks/*.md 2>/dev/null
|
|
41
|
-
```
|
|
42
|
-
|
|
43
|
-
For each file found, read it and follow its directives. Playbooks may contain rules about planning conventions, required steps, or quality expectations that apply to this plan.
|
|
44
|
-
|
|
45
|
-
## Step 2: Read Assignment Details
|
|
46
|
-
|
|
47
|
-
Read the following files to understand the assignment:
|
|
48
|
-
|
|
49
|
-
1. Read `<assignmentDir>/assignment.md` -- extract the objective, acceptance criteria, context section, and the `## Todos` list
|
|
50
|
-
2. Read `<assignmentDir>/comments.md` if it exists -- inherited questions, notes, and feedback
|
|
51
|
-
3. Read `<projectDir>/project.md` -- extract the project goal for broader context
|
|
52
|
-
4. Read `<projectDir>/manifest.md` -- navigation index for the project
|
|
53
|
-
|
|
54
|
-
Per-project `agent.md` and `claude.md` were removed in v0.2.0. The agent-level
|
|
55
|
-
conventions now live in the repo root `CLAUDE.md` / `AGENTS.md` and in
|
|
56
|
-
`~/.syntaur/playbooks/`, which Step 1.5 already loaded.
|
|
57
|
-
|
|
58
|
-
If the assignment has dependencies (`dependsOn` in frontmatter), read each
|
|
59
|
-
dependency's `handoff.md` and `decision-record.md` for integration context and
|
|
60
|
-
upstream decisions:
|
|
61
|
-
- `<projectDir>/assignments/<dep-slug>/handoff.md`
|
|
62
|
-
- `<projectDir>/assignments/<dep-slug>/decision-record.md`
|
|
63
|
-
|
|
64
|
-
## Step 3: Explore Workspace (if set)
|
|
65
|
-
|
|
66
|
-
If `workspaceRoot` is not null:
|
|
67
|
-
|
|
68
|
-
1. Check if the workspace directory exists:
|
|
69
|
-
```bash
|
|
70
|
-
ls <workspaceRoot>
|
|
71
|
-
```
|
|
72
|
-
2. Explore the codebase structure to understand what exists:
|
|
73
|
-
- Use `Glob` to find key files (e.g., `**/*.ts`, `**/package.json`, `**/*.md`)
|
|
74
|
-
- Use `Grep` to search for relevant patterns mentioned in the assignment
|
|
75
|
-
- Read key files like `package.json`, `tsconfig.json`, or entry points
|
|
76
|
-
3. Note any existing patterns, conventions, or architecture you discover
|
|
77
|
-
|
|
78
|
-
If `workspaceRoot` is null, skip this step and note in the plan that no workspace is configured.
|
|
79
|
-
|
|
80
|
-
## Step 4: Write the Plan
|
|
81
|
-
|
|
82
|
-
Plans are versioned. The first plan for an assignment is `plan.md`; subsequent plans are `plan-v2.md`, `plan-v3.md`, etc. Each plan gets a linked entry in the `## Todos` section of `assignment.md`, and any prior active plan todo is marked superseded (never deleted).
|
|
83
|
-
|
|
84
|
-
### 4a. Determine the next plan filename
|
|
85
|
-
|
|
86
|
-
Use Glob to list `<assignmentDir>/plan*.md`. Then:
|
|
87
|
-
|
|
88
|
-
- If no plan files exist, the target is `plan.md` and the version label is "plan".
|
|
89
|
-
- If `plan.md` exists but no `plan-v<N>.md`, the target is `plan-v2.md` and the version label is "plan v2".
|
|
90
|
-
- Otherwise, pick the smallest `N >= 2` such that `plan-v<N>.md` does not exist. The version label is `plan v<N>`.
|
|
91
|
-
|
|
92
|
-
Remember this `planFilename` and `versionLabel` for the remaining substeps.
|
|
93
|
-
|
|
94
|
-
### 4b. Write the plan file
|
|
95
|
-
|
|
96
|
-
Write `<assignmentDir>/<planFilename>` with standard plan frontmatter:
|
|
97
|
-
|
|
98
|
-
```yaml
|
|
99
|
-
---
|
|
100
|
-
assignment: <assignmentSlug>
|
|
101
|
-
status: draft
|
|
102
|
-
created: "<nowTimestamp>"
|
|
103
|
-
updated: "<nowTimestamp>"
|
|
104
|
-
---
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
Then the markdown body should include:
|
|
108
|
-
|
|
109
|
-
1. **Overview** -- one paragraph summarizing the approach
|
|
110
|
-
2. **Tasks** -- numbered list of implementation tasks, each with:
|
|
111
|
-
- Description of what to do
|
|
112
|
-
- Files to create or modify (with paths)
|
|
113
|
-
- Dependencies on other tasks
|
|
114
|
-
- Estimated complexity (low/medium/high)
|
|
115
|
-
3. **Acceptance Criteria Mapping** -- for each criterion from assignment.md, which task(s) address it
|
|
116
|
-
4. **Risks and Open Questions** -- anything that might block or complicate implementation
|
|
117
|
-
5. **Testing Strategy** -- how to verify the implementation works
|
|
118
|
-
|
|
119
|
-
**Decision capture:** While planning, note any meaningful choices you make (library picks, schema design, architectural calls, rejected alternatives). Record each as a numbered entry in `<assignmentDir>/decision-record.md` with the format `## Decision N: <short title>` — fields: Status (proposed/accepted), Context, Decision, Consequences. Downstream assignments that depend on this one auto-load these decisions during `/grab-assignment`, so they pay off over time.
|
|
120
|
-
|
|
121
|
-
If the target file already exists (only possible for `plan.md` on first re-run against a scaffolded-but-empty plan), preserve the frontmatter and replace only the body, flipping `status` from `draft` to `in_progress` and updating `updated`.
|
|
122
|
-
|
|
123
|
-
### 4c. Update assignment.md Todos
|
|
124
|
-
|
|
125
|
-
Read `<assignmentDir>/assignment.md` and locate the `## Todos` section.
|
|
126
|
-
|
|
127
|
-
1. **Supersede prior plan todos.** Scan unchecked todo lines for any that match the pattern `- [ ] Execute [<label>](./plan.md)` or `- [ ] Execute [<label>](./plan-v<N>.md)`. For each match, rewrite the line as:
|
|
128
|
-
|
|
129
|
-
```
|
|
130
|
-
- [x] ~~Execute [<label>](./<old-plan-filename>)~~ (superseded by <versionLabel>)
|
|
131
|
-
```
|
|
132
|
-
|
|
133
|
-
Never delete the old line — preserve history.
|
|
134
|
-
|
|
135
|
-
2. **Append the new plan todo.** Append a new line to the end of the `## Todos` section:
|
|
136
|
-
|
|
137
|
-
```
|
|
138
|
-
- [ ] Execute [<versionLabel>](./<planFilename>)
|
|
139
|
-
```
|
|
140
|
-
|
|
141
|
-
3. **Missing section fallback.** If the `## Todos` section does not exist (legacy assignment predating this convention), insert it immediately after `## Acceptance Criteria` with a short guidance HTML comment followed by the new todo line. Match the template used by `/create-assignment`.
|
|
142
|
-
|
|
143
|
-
Also update the assignment frontmatter `updated` timestamp.
|
|
144
|
-
|
|
145
|
-
## Step 5: Report to User
|
|
146
|
-
|
|
147
|
-
After writing the plan:
|
|
148
|
-
1. Summarize the plan (number of tasks, key decisions)
|
|
149
|
-
2. Note any open questions or risks that need human input
|
|
150
|
-
3. Suggest next step: begin implementing the first task, or run `/complete-assignment` when all work is done
|
|
151
|
-
|
|
152
|
-
**Remind the agent about recordkeeping during implementation:**
|
|
153
|
-
- Check off acceptance criteria in `assignment.md` as each one is completed, not in a batch at the end
|
|
154
|
-
- Append timestamped milestones to `progress.md` (separate append-only file) — not to `assignment.md`
|
|
155
|
-
- Use `syntaur comment <slug-or-uuid> "body" --type note|question|feedback` to add a comment to `comments.md`
|
|
156
|
-
- `assignment.md` is a live document — keep its status, todos, and acceptance checkboxes reflecting current state at all times
|
|
@@ -1,86 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: syntaur-protocol
|
|
3
|
-
description: This skill should be used when the user mentions "syntaur", "assignment", "project", works with files under ~/.syntaur/, references assignment.md, plan.md, handoff.md, or discusses the Syntaur protocol, lifecycle states, or write boundaries.
|
|
4
|
-
version: 0.1.0
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
# Syntaur Protocol Knowledge
|
|
8
|
-
|
|
9
|
-
You are working within the Syntaur protocol. Follow these rules at all times.
|
|
10
|
-
|
|
11
|
-
## Write Boundary Rules (CRITICAL)
|
|
12
|
-
|
|
13
|
-
You MUST respect file ownership boundaries. Violations will be blocked by the PreToolUse hook.
|
|
14
|
-
|
|
15
|
-
### Files you may WRITE directly:
|
|
16
|
-
1. **Your assignment folder** -- only the assignment you are currently working on:
|
|
17
|
-
- `assignment.md`, `plan*.md` (0 or more versioned plan files), `progress.md`, `scratchpad.md`, `handoff.md`, `decision-record.md`
|
|
18
|
-
- Path (project-nested): `~/.syntaur/projects/<project>/assignments/<your-assignment>/`
|
|
19
|
-
- Path (standalone): `~/.syntaur/assignments/<your-assignment-uuid>/` — folder named by UUID, `project: null`, `slug` display-only
|
|
20
|
-
2. **Shared resources and memories** at the project level:
|
|
21
|
-
- `~/.syntaur/projects/<project>/resources/<slug>.md`
|
|
22
|
-
- `~/.syntaur/projects/<project>/memories/<slug>.md`
|
|
23
|
-
3. **Your workspace** -- source code files within the workspace defined in your assignment's frontmatter (`workspace.worktreePath` or `workspace.repository`)
|
|
24
|
-
4. **Context file** -- `.syntaur/context.json` in the current working directory
|
|
25
|
-
|
|
26
|
-
### Files written only via CLI (never edit directly):
|
|
27
|
-
- `comments.md` (any assignment) — use `syntaur comment <slug-or-uuid> "body" --type question|note|feedback [--reply-to <id>]`. Never edit directly. Questions carry a `resolved` flag toggled in the dashboard.
|
|
28
|
-
- Another assignment's `## Todos` section — use `syntaur request <target> "text"` to append a todo annotated `(from: <source>)`.
|
|
29
|
-
|
|
30
|
-
### Files you must NEVER write:
|
|
31
|
-
1. `project.md` -- human-authored, read-only
|
|
32
|
-
2. `manifest.md` -- derived, rebuilt by tooling
|
|
33
|
-
3. Any file prefixed with `_` (`_index-*.md`, `_status.md`) -- derived
|
|
34
|
-
4. Other agents' assignment folders (except via the CLI-mediated channels above)
|
|
35
|
-
5. Any files outside your workspace boundary
|
|
36
|
-
|
|
37
|
-
## Current Assignment Context
|
|
38
|
-
|
|
39
|
-
If `.syntaur/context.json` exists in the current working directory, read it to determine:
|
|
40
|
-
- `projectSlug` -- which project you are working on
|
|
41
|
-
- `assignmentSlug` -- which assignment is yours
|
|
42
|
-
- `projectDir` -- absolute path to the project folder
|
|
43
|
-
- `assignmentDir` -- absolute path to your assignment folder
|
|
44
|
-
- `workspaceRoot` -- absolute path to your code workspace (if set)
|
|
45
|
-
|
|
46
|
-
## Protocol References
|
|
47
|
-
|
|
48
|
-
For detailed protocol information, read these files:
|
|
49
|
-
- **Protocol summary:** `${CLAUDE_PLUGIN_ROOT}/references/protocol-summary.md`
|
|
50
|
-
- **File ownership rules:** `${CLAUDE_PLUGIN_ROOT}/references/file-ownership.md`
|
|
51
|
-
|
|
52
|
-
## Lifecycle Commands
|
|
53
|
-
|
|
54
|
-
Use the `syntaur` CLI for state transitions and coordination:
|
|
55
|
-
- `syntaur assign <slug> --agent <name> --project <project>` -- set assignee
|
|
56
|
-
- `syntaur start <slug> --project <project>` -- pending -> in_progress
|
|
57
|
-
- `syntaur review <slug> --project <project>` -- in_progress -> review
|
|
58
|
-
- `syntaur complete <slug> --project <project>` -- in_progress/review -> completed
|
|
59
|
-
- `syntaur block <slug> --project <project> --reason <text>` -- block an assignment
|
|
60
|
-
- `syntaur unblock <slug> --project <project>` -- unblock
|
|
61
|
-
- `syntaur fail <slug> --project <project>` -- mark as failed
|
|
62
|
-
- `syntaur create-assignment "<title>" [--type <type>] [--project <slug> | --one-off]` -- create project-nested or standalone assignment
|
|
63
|
-
- `syntaur comment <slug-or-uuid> "body" --type question|note|feedback [--reply-to <id>]` -- append to `comments.md`
|
|
64
|
-
- `syntaur request <target> "text" [--from <source>]` -- append a todo to another assignment's `## Todos`
|
|
65
|
-
|
|
66
|
-
## Troubleshooting
|
|
67
|
-
|
|
68
|
-
If Syntaur state looks inconsistent (missing files, stale manifests, unexpected hook blocks), run `syntaur doctor` to diagnose. The `/doctor-syntaur` slash command wraps it and helps interpret results.
|
|
69
|
-
|
|
70
|
-
## Playbooks
|
|
71
|
-
|
|
72
|
-
Playbooks are user-defined behavioral rules stored in `~/.syntaur/playbooks/`. Each playbook is a markdown file with imperative rules that agents must follow. When you begin work on any assignment, read all playbook files and follow their directives. Playbooks take precedence over default conventions when they conflict.
|
|
73
|
-
|
|
74
|
-
```bash
|
|
75
|
-
ls ~/.syntaur/playbooks/*.md 2>/dev/null
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
## Conventions
|
|
79
|
-
|
|
80
|
-
- Assignment frontmatter is the single source of truth for state. `project` is the containing project slug (`null` for standalone); `type` is a classification validated against `config.md` `types.definitions` when present.
|
|
81
|
-
- Slugs are lowercase, hyphen-separated. For standalone assignments, the folder is named by UUID; `slug` is display-only.
|
|
82
|
-
- Always read `project.md` at the project level (when project-nested) before starting work.
|
|
83
|
-
- Append timestamped entries to `progress.md` as work lands — do NOT add a `## Progress` section to `assignment.md`.
|
|
84
|
-
- Record questions/notes/feedback via `syntaur comment` — never edit `comments.md` directly. Do NOT set status to blocked for questions.
|
|
85
|
-
- Use `syntaur request` to route work to another assignment.
|
|
86
|
-
- Commit frequently with messages referencing the assignment slug.
|
|
@@ -1,64 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: complete-assignment
|
|
3
|
-
description: Use when the user wants to write a Syntaur handoff, close the current session, and transition the assignment to review or completed.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Complete Assignment
|
|
7
|
-
|
|
8
|
-
Write a handoff for the current Syntaur assignment and transition it to `review` or `completed`.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
|
|
12
|
-
User arguments: `$ARGUMENTS`
|
|
13
|
-
|
|
14
|
-
If the user passed `--complete`, transition directly to `completed` only when all acceptance criteria are met AND all todos are either checked or marked superseded. Otherwise transition to `review`.
|
|
15
|
-
|
|
16
|
-
## Workflow
|
|
17
|
-
|
|
18
|
-
1. Read `.syntaur/context.json`. If it does not exist, tell the user there is no active assignment.
|
|
19
|
-
2. Read `<assignmentDir>/assignment.md` and evaluate every item in the `## Acceptance Criteria` section AND every item in the `## Todos` section. Superseded todos (marked `- [x] ~~...~~ (superseded by ...)`) count as resolved. If any acceptance criterion is unmet OR any todo is still `- [ ]` and not superseded, warn the user before proceeding.
|
|
20
|
-
2.5. Append a final entry to `<assignmentDir>/progress.md` (reverse-chron, newest first) under a new `## <ISO 8601 timestamp>` heading summarizing the final state of the work. Bump `entryCount` and `updated` in the frontmatter. Do NOT add a `## Progress` section to `assignment.md` — progress entries live exclusively in `progress.md` as of protocol v2.0.
|
|
21
|
-
3. Read `<assignmentDir>/handoff.md` and append a new handoff entry using the protocol format:
|
|
22
|
-
|
|
23
|
-
```markdown
|
|
24
|
-
## Handoff <N>: <ISO 8601 timestamp>
|
|
25
|
-
|
|
26
|
-
**From:** codex
|
|
27
|
-
**To:** human
|
|
28
|
-
**Reason:** <Why this handoff is happening>
|
|
29
|
-
|
|
30
|
-
### Summary
|
|
31
|
-
<One paragraph>
|
|
32
|
-
|
|
33
|
-
### Current State
|
|
34
|
-
- <What is working>
|
|
35
|
-
- <What is not working or still partial>
|
|
36
|
-
- <Acceptance criteria status: N of M met>
|
|
37
|
-
|
|
38
|
-
### Next Steps
|
|
39
|
-
- <Recommended follow-up actions>
|
|
40
|
-
|
|
41
|
-
### Important Context
|
|
42
|
-
- <Anything the next person needs to know>
|
|
43
|
-
```
|
|
44
|
-
|
|
45
|
-
4. Update the handoff frontmatter:
|
|
46
|
-
- set `updated` to the current timestamp
|
|
47
|
-
- increment `handoffCount`
|
|
48
|
-
5. Update acceptance criteria and todo checkboxes in `assignment.md` to match reality. Do NOT modify superseded todo lines (those matching `- [x] ~~...~~ (superseded by ...)`).
|
|
49
|
-
6. If `.syntaur/context.json` includes `sessionId`, mark that session as completed through the dashboard API:
|
|
50
|
-
|
|
51
|
-
```bash
|
|
52
|
-
curl -s -X PATCH "http://localhost:$(cat ~/.syntaur/dashboard-port 2>/dev/null || echo 4800)/api/agent-sessions/<session-id>/status" \
|
|
53
|
-
-H "Content-Type: application/json" \
|
|
54
|
-
-d '{"status":"completed","projectSlug":"<project-slug>"}'
|
|
55
|
-
```
|
|
56
|
-
|
|
57
|
-
7. Transition the assignment:
|
|
58
|
-
- `syntaur complete <assignment-slug> --project <project-slug>` when `--complete` is allowed
|
|
59
|
-
- otherwise `syntaur review <assignment-slug> --project <project-slug>`
|
|
60
|
-
8. Delete `.syntaur/context.json`.
|
|
61
|
-
9. Summarize:
|
|
62
|
-
- new status
|
|
63
|
-
- acceptance criteria met vs total
|
|
64
|
-
- any criteria still unmet or follow-up risk
|
|
@@ -1,49 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: create-assignment
|
|
3
|
-
description: Use when the user wants to create a new Syntaur assignment inside a project or as a one-off project plus assignment.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Create Assignment
|
|
7
|
-
|
|
8
|
-
Create a new Syntaur assignment from Codex.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
|
|
12
|
-
User arguments: `$ARGUMENTS`
|
|
13
|
-
|
|
14
|
-
Parse:
|
|
15
|
-
|
|
16
|
-
- First positional argument: assignment title
|
|
17
|
-
- `--project <slug>` required unless `--one-off`
|
|
18
|
-
- `--one-off` optional — creates a **standalone** assignment at `~/.syntaur/assignments/<uuid>/` with `project: null`. Folder named by UUID; `slug` is display-only. `--depends-on` is not permitted for standalone assignments.
|
|
19
|
-
- `--slug <slug>` optional
|
|
20
|
-
- `--priority <level>` optional, default `medium`
|
|
21
|
-
- `--type <type>` optional — classification such as `feature`, `bug`, `refactor`, `research`, `chore`. Defaults to `feature`. When `~/.syntaur/config.md` defines `types.definitions`, the CLI validates against that list.
|
|
22
|
-
- `--depends-on <slug[,slug...]>` optional (project-nested only)
|
|
23
|
-
- `--dir <path>` optional
|
|
24
|
-
|
|
25
|
-
If no title was provided, ask the user for it.
|
|
26
|
-
|
|
27
|
-
If neither `--project` nor `--one-off` was provided, look for `.syntaur/context.json` in the current working directory. If present, default the project to that context's `projectSlug` and tell the user you are using it.
|
|
28
|
-
|
|
29
|
-
## Workflow
|
|
30
|
-
|
|
31
|
-
1. Run one of:
|
|
32
|
-
- `syntaur create-assignment "<title>" --project <slug> [--slug <slug>] [--priority <level>] [--depends-on <slugs>] [--type <type>] [--dir <path>]`
|
|
33
|
-
- `syntaur create-assignment "<title>" --one-off [--slug <slug>] [--priority <level>] [--type <type>] [--dir <path>]`
|
|
34
|
-
2. If the command fails, report the error and stop.
|
|
35
|
-
3. Read the generated `assignment.md`.
|
|
36
|
-
4. Summarize:
|
|
37
|
-
- assignment slug (for standalone assignments, also report the UUID — the folder is named by UUID, not slug)
|
|
38
|
-
- project slug (or `null` for standalone)
|
|
39
|
-
- priority
|
|
40
|
-
- type
|
|
41
|
-
- location
|
|
42
|
-
- created files: `assignment.md`, `progress.md`, `comments.md`, `scratchpad.md`, `handoff.md`, `decision-record.md` (plan files are NOT scaffolded — they are created on demand by `plan-assignment`)
|
|
43
|
-
5. Remind the user:
|
|
44
|
-
- Progress entries go into `progress.md` via direct appends (not into `assignment.md`).
|
|
45
|
-
- Comments are appended via `syntaur comment <slug-or-uuid> "body" --type question|note|feedback` — never edit `comments.md` directly.
|
|
46
|
-
6. Suggest next steps:
|
|
47
|
-
- fill in the objective, context, acceptance criteria, and any initial todos in the `## Todos` section
|
|
48
|
-
- or run `plan-assignment` to create a plan file and auto-append a linked todo to `## Todos`
|
|
49
|
-
- run `grab-assignment` to claim it if work should begin now
|
|
@@ -1,73 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: grab-assignment
|
|
3
|
-
description: Use when the user wants to load a Syntaur assignment into context, create .syntaur/context.json, and register a Codex session. Works regardless of assignment status.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Grab Assignment
|
|
7
|
-
|
|
8
|
-
Load a Syntaur assignment into the current working context and register this Codex session.
|
|
9
|
-
|
|
10
|
-
**Grabbing is non-destructive.** It never fails because of status. Any status (`pending`, `in_progress`, `blocked`, `review`, `completed`, `failed`) can be grabbed — grabbing just sets up context and registers the session. Only a `pending` assignment additionally transitions to `in_progress`; any other status is left untouched.
|
|
11
|
-
|
|
12
|
-
## Arguments
|
|
13
|
-
|
|
14
|
-
User arguments: `$ARGUMENTS`
|
|
15
|
-
|
|
16
|
-
Parse:
|
|
17
|
-
|
|
18
|
-
- First positional argument: project slug
|
|
19
|
-
- Second positional argument: optional assignment slug
|
|
20
|
-
|
|
21
|
-
## Workflow
|
|
22
|
-
|
|
23
|
-
1. If `.syntaur/context.json` already exists in the current working directory, read it and warn that claiming another assignment will replace the active context.
|
|
24
|
-
2. Read the project entry files:
|
|
25
|
-
- `~/.syntaur/projects/<project-slug>/manifest.md`
|
|
26
|
-
- `~/.syntaur/projects/<project-slug>/project.md`
|
|
27
|
-
- `~/.syntaur/projects/<project-slug>/agent.md`
|
|
28
|
-
- `~/.syntaur/projects/<project-slug>/claude.md` if it exists
|
|
29
|
-
Note the `workspace` field in `project.md` frontmatter if present. This indicates which project/codebase grouping the project belongs to. When writing context to `.syntaur/context.json` (Step 8), include `"workspace": "<value>"` if the project has a workspace.
|
|
30
|
-
3. Discover assignments under `~/.syntaur/projects/<project-slug>/assignments/`. Do **not** filter by status — every assignment is grabbable.
|
|
31
|
-
4. If no assignment slug was provided:
|
|
32
|
-
- list assignments with title, priority, and current status (highlight `pending` ones as the default candidates)
|
|
33
|
-
- ask the user to choose unless there is exactly one obvious candidate
|
|
34
|
-
If a slug *was* provided, verify the directory exists. Its status does not matter; do not block on it.
|
|
35
|
-
5. Read the chosen assignment's `assignment.md` — its frontmatter for `status`, and its markdown body for the objective, acceptance criteria, and `## Todos` section (active todos indicate outstanding work and may link to plan files to execute). If `dependsOn` is non-empty, also read each dep's `handoff.md` AND `decision-record.md` to inherit upstream context and decisions.
|
|
36
|
-
6. Claim the assignment:
|
|
37
|
-
- Always: `syntaur assign <assignment-slug> --agent codex --project <project-slug>` (safe at any status; does not transition state)
|
|
38
|
-
- **Only if current status is `pending`**: `syntaur start <assignment-slug> --project <project-slug>` to transition it to `in_progress`. Skip this command for any other status — grabbing must not rewind a `review`, `completed`, or `failed` assignment.
|
|
39
|
-
If `syntaur assign` fails (e.g., project not found, invalid slug), report and stop. Do not treat a non-pending status as a failure.
|
|
40
|
-
7. If the assignment has no workspace configured, set `workspace.repository` and `workspace.worktreePath` to the current working directory so write boundaries are meaningful.
|
|
41
|
-
8. Create or merge `.syntaur/context.json` in the current working directory. If the file already exists, preserve its contents and layer the new assignment fields on top (never overwrite):
|
|
42
|
-
|
|
43
|
-
```json
|
|
44
|
-
{
|
|
45
|
-
"projectSlug": "<project-slug>",
|
|
46
|
-
"assignmentSlug": "<assignment-slug>",
|
|
47
|
-
"projectDir": "/absolute/path/to/project",
|
|
48
|
-
"assignmentDir": "/absolute/path/to/assignment",
|
|
49
|
-
"workspaceRoot": "/absolute/path/to/workspace",
|
|
50
|
-
"title": "<assignment title>",
|
|
51
|
-
"branch": "<workspace.branch or null>",
|
|
52
|
-
"grabbedAt": "<ISO 8601 timestamp>",
|
|
53
|
-
"sessionId": "<real-codex-session-id>",
|
|
54
|
-
"transcriptPath": "<absolute path to the matching rollout jsonl>"
|
|
55
|
-
}
|
|
56
|
-
```
|
|
57
|
-
|
|
58
|
-
9. Register the agent session using the REAL Codex session id and rollout path — never synthesize a UUID:
|
|
59
|
-
- Resolve both by running the plugin-shipped helper: `bash ./scripts/resolve-session.sh "$(pwd)"` (script lives at `platforms/codex/scripts/resolve-session.sh`; referenced via the same relative path used by other Codex hooks in `hooks.json`). Parse the two output lines: `session_id=<id>` and `transcript_path=<abs path>`. If the helper exits non-zero, stop and report "no matching Codex rollout for this cwd — aborting registration. Start a Codex session in this cwd first."
|
|
60
|
-
- Merge `sessionId` + `transcriptPath` into `.syntaur/context.json` (use `jq '. + {sessionId:$sid, transcriptPath:$tp}'` to preserve existing fields).
|
|
61
|
-
- Run: `syntaur track-session --project <project-slug> --assignment <assignment-slug> --agent codex --session-id <id> --transcript-path <path> --path <cwd>`
|
|
62
|
-
10. Summarize:
|
|
63
|
-
- assignment slug and title
|
|
64
|
-
- current status (call it out if the assignment was already past `pending` — e.g., "already in `review`, status unchanged")
|
|
65
|
-
- objective
|
|
66
|
-
- acceptance criteria
|
|
67
|
-
- active todos from the `## Todos` section (if any), including any plan files they link to
|
|
68
|
-
- workspace path
|
|
69
|
-
11. Suggest a next step appropriate to status:
|
|
70
|
-
- `pending` / `in_progress`: `plan-assignment`
|
|
71
|
-
- `blocked`: investigate `blockedReason`
|
|
72
|
-
- `review`: inspect the implementation and help verify acceptance criteria
|
|
73
|
-
- `completed` / `failed`: read the handoff; grab is probably for reference or reopen
|
|
@@ -1,61 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: plan-assignment
|
|
3
|
-
description: Use when the user wants a detailed implementation plan written as a versioned plan file for the current Syntaur assignment.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Plan Assignment
|
|
7
|
-
|
|
8
|
-
Create an implementation plan for the current Syntaur assignment. Plans are versioned files: the first is `plan.md`, later ones are `plan-v2.md`, `plan-v3.md`, etc. Each plan gets a linked entry in the `## Todos` section of `assignment.md`, and any prior active plan todo is marked superseded.
|
|
9
|
-
|
|
10
|
-
## Arguments
|
|
11
|
-
|
|
12
|
-
Optional notes from the user: `$ARGUMENTS`
|
|
13
|
-
|
|
14
|
-
## Workflow
|
|
15
|
-
|
|
16
|
-
1. Read `.syntaur/context.json` from the current working directory. If it does not exist, tell the user to claim an assignment first.
|
|
17
|
-
2. Read:
|
|
18
|
-
- `<assignmentDir>/assignment.md`
|
|
19
|
-
- `<assignmentDir>/comments.md` (if it exists — inherited questions / notes)
|
|
20
|
-
- `<projectDir>/project.md`
|
|
21
|
-
- `<projectDir>/manifest.md`
|
|
22
|
-
|
|
23
|
-
Per-project `agent.md` / `claude.md` were removed in v0.2.0. Repo-level
|
|
24
|
-
`CLAUDE.md` / `AGENTS.md` and `~/.syntaur/playbooks/` take their place;
|
|
25
|
-
read playbooks via `ls ~/.syntaur/playbooks/*.md`.
|
|
26
|
-
3. If the assignment depends on other assignments, read each dependency's `handoff.md` AND `decision-record.md` for upstream integration context and accepted decisions.
|
|
27
|
-
4. Explore `workspaceRoot` when it exists:
|
|
28
|
-
- inspect project structure
|
|
29
|
-
- find likely implementation files
|
|
30
|
-
- note conventions and architecture
|
|
31
|
-
5. Determine the next plan filename:
|
|
32
|
-
- List `<assignmentDir>/plan*.md`.
|
|
33
|
-
- If none exist, target is `plan.md` (version label: "plan").
|
|
34
|
-
- Otherwise pick the smallest `N >= 2` such that `plan-v<N>.md` does not exist (version label: `plan v<N>`).
|
|
35
|
-
6. Write `<assignmentDir>/<planFilename>` with standard plan frontmatter (`assignment`, `status: draft`, `created`, `updated`) and a body containing the sections below. If the file already exists (only possible for `plan.md` on first re-run), preserve frontmatter, flip `status` from `draft` to `in_progress`, update `updated`, and replace only the body.
|
|
36
|
-
7. Update `<assignmentDir>/assignment.md`:
|
|
37
|
-
- Find unchecked todos matching `- [ ] Execute [<label>](./plan*.md)`. Rewrite each as `- [x] ~~Execute [<label>](./<old-filename>)~~ (superseded by <versionLabel>)`. Never delete the old line.
|
|
38
|
-
- Append a new todo: `- [ ] Execute [<versionLabel>](./<planFilename>)`.
|
|
39
|
-
- If `## Todos` is missing (legacy assignment), insert it right after `## Acceptance Criteria` with a short guidance comment and the new todo line.
|
|
40
|
-
- Refresh the assignment frontmatter `updated` timestamp.
|
|
41
|
-
|
|
42
|
-
## Plan Contents
|
|
43
|
-
|
|
44
|
-
Write these sections:
|
|
45
|
-
|
|
46
|
-
1. Overview
|
|
47
|
-
2. Tasks
|
|
48
|
-
3. Acceptance Criteria Mapping
|
|
49
|
-
4. Risks and Open Questions
|
|
50
|
-
5. Testing Strategy
|
|
51
|
-
|
|
52
|
-
**Decision capture:** While planning, record meaningful choices (library picks, schema design, architectural calls, rejected alternatives) as numbered entries in `<assignmentDir>/decision-record.md` using `## Decision N: <short title>` with Status (proposed/accepted), Context, Decision, Consequences. Downstream assignments that depend on this one auto-load these on grab.
|
|
53
|
-
|
|
54
|
-
## Reporting
|
|
55
|
-
|
|
56
|
-
After writing the plan:
|
|
57
|
-
|
|
58
|
-
- summarize the number of tasks and key decisions
|
|
59
|
-
- call out open questions or risks
|
|
60
|
-
- note which plan filename was written and which prior plan (if any) was superseded
|
|
61
|
-
- remind yourself to keep `assignment.md` acceptance criteria + todos current during implementation, append milestones to `progress.md` (not `assignment.md`), and record comments via `syntaur comment <slug-or-uuid> "body" --type note|question|feedback`
|
|
@@ -1,102 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: syntaur-protocol
|
|
3
|
-
description: Use when the user mentions Syntaur, projects, assignments, files under ~/.syntaur/, assignment.md, plan.md, handoff.md, .syntaur/context.json, lifecycle states, or write boundaries.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Syntaur Protocol
|
|
7
|
-
|
|
8
|
-
You are working within the Syntaur protocol. Follow these rules at all times.
|
|
9
|
-
|
|
10
|
-
## Write Boundary Rules
|
|
11
|
-
|
|
12
|
-
Respect file ownership boundaries.
|
|
13
|
-
|
|
14
|
-
### Files you may write directly
|
|
15
|
-
|
|
16
|
-
1. Your assignment folder only:
|
|
17
|
-
- `assignment.md`
|
|
18
|
-
- `plan*.md` (0 or more versioned plan files, e.g., `plan.md`, `plan-v2.md`)
|
|
19
|
-
- `progress.md` (append timestamped entries, newest first; replaces the old `## Progress` body section)
|
|
20
|
-
- `scratchpad.md`
|
|
21
|
-
- `handoff.md`
|
|
22
|
-
- `decision-record.md`
|
|
23
|
-
- Path (project-nested): `~/.syntaur/projects/<project>/assignments/<your-assignment>/`
|
|
24
|
-
- Path (standalone): `~/.syntaur/assignments/<your-assignment-uuid>/` — folder named by UUID, `project: null`, `slug` display-only
|
|
25
|
-
2. Project-level shared files:
|
|
26
|
-
- `~/.syntaur/projects/<project>/resources/<slug>.md`
|
|
27
|
-
- `~/.syntaur/projects/<project>/memories/<slug>.md`
|
|
28
|
-
3. Workspace files inside the assignment's configured workspace root
|
|
29
|
-
4. `.syntaur/context.json` in the current working directory
|
|
30
|
-
|
|
31
|
-
### Files written only via CLI
|
|
32
|
-
|
|
33
|
-
- `comments.md` (any assignment) — use `syntaur comment <slug-or-uuid> "body" --type question|note|feedback [--reply-to <id>]`. Never edit directly.
|
|
34
|
-
- Another assignment's `## Todos` section — use `syntaur request <target> "text"` to append a todo annotated `(from: <source>)`.
|
|
35
|
-
|
|
36
|
-
### Files you must never write
|
|
37
|
-
|
|
38
|
-
1. `project.md`
|
|
39
|
-
2. `manifest.md`
|
|
40
|
-
3. Any file prefixed with `_`
|
|
41
|
-
4. Other agents' assignment folders (except via the CLI-mediated channels above)
|
|
42
|
-
5. Anything outside the current workspace boundary
|
|
43
|
-
|
|
44
|
-
## Current Assignment Context
|
|
45
|
-
|
|
46
|
-
If `.syntaur/context.json` exists in the current working directory, read it before making changes. Use it to determine:
|
|
47
|
-
|
|
48
|
-
- `projectSlug`
|
|
49
|
-
- `assignmentSlug`
|
|
50
|
-
- `projectDir`
|
|
51
|
-
- `assignmentDir`
|
|
52
|
-
- `workspaceRoot`
|
|
53
|
-
- `sessionId` if present
|
|
54
|
-
|
|
55
|
-
## Required Reading Order
|
|
56
|
-
|
|
57
|
-
When you are working on an existing assignment, read these in order:
|
|
58
|
-
|
|
59
|
-
1. `<projectDir>/manifest.md` (project-nested assignments only)
|
|
60
|
-
2. `<projectDir>/project.md` (project-nested assignments only)
|
|
61
|
-
3. `<assignmentDir>/assignment.md` — frontmatter now includes `project: <slug> | null` and `type: <classification> | null`
|
|
62
|
-
4. any `<assignmentDir>/plan*.md` files linked from active todos in the `## Todos` section
|
|
63
|
-
5. `<assignmentDir>/progress.md` (if present)
|
|
64
|
-
6. `<assignmentDir>/comments.md` (if present)
|
|
65
|
-
7. `<assignmentDir>/handoff.md`
|
|
66
|
-
|
|
67
|
-
## Lifecycle Commands
|
|
68
|
-
|
|
69
|
-
Use the `syntaur` CLI for state transitions and coordination:
|
|
70
|
-
|
|
71
|
-
- `syntaur assign <slug> --agent <name> --project <project>`
|
|
72
|
-
- `syntaur start <slug> --project <project>`
|
|
73
|
-
- `syntaur review <slug> --project <project>`
|
|
74
|
-
- `syntaur complete <slug> --project <project>`
|
|
75
|
-
- `syntaur block <slug> --project <project> --reason <text>`
|
|
76
|
-
- `syntaur unblock <slug> --project <project>`
|
|
77
|
-
- `syntaur fail <slug> --project <project>`
|
|
78
|
-
- `syntaur create-assignment "<title>" [--type <type>] [--project <slug> | --one-off]`
|
|
79
|
-
- `syntaur comment <slug-or-uuid> "body" --type question|note|feedback [--reply-to <id>]`
|
|
80
|
-
- `syntaur request <target> "text" [--from <source>]`
|
|
81
|
-
|
|
82
|
-
## Troubleshooting
|
|
83
|
-
|
|
84
|
-
If Syntaur state looks inconsistent (missing files, stale manifests, unexpected hook blocks), run `syntaur doctor` to diagnose. Use `--json` for structured output.
|
|
85
|
-
|
|
86
|
-
## Conventions
|
|
87
|
-
|
|
88
|
-
- Assignment frontmatter is the single source of truth. `project` is the containing project slug (`null` for standalone); `type` is a classification validated against `config.md` `types.definitions` when present.
|
|
89
|
-
- Slugs are lowercase and hyphen-separated. For standalone assignments the folder is named by UUID; `slug` is display-only.
|
|
90
|
-
- Update acceptance criteria and `## Todos` checkboxes as work lands, not only at the end.
|
|
91
|
-
- Append timestamped entries to `progress.md` after meaningful milestones. Do NOT add a `## Progress` section to `assignment.md`.
|
|
92
|
-
- Record questions/notes/feedback via `syntaur comment` — never edit `comments.md` directly. Do NOT set status to blocked for questions.
|
|
93
|
-
- When requirements shift, supersede the prior plan todo (`- [x] ~~...~~ (superseded by plan-v<N>)`) instead of rewriting the old plan file.
|
|
94
|
-
- Write handoffs with enough context for another agent or human to continue cleanly.
|
|
95
|
-
- Use `syntaur request` to route work to another assignment.
|
|
96
|
-
|
|
97
|
-
## References
|
|
98
|
-
|
|
99
|
-
Read these only when you need the detailed rules or directory layout:
|
|
100
|
-
|
|
101
|
-
- `../../references/protocol-summary.md`
|
|
102
|
-
- `../../references/file-ownership.md`
|