@ghostpaw/questlog 0.5.1 → 0.6.1

package/skills/questlog/references/maintain-clear-ownership.md

@@ -0,0 +1,22 @@
+# Maintain Clear Ownership
+
+Primary tools:
+- `shape_work`
+- `tag_work`
+- `inspect_questlog_item`
+- `review_questlog`
+
+Steps:
+1. Use `shape_work` to create or settle the real work item with ownership clarity embedded in the title, objective, or narrative details.
+2. Use `tag_work` when a lightweight ownership or team classification tag helps portfolio review.
+3. Use `inspect_questlog_item` to confirm the exact wording and current structure of the owned work.
+4. Use `review_questlog` with tag filters when you need to inspect one ownership slice of the portfolio.
+
+Outcome handling:
+- Treat `success` as confirmation that the ownership signal is now present in real work structure or classification.
+- Treat `no_op` as confirmation that the ownership tag or state was already present.
+
+Failure handling:
+- Do not invent an assignee field that the system does not have.
+- Do not hide unclear ownership behind generic task wording.
+- Do not treat tags as a substitute for writing a clear objective or context.

package/skills/questlog/references/manage-approvals-and-promises.md

@@ -0,0 +1,22 @@
+# Manage Approvals And Promises
+
+Primary tools:
+- `shape_work`
+- `organize_work`
+- `plan_quest`
+- `review_questlog`
+
+Steps:
+1. Model the approval step as a concrete quest instead of a hidden note.
+2. Model dependent execution work separately and connect it with `organize_work` unlocks when the approval is a hard prerequisite.
+3. Use `plan_quest` to record the real timing pressure on the approval and the dependent work.
+4. Use `review_questlog` to confirm which approval work is blocked, due soon, or overdue.
+
+Outcome handling:
+- Treat `success` as confirmation that the promise is now visible in real work structure.
+- Treat blocked review results as a truth to manage, not as an inconvenience to hide.
+
+Failure handling:
+- Do not bury approvals inside another quest objective.
+- Do not pretend a promise is safe if the approval quest is already overdue.
+- Do not skip the unlock when the downstream work truly cannot start yet.

package/skills/questlog/references/plan-successor-work.md

@@ -0,0 +1,22 @@
+# Plan Successor Work
+
+Primary tools:
+- `run_quest`
+- `shape_work`
+- `capture_rumor`
+- `inspect_questlog_item`
+
+Steps:
+1. If successor work is already clear at abandonment time, use `run_quest` with `action: "abandon_and_spawn_followups"`.
+2. If the current quest should finish cleanly before successor work is created, use `run_quest` first and then use `shape_work` for the new quest or questline.
+3. If the next step is still fuzzy, use `capture_rumor` instead of inventing a fake follow-up.
+4. Use `inspect_questlog_item` on spawned or newly created work when you need to confirm the handoff.
+
+Outcome handling:
+- Treat `success` as a real successor planning step.
+- Treat `error` from empty follow-up spawn requests as a signal to use plain abandon or another honest path instead.
+
+Failure handling:
+- Do not abandon-and-spawn with an empty follow-up list.
+- Do not invent successor work when the real next step is still uncertain.
+- Do not leave successor work implied but unmodeled when it is already clearly known.

package/skills/questlog/references/plan-time-correctly.md

@@ -0,0 +1,22 @@
+# Plan Time Correctly
+
+Primary tools:
+- `plan_quest`
+- `review_questlog`
+- `inspect_questlog_item`
+
+Steps:
+1. Use `plan_quest` with `action: "set_time"` to change not-before, due, schedule, all-day, or estimate fields.
+2. Use `inspect_questlog_item` when the current timing state needs exact diagnosis before changing it.
+3. Use `review_questlog` to verify the downstream effect in deferred, due-soon, overdue, scheduled-now, or missed-scheduled views.
+4. If the exact timing request is unchanged, accept the `no_op` result instead of forcing meaningless churn.
+
+Outcome handling:
+- Treat `success` as a real planning change.
+- Treat `no_op` as confirmation that the planning state is already correct.
+- Treat `error` as conflicting or invalid timing input that must be repaired before retrying.
+
+Failure handling:
+- Do not use one date field to mean every kind of timing intent.
+- Do not assume a schedule miss is the same as being overdue.
+- Do not re-plan blindly without first understanding the current quest timing state.

