syntaur 0.3.3 → 0.4.1

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.
Files changed (33) hide show
  1. package/README.md +236 -49
  2. package/dist/index.js +886 -162
  3. package/dist/index.js.map +1 -1
  4. package/package.json +9 -2
  5. package/platforms/claude-code/.claude-plugin/plugin.json +1 -5
  6. package/platforms/claude-code/agents/syntaur-expert.md +30 -18
  7. package/platforms/claude-code/commands/complete-assignment/complete-assignment.md +20 -0
  8. package/platforms/claude-code/commands/create-assignment/create-assignment.md +20 -0
  9. package/platforms/claude-code/commands/create-project/create-project.md +20 -0
  10. package/platforms/claude-code/commands/grab-assignment/grab-assignment.md +20 -0
  11. package/platforms/claude-code/commands/plan-assignment/plan-assignment.md +20 -0
  12. package/statusline/statusline.sh +224 -0
  13. package/vendor/syntaur-skills/LICENSE +21 -0
  14. package/vendor/syntaur-skills/README.md +43 -0
  15. package/vendor/syntaur-skills/skills/complete-assignment/SKILL.md +146 -0
  16. package/vendor/syntaur-skills/skills/create-assignment/SKILL.md +72 -0
  17. package/vendor/syntaur-skills/skills/create-project/SKILL.md +56 -0
  18. package/vendor/syntaur-skills/skills/grab-assignment/SKILL.md +158 -0
  19. package/vendor/syntaur-skills/skills/plan-assignment/SKILL.md +137 -0
  20. package/vendor/syntaur-skills/skills/syntaur-protocol/SKILL.md +119 -0
  21. package/vendor/syntaur-skills/skills/syntaur-protocol/references/file-ownership.md +67 -0
  22. package/vendor/syntaur-skills/skills/syntaur-protocol/references/protocol-summary.md +82 -0
  23. package/platforms/claude-code/hooks/statusline.sh +0 -110
  24. package/platforms/claude-code/skills/complete-assignment/SKILL.md +0 -155
  25. package/platforms/claude-code/skills/create-assignment/SKILL.md +0 -67
  26. package/platforms/claude-code/skills/grab-assignment/SKILL.md +0 -202
  27. package/platforms/claude-code/skills/plan-assignment/SKILL.md +0 -156
  28. package/platforms/claude-code/skills/syntaur-protocol/SKILL.md +0 -86
  29. package/platforms/codex/skills/complete-assignment/SKILL.md +0 -64
  30. package/platforms/codex/skills/create-assignment/SKILL.md +0 -49
  31. package/platforms/codex/skills/grab-assignment/SKILL.md +0 -73
  32. package/platforms/codex/skills/plan-assignment/SKILL.md +0 -61
  33. 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`