Prompt file imported from AGIBuild/Sinaris (.cursor/commands/sx-proposal.md). Copyright stays with the author.

Sinaris Proposal

Use the sinaris-proposal skill to capture a new demand for an already-published project before phase design. Proposal is not more recommended than Guide; use Guide for new projects or missing/incomplete project context.

Existing project demand: Proposal -> Design -> Apply -> Evaluator

Host Agent Mode Boundary

Do not enter any host Agent Plan mode while running this Sinaris workflow. Continue through Sinaris commands and workflow gates only.

Start by reading confirmed context and the current proposal board:

sinaris guide context --format json
sinaris proposal status --detail --format json

Empty Guide Context Handoff

If sinaris guide context --format json reports an empty project context, do not reshape the user's proposal demand into Guide ICOD questions.

Correct behavior:

• Preserve the user's original demand verbatim as the pending proposal demand.
• Tell the user that project-level context is missing and must be completed before this proposal can be recorded.
• Switch to Guide only to capture project-level context: project goal, target users, business value, current product state, first-scope boundary, and milestone roadmap.
• Do not ask implementation or architecture questions about the pending proposal during Guide. For example, do not ask whether the pending demand should use a Hub backend proxy, CLI proxy, or frontend bridge.
• After Guide is published, return to this original /sx-proposal demand and continue the Proposal One Question Loop from ## Problem.

Guide-first is a temporary context prerequisite, not a replacement for Proposal and not permission to enter Design or Apply.

Print the on-disk template to learn the section contract and target path:

sinaris proposal template

Use deferred persistence: the discussion phase must not create .sinaris/proposals/** files or DB rows. First use the One Question Loop in chat, then output a Final Proposal Summary and ask for confirmation.

Use the One Question Loop: ask exactly one question per turn, write the user's answer into one section, and only then move on to the next section. Do not bundle multiple questions in the same turn and do not draft the whole markdown in one shot before the user has answered.

Do not show internal enum names in user-facing proposal questions. For context-impact decisions, ask with plain labels such as "Directly continue", "Use as design input", "Update the plan first", and "Resolve the conflict first"; map the selected option to the required markdown value only when writing the proposal file.

After the user confirms the Final Proposal Summary, allocate the official id/path and then author the markdown with your file Write tool:

sinaris proposal next --slug <slug> --format json

The body must contain these sections: ## Problem, ## Observed Context, ## Assumptions, ## Options (with one Recommended: line), ## Recommended Design Direction, ## Decision Summary, ## Impact, ## Context Impact Assessment, ## Risks, ## Open Questions, and ## Next Step. ## Decision Summary is required when status: Designed. ## Context Impact Assessment must include Action: <None | CreateMilestone | UpdateMilestone | UpdateProject | CreateDecision | Multiple>.

Validate before publishing — exit code is non-zero on validation failures:

sinaris proposal check --path .sinaris/proposals/<slug>/proposal.md --stage designed --format json

Publish once check passes. The CLI rewrites status only through workflow commands; do not write Applied or Rejected into the markdown:

sinaris proposal publish --path .sinaris/proposals/<slug>/proposal.md --format json

If the proposal needs a milestone after publish:

sinaris milestone next --slug <slug> --after <milestone-id> --format json

When ContextAction=CreateMilestone or ContextAction=UpdateMilestone, author .sinaris/milestones/mN/milestone.md with the approved proposal scope, then run:

sinaris milestone save --path .sinaris/milestones/mN/milestone.md --source-proposal <proposal-id> --format json
sinaris proposal prepare-design <proposal-id> --format json

Use proposal assign-milestone <id> --milestone <milestone-id> only when ContextAction=None and the proposal simply belongs to an existing milestone; it is not for ContextAction=CreateMilestone or ContextAction=UpdateMilestone.

When the user explicitly enters Design Mode for a Designed proposal, switch to the sinaris-design skill and link the proposal during phase save:

sinaris phase save \
  --path .sinaris/milestones/m<seq>/p<n>-<slug>.md \
  --milestone <milestone-id> \
  --proposal <proposal-id> \
  --format json

To withdraw a proposal that has not been linked to a phase:

sinaris proposal reject <id> --reason "<why>"

Do not edit .sinaris/charter.md or .sinaris/context/*.md from this command — those belong to Guide. Milestone markdown may only be authored when the accepted proposal requires milestone save --source-proposal.