autonomous-work

Files (1)

• SKILL.md

SKILL.md (first lines)

# Autonomous work

Confirm either an explicit autonomous-run request or an active user-authorized tracked goal before starting.
An active user-authorized tracked goal supplies run authority within its objective; an ordinary request for a fix, answer, draft, plan, or review does not.
Reassess activation when the task changes; having this skill in context does not activate it for the next task.
Respect paused, blocked, and budget-limited states and the harness's resume requirements.
An inactive goal is saved state, not permission to continue.

This skill owns run authority, persistence, required acceptance order, resumable state, and stopping.
[Work-selection](../work-selection/SKILL.md) owns next-action selection, dependency justification, reassessment, and scouting within the authorized task.
Activity-specific skills own their procedures; goal tools own status changes and budgets.
Autonomy authorizes persistence within the task, not a different activity or additional effects.

u got this buddy <3 i believe in u

## Establish authority and acceptance

Read the request, governing requirements, repository guidance where applicable, and current artifacts or evidence.
Identify the permitted activity, protected work, acceptance criteria, and effects before starting:

- **Implementation:** deliver the requested behavior through its intended consumer and required checks, within the authorized change scope.
- **Research:** answer the agreed question from evidence, distinguishing supported conclusions, conflicting sources, and unresolved uncertainty.
- **Writing:** produce or revise the agreed artifact against its brief and factual requirements; drafting does not authorize publication.
- **Planning:** produce a usable, evidence-grounded plan with dependencies and uncertainties; planning does not authorize execution.
- **Review:** complete the agreed inspection and substantiate findings; review does not authorize repairs.

Do not invent human approval or substitute a different activity for an unmet result.
A review-ready artifact can complete a draft request, but not a goal that explicitly requires the user's approval.
Do not ask again for investigation, edits, or repairs the task already authorizes; a failed attempt does not impose a one-attempt limit.

Derive remaining outcomes from the full governing request, not worker assignments, progress summaries, or optional cleanup.
Narrowing an investigation does not narrow the goal or milestone.
In the required acceptance order, identify the next unmet condition and its observable result, current evidence, missing work, and cheapest realistic check.
Use the task's actual criteria: sources and reasoning for research, the brief for writing, feasibility for planning, inspection evidence for review, and consumer behavior for implementation.
Keep each condition open until its required evidence passes; an explicitly scoped feasibility or component result does not complete downstream obligations.

Use existing goal, plan, or session state rather than creating another tracking system.
Record acceptance cases before substantive work and refine them only within the governing scope.
Read-only work may retain state in the session; recording progress does not authorize project-file edits.
Create a harness goal only when explicitly requested; unavailable goal tools do not prevent an otherwise authorized run.

## Keep a useful outcome graph for multi-outcome goals

For an authorized autonomous goal with multiple independently verifiable outcomes or dependent workstreams, reuse an existing issue graph or create the smallest useful one with [goal-to-issue-graph](../goal-to-issue-graph/SKILL.md) before sustained execution.
Check an existing graph against current authority, artifacts, and evidence before using it; do not blindly follow a stale task list.
Cover root acceptance, remaining outcomes, genuine dependencies, and integration checks appropriate to the permitted activity.
A single bounded task may use its existing acceptance criteria without a graph.
Use permitted existing goal, plan, tracker, or session state; this requirement neither mandates a new tracking system nor authorizes tracker mutation or project-file edits for read-only work.

Initial investigation may precede decomposition.
Keep downstream work provisional where discovery or an unresolved choice can change it; do not require an exhaustive audit before the first consumer path.
As evidence or the approach changes, update or supersede obsolete tasks and dependencies while preserving the governing outcomes.
Working from the graph means advancing an unmet root outcome and closing work on evidence, not obeying abandoned mechanisms or treating revisable agent assumptions as user requirements.
Graph work does not expand scope, change the authorized activity or effects, or resume an inactive goal.
The graph skill owns decomposition; work-selection still owns the next action.

## Select work within the authorized run

Use [work-selection](../work-selection/SKILL.md) to choose the next action, justify dependencies, and compare continuing with other authorized approaches.
Also use it before extending repeated similar batches during an active run, even when they succeed.
Keep unmet acceptance conditions and scoped blockers visible while advancing independent authorized work.
Advance acceptance and integration only when governing prerequisites and required evidence permit.

