mailhexu/kosmic/kosmic-usage

kosmic Usage Skill

<!-- Generated by the Kosmic Projection CLI. Do not edit. -->

Working State: working-tree

Work record authority

• Project: kosmic; canonical records: /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic/specs and /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic/subprojects.
• Shared knowledge stays at /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic/notes, /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic/mathdocs, and /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic/skills; never copy it into a subproject.
• Ordinary work has no universal mandatory record: choose records when they add real value for complexity, risk or coordination, or when the user explicitly selects one; explicitly record-governed CLI operations keep requiring their declared records. When a record governs the work, reuse a covering approved governing record or create one through Kosmic. Choose a Quick Task or owner-local Story/Epic/Architecture/PRD hierarchy by actual scope, risk and uncertainty, including for new features and existing-feature amendments; materialize accurate approval from the user's disclosed implementation authority. Routine Task 1 initialization is the bounded exception below.
• Routine Task 1 initialization establishes only its documented setup outputs, without a Quick Task, implementation review, or work start/finish. Changing initialization behavior is development work. Draft planning creates only its bounded hierarchy and planning outputs; PRD success is not implementation approval. Migration, registration and installation retain their explicit approvals.
• Follow Kosmic SKILL.md "Continuous execution": an explicit bounded implementation request covers matching planning records and execution through completion, for new features and amendments alike. Record the disclosed instruction and scope, materialize accurate approved governing records before record-governed work start, and continue authorized ready work after owned-only commits. Documents and Story boundaries are not approval gates. Planning-only requests authorize drafts, not code; vague continuation and silence grant no new implementation authority. Ask once for genuinely new material scope, safety, ownership, cost/external commitment or scientific acceptance decisions. Never edit receipted records.
• Act, then report (Kosmic SKILL.md "Continuous execution"): perform an authorized executable next action in the same turn; an intention-only final reply, plan or phase change is not execution. Report observed results or a concrete material-decision, prerequisite or external-wait blocker. Await/resume pending jobs through the host when available; preserve safety and never fabricate activity or make pointless tool calls.
• Investigate verifiable prerequisites before reporting a blocker (Kosmic SKILL.md "Continuous execution"): attempt feasible authorized checks with available inputs, supported tools and authoritative sources, rather than stop at 'not verified'. Report actual attempts, evidence and the exact unresolved input/capability or material decision. Factual uncertainty is not itself a user decision; never assume scientific validity, relax acceptance or authorize otherwise unapproved costly/destructive/external actions.
• Gather evidence before batching decisions (Kosmic SKILL.md "Continuous execution"): collect open questions while completing feasible authorized independent checks, then present remaining decisions together with the relevant content or link, a plain-language summary, evidence, recommendations, and understandable choices with tradeoffs. A decision blocks only dependent consequential actions; ask earlier if no safe authorized progress remains. Never take unapproved consequences to postpone a question; genuinely new later decisions may require another batch.
• Recovery first: a diagnostic starts problem-solving, not an automatic stop. Apply the requested operation's documented checks and find the smallest concrete recovery using authoritative context/native outputs. Carry out safe already-authorized recovery; for new scope, destructive action, conflicting ownership or another material decision, recommend a specific action with risks and ask only for that approval before acting. For an unavailable prerequisite, name it and how to obtain it. Unrelated audits/optional diagnostics do not add approval gates; never suppress failed authority, scientific, review or completion checks.
• Explicit cross-Project implementation may use a coordinating Epic with linked owning records, or bounded Quick Tasks for small low-risk work. Follow Kosmic Task 5's cross-Project path: resolve each exact checkout and owning Project; explicit authorization of that Project's changes covers required native registration setup when unambiguous. NOT_REGISTERED means register under the required registration Quick Task, then start the owning implementation record—not stop permanently or bypass authority. Never overwrite another Project's binding.
• Explicit idea capture is a bounded exception: idea writes exactly one note in the selected Project's ideas/ or the selected vault's GeneralIdeas/, plus that missing child directory only, without a governing record, bootstrap, review, or work start/finish. It authorizes no other change.
• For record-governed work, register the exact working root; a fixed subproject constrains that directory, never selects an active task. Use work show --project /home/hexu/projects/myagentskills/kosmic/memnotes/Projects/kosmic --work-record RECORD_REF only when record resolution is needed, not to confirm a successful command. No shared mutable selection pointer is permitted.
• Active context: retain Project, subproject (or shared), canonical path and worktree through sibling reads, resume/compaction and delegated handoffs, and retain each applicable qualified record only when one exists — recordless contexts carry Project/subproject/worktree identity without manufacturing records. Reading another owner's Story never selects it; change tasks only for the user's request or an authorized plan. Follow Kosmic SKILL.md Active context; no persistent selector or per-command orientation check. Shared-vault work may retain multiple active Project and subproject contexts at once; retaining a context never selects an unrelated record.
• An absent canonical or installed Skill Pair is not a prerequisite for ordinary development or Consumer Interface completion, and completion does not require a present pair to pass declared-source or projection validation or related notes to be fresh: consult authoritative Project notes directly; do not ask to generate or install a pair. Operations that actually consume or publish a pair keep their integrity and authority gates at that operation. Recover stale output only for actual pair consumption under the existing approved same-Project record. Malformed or partial artifacts are not absent.
• Installation collisions, unrelated structural validation findings, and concurrent derived-STATUS updates are not blanket workflow stops: treat each refusal or finding as a specific, recoverable conflict, preserve user-owned data, and resolve a real target conflict only at actual publication. Managed installers never silently overwrite an unmanaged or foreign Skill; unrelated defects elsewhere are reported without stopping this Project's or record's own checks.
• Start record-governed writable work in the current checkout; create a dedicated worktree only when the user asks. Pass the approved governing record explicitly as --work-record to each checked mutating command. Concurrent admission covers canonical Project metadata roots, slug-owner subproject specs, matching roots in sibling Projects with valid ProjectEntry.md, recognized Projects' .kosmic controls, and configured STATUS destinations. Valid sibling ProjectEntry and foreign registration/control metadata, including validated registered-worktree bindings, remain foreign, unbound, and out of scope. Only this Project's active identity surfaces (its ProjectEntry.md, registry, and binding identities), unsafe paths (absolute, .., or symlink escapes), and a non-root worktree still refuse at work start; source, unknown or noncanonical paths, and cross-owner renames are warnings listed in unrelated_changes, unclaimed and untouched.
• Repository dirtiness alone is not a conflict: unrelated changes are warned about and remain uncommitted, unowned, and untouched. Finish uses the reviewed scope by default; an explicit scope may narrow it. Unrelated work never needs to land before completion. Finish creates a missing STATUS only at the safe canonical ProjectEntry.status_root; it preserves differing existing or concurrent content with a warning. A deliberate record-optional generate-status overwrites STATUS, so reconcile user-authored content first.
• Direct read-only inspection searches authoritative notes/specs without bootstrap, migration, installation or generated-state repair; report missing/stale material instead. Generated guidance, routed operations and execution/mutation retain their normal prerequisites and live authority checks.
• For implementation completion, record actual acceptance/smoke evidence and pinned two-axis review, then use the documented work finish invocation. Finish owns the completion log, existing index-row status updates and receipt-derived STATUS — stepwise, not cross-file atomic. Native spec-create owns each new record and row at its returned record_path/index_path; historical missing rows and non-native artifacts need explicit separate handling, not automatic repair. Do not duplicate the completion log or refresh STATUS after success. Unreceipted done is pending; rerun finish after interruption.
• Trust successful commands for their documented outputs: use returned identities, paths and receipts without administrative read-back or validation. On error follow the diagnostic and documented recovery; failure does not imply rollback. Completion reports still name the qualified record, canonical path and actual acceptance/smoke/review results for changed implementation.
• After approved scope and required verification/review pass, finish; non-blocking suggestions remain advisory rather than automatically causing edits, tasks, re-review or republication. Any chosen source change still needs applicable revision-bound review.

Topics

• Projection CLI experience commands
• Dream Reflection workflow
• Managed Run Workspace Lifecycle
• Notation
• Note writing style
• Project status file
• Shared Domain Skill Library

Load only the topic references needed for the current task.