From geas
Mission intake gate — collaborative exploration to freeze a mission spec. One question at a time, section-by-section approval.
npx claudepluginhub choam2426/geasThis skill uses the workspace's default tool permissions.
Before any mission execution, run this gate to freeze the mission specification.
Transforms raw ideas into structured missions with milestones, features, agent types, constraints, and generates exact maestro handoff command for first agent.
Builds manifests to plan work, scope tasks, spec requirements, and break down complex tasks before coding. Converts needs into deliverables, invariants, and verification criteria for features, bugs, refactors.
Turns vague goals into structured requirements.md via systematic interview across business/user/tech axes, extraction, and cross-check. Outputs for /blueprint in greenfield/feature/refactor/bugfix formats.
Share bugs, ideas, or general feedback.
Before any mission execution, run this gate to freeze the mission specification.
Missions arrive as natural language with hidden assumptions, ambiguous scope, and implicit constraints. This gate surfaces those gaps through collaborative exploration and produces an immutable mission spec file (.geas/missions/{mission_id}/spec.json) before the team starts building.
Read the raw mission. Determine if it's too large for a single spec:
Ask the user questions to surface hidden assumptions. Use the AskUserQuestion tool.
Rules:
Question categories:
If the user says "just build it" at any point — respect that, set readiness_override: true, fill best-effort values for unchecked items, and proceed.
When requirements are clear enough, present 2-3 scope/approach options:
Option A (recommended): CLI-only with SQLite — simple, fast, self-contained
Option B: CLI + REST API — extensible but more complexity
Option C: TUI with ratatui — richer UX but harder to test
Present each seed section to the user and get explicit approval before moving on:
As each section is approved, mark it in the completeness checklist.
Check the completeness checklist — all items must be true:
mission: approveddomain_profile: selectedmode: selected (lightweight / standard / full_depth)done_when: approved (one-sentence success definition)acceptance_criteria: approved (>= 3 items)scope_in: approved (>= 1 item)scope_out: approved (>= 1 item)target_user: approvedconstraints: approvedaffected_surfaces: identifiedDetermine the next mission ID by scanning .geas/missions/mission-*/ directories — pick the next sequential number (mission-001, mission-002, etc.).
Create the mission directory structure:
mkdir -p .geas/missions/{mission_id}/tasks .geas/missions/{mission_id}/evidence .geas/missions/{mission_id}/contracts .geas/missions/{mission_id}/packets .geas/missions/{mission_id}/decisions/pending .geas/missions/{mission_id}/evolution .geas/missions/{mission_id}/phase-reviews
Write .geas/missions/{mission_id}/spec.json following the schema at schemas/mission-spec.schema.json. Include:
"version": "1.0", "artifact_type": "mission_spec", "artifact_id": "mission-{n}""producer_type": "orchestration_authority", "mission_id": "mission-{n}""created_at" (actual UTC timestamp)Always include the source field:
"full_intake" — complete Socratic exploration with user"quick_intake" — user skipped detailed intake"existing_project" — auto-generated for existing project onboardingShow the user a detailed mission briefing:
═══════════════════════════════════════════════════
MISSION SPEC — {mission_id}
═══════════════════════════════════════════════════
Mission: <refined mission statement>
Done when: <one-sentence success definition>
Domain: <domain_profile>
Mode: <lightweight | standard | full_depth>
Target user: <who>
─── SCOPE ─────────────────────────────────────────
IN:
• <feature/capability 1>
• <feature/capability 2>
• ...
OUT:
• <explicitly excluded 1>
• <explicitly excluded 2>
• ...
─── ACCEPTANCE CRITERIA ───────────────────────────
1. <observable, falsifiable criterion>
2. <observable, falsifiable criterion>
3. <observable, falsifiable criterion>
...
─── CONSTRAINTS ───────────────────────────────────
• <technical or business constraint>
• ...
─── AFFECTED SURFACES ─────────────────────────────
• <area/path/system expected to be touched>
• ...
─── RISK NOTES ────────────────────────────────────
• <initial risk observation>
• ...
(none identified = "No significant risks identified at intake")
─── ASSUMPTIONS ───────────────────────────────────
• <confirmed assumption>
• ...
─── AMBIGUITIES ───────────────────────────────────
• <deferred ambiguity + rationale>
• ...
(none = "All ambiguities resolved during intake")
═══════════════════════════════════════════════════
Ask: "Does this capture your intent? Any changes before we start?" If confirmed → seed is frozen. Proceed to execution. If changes → update and re-confirm.
For lightweight missions (adding a feature to an existing project):
.geas/missions/{mission_id}/spec.json — both new and existing projects..geas/missions/mission-001/spec.json with source: "full_intake".geas/missions/mission-001/spec.json with source: "existing_project".geas/missions/mission-{n}/spec.json with source: "quick_intake" or "full_intake"schemas/mission-spec.schema.json