package/skills/questlog/references/prioritize-across-streams.md

@@ -0,0 +1,21 @@
+# Prioritize Across Streams
+
+Primary tools:
+- `review_questlog`
+- `inspect_questlog_item`
+- `plan_quest`
+
+Steps:
+1. Use `review_questlog` to assemble the real candidate pool: available, blocked, due-soon, overdue, or questline slices.
+2. Use `inspect_questlog_item` on a candidate when the row is not enough to decide.
+3. Prioritize from the available work, not from blocked wishful thinking.
+4. Reflect the choice in `plan_quest` so the system shows what is actually next.
+
+Outcome handling:
+- Treat blocked candidates as real constraints, not as silent ties.
+- Treat empty views as real signal about the current portfolio state.
+
+Failure handling:
+- Do not choose blocked work as if it were executable now.
+- Do not pretend a priority decision exists if the candidate pool is still unclear.
+- Do not leave the system unchanged after deciding what should move next.

package/skills/questlog/references/protect-capacity-and-focus.md

@@ -0,0 +1,20 @@
+# Protect Capacity And Focus
+
+Primary tools:
+- `review_questlog`
+- `plan_quest`
+- `run_quest`
+
+Steps:
+1. Use `review_questlog` to inspect active, in-progress, scheduled-now, or missed-scheduled load before committing more work.
+2. If too much is scheduled or active at once, use `plan_quest` to rebalance timing instead of pretending everything can move now.
+3. Use `run_quest` only for real execution progress once the load is honest.
+
+Outcome handling:
+- Treat dense scheduled-now or in-progress views as real capacity warnings.
+- Treat empty views as signal too; do not manufacture urgency.
+
+Failure handling:
+- Do not stack new timing commitments on top of already impossible schedules.
+- Do not use execution updates to hide planning overload.
+- Do not confuse availability with realistic capacity.

package/skills/questlog/references/recover-from-modeling-mistakes.md

@@ -0,0 +1,25 @@
+# Recover From Modeling Mistakes
+
+Primary tools:
+- `inspect_questlog_item`
+- `review_questlog`
+- `shape_work`
+- `organize_work`
+- `plan_quest`
+- `retire_work`
+
+Steps:
+1. Diagnose first with `inspect_questlog_item` or the appropriate `review_questlog` view.
+2. Choose the smallest honest fix: re-plan timing, change structure, correct unlocks, archive or hide an item, or reshape successor work.
+3. Prefer a corrective move that preserves truthful history over one that merely makes the surface look cleaner.
+4. Re-run inspect or review after the correction to confirm the model now matches reality.
+
+Outcome handling:
+- Treat `success` as confirmation that the smallest honest correction landed.
+- Treat `no_op` as a clue that the model may already match the intended correction.
+- Treat `error` as a sign you still have not diagnosed the issue precisely enough.
+
+Failure handling:
+- Do not start with mutation before diagnosis.
+- Do not erase real execution history just to hide a modeling error.
+- Do not stack multiple speculative corrections when one targeted fix will do.

package/skills/questlog/references/report-status-and-manage-expectations.md

@@ -0,0 +1,20 @@
+# Report Status And Manage Expectations
+
+Primary tools:
+- `review_questlog`
+- `inspect_questlog_item`
+
+Steps:
+1. Use `review_questlog` to assemble the current slices that matter: available, blocked, in-progress, overdue, resolved, or questlines.
+2. Use `inspect_questlog_item` when one item needs exact detail before you report its state or risk.
+3. Report what the system actually shows instead of compressing everything into one vague summary.
+4. If a stakeholder asks about something that is not in the system, say that explicitly and capture or shape it separately instead of bluffing.
+
+Outcome handling:
+- Treat empty review views as valid status facts.
+- Treat `error` as a bad view or filter contract that must be fixed before reporting.
+
+Failure handling:
+- Do not rely on memory when the system can answer directly.
+- Do not call blocked work available just because it is important.
+- Do not merge resolved and reward-unclaimed states into one misleading status line.

