Menu
Use when creating and writing an Ito change proposal (new change or existing change id). Delegates to Ito CLI instruction artifacts.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Implement Ito Lite markdown changes by reading proposal/spec/design/tasks artifacts and updating manual task statuses. Use when applying or executing a prompt-only Ito Lite change without the ito CLI.
Archive completed Ito Lite changes by manually merging spec deltas into current specs and moving the change to archive. Use after implementation and verification when no ito CLI is available.
Create prompt-driven Ito Lite change proposal packages in markdown. Use for drafting proposal.md, spec deltas, optional design.md, and tasks.md without the ito CLI or validation executable.
Review Ito Lite markdown proposal packages before implementation. Use to check proposal.md, spec deltas, design.md, and tasks.md for consistency, risk, testability, and manual validation without the ito CLI.
Initialize a markdown-only Ito Lite workspace with no executables. Use when setting up prompt-driven change proposals, creating .ito-lite/project.md, or preparing a repo for Ito-style specs, changes, and tasks without the ito CLI.
Coordinate the prompt-only Ito Lite workflow for proposals, specs, tasks, reviews, implementation, and archive without the ito executable. Use when the user asks for Ito-style planning, change proposals, lightweight specs, or markdown-only change management.
| name | ito-proposal |
| description | Use when creating and writing an Ito change proposal (new change or existing change id). Delegates to Ito CLI instruction artifacts. |
Collaborate with the user to understand their intent, then create a change and generate proposal artifacts.
If the user already provided a change ID, skip to Step 4 (Generate artifacts) — the change already exists.
If the request arrived from ito-proposal-intake, ito-fix, or ito-feature, treat the intake summary as the shared understanding. Ask only the smallest number of follow-up questions needed to unblock change creation.
Step 0: Understand the change (do this first)
Do NOT jump straight into creating files. Confirm the change shape first:
ito-proposal-intake before continuing.ito-brainstorming instead of looping back into intake.Only proceed to Step 1 once you and the user agree on what the change is and why it matters.
Step 0.5: Consult the Ito wiki when present
If .ito/wiki/index.md exists, read it early to find relevant topic pages, specs, modules, research syntheses, archived-change summaries, and workflow notes.
.ito/wiki/ topic page, index.md, log.md, or _meta/status.md so future planning can reuse it.Step 1: Choose a schema
ito agent instruction schemas
Recommend the best-fit schema for the request shape:
If the user has no preference, recommend the best fit rather than defaulting automatically to spec-driven. Keep spec-driven as the safe fallback when the request still needs the full proposal pipeline.
Step 2: Confirm the module (mandatory gate)
⛔ Do NOT create any change scaffolding until the user has confirmed their module choice.
ito list --modules to show available modules and sub-modules.ito create module "<name>")ito create sub-module "<name>" --module <parent-id>)000. Always ask.Step 3: Create the change
After the user confirms the module:
# For a module:
ito create change "<change-name>" --module <module-id> --schema <schema>
# For a sub-module:
ito create change "<change-name>" --sub-module <NNN.SS> --schema <schema>
Step 4: Generate artifacts
ito agent instruction proposal --change "<change-id>"
ito agent instruction specs --change "<change-id>"
ito agent instruction design --change "<change-id>"
ito agent instruction tasks --change "<change-id>"
Follow the printed instructions for each artifact exactly.
Testing Policy
ito agent instruction proposal|apply.