autonomous-readiness

Solid

Decide whether an already-defined project is ready to boot an unattended overnight run, and refuse until it is. Reads the project's own definition artifacts through the shared definition-completeness reader, emits a per-criterion ledger with a BOOT or NOT-READY verdict naming every missing item, and returns NOT-READY when a declared runtime surface has no evidence adapter rather than booting blind. It reports and routes: it never answers a criterion on the operator's behalf, never records a decision as user input, and a BOOT verdict never substitutes for plan approval. Use before handing a night to autonomous-run. Do not use to approve a plan (use approve-plan), to drive the run itself (use autonomous-run), to view a run already in flight (use autonomous-board), or to shape a fuzzy objective before a task exists (use problem-framing).

AI & Automation 6 stars 0 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
28
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

Act as the boot gate for the autonomous delivery track, deciding whether a project is defined well enough to hand a night to `autonomous-run`, and refusing until it is. Goal: Produce a per-criterion readiness ledger and one verdict, BOOT or NOT-READY, over an already-defined project. The gate exists because `autonomous-run` checks only that a plan is approved and waved; it never asks whether the product context behind that plan is complete, so an underspecified project could reach a detached night and spend it stalling. This command asks first. It reports and routes; it decides nothing on the operator's behalf and it writes no product code. Mandatory context bootstrap (before any output): <!-- shared:mandatory-context-bootstrap --> - Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first: - `## LLM execution contract` - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mappings.md` and needed only for non-Claude-Code tools) - `## Global output contract` (including **Adaptive handoff** and **Mode selection rule**) - `## Cross-cutting workflow guardrails` - **Bootstrap tiers (ADR-0025):** the light-weight commands (`branch-commit`, `what-next`, `where-we-at`, `slice-closure`, `compact-task-memory`) may skip `## Editor mode policy` good-fits lists and `## Cross-cutting workflow guardrails` sequencing heuristics, reading only the mode definitions and the core guardrail rules (routing memory, command-less input...

Details

Author
Mozurok
Repository
Mozurok/fhorja.dev
Created
1 months ago
Last Updated
5 days ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

autonomous-run

Drive an approved, waved IMPLEMENTATION_PLAN through the autonomous delivery track. A thin dispatcher over the existing fleet primitives (the Workflow tool, implement-approved-slice as single writer) bounded by two human gates and a runtime governor. Runs verifiable slices with little supervision and emits PROPOSED slice diffs only; it never merges. Use when the plan is approved (approve-plan), autonomous-readiness returned BOOT, broken into dependency-ordered waves, and the maintainer wants the work between the two gates run hands-off in a single supervised session. Do not use when the plan is not yet approved (run approve-plan), readiness is absent or NOT-READY (run autonomous-readiness), the work is a single slice (use implement-approved-slice), the run would need to auto-merge (never allowed; a human always performs the merge), or cross-session durable resume (restart and re-attach) is required (out of v1 scope; a detached continuous background session is in scope via the opt-in background mode).

6 Updated 5 days ago
Mozurok
AI & Automation Solid

autonomous-board

Read-only board-of-record view for an autonomous-run task (ADR-0044 D7, wos/autonomous-track.md). Renders the run as the spec, the IMPLEMENTATION_PLAN waves and slices, and the TASK_STATE phases mapped to to-do / in-progress / escalated / proposed / done columns, sourced only from the Fhorja task artifacts. No external work tracker; no writes. Use when the maintainer wants a single-glance status of an autonomous run without opening every artifact. Do not use to change state (use sync-task-state), to assess a normal multi-slice task (use where-we-at), or to route the next command (use what-next).

6 Updated 5 days ago
Mozurok
AI & Automation Listed

autonomy-readiness

Evaluate whether an autonomous, always-on, scheduled, headless, or self-evolving workflow is ready to run safely. Use when the user says "autonomy readiness," "activation gate review," "is this workflow ready to run autonomously," "go/no-go autonomy," "always-on readiness," "headless operation review," or "/agent-collab:autonomy-readiness." Also offer this proactively before enabling background agents, recurring automations, auto-merge/self-evolution, external actions, unattended host runs, or any workflow that can continue without a human watching.

0 Updated today
sumitake