package/skills/questlog/references/revise-or-reshape-commitment.md

@@ -0,0 +1,22 @@
+# Revise Or Reshape Commitment
+
+Primary tools:
+- `inspect_questlog_item`
+- `plan_quest`
+- `run_quest`
+
+Steps:
+1. Use `inspect_questlog_item` to confirm whether the quest has already started or resolved.
+2. If the quest has not started, use `plan_quest` with `action: "revise_objective"` to sharpen the commitment.
+3. If execution has already started, do not rewrite history. Use `run_quest` to finish, abandon, or abandon-and-spawn follow-up work instead.
+4. Accept `no_op` when the requested objective is already the current one.
+
+Outcome handling:
+- Treat `success` as a valid pre-start revision or honest lifecycle reshape.
+- Treat `no_op` as confirmation that the objective already matches.
+- Treat `error` from revise-after-start as a rule you should respect, not bypass.
+
+Failure handling:
+- Do not revise objective text after real execution has begun.
+- Do not hide a broken commitment with wording changes when the truth is that the work must be abandoned or succeeded by follow-ups.
+- Do not guess whether a quest has started; inspect it first.

package/skills/questlog/references/run-operational-review.md

@@ -0,0 +1,24 @@
+# Run Operational Review
+
+Primary tools:
+- `review_questlog`
+- `inspect_questlog_item`
+- `plan_quest`
+- `run_quest`
+
+Steps:
+1. Start with `review_questlog` and choose the right operational surface such as available, blocked, deferred, overdue, in-progress, or scheduled views.
+2. Use `inspect_questlog_item` when one row needs a closer read before acting.
+3. If the review reveals timing drift, use `plan_quest` to correct the planning state.
+4. If the review reveals executable work that should actually move, use `run_quest` for lifecycle progress.
+5. End the review with at least one honest system change when the review uncovered something actionable.
+
+Outcome handling:
+- Treat empty review views as valid `success`.
+- Treat `needs_clarification` as expected when a view like `quests.scheduled_for_day` requires a day choice.
+- Treat `error` as a sign that the chosen view or filter combination is invalid.
+
+Failure handling:
+- Do not substitute search for a structured review surface.
+- Do not stop at observation when the review surfaced a real next action.
+- Do not guess a day-specific schedule view without providing the day.

package/skills/questlog/references/run-recurring-rhythms.md

@@ -0,0 +1,24 @@
+# Run Recurring Rhythms
+
+Primary tools:
+- `manage_repeatable`
+- `review_questlog`
+- `inspect_questlog_item`
+- `run_quest`
+
+Steps:
+1. Use `manage_repeatable` with `action: "create"` to define the recurring pattern with RRULE and anchor timing.
+2. Use `manage_repeatable` with `action: "preview_due"` or `review_questlog` with `view: "repeatables.due_anchors"` to inspect what is due.
+3. Use `manage_repeatable` with `action: "spawn_due"` to materialize real concrete quests.
+4. Use `inspect_questlog_item` or normal execution tools on the spawned quests.
+5. Use `manage_repeatable` with `action: "update"` or `action: "archive"` to change future behavior honestly.
+
+Outcome handling:
+- Treat empty previews as valid `success`.
+- Treat empty spawns as a real no-op instead of a failure.
+- Treat `error` as a repeatable definition or RRULE problem that needs repair.
+
+Failure handling:
+- Do not model recurring work as one permanent open quest.
+- Do not assume repeatables materialize automatically without `spawn_due`.
+- Do not rewrite already spawned history when only the future cadence changed.

package/skills/questlog/references/search-and-retrieve-context.md

