@ghostpaw/questlog 0.7.0 → 0.9.0

package/dist/questlog_skill_spec-JLZH3JL2.js

@@ -0,0 +1,807 @@
+#!/usr/bin/env node
+import { questlogMcpInstructions } from './chunk-SVWAEAKC.js';
+import { reviewQuestlogTool, questlogSurfaceTools } from './chunk-3Y5F3SMB.js';
+
+// src/skills/skill_types.ts
+function defineQuestlogSkill(skill) {
+  return skill;
+}
+
+// src/skills/archive-delete-and-prune.ts
+var archiveDeleteAndPruneSkill = defineQuestlogSkill({
+  name: "archive-delete-and-prune",
+  description: "Choose the right retirement action for each kind of work so history stays honest and hiding does not get confused with archival or terminal execution truth.",
+  content: `# Archive Delete And Prune
+
+Primary tools:
+- \`shape_work\`
+- \`organize_work\`
+- \`manage_repeatable\`
+- \`retire_work\`
+- \`run_quest\`
+
+Steps:
+1. Use \`shape_work\` to dismiss rumors when intake should be retired without becoming committed work.
+2. Use \`organize_work\` to archive questlines when the arc is complete but should remain visible as retired structure.
+3. Use \`manage_repeatable\` to archive repeatable definitions when they should stop spawning future work.
+4. Use \`retire_work\` to hide items when they should disappear from active operation while preserving history.
+5. Use \`run_quest\` to abandon real committed work instead of hiding it when the truthful record is that the work ended unsuccessfully.
+
+Outcome handling:
+- Treat \`success\` as confirmation that the right retirement path happened.
+- Treat \`no_op\` from repeated hide as confirmation that the item is already retired that way.
+- Treat \`error\` as a sign that the target or retirement mode is wrong.
+
+Failure handling:
+- Do not soft-hide committed execution work just to make dashboards look tidy.
+- Do not confuse archive with hide.
+- Do not use \`manage_repeatable\` for hiding repeatables now that \`retire_work\` is the canonical hide path.`
+});
+
+// src/skills/choose-work-shape.ts
+var chooseWorkShapeSkill = defineQuestlogSkill({
+  name: "choose-work-shape",
+  description: "Choose the right structure for new work by separating uncertainty, one-shot execution, multi-step arcs, and recurring patterns.",
+  content: `# Choose Work Shape
+
+Primary tools:
+- \`capture_rumor\`
+- \`shape_work\`
+- \`manage_repeatable\`
+- \`inspect_questlog_item\`
+
+Steps:
+1. Use \`capture_rumor\` when the work is still uncertain, interpretive, or politically fuzzy.
+2. Use \`shape_work\` with \`create_quest\` when there is one concrete executable step with one honest objective.
+3. Use \`shape_work\` with \`create_questline\` when several related quests need shared initiative context.
+4. Use \`manage_repeatable\` with \`create\` when the work is a cadence that should spawn fresh quests over time.
+5. Use \`shape_work\` with \`settle_rumor\` when a rumor is ready to graduate into committed quest or questline structure.
+6. Use \`inspect_questlog_item\` after creation when you need to confirm the chosen shape before planning or execution.
+
+Outcome handling:
+- Treat \`success\` as confirmation that the chosen shape now exists in the system.
+- Treat \`needs_clarification\` as a sign that the shape choice is still incomplete and should not be guessed.
+- Treat \`error\` as a sign that the requested shape or inputs are invalid as entered.
+
+Failure handling:
+- If the work feels both vague and actionable, keep it as a rumor until one executable step is truly obvious.
+- Do not create a repeatable just because something happened twice.
+- Do not force a questline when one real quest would be enough.`
+});
+
+// src/skills/clarify-ambiguous-requests.ts
+var clarifyAmbiguousRequestsSkill = defineQuestlogSkill({
+  name: "clarify-ambiguous-requests",
+  description: "Treat ambiguity as a real state, capture uncertainty honestly, and only commit work structure once the next executable shape is clear.",
+  content: `# Clarify Ambiguous Requests
+
+Primary tools:
+- \`capture_rumor\`
+- \`search_questlog\`
+- \`inspect_questlog_item\`
+- \`shape_work\`
+
+Steps:
+1. If the request is still ambiguous, use \`capture_rumor\` instead of forcing it into a quest too early.
+2. Use \`search_questlog\` when the ambiguity might really be duplicate or overlapping work instead of net-new intake.
+3. Use \`inspect_questlog_item\` when you need the exact current state of the intake item before deciding how to commit it.
+4. Once the missing outcome or structure is clear, use \`shape_work\` with the smallest honest action: \`create_quest\`, \`create_questline\`, or \`settle_rumor\`.
+5. If \`shape_work\` returns \`needs_clarification\`, answer the missing branch choice before retrying. Do not guess between quests and questlines.
+
+Outcome handling:
+- Treat \`success\` as a valid clarification milestone or committed structure change.
+- Treat \`needs_clarification\` as expected when the system can see that the request is valid in spirit but still underdetermined.
+- Treat \`error\` as a real contract or state problem that must be repaired before continuing.
+
+Failure handling:
+- If someone wants speed without clarity, record the uncertainty as intake and move forward honestly.
+- If several plausible existing items match, stop at clarification instead of choosing one silently.
+- Do not fabricate a crisp quest objective just to make the system look tidy.`
+});
+
+// src/skills/close-work-and-claim-outcomes.ts
+var closeWorkAndClaimOutcomesSkill = defineQuestlogSkill({
+  name: "close-work-and-claim-outcomes",
+  description: "Close work with the correct terminal lifecycle action, then handle any concrete reward claim as a separate explicit step.",
+  content: `# Close Work And Claim Outcomes
+
+Primary tools:
+- \`run_quest\`
+- \`reward_work\`
+- \`review_questlog\`
+- \`inspect_questlog_item\`
+
+Steps:
+1. Use \`run_quest\` with the correct terminal action: \`finish\` for successful completion or \`abandon\` when the work did not land.
+2. Use \`inspect_questlog_item\` or \`review_questlog\` when you need to confirm the exact post-resolution state.
+3. If rewards exist, use \`reward_work\` with \`action: "claim"\` as a separate follow-up step.
+4. Accept \`no_op\` on repeated reward claim as confirmation that the outcome was already claimed.
+
+Outcome handling:
+- Treat \`success\` as a real terminal lifecycle step or reward claim.
+- Treat \`no_op\` on claim as valid confirmation, not as a failure.
+- Treat \`error\` as a real invalid-state problem that needs diagnosis before retrying.
+
+Failure handling:
+- Do not treat quest finish and reward claim as one hidden operation.
+- Do not leave reward claim ambiguous after successful closure when the reward matters.
+- Do not close work with a fake success outcome when it should be abandoned instead.`
+});
+
+// src/skills/create-concrete-quest.ts
+var createConcreteQuestSkill = defineQuestlogSkill({
+  name: "create-concrete-quest",
+  description: "Create real, bounded executable quests only when the objective is concrete enough to execute without interpretive guesswork.",
+  content: `# Create Concrete Quest
+
+Primary tools:
+- \`shape_work\`
+- \`inspect_questlog_item\`
+- \`plan_quest\`
+
+Steps:
+1. Use \`shape_work\` with \`action: "create_quest"\` only when there is one clear executable objective.
+2. Put shared arc context in a questline, not inside a bloated quest objective.
+3. Use \`inspect_questlog_item\` after creation when you need to confirm the exact quest detail that was created.
+4. Use \`plan_quest\` later for timing or estimate refinement instead of overloading creation with every downstream decision.
+
+Outcome handling:
+- Treat \`success\` as confirmation that a concrete quest now exists.
+- Treat \`error\` as a sign that the requested quest input is invalid and should be repaired before retrying.
+
+Failure handling:
+- If the objective still needs interpretation, go back to intake or clarification instead of creating the quest.
+- If the work is really multi-step, use questline structure instead of one overloaded quest.
+- Do not create a quest whose title and objective hide uncertainty.`
+});
+
+// src/skills/detect-slips-and-staleness.ts
+var detectSlipsAndStalenessSkill = defineQuestlogSkill({
+  name: "detect-slips-and-staleness",
+  description: "Detect work that is slipping or going stale by reading overdue, deferred, in-progress, and related operational views before choosing one recovery move.",
+  content: `# Detect Slips And Staleness
+
+Primary tools:
+- \`review_questlog\`
+- \`inspect_questlog_item\`
+- \`plan_quest\`
+- \`run_quest\`
+
+Steps:
+1. Use \`review_questlog\` to look at overdue, due-soon, deferred, in-progress, or missed-scheduled views.
+2. Use \`inspect_questlog_item\` when one slipping item needs exact diagnosis before action.
+3. If the problem is timing drift, use \`plan_quest\` to repair the planning state.
+4. If the problem is execution drift, use \`run_quest\` for the next real lifecycle move.
+
+Outcome handling:
+- Treat empty stale-work views as valid \`success\`.
+- Treat \`error\` as a bad view or filter choice, not as evidence that the work is healthy.
+
+Failure handling:
+- Do not call work healthy just because it is still open.
+- Do not change timing blindly before you inspect the exact item.
+- Do not assume a stale item is blocked; diagnose it first.`
+});
+
+// src/skills/escalate-and-unblock.ts
+var escalateAndUnblockSkill = defineQuestlogSkill({
+  name: "escalate-and-unblock",
+  description: "Diagnose blockers honestly, then remove or realign hard gates when the model is wrong instead of treating every delay as generic escalation theater.",
+  content: `# Escalate And Unblock
+
+Primary tools:
+- \`review_questlog\`
+- \`inspect_questlog_item\`
+- \`organize_work\`
+- \`plan_quest\`
+
+Steps:
+1. Use \`review_questlog\` to confirm whether work is actually blocked.
+2. Use \`inspect_questlog_item\` to diagnose the exact blocker on the affected quest.
+3. If the unlock graph is wrong, use \`organize_work\` to remove or replace the blocker set.
+4. If the work is not truly blocked, use planning changes instead of fake escalation language.
+
+Outcome handling:
+- Treat \`success\` as a real unblock step.
+- Treat \`error\` as a structural issue that still needs diagnosis.
+
+Failure handling:
+- Do not call work blocked when it is only unclear or underspecified.
+- Do not leave a quest in the blocked state after the model has changed.
+- Do not remove prerequisites casually; inspect before unblocking.`
+});
+
+// src/skills/frame-initiative-questline.ts
+var frameInitiativeQuestlineSkill = defineQuestlogSkill({
+  name: "frame-initiative-questline",
+  description: "Use questlines for shared initiative context, then attach concrete quests and maintain the structure without confusing one quest with one arc.",
+  content: `# Frame Initiative Questline
+
+Primary tools:
+- \`shape_work\`
+- \`organize_work\`
+- \`review_questlog\`
+- \`inspect_questlog_item\`
+
+Steps:
+1. Use \`shape_work\` with \`create_questline\` when several related quests need one umbrella initiative.
+2. Use \`shape_work\` with \`attach_quest_to_questline\` or \`detach_quest_from_questline\` to place concrete quests correctly inside the initiative.
+3. Use \`organize_work\` to update questline fields or archive the questline once the arc is truly retired.
+4. Use \`review_questlog\` and \`inspect_questlog_item\` to verify the initiative health and exact structure.
+
+Outcome handling:
+- Treat \`success\` as a real questline or membership change.
+- Treat \`no_op\` as confirmation that the quest was already attached or detached as requested.
+- Treat \`error\` as a sign that the target ids or structural state are invalid.
+
+Failure handling:
+- Do not create a questline for one isolated executable task.
+- Do not leave membership implied; attach or detach quests explicitly.
+- Do not archive a questline just to hide active work that still matters.`
+});
+
+// src/skills/handle-exceptions-and-weird-cases.ts
+var handleExceptionsAndWeirdCasesSkill = defineQuestlogSkill({
+  name: "handle-exceptions-and-weird-cases",
+  description: "Handle weird cases by diagnosing the actual tool outcome, routing into clarification or recovery when needed, and refusing to fake a clean normal-state story.",
+  content: `# Handle Exceptions And Weird Cases
+
+Primary tools:
+- \`inspect_questlog_item\`
+- \`search_questlog\`
+- \`review_questlog\`
+- then the nearest corrective tool such as \`shape_work\`, \`organize_work\`, \`plan_quest\`, or \`run_quest\`
+
+Steps:
+1. Start with diagnosis, not mutation. Use \`inspect_questlog_item\`, \`search_questlog\`, or \`review_questlog\` depending on what is actually unknown.
+2. If the tool returns \`needs_clarification\`, stop and answer the missing branch instead of guessing.
+3. If the tool returns \`error\`, read the recovery guidance and choose the next corrective tool deliberately.
+4. Only mutate state after the weird case has been made specific enough to model honestly.
+
+Outcome handling:
+- Treat \`success\` as a real answer, even if that answer is an empty review view.
+- Treat \`no_op\` as signal that the requested change was already true.
+- Treat \`needs_clarification\` as expected when the system can enumerate the ambiguity safely.
+- Treat \`error\` as a structured boundary, not as a cue to improvise around the rules.
+
+Failure handling:
+- Do not force a weird case into a fake normal flow just to keep moving.
+- Do not guess among multiple plausible targets.
+- Do not mutate first and inspect later.`
+});
+
+// src/skills/intake-triage.ts
+var intakeTriageSkill = defineQuestlogSkill({
+  name: "intake-triage",
+  description: "Triage new asks, ideas, and vague incoming work into the right next step without prematurely committing execution structure.",
+  content: `# Intake Triage
+
+Primary tools:
+- \`search_questlog\`
+- \`capture_rumor\`
+- \`inspect_questlog_item\`
+- \`shape_work\`
+
+Steps:
+1. Start with \`search_questlog\` when the ask might duplicate existing work. Use \`mode: "identify_one"\` when you need one exact target instead of a browse list.
+2. If the work is still vague, risky, or under-specified, use \`capture_rumor\` with only the minimum facts that explain what arrived and why it matters.
+3. Use \`inspect_questlog_item\` on the returned rumor id when you need to confirm the intake record before deciding what to do next.
+4. Use \`shape_work\` for the next honest transition: \`dismiss_rumor\`, \`reopen_rumor\`, or later \`settle_rumor\`.
+5. If the ask is already clearly executable, hand off to \`shape_work\` with \`create_quest\` or \`create_questline\` instead of letting it rot in intake.
+
+Outcome handling:
+- Treat \`success\` as a usable search or intake result.
+- Treat \`no_op\` as confirmation that the rumor is already in the requested state.
+- Treat \`needs_clarification\` from \`search_questlog\` as a stop signal: choose among the returned candidates instead of guessing.
+- Treat \`error\` as a cue to repair the query or target before continuing.
+
+Failure handling:
+- If the ask is urgent but unclear, still capture it first instead of inventing execution detail.
+- If similar work already exists, reuse or update that thread instead of creating parallel intake.
+- Do not create a quest just because someone asked for something.`
+});
+
+// src/skills/maintain-clear-ownership.ts
+var maintainClearOwnershipSkill = defineQuestlogSkill({
+  name: "maintain-clear-ownership",
+  description: "Keep ownership explicit through quest content and classification because Questlog does not provide a separate assignee field or ownership tool.",
+  content: `# 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.`
+});
+
+// src/skills/manage-approvals-and-promises.ts
+var manageApprovalsAndPromisesSkill = defineQuestlogSkill({
+  name: "manage-approvals-and-promises",
+  description: "Treat approvals and commitments as modeled work with timing and dependencies instead of burying them as vague narrative promises.",
+  content: `# 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.`
+});
+
+// src/skills/plan-successor-work.ts
+var planSuccessorWorkSkill = defineQuestlogSkill({
+  name: "plan-successor-work",
+  description: "Create explicit successor work after closure by spawning follow-ups or shaping new work, while keeping uncertain next steps in intake instead of faking certainty.",
+  content: `# 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.`
+});
+
+// src/skills/plan-time-correctly.ts
+var planTimeCorrectlySkill = defineQuestlogSkill({
+  name: "plan-time-correctly",
+  description: "Use quest planning fields honestly so availability, due pressure, and schedule intent stay meaningful instead of getting collapsed into one generic date.",
+  content: `# 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.`
+});
+
+// src/skills/prioritize-across-streams.ts
+var prioritizeAcrossStreamsSkill = defineQuestlogSkill({
+  name: "prioritize-across-streams",
+  description: "Prioritize across competing work streams by reading real candidate sets, distinguishing available from blocked work, and then reflecting the choice in planning.",
+  content: `# 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.`
+});
+
+// src/skills/protect-capacity-and-focus.ts
+var protectCapacityAndFocusSkill = defineQuestlogSkill({
+  name: "protect-capacity-and-focus",
+  description: "Protect capacity and focus by reading the real in-progress and scheduled-now load, then using planning to rebalance instead of silently overcommitting.",
+  content: `# 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.`
+});
+
+// src/skills/recover-from-modeling-mistakes.ts
+var recoverFromModelingMistakesSkill = defineQuestlogSkill({
+  name: "recover-from-modeling-mistakes",
+  description: "Recover from modeling mistakes by diagnosing the exact current state first, then applying the smallest honest corrective tool instead of rewriting history blindly.",
+  content: `# 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.`
+});
+
+// src/skills/report-status-and-manage-expectations.ts
+var reportStatusAndManageExpectationsSkill = defineQuestlogSkill({
+  name: "report-status-and-manage-expectations",
+  description: "Build status reporting from the real questlog state, separating available, blocked, in-progress, slipping, and resolved work without relying on memory.",
+  content: `# 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.`
+});
+
+// src/skills/revise-or-reshape-commitment.ts
+var reviseOrReshapeCommitmentSkill = defineQuestlogSkill({
+  name: "revise-or-reshape-commitment",
+  description: "Revise a quest objective before execution starts, but reshape commitments honestly with lifecycle tools once real execution history exists.",
+  content: `# 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.`
+});
+
+// src/skills/run-operational-review.ts
+var runOperationalReviewSkill = defineQuestlogSkill({
+  name: "run-operational-review",
+  description: "Drive daily or weekly operational review from structured list views, then move from diagnosis into actual planning or execution changes.",
+  content: `# 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.`
+});
+
+// src/skills/run-recurring-rhythms.ts
+var runRecurringRhythmsSkill = defineQuestlogSkill({
+  name: "run-recurring-rhythms",
+  description: "Model recurring work as repeatable definitions that spawn fresh concrete quests over time instead of living forever as one immortal task.",
+  content: `# 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.`
+});
+
+// src/skills/search-and-retrieve-context.ts
+var searchAndRetrieveContextSkill = defineQuestlogSkill({
+  name: "search-and-retrieve-context",
+  description: "Find relevant questlog context quickly, then switch from discovery to exact inspection without confusing free-text search with structured review surfaces.",
+  content: `# 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.`
+});
+
+// src/skills/sequence-with-unlocks.ts
+var sequenceWithUnlocksSkill = defineQuestlogSkill({
+  name: "sequence-with-unlocks",
+  description: "Model hard sequencing with unlocks between concrete quests so blocked and available work stay truthful and reviewable.",
+  content: `# 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.`
+});
+
+// src/skills/settle-rumor-into-structure.ts
+var settleRumorIntoStructureSkill = defineQuestlogSkill({
+  name: "settle-rumor-into-structure",
+  description: "Turn a ready rumor into committed quest or questline structure without losing provenance or pretending vague intake is settled.",
+  content: `# 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.`
+});
+
+// src/skills/tag-and-filter-portfolios.ts
+var tagAndFilterPortfoliosSkill = defineQuestlogSkill({
+  name: "tag-and-filter-portfolios",
+  description: "Use tags for cross-cutting classification and portfolio filtering without confusing tags for status, timing, or dependency modeling.",
+  content: `# 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.`
+});
+
+// src/skills/skill_registry.ts
+var questlogSkills = [
+  archiveDeleteAndPruneSkill,
+  chooseWorkShapeSkill,
+  clarifyAmbiguousRequestsSkill,
+  closeWorkAndClaimOutcomesSkill,
+  createConcreteQuestSkill,
+  detectSlipsAndStalenessSkill,
+  escalateAndUnblockSkill,
+  frameInitiativeQuestlineSkill,
+  handleExceptionsAndWeirdCasesSkill,
+  intakeTriageSkill,
+  maintainClearOwnershipSkill,
+  manageApprovalsAndPromisesSkill,
+  planSuccessorWorkSkill,
+  planTimeCorrectlySkill,
+  prioritizeAcrossStreamsSkill,
+  protectCapacityAndFocusSkill,
+  recoverFromModelingMistakesSkill,
+  reportStatusAndManageExpectationsSkill,
+  reviseOrReshapeCommitmentSkill,
+  runOperationalReviewSkill,
+  runRecurringRhythmsSkill,
+  searchAndRetrieveContextSkill,
+  sequenceWithUnlocksSkill,
+  settleRumorIntoStructureSkill,
+  tagAndFilterPortfoliosSkill
+];
+
+// src/soul.ts
+var questlogSoulTraits = [
+  {
+    principle: "Store the least committed truth first.",
+    provenance: "The worst downstream errors usually start upstream: vague asks are turned into quests, soft ideas become fake deadlines, and half-understood work is treated as fully shaped. Using rumors and clarification before commitment keeps uncertainty where it belongs."
+  },
+  {
+    principle: "Read before you prescribe.",
+    provenance: "Many management mistakes are category mistakes: blocked work gets treated as available, missed schedule as overdue, or resolved work as fully closed when follow-through still remains. Reading the derived state first prevents confident but wrong interventions."
+  },
+  {
+    principle: "Protect history when reality changes.",
+    provenance: "Once execution starts, rewriting a quest into a different commitment destroys the meaning of the record. Honest finishes, abandonments, and follow-up quests preserve what actually happened and keep later review, planning, and reporting trustworthy."
+  },
+  {
+    principle: "Close the last mile, not just the main work.",
+    provenance: "Operational debt often hides in almost-done states: work finished but not claimed, reported, handed off, reviewed, or retired. Treating closure as a real phase prevents stale rewards, lingering initiatives, and misleading progress signals."
+  }
+];
+
+// src/surface/questlog_skill_spec.ts
+var questlogSkillSpec = {
+  name: "questlog",
+  cheatSheet: [
+    "`questlog` and `ghostpaw-questlog` are the same binary.",
+    "",
+    '- `questlog add --title "..." --tag a,b --due tomorrow`',
+    `- \`questlog list [--view <view>]\`: ${reviewQuestlogTool.inputSchema.properties?.view?.enum?.join(", ")}.`,
+    '- `questlog done <id> --outcome "..."`',
+    "- `questlog search <words>`",
+    "- `questlog show <id>`",
+    "- Use `--json` on any plain command.",
+    "- Exit codes: 0 ok / 1 error / 2 usage / 3 needs input.",
+    "- Database: `~/.ghostpaw/questlog.db`; override with `--db` or `GHOSTPAW_QUESTLOG_DB`.",
+    "- Use one database per agent or project."
+  ].join("\n"),
+  description: "Manage local tasks, calendar commitments, and recurring work. Use when planning, executing, reviewing, or organizing work.",
+  license: "MIT",
+  compatibility: "Node.js 24 or newer. MCP stdio or ghostpaw-questlog CLI.",
+  bin: "ghostpaw-questlog",
+  packageName: "@ghostpaw/questlog",
+  server: "ghostpaw-questlog",
+  about: questlogMcpInstructions,
+  tools: questlogSurfaceTools,
+  workflows: questlogSkills,
+  principles: questlogSoulTraits.map((trait) => trait.principle)
+};
+
+export { questlogSkillSpec };