Conversation
Signed-off-by: akoziar <koziar.artem@gmail.com>
The task commands now run a read-only architect consultant bound to the task and conversation, so requirements, specifications, and implementation decisions are grounded before they reach a human gate. Material advice is persisted with the task; it never substitutes for human approval or independent review. Also adds decision-bound continuation: once a stage is authorized, routine file work and recoverable technical failures proceed without re-asking, while real decisions, scope changes, and acceptance gates still stop and wait for the user. Local pre-commit bypassed: the same four baseline test failures reproduce on the unchanged base (761 tests pass) and are unrelated to this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A task command no longer asks whether to continue into the next stage and no longer starts it. It ends the stage in the task files, reports what was produced and what is still open, and hands the user one command line to paste into a new chat. The next stage then resumes from the recorded files rather than from a long conversation. The command line is rendered in the host's own invocation syntax, mirroring how the user invoked the current command, so Claude Code shows `/rosetta:task-spec TASK-0001` and never another host's prefix. That rule lives in its own reference so the read-only listing path can apply it without loading a write procedure. Decision-bound continuation is bounded accordingly: it authorizes work inside the invoked stage only, never across its boundary. Local pre-commit bypassed with the user's permission: the same four baseline test failures reproduce on the unchanged base (761 tests pass) and are unrelated to this change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this proposal
I am looking at Rosetta from the user's side: how easy and comfortable it is for
a developer to actually work with it day to day.
This proposal came out of Igor Liudiak's lecture on using Rosetta. The lecture is
genuinely useful — after it you know which commands exist and why you would use
them. What it does not answer is the next question: what do I actually do, and in
what order, with my everyday tasks, if I do not want to learn every Rosetta
command first? People do not like learning new things, and today the entry point
into Rosetta asks them to.
So the goal here is one simple flow with three understandable steps — business
requirements, specification and architecture, implementation — plus one command
to see all tasks and their state, so several tasks can be in flight at once
without losing track of any of them.
Rosetta has a rich set of skills and workflows, but developers still need to work out which ones to use for everyday tasks. This draft proposes four entry points that make the daily workflow clear while reusing Rosetta's existing capabilities.
rosetta:tasks-listrosetta:task-definerosetta:task-specrosetta:task-implementBefore: choose and connect individual workflows, then carry context between conversations.
With this proposal: start with a task ID and follow the next step; requirements, approvals, and progress survive new chats. Different tasks can move through different stages in separate terminals. Use separate worktrees when parallel implementations touch shared files.
Task records and plans live in
plans/<TASK_ID>/; requirements live indocs/REQUIREMENTS/<TASK_ID>/. This is optional: existing workflows and small tasks without documentation keep their current behavior. Epic management, external tracker integration, and parallel execution orchestration are outside this proposal.Architect consultation and fewer interruptions
The three task commands now run a read-only architect as a background consultant, bound to that task and conversation. It reviews requirements for gaps before they are agreed, advises on architecture and the plan, and helps diagnose failures during implementation. Its advice is recorded with the task as execution evidence — it never counts as human approval or as the independent review.
Alongside it, the commands carry a scoped continuation rule: once a stage is authorized, routine file work, progress recording, and recovery from a diagnosed technical failure continue without asking again. Real decisions, new scope, changed behavior, stale approvals, and every acceptance or safety gate still stop and wait for the person. The scope is only what the user or the invoking workflow supplied, and it is dropped when the invocation ends.
One stage per chat
A command does not ask whether to continue into the next stage and does not start it. It ends the stage in the task files, reports what was produced and what is still open, and gives one command line to paste into a new chat — rendered in the host's own invocation syntax, so Claude Code shows
/rosetta:task-spec TASK-0001and never another host's prefix. The next stage resumes from the recorded files instead of a long conversation, which is also what makes separate terminals per task practical. A finished, accepted task needs no new chat, and a decision that comes up mid-stage is still raised in place.Validation: Rosetta's formal prompt validation found no blockers; its findings were applied. 32 focused tests and the 1441-test main suite pass. Both plugin profiles were regenerated for 14 targets. The full generator suite has four existing failures reproduced on the unchanged base (761 tests pass); they concern hook bundles, agent model names, and a profile description string, none of them touched here. Local pre-commit was bypassed for this draft because of those baseline failures. Live multi-chat execution remains to be validated. Most changed files are generated plugin copies.
Feedback requested: does this provide a clear everyday starting point, and are the four command boundaries right?
🤖 Generated with Claude Code