@@ -0,0 +1,23 @@
+# Search And Retrieve Context
+
+Primary tools:
+- `search_questlog`
+- `review_questlog`
+- `inspect_questlog_item`
+
+Steps:
+1. Use `search_questlog` for free-text discovery across quests and rumors when you do not know the exact id yet.
+2. Use `mode: "identify_one"` when you need one exact target and want the tool to stop at clarification instead of guessing.
+3. Once you know the item id, switch to `inspect_questlog_item` for exact detail.
+4. If the thing you need is better represented as a structured list or a non-FTS entity kind, use `review_questlog` instead of forcing search to do the wrong job.
+5. Use `detailLevel: "compact"` by default and ask for `detailLevel: "full"` only when the richer payload is truly needed.
+
+Outcome handling:
+- Treat empty `search_questlog` results as valid `success`, not as proof that nothing relevant exists everywhere.
+- Treat `needs_clarification` from identify-one search as a cue to choose a candidate.
+- Treat `error` as a malformed query or invalid target problem.
+
+Failure handling:
+- Do not assume full-text search covers questlines, repeatable definitions, or every relational angle.
+- Do not keep browsing when you already have an exact item id; inspect it.
+- Do not read large full-detail payloads unless the next decision needs them.

package/skills/questlog/references/sequence-with-unlocks.md

@@ -0,0 +1,23 @@
+# Sequence With Unlocks
+
+Primary tools:
+- `organize_work`
+- `review_questlog`
+- `inspect_questlog_item`
+- `shape_work`
+
+Steps:
+1. Create the concrete quests first, then use `organize_work` with `add_unlock`, `remove_unlock`, or `replace_unlocks` to model hard gates.
+2. Use `review_questlog` to confirm the effect in the blocked and available views.
+3. Use `inspect_questlog_item` when the exact unlock graph on one quest needs diagnosis.
+4. Treat unlocks as hard prerequisites, not as soft notes or labels.
+
+Outcome handling:
+- Treat `success` as a real unlock graph change.
+- Treat `no_op` as confirmation that the blocker set already matched.
+- Treat `error` as a real constraint problem such as self-unlock or cycle creation.
+
+Failure handling:
+- Do not use unlocks for work that is merely preferred or informative.
+- Do not ignore blocked review results after adding an unlock.
+- Do not force a dependency graph that violates the cycle rules.

package/skills/questlog/references/settle-rumor-into-structure.md

@@ -0,0 +1,25 @@
+# Settle Rumor Into Structure
+
+Primary tools:
+- `capture_rumor`
+- `shape_work`
+- `inspect_questlog_item`
+- `review_questlog`
+
+Steps:
+1. Use `capture_rumor` first if the incoming work is not already tracked as intake.
+2. When the rumor is ready to graduate, use `shape_work` with `action: "settle_rumor"`.
+3. Include the real downstream structure: one or more quest inputs, a questline input, or both.
+4. If `shape_work` returns `needs_clarification`, answer the missing structure question before retrying.
+5. Use `inspect_questlog_item` on the rumor or created items when you need to confirm provenance and relationships.
+6. Use `review_questlog` with `view: "quests.available"` when you want to verify that the new concrete work is now visible for execution.
+
+Outcome handling:
+- Treat `success` as a real commitment transition out of intake.
+- Treat `needs_clarification` as a normal stop when the downstream structure is still underspecified.
+- Treat `error` as a sign that the target or input contract needs repair before settlement can continue.
+
+Failure handling:
+- If the rumor is still too vague, do not settle it just to clean up intake.
+- If only one concrete next step is known, create that exact structure instead of inventing a larger arc.
+- Do not leave settled work unverifed; inspect or review the result.

package/skills/questlog/references/tag-and-filter-portfolios.md

@@ -0,0 +1,21 @@
+# Tag And Filter Portfolios
+
+Primary tools:
+- `tag_work`
+- `review_questlog`
+- `inspect_questlog_item`
+
+Steps:
+1. Use `tag_work` to add, remove, or replace classification tags on quests and repeatable definitions.
+2. Use `review_questlog` with `filters.tagNames` to review one tagged slice of the portfolio.
+3. Use `inspect_questlog_item` when you need the exact detail of a tagged item before changing its classification.
+
+Outcome handling:
+- Treat `success` as confirmation that the target now has the intended tag set.
+- Treat `no_op` as confirmation that the requested tag state already existed.
+- Treat `error` as an invalid target or unsupported action problem.
+
+Failure handling:
+- Do not use tags to fake lifecycle state or prerequisites.
+- Do not ignore no-op tag responses; they often tell you the portfolio is already classified correctly.
+- Do not filter by tags and assume that is the same as a schedule or dependency review.