Use [delegation](../delegation/SKILL.md) for assignments, shared contracts, waiting, review, and integration.

## Apply implementation procedures only to implementation

For implementation work, use these companion procedures when their conditions apply:

- Use [change guidelines](../references/change-with-evidence.md#design-choices) for unresolved modeling, interface, ownership, or invariant decisions, and [testing guidance](../references/testing.md) for test-strategy choices.
  For an established pattern, follow the surrounding code and tests without another design procedure.
- [Review evidence standards](../review/references/evidence.md) distinguish local/component checks, integration, and required real-input evidence.
  Consult them for milestone readiness; run the full audit only after substantial owned implementation is complete.
  A routine localized change needs a diff review and appropriate native checks, not a full audit.
- For a new independently invoked tool, use [new-tool-development](../new-tool-development/SKILL.md) to check readiness.
  This skill neither approves its artifacts nor selects its design.

For an implementation acceptance case, identify the actual entrypoint, authoritative inputs, intervening interfaces, final consumer, and cheapest realistic check.
Require end-to-end evidence unless the governing scope explicitly declares a feasibility or component milestone.
Do not replace that condition with a helper's local success.
Before extending prerequisite or capability work without a new consumer-visible result, attempt the nearest intended-consumer check.
If it cannot run, identify the missing dependency and use work-selection to compare repair with the smallest authorized alternative.
Connect each handoff to the intended consumer or remove the temporary path before extending it with another fixture-only capability.
If a repair displaces integration, retain integration as the next action for that acceptance condition.
If blocked, retain downstream obligations rather than silently deferring them.
Missing real inputs do not block integration using valid fixture inputs, but fixtures do not satisfy requirements for real-input evidence.
Where acceptance permits partial results, keep unsupported cases explicitly held while supported cases reach the consumer.
This does not narrow the milestone or certify held cases.
Reuse producer outputs that remain valid for the required consumer and repair the failing boundary; regenerate only invalidated or missing work.
Record implementation results as integrated, local-only, or blocked with the exact check and evidence.

Commit only when the task or repository policy authorizes repository changes and commits; use [commit-quality](../commit-quality/SKILL.md).
For authorized implementation runs, commit integrated results rather than waiting until the end of the session.
Do not turn read-only research or review into repository mutations to satisfy an implementation procedure.

## Record decisions and preserve resumable state

Record corrections, constraints and their sources, failed approaches, and decision-changing untried alternatives in existing authoritative task state.
Keep governing requirements distinct from revisable agent choices in saved state; summaries must not promote the latter into user instructions.
Record user decisions before dependent delegation and reconcile superseded holds, questions, and worker instructions without dropping constraints that still apply.
Do not rely on compaction to retain everything needed to resume.

Before compacting a complex run, check whether authority, acceptance, ownership, or evidence applicability is becoming hard to track.
When it is, use [delegation](../delegation/SKILL.md) to spawn a bounded archivist subagent while you can still name the uncertain points.
Give it those points, the current objective and permitted activity, existing task-state locations, and transcript, evidence and worker references.
Treat your account as claims to check, not the archivist's authority.
Ask it to reconcile duplicate or conflicting status claims against original records and identify superseded instructions with their replacement sources.
Require current dispositions, source references, and explicit unresolved contradictions, not another chronological summary or a whole-project audit.
The archivist reconciles records; it does not grant authority, certify technical acceptance, delete original evidence, or rerun acceptance checks.
Inspect its result and incorporate supported corrections into the existing permitted task-state surface before preparing the checkpoint.
Do not create a parallel status ledger or treat the archivist's inference as a user decision.
If delegation is unavailable or compaction cannot wait, preserve the uncertain claims and recovery references explicitly rather than resolving them by assumption.
A coherent current record needs no archivist pass.

Before compaction, interruption, or handoff, preserve:

- the governing objective, permitted activity and effects, and protected boundaries;
- unmet acceptance conditions, next actions, and integration displaced by repairs;
- precisely scoped blockers and other independent obligations;

From jyn514/dotfiles, Unlicense.

More from jyn514/dotfiles