@codetreker/daynight 0.26.0 → 0.27.2

package/dist/commands/skill/skills/using-daynight/references/handbook.md

@@ -1,294 +1,37 @@
-# Daynight handbook
-
-Use the installed `daynight` CLI. Discover command groups with `daynight --help`
-and read the relevant command's `--help` for arguments, options, and output
-formats. The installed `dn` alias accepts the same commands. This reference indexes project/task commands and explains the context
-needed to use them correctly.
-
-## Command index
-
-| Command | Purpose |
-|---|---|
-| `login` | Authorize CLI access through the browser using a device code. |
-| `logout` | Revoke and remove the current CLI credential. |
-| `review add-repo` | Configure a repository for review; review run/list also guide first-use configuration in an interactive terminal. |
-| `project create` | Register a repository as a project or find its existing project. |
-| `project list` | Find projects on the configured service. |
-| `project show` | Inspect a project's details. |
-| `task create` | Register a todo task with its metadata and dependencies. |
-| `task ready` | Read a bounded candidate page of todo tasks with completed prerequisites. |
-| `task list` | Read every matching page; defaults to unfinished tasks. |
-| `task show` | Read one task's complete details and exact version. |
-| `task update` | Change metadata, automatic-execution permission, platform requirements, dependencies, or PR references; status is not writable. |
-| `task set-status` | Set todo, in_progress, or done using an observed exact version. |
-| `task delete` | Soft-delete one task using an observed exact version, retaining stored data and attachments. |
-| `task graph` | Inspect the project's dependency graph and summary. |
-| `task attachment put` | Upload or replace one attachment file. |
-| `task attachment list` | Read a task's attachment inventory and metadata. |
-| `task attachment read` | Retrieve an attachment's original bytes. |
-| `task attachment remove` | Delete one attachment file. |
-
-## Operational context
-
-**Service credentials.** The CLI defaults to `https://daynight.cc` without a
-configuration file or `serverUrl`. An explicit origin overrides it for a test
-server. Use `daynight login` to display a code and open the browser verification
-page, or `daynight login --no-browser` to authorize in another browser. The user
-must compare the code, check the account and explicitly approve. A saved CLI
-credential never expires by default. The Web account's token manager can set a
-future expiry, restore “Never expires”, or revoke it; changing expiry preserves the same
-credential and does not require another login. Expired or revoked credentials
-cannot be revived. `daynight logout` revokes the current credential and clears its saved value
-after confirmation or an already-invalid response; network or unconfirmed
-failures remain visible. Login does not execute any pending business operation.
-
-A service command without a saved credential fails before dispatch and points
-to `daynight login`; a server 401 gives the same guidance. Do not automatically
-start login, retry anonymously, or blindly repeat a mutation. Reconcile an
-unconfirmed write before another mutation. Project discovery and explicit project
-IDs grant no access; current service membership decides authorization.
-
-For a test service or noninteractive automation, provision the existing
-`serverUrl` and `serverToken` fields in `~/.daynight/config.yml` through a trusted
-configuration or secret source. Omit `serverUrl` only for `https://daynight.cc`.
-Never put a token in command arguments, chat, task descriptions, checkpoints or
-attachments. Keep credential files private, with POSIX mode `0600`. Pair each
-credential with its intended normalized origin; when changing services externally,
-remove or replace the old token before another request. External file writes do
-not run CLI credential cleanup or participate in its write lock. Credentials
-require HTTPS except for literal localhost or numeric-loopback HTTP. File
-provisioning performs no network or login checks. There is no top-level `setup`
-command; `completion setup` remains the independent shell startup installer.
-
-**Project discovery.** Inside a Git worktree, task commands can omit `--project`:
-the CLI matches the origin repository URL to a project on the configured
-service. An explicit project overrides discovery for that invocation. Resolve
-missing or ambiguous matches rather than guessing an ID or creating a project
-to make a query succeed.
-
-**Read scope.** Ready is a candidate page of todo tasks, ordered by
-creation rather than relevance. An empty page does not rule out in-progress or dependency-blocked work. List traverses every matching page but
-excludes `done` by default; include completed tasks explicitly when checking the
-full backlog or prior registrations. Its grouping is in-progress, ready todo,
-blocked todo, then done when included; this does not rank relevance.
-Human lists are summaries; JSON lists omit only `description` and preserve every
-other task field. Use show when a description is needed; ready, details and write
-results retain full tasks. Graph provides compact dependency context without
-full descriptions, PR properties, or versions. Read the selected task's details
-before acting. A graph-limit error still permits bounded candidate and
-individual task reads.
-
-**Task status.** Creation starts in `todo` with no task approval stage and does
-not start execution. `task set-status <task-id> <status> --if-version <version>`
-sets any of `todo`, `in_progress`, or `done` through ordinary status setting.
-To finish an explicitly supplied active worker claim, use
-`task set-status <task-id> done --claim-id <claim-id> --if-version <version>`.
-The claim ID must be a UUID and is valid only with `done`; the CLI never infers
-it from task data or the environment. This path uses the existing worker
-completion operation: a real completion requires the current owner, active
-claim, in-progress task, and exact version, and retains worker history with
-`state=completed`. Omit `--claim-id` for ordinary status setting; refusal never
-causes fallback between these operations. Read the
-[managed autopilot reference](autopilot-managed-task.md) only when the worker
-startup prompt explicitly selects that mode; ordinary status operations do not
-load its execution rules. A valid worker-managed assignment already has sufficient
-authorization for its in-scope delivery and PR merge. Its executor merges once the
-required checks, current-head approvals, blocking-thread resolution, and
-mergeability conditions are met without requesting additional permission, while
-honoring explicit user restrictions, pause, and revocation.
-
-The service checks the exact version
-before a same-status no-op; it preserves all fields for a current-version no-op
-and refuses stale versions. A real change increments the version once. Generic
-metadata updates cannot write status. Status, materials, and readiness grant no
-implementation, publication, deployment, or merge permission.
-
-Entering in_progress or done requires every direct prerequisite done. Reopening
-done to todo or in_progress is refused when a direct successor is in_progress or
-done; successors are never changed automatically. Entering in_progress starts a
-new execution interval and clears completion; returning to todo clears both
-endpoints. In_progress to done retains the nullable start and records completion.
-Todo to done records only completion, with unknown duration. Same-status and
-metadata updates preserve timing. Ordinary status changes provide no process ownership,
-release, withdrawal, stop, or lease semantics. The Web confirms every status choice,
-including the current status; cancel and Escape submit no request.
-
-**Task deletion.** `task delete <task-id> [--remove-depends] --if-version <version>`
-removes a task from normal lists, graphs, readiness, and detail access while
-retaining its stored data, its own prerequisite references, and attachment files.
-Deletion is independent of the task's status. Without `--remove-depends`, an
-undeleted task depending on the target prevents deletion; a task with no such
-references can be deleted directly. The service checks this in the deletion
-transaction; the CLI does not download the graph to decide whether deletion is
-allowed.
-
-`--remove-depends` is an optional switch with no value. It explicitly authorizes
-removing all other tasks' ordinary and external dependencies on the target in the
-same transaction as soft deletion, including references added before that
-transaction executes. This can make affected tasks ready. Each task whose
-relationships change receives a new version; its status, execution times, worker
-ownership, and other data are preserved. The target's own prerequisite references
-are retained. An active worker claim on the target always prevents deletion;
-release the stopped worker through the authorized workflow before reconsidering
-it. Deleting a task requires explicit user authorization for that task; removing
-other tasks' dependencies requires that additional authorization. Deletion is not
-a completion action.
-
-Read the full task and preserve the exact version used for the deletion decision.
-Without `--if-version`, the CLI reads the latest version immediately before
-submitting; that read cannot protect an earlier decision. A successful deletion
-returns no task resource or removed-reference count. An authorized read of a
-deleted task returns `410 task_deleted`, distinct from a missing task or
-inaccessible project. On a lost response, GET the task to reconcile:
-`task_deleted` confirms it is deleted; a live resource requires a new decision,
-and a permission or transport failure leaves the outcome unconfirmed. Never
-replay deletion automatically. The Web confirmation explicitly authorizes
-removing other tasks' dependencies together with deletion; the CLI submits its
-selected mode directly.
-
-**Automatic execution permission.** Tasks expose the required boolean
-`allowAgents`, independent of status and dependency readiness. New tasks
-start false; public creation cannot set it. Existing tasks receive true through
-the database migration. Use `task update <task-id> --allow-agents true|false --if-version <version>` only
-for an explicitly authorized permission change.
-Omission preserves the current value, including explicit false. Actual changes
-are locked during in_progress; exact-version same-value requests keep the
-version and timestamps, while stale versions still conflict. Status changes and other metadata updates preserve the flag.
-
-`task list` and `task ready` accept `--allow-agents true|false`. The server
-combines that condition with other filters before pagination and the ready limit;
-an unfiltered ready page may contain tasks without automatic-execution permission.
-Automatic selection requires true and does not enable permission itself.
-Only explicitly authorized [handoff](handoff.md) reviews the task against
-[the content standard](task-content.md) before enabling it; creation, breakdown,
-and execution do not do so implicitly. An explicitly user-selected task may still
-use manual execution regardless of the flag. Permission does not grant execution, publication or merge authority.
-A lost permission PATCH response is an unconfirmed write: read actual task state
-before reconsidering the operation, without resubmitting automatically.
-
-**Execution platform.** Complete tasks, inventory items and graph nodes expose
-`requiredPlatform` as `null`, `windows`, `linux` or `macos`; null means unrestricted.
-Set a requirement with `task create --required-platform <platform>` or
-`task update <task-id> --required-platform <platform> --if-version <version>`.
-Clear it with `task update <task-id> --clear-required-platform --if-version <version>`;
-setting and clearing in one command is invalid. Omitting both update options
-preserves the requirement. Existing and new tasks without a requirement are
-unrestricted. Actual changes are locked during in_progress; an exact-version
-same-value request keeps version and timestamps, while stale versions conflict.
-Explicitly user-selected tasks and fixed queues retain their manual execution
-path independently of platform compatibility. Automatic selections keep their
-actual-platform context and recheck full-task eligibility before set-status.
-
-`task list` and `task ready` accept `--compatible-platform <platform>`. The
-server includes unrestricted tasks and exact matches, combining this condition
-with status, readiness and `--allow-agents` before pagination or the ready limit.
-Platform compatibility does not change readiness or enable automatic execution.
-Preserve the filter when requesting additional candidate inventory; do not filter
-a bounded unfiltered ready page locally. A query option selects a candidate
-platform and does not establish the actual execution environment. Worker runtime
-must identify its own platform; a Linux runtime in WSL is Linux.
-
-**Task concurrency.** Bind each metadata update and status change to
-the exact version read for that decision using `--if-version`; the CLI's default
-pre-submit read cannot protect an earlier decision. Preserve full int64 decimal
-digits without numeric rounding. Entering in_progress is a versioned transition, not an
-assignee lock, renewable lease or proof that existing work belongs to this
-session. On a conflict, reread and reconsider; a new action needs a fresh
-decision, not merely a newer version. Never retry a mutation automatically.
-
-**Dependency classification.** `dependsOn` contains every direct prerequisite;
-`externalDependsOn` is its explicit external subset. Ordinary prerequisites are
-`dependsOn` minus that subset. Both are canonical, duplicate-free UUID sets,
-not insertion order. Every prerequisite must be done before entering in_progress or done,
-including external ones; cycle checks and project access rules use all edges.
-External means cross-chain within the same project, not a cross-project
-reference. It separates chain ownership, not blocking or authorization. Use
-ordinary relationships for confirmed same-chain work and external relationships
-for verified prerequisites owned by another chain. Confirm task content and
-ownership; done status, a similar title, current graph roots or the displayed
-component do not establish the classification.
-
-### Dependency reduction
-
-When creating tasks or registering a Goal breakdown, keep only necessary direct
-prerequisites. Read the relevant dependency paths before writing. In
-`A → B → C`, arrows run from prerequisite to successor: C declares B, not both A
-and B. Omit `A → C` because the retained path already supplies A. Keep independent
-prerequisites that have no alternative path.
-
-An ordinary edge is redundant only when another path made entirely of ordinary
-edges supplies the same prerequisite; this preserves chain ownership and the
-Goal's ordinary design gate. An external edge may be supplied by an alternative
-path containing either kind. Preserve the classification of every retained edge.
-Check the retained graph as a whole, and read it back after registration to verify
-that required paths remain and no redundant direct edges were added. Source
-references do not require additional execution dependencies. This registration
-rule does not authorize cleanup of unrelated existing relationships.
-
-### Relationship and content writes
-
-**CLI relationship replacement.** `--depends-on` declares ordinary prerequisites;
-`--external-depends-on` declares external ones. Supplying either option compiles
-their full union as `dependsOn` and the exact external set as `externalDependsOn`.
-This replaces every relationship and its classification. An external-only option
-replaces the set with only those external edges; it does not append or merely
-mark an existing edge. An ordinary-only option makes every supplied edge ordinary
-by explicitly sending an empty external subset. Repeat options for the complete
-intended sets. Duplicate or cross-declared IDs fail, including case-equivalent
-UUIDs. Omit both options to preserve relationships; `--clear-dependencies` sends
-both empty sets and conflicts with either option. Before a dependency edit, read
-all D/E values and derive the ordinary set D−E, then preserve every still-needed
-relationship under its intended declaration. Read back the full sets afterward.
-Installed command help owns exact syntax.
-
-**Direct API patches.** API fields are independently optional. Omitting both
-preserves relationships. Supplying only `dependsOn` replaces IDs, preserves
-classification on surviving edges and makes new edges ordinary. Supplying only
-`externalDependsOn` preserves IDs and replaces the complete external subset;
-supplying both replaces both sets exactly. The external set must belong to the
-final complete set. This API partial-patch rule differs from the CLI compiler's
-explicit full relationship replacement; do not infer CLI append semantics from it.
-
-**Other replacement fields.** Descriptions and PR reference lists replace the
-whole supplied field. Preserve every still-needed value. Omitted fields stay
-unchanged; clearing and option-pairing syntax is in command help.
-
-**Markdown descriptions.** Write task-specific Markdown descriptions following
-[create-task](create-task.md) and [the task content standard](task-content.md).
-The description and actual references jointly supply the task definition and
-produced results; complete inline content needs no primary attachment. Execution
-and discussion plans, processes, and operational authorization stay in the
-session under the shared content boundary. The Web displays CommonMark/GFM, while
-API and CLI reads preserve the original string, including line breaks and fenced code. There
-is no format flag. Relative description links and images start at the current
-task's attachment root; Markdown attachment internals start at their containing
-file's directory. Keep real case-sensitive paths inside the task root, confirm
-uploaded contents before linking them, and preserve Markdown and valid references
-when replacing a description. Shared inputs retain their owning task ID and
-content location: description with applicable sections for inline content, full
-path for an actual attachment, or verified immutable repository URL. Read source
-descriptions with `task show --json` and attachment contents separately. They
-are not cross-task relative links, and inline content needs no fabricated path.
-
-**Attachment independence.** Task reads contain no attachment inventory.
-Attachments use case-sensitive relative paths; uploads to the same path replace
-that file, so keep mock UI resources at their referenced relative locations.
-Attachment changes do not change the task's version, status, or update timestamp.
-Task versions therefore cannot protect attachment writes. Multiple file
-operations are independent, and file bytes and metadata can change partially;
-confirm actual contents as well as metadata when reconciling a write.
-
-**Unconfirmed writes.** A timeout, cancellation or lost response may follow an
-applied change. Read back current task fields or attachment contents before
-another mutation; cancellation does not prove rollback. For an unconfirmed
-create, establish identity from complete fields and operation context; a matching
-title or an empty lookup alone is insufficient. Preserve actual errors and
-resource IDs rather than reporting success or blindly resending a write.
-
-Task registration, ordinary execution, and requested handoff follow
-[create-task](create-task.md), [run-task](run-task.md), and [handoff](handoff.md),
-respectively. For a chain of independently tracked delivery stages, use
-[the Goal protocol](goal.md). Every stage and delivery task follows the same
-todo/in_progress/done contract. Registration and discussion confirmation grant
-no delivery execution permission. Each execution remains on its specified task;
-listing ready work does not select or start it.
+# CLI handbook
+
+Use the installed `daynight` CLI.
+This file maps command entry points; consult that version's `--help` for arguments, defaults, and option combinations.
+
+## Find help
+
+```bash
+daynight --version
+daynight --help
+daynight task --help
+daynight task update --help
+daynight task attachment put --help
+```
+
+Navigate from top-level help down to the required command.
+Do not treat this skill's workflow names as CLI commands or infer commands from field names.
+
+## Command map
+
+| Purpose | Command entry points | Guidance |
+| --- | --- | --- |
+| Sign in or out | `login`, `logout` | [Setup](setup.md) |
+| Shell completion | `completion setup` | [Setup](setup.md) |
+| Create, list, or inspect projects | `project create`, `project list`, `project show` | [Project management](project-management.md) |
+| Query tasks | `task list`, `task ready`, `task show` | [Task management](task-management.md#task-queries) |
+| Read task dependency graphs | `task graph <task-id>` | [Verify dependency changes](task-management.md#verify-dependency-changes) |
+| Create tasks | `task create` | [Create task](create-task.md) |
+| Change metadata | `task update` | [Task management](task-management.md#metadata) |
+| Set or remove task properties | `set-property`, `remove-property` | [Managed task user interaction signals](autopilot-managed-task.md#request-user-interaction) |
+| Change status | `task set-status` | [Task management](task-management.md#status-and-timing) |
+| Delete tasks | `task delete` | [Task management](task-management.md#task-deletion) |
+| Upload, list, read, or remove attachments | `task attachment put/list/read/remove` | [Task content standard](task-content.md#attachments-and-references) |
+| Set up and manage workers | `worker` | See `daynight worker --help`; for execution within an assignment, see [managed task execution](autopilot-managed-task.md). |
+
+Follow [write safety](write-safety.md) for writes.
+CLI help explains command syntax; reference files explain when to use commands, what they affect, and how to confirm outcomes.

package/dist/commands/skill/skills/using-daynight/references/handoff.md

@@ -1,105 +1,47 @@
-# Handoff a task
+# Task handoff
 
-Use `handoff <task-id>` only when the user explicitly requests handoff of that
-task or a fixed set of tasks. This is a skill mode, not a CLI subcommand. The
-request authorizes content review and, after it passes, enabling `allowAgents`
-for those tasks. Creating, breaking down, or automatically discovering tasks does
-not authorize permission changes. Read [the handbook](handbook.md) for CLI
-operations and [the task content standard](task-content.md) for sufficiency.
+Use for a task or fixed group of tasks that the user explicitly requests to hand off: review content, enable automatic execution permission after it passes, then return.
+See [authorization and scope](authorization.md) for boundaries; handoff does not start execution in this session or change status, dependencies, or platform.
 
-Handoff ends after review, any authorized permission update, and reconciliation.
-It does not start this session's task execution, change status,
-dependencies or platform, or grant independent implementation, merge, mainline
-push, deployment, or external-communication authority. Existing execution and
-delivery authorization remains applicable to later scheduling.
+## Content review
 
-## Review the task and its sources
+Read the project and complete task, preserving the exact version, status, permission, platform, dependencies, and worker records.
+Read actually required sources under the [task content standard](task-content.md), checking definitions, stage requirements, producer and consumer contracts, and the [Goal architecture index](goal.md#register-the-delivery-breakdown).
 
-Read the intended project and complete task, retaining its exact version,
-status, `allowAgents`, platform, dependencies, and worker record. Read the
-required source contents, including referenced source-task descriptions or
-actual attachments, and necessary further references under the content standard.
-Check current-stage sufficiency, responsibility boundaries, relevant
-producer/consumer contracts, and Goal delivery tasks' direct architecture index.
-Check the task definition, actual required inputs, and produced results; do not
-require a session execution plan or record the handoff review process in task
-material.
+For todo tasks with permission false, organize confirmed content within existing authorization; missing decisions prevent approval, and material changes require user confirmation.
+Incomplete predecessor tasks need not block handoff when existing designs and interfaces sufficiently define the work, but do not claim that future outputs are already readable.
+Tasks with permission already true may be selected at any time; review them read-only, without assuming execution is paused.
 
-For a `todo` task with permission false, organize its description or authorized
-source documents only from existing confirmed information. Missing decisions
-block review. Obtain user confirmation for material scope or behavior changes,
-then reread the changed description and affected actual sources. Unfinished
-prerequisites need not prevent handoff when the design and agreed interfaces
-already define the future work; preserve their real blockers and do not claim
-pending outputs are readable.
+## Act on observed state
 
-Already-enabled tasks receive a read-only re-audit: they may be selected while
-review is underway. Do not assume they are paused or edit their content under
-that assumption. Follow the state rules below before any permission change.
+| State | Action |
+| --- | --- |
+| todo, permission false, review passed | Enable permission using the exact version on which the final review decision was based, then reconcile. Real dependency blockers may remain. |
+| todo, permission false, review failed | Keep permission false and report specific gaps. |
+| todo, permission true | Review read-only; do not rewrite the same value as a review marker. |
+| in_progress, permission false | Report that permission is locked; do not change status to bypass it. |
+| in_progress, permission true | Review read-only and report execution status; review does not pause, stop, release, or withdraw execution. |
+| done | Report that it is complete and needs no handoff; do not reopen or change permission. This is handoff policy, not an API restriction. |
 
-## State and ownership rules
+Preserve ownership and history for active or released workers.
+New claims, workspaces, or native sessions for released tasks require an authorized administrative decision; enabling permission does not restore old execution or deleted resources.
 
-| Observed state | Handoff behavior |
-|---|---|
-| `todo`, permission false, review passes | Enable using the reviewed exact version, then reconcile. Dependency blockers may remain. |
-| `todo`, permission false, review fails | Keep permission false and report concrete gaps. Confirmed-information organization follows the review rules above. |
-| `todo`, permission true | Read-only re-audit; do not rewrite the same flag as an audit marker. |
-| `in_progress`, permission false | Report the permission lock; do not newly enable or reset status to evade it. |
-| `in_progress`, permission true | Read-only re-audit and report actual execution state. Review does not pause, stop, release, or withdraw execution. |
-| `done` | Report completion and no handoff needed; do not reopen or update permission. This is mode policy, not an API prohibition on completed-task updates. |
-| Active or released worker record | Preserve ownership and execution history. An active execution keeps its original resources. A released task starts a fresh claim/worktree/native session only through an authorized management decision; enabling permission neither resumes it nor restores deleted source resources. |
+## Update and reconcile
 
-If an already-enabled task fails re-audit, report the failed review, actual flag,
-and continued scheduling exposure. Keep its permission unchanged. Revocation or
-stopping needs separately explicit scope and the established workflow, including
-running-task locks and worker controls. A failed review is not a successful
-handoff or an implicit suspension.
+1. Finish authorized content organization, read back and compare required mutable sources again, not just metadata.
+2. Use `task update` to enable `allowAgents` under [write safety](write-safety.md); write the final description in the same operation if needed, omitting unrelated options.
+3. Check the response and read back the complete task and required sources.
+   A worker may claim the task immediately after permission is enabled; a higher final version or a transition to in-progress with a worker is not a failure and must not trigger a retry.
 
-## Enable permission and reconcile
-
-Finish authorized document changes and read them back before enabling permission.
-Recheck required mutable references against the contents reviewed; compare actual
-contents, not merely inventory or timestamps. Resolve changes before proceeding.
-Attachment writes and cross-task references are not atomically protected by the
-task version, and handoff does not provide server-side certification or freezing.
-
-For a reviewed false-permission `todo`, use the installed CLI's versioned
-`task update --allow-agents true` with the exact version on which the final
-review decision was based. A final description may be included in that same
-update. Omit unrelated options and preserve dependencies, platform, PR references,
-worker data, and other fields. Do not update status to make the task eligible.
-
-Check the write result and read back the complete task and required sources.
-On a version conflict, reread and reassess rather than merely replacing the
-version and replaying. If a write response is lost or uncertain, reconcile by
-reads only before considering any new mutation; do not automatically replay it.
-An unreadable reconciliation leaves the outcome unconfirmed: preserve the actual
-error and do not report successful handoff.
-
-Scheduling can claim the task immediately after enabling permission, so the final
-GET may show a higher version and `in_progress` with a worker. Report the actual
-observation; do not require equality with the update response's version or retry
-because execution was observed. Another writer may have set the same flag during
-an uncertain outcome. Without a confirmed write result, report only the observed
-state rather than attributing the change to this operation.
-
-If final source verification fails or reveals material changes, report review
-incomplete or failed and the actual permission/state, including continued
-scheduling exposure when true. Do not claim success or automatically revoke the
-flag. Further action follows the same explicit authorization and state rules.
+If review fails or source verification fails after the update, report the actual permission and that scheduling may still occur; do not claim successful handoff or automatically revoke permission.
+Revocation or stopping execution requires separately defined scope and the administrative workflow.
+Without a confirmed response, report only actual observations, without attributing the change to this operation.
 
 ## Report and return
 
-Read back the complete task before reporting, including read-only re-audits.
-Reassess changed review-relevant metadata or sources; a newly observed worker
-claim is reported under the state rules rather than treated as proof of failure.
-Report each task's content-review result, changes or concrete gaps, observed
-version, permission and status, remaining dependency blockers, and applicable
-worker ownership and management constraints. Distinguish a confirmed permission
-update from an uncertain write and a read-only re-audit. Permission true alone proves neither
-execution started nor completion; report either only from actual evidence.
+Before reporting, read back the complete task and reassess changes that affect the review.
+For each task, report the review conclusion, changes or gaps, observed version, permission, status, dependency blockers, and applicable worker ownership; distinguish confirmed updates, uncertain writes, and read-only review.
 
-For a fixed set, review and report each task separately; one pass does not cover
-other tasks. Return without selecting work or starting execution. The flag is
-not a durable review certificate, and this mode does not bulk-rewrite existing
-permission values.
+Handle each task in a fixed group individually; one passing does not mean the others passed.
+Permission true is neither permanent proof of review nor proof that execution has started or finished.
+Return without selecting or starting work.

package/dist/commands/skill/skills/using-daynight/references/project-management.md

@@ -0,0 +1,24 @@
+# Project management
+
+A Project is associated with a Git repository.
+Project identity determines the scope of task operations; confirm the service, access identity, and project before operating on tasks.
+
+## Discovery and selection
+
+Within a Git repository and its worktrees, task commands may omit `--project`; the CLI matches the `origin` URL to projects on the configured service.
+An explicit project overrides automatic discovery for that invocation.
+
+Use `project list` to find accessible projects and `project show` to verify the selected project.
+If there is no match or the match is ambiguous, confirm the repository, service, and target project.
+Do not guess IDs or create projects merely to make a query succeed.
+See the relevant `--help` for details.
+
+## Register a project
+
+With authorization, use `project create` to register the repository as a project.
+Reuse an existing project when exactly one matches; resolve identity first when the match is ambiguous.
+Retain the returned project ID, then read the project details to confirm the repository and name.
+
+If the creation response is uncertain, establish the actual outcome first under [write safety](write-safety.md).
+An identical name does not prove project identity.
+Consult `daynight project --help` for available project configuration operations.

package/dist/commands/skill/skills/using-daynight/references/run-task.md

@@ -1,66 +1,25 @@
-# Run one task
+# Ordinary task execution
 
-Execute exactly one specified task ID within the user's authorized scope. Read
-[the handbook](handbook.md) for CLI operations, data semantics, and failures.
-This mode owns the ordinary task lifecycle. It returns without choosing a
-successor, except for the explicit user-directed requirements-to-solution
-transition under [the Goal protocol](goal.md).
+Use for one task explicitly specified by the user.
+Apply [authorization and scope](authorization.md) first, read the complete task with `daynight task show <task-id> --json`, and verify inputs and completion conditions under [shared task execution](task-execution.md).
 
-## Establish the task
+## Start or resume
 
-Read the complete task with `daynight task show <task-id> --json`. Preserve the
-requested task ID through recovery and waiting. Read and apply
-[shared task execution](task-execution.md) for its required inputs,
-prerequisites, confirmed scope, work, results, and acceptance.
+| Observed status | Behavior |
+| --- | --- |
+| todo | Once ready and authorized for execution, use `task set-status` with the exact observed version to enter `in_progress`; confirm success before starting. |
+| in_progress | Reconcile existing work and session context, coordinate and resume through established repository mechanisms, and do not treat status as an execution lock. |
+| done | Report that it is already complete; consider reopening only when the explicit request includes it. |
 
-An explicitly user-selected task may use this execution path regardless of
-`allowAgents` or platform compatibility. These conditions gate automatic worker
-selection, not an explicit task assignment. They do not remove dependencies,
-stage inputs, or execution and delivery authorization. This mode does not select
-candidates or automatically advance a fixed task queue.
+An explicit ordinary assignment is not restricted by `allowAgents` or platform filtering for automatic selection; see [task management](task-management.md#metadata).
+This workflow does not select candidate tasks or advance a queue automatically.
 
-Creation leaves a task `todo` and does not execute it. An explicit request to
-start the current Goal discussion, or the user-directed transition that starts
-solution discussion, authorizes entering `in_progress` for that discussion under
-the Goal protocol; registration alone does not. Existing execution authorization
-remains limited to its stated scope. Task status never expands implementation
-or delivery authorization.
+## Complete or wait
 
-## Start or resume the task
+Follow the shared execution rules.
+Once all completion conditions are met, reread the in-progress task, set it to done using its observed version, and confirm the service result.
+Handle all changes and uncertain responses under [write safety](write-safety.md); ordinary completion does not include a worker claim.
 
-For ready `todo`, begin only when dependencies are done, required stage inputs
-are complete, and the work is authorized. Use
-`task set-status <task-id> in_progress --if-version <observed-version>` with the
-exact version observed for that decision and confirm `in_progress` before
-starting. A stale version or changed prerequisite requires rereading and
-reconsidering, with no automatic mutation retry.
-
-For `in_progress`, recover existing work and coordinate using the project's
-established mechanisms; the state is not an assignee lock or lease. A task
-already `done` is reported as such unless reopening is within the explicit
-requested scope. An authorized reopening uses the same versioned status setter
-and dependency protection.
-
-Perform the authorized work and establish acceptance readiness under
-[shared task execution](task-execution.md). Starting a task is not evidence that
-its delivery or acceptance is complete.
-
-## Complete or return waiting
-
-When all task acceptance and delivery conditions are satisfied and its required
-results are readable, reread the complete in-progress task and use
-`task set-status <task-id> done --if-version <observed-version>` with its exact
-observed version. Only service confirmation establishes the status update;
-reconcile uncertain results before reporting success. Do not replay an
-unconfirmed mutation automatically.
-
-For Goal discussions, completion follows the confirmation gates and accepted
-materials in the Goal protocol. After requirements completion is confirmed, an
-explicit user direction can start the specified solution discussion under that
-protocol. It grants no automatic successor selection or delivery authorization.
-Whole-Goal acceptance follows the Goal protocol.
-
-Otherwise return after this task completes or needs external intervention.
-Unstarted work stays `todo`; active work stays `in_progress`. Keep the target and
-waiting checkpoint when necessary PR merges, human confirmation, permission, or
-acceptance remain pending; do not select another task to bypass the wait.
+When merging, human confirmation, authorization, or acceptance is still missing, keep the task in progress and preserve the waiting context.
+Tasks not yet started remain todo.
+Return when complete or when external intervention is needed, without selecting a successor; follow the [Goal protocol](goal.md) for discussion-stage transitions explicitly directed by the user.

package/dist/commands/skill/skills/using-daynight/references/setup.md

@@ -0,0 +1,16 @@
+# Setup
+
+Use this when first connecting to Daynight or confirming the current repository is ready to use. See the [CLI handbook](handbook.md) for finding commands and arguments.
+
+1. Run `daynight --version` and `daynight --help` to confirm the CLI is available.
+   If it is not installed, obtain user authorization and follow the [installation guide](https://daynight.cc/setup).
+2. Confirm the target service and signed-in identity. When authentication is needed, use `daynight login` and have the user follow the prompts to verify the code and account in the browser and authorize access.
+   See `daynight login --help` for remote-terminal options. Do not ask the user to provide credentials in chat.
+3. Confirm the project for the current Git repository under [project management](project-management.md). If there is no project, obtain registration authorization before creating one; service or permission failures do not mean the project is absent.
+4. Read the repository's `AGENTS.md` and `CLAUDE.md` to establish task tracking, language, workspace, delivery, and authorization rules.
+   If repository instructions need to be added or adjusted, confirm the content and editing permission first; setup does not imply permission to rewrite instructions.
+5. Confirm that project and task queries are accessible. Report actual failures and preserve completed configuration; do not bypass problems by creating duplicate projects.
+
+Configure interactive completion with `daynight completion setup`.
+Setting up and running a worker environment are separate operations; consult `daynight worker --help` first.
+Ordinary task management does not require starting a worker.