run

Devora

User input

$ARGUMENTS

1. Run devora status --json, devora govern status --json, devora govern drift --json, devora skill list --json, and devora quality status --json. Use read-only devora doctor --json on project import, unexplained inconsistent state, or an explicit health check—not as a mandatory preflight for every routine task. Read .devora/project.md, the relevant files under .devora/context/, the current Change when present, and only the project Skills relevant to the request. Resolve evidence drift before relying on affected conclusions. Run devora quality scan --json when no quality baseline exists or the project's test/tool setup materially changed; this discovers declared capabilities without executing project code.
2. Route by intent without asking the user to choose a mode when the request is clear:
   • Governance: inspect code and documents without modifying business code. Run devora govern scan --json on import, material structure changes, or an unfamiliar area; its sources, modules, and risks only route inspection. Use project/module/focused profiles according to breadth. Batch evidence into Findings and use --relation conflicts_with:<id>, depends_on:<id>, or supersedes:<id> when conclusions interact. Assign L1-L4 to risks and list required test IDs with --validation; every L3/L4 Finding needs a devora govern control. Put organization policy in devora govern policy or a reviewed policy-sync source; use --mandatory only for a project Finding. Conclude direct evidence, ask only material unknowns, and continue until relation blockers, missing controls, and missing_targets are empty. Do not repeat a remembered clarification unless its revisit time is due. devora govern complete also verifies that business files did not change during Governance and seals local evidence for later drift checks.
   • Capability building: search installed Skills, approved catalogs, and upstream repositories first; review scope, license, provenance, revision, instructions, and security before devora skill install. If none fits, use skill-creator when available, or devora skill create for a concise entry point. Run devora skill validate with Governance --scope, material --finding/--control dependencies, and observable --scenario id=description cases. Record each with devora skill scenario; failed, blocked, stale, or pending Skills are not active. Mandatory rules are captured automatically and invalidate Skills when they change. Do not create a Change for governance- or capability-only work.
   • Development: continue with the Change rules below. If required context or capability is missing, temporarily govern or build the Skill and then resume the original task.
3. For development, directly decide whether the request continues the active Change or starts a new one. Resolve missing Governance or capability state, then resume the same request. Confirm module candidates against evidence. Select active Skills, allowed paths, protected paths, quality policy types, and any parent Change; describe pre-existing partial work with --baseline-note. Use repeatable --type values such as frontend, api, database, authorization, dependency, infrastructure, or cross-repository when paths alone do not express the mixed Change. L3/L4 Changes require --allow. Start with devora change start <name> --module <module> --scope <scope> --skill <skill> --allow <path> --exclude <protected-path> --type <type> --json, repeating options as needed. If the request draws materially from PRDs, files, directories, URLs, UI images/designs, tickets, or API material, register only the sources actually read with devora change source record. Track source-specific conflicts or gaps with devora change requirement clarify, resolve them from explicit evidence, update change.md, and confirm the unified baseline plus observable acceptance criteria before Build. Trivial prompt-only work keeps the default not_required baseline. When a captured company rule or exception changes, inspect it and use devora change policy-refresh --reason <reason> only after explicitly deciding to adopt it; this resets validation and approval state. A cross-repository Change must register its producer/consumer repositories, create a proposed versioned devora change contract, and advance it with actor/evidence through contract-status before release.
4. For ordinary low-risk work, keep only change.md: implement, run the generated minimum matrix, run devora change audit, record material results with devora change validate, run devora quality gate, update the outcome, then close as completed.
5. For complex, high-risk, cross-module, or approval-sensitive work, follow Design, Build, and Review. If the user expands scope or new evidence raises risk, run devora change expand --reason <reason> with only the added scopes, Skills, allowed paths, or protected paths; it preserves the original baseline and adds high-risk artifacts. Never use expansion to legitimize an accidental out-of-scope edit.
6. Before closing, promote only reusable implementation conclusions into the relevant Governance scope and update/revalidate affected Skills. Record material incident or Review learning with devora govern feedback, then close it with feedback-status only when resolution evidence exists. Retire policies, revoke exceptions, and advance contracts through their explicit lifecycle commands instead of deleting or overwriting their history. Complete the resulting governance/capability work, then resume the same Change; do not turn task-specific detail into global context.
7. Use devora doctor --profile pilot --fail-on-issues --json only when the user or release process asks to accept a representative project pilot; it expects a clean resting state after at least one completed Change. Stop only for a material decision that cannot be inferred safely, a concrete external blocker, or an explicit approval gate. Preserve unrelated user changes and never broaden task scope merely because governance found a legacy issue.