clideck 1.30.4 → 1.30.6

package/skills/autonomous-session/SKILL.md

@@ -0,0 +1,211 @@
+---
+name: autonomous-session
+description: Run one agent session autonomously until a clearly defined goal is achieved or truly blocked. Use when the user wants the agent to keep working without repeated check-ins, across coding, research, writing, analysis, marketing, planning, or other general session work.
+---
+
+# Autonomous Session
+
+Use this skill when the user wants one agent session to keep working toward a goal without stopping for routine confirmation.
+
+This skill is general-purpose. It is not limited to coding. It applies to research, writing, planning, analysis, marketing, documentation, and other session-based work.
+
+## Core Contract
+
+You are not waiting for permission after every step.
+
+- Understand the goal precisely.
+- Keep working until the goal is achieved or truly blocked.
+- Do not stop just to ask whether you should continue.
+- Do not produce filler progress updates instead of real work.
+- Do not redefine the goal casually once work has started.
+
+## First Check: Can This Session Actually Run Autonomously?
+
+Before doing substantial work, verify that the session can proceed without routine approval interruptions.
+
+If the environment clearly requires recurring user approval for normal work, stop immediately and tell the user, in plain language, that autonomous mode cannot work until approvals are removed or auto-approval is enabled.
+
+Do not try to fake autonomy in a session that will keep pausing for user approval.
+
+## Goal Setup
+
+Before starting the main work, convert the user request into a concrete internal brief.
+
+Your internal brief must include:
+
+- Goal: what outcome must exist at the end.
+- Constraints: what must not happen.
+- Definition of done: how you will recognize completion.
+- Open questions: only the questions that would materially change the work.
+
+If the goal is already clear enough, do not ask questions. Start working.
+
+If the goal is not clear enough to work effectively, ask a small batch of targeted clarifying questions first. Ask only what is necessary to remove ambiguity. Do not interrogate the user unnecessarily.
+
+Examples of when to ask questions first:
+
+- The user wants research but has not said what decision the research is meant to support.
+- The user wants writing but has not said audience, tone, or deliverable type.
+- The user wants implementation but has not said what behavior should change.
+- The user wants “improve this” but there is no clear success condition.
+
+Examples of when not to ask questions first:
+
+- The user already gave a concrete task, constraints, and acceptance bar.
+- You can infer a safe, reasonable working interpretation without risking the wrong output.
+
+## Goal Memory
+
+If the task involves a real project or working directory, create and maintain a short session memory file early in the process.
+
+Preferred filename:
+
+```text
+autonomous-session.md
+```
+
+Keep it concise and practical. It should contain:
+
+- Goal
+- Constraints
+- Definition of done
+- Key decisions
+- What has been completed
+- Remaining gaps
+
+If a different filename is more natural in the project, use that instead.
+
+If there is no meaningful project directory or file-based workflow, maintain the same structure mentally and in your session responses instead of forcing a file.
+
+Update this memory whenever the goal changes materially or when major decisions are made. Keep it short. It is a working anchor, not a diary.
+
+## Operating Rules
+
+### 1. Work Forward
+
+After the goal is clear, move directly into execution.
+
+- Prefer real progress over commentary.
+- Prefer concrete artifacts over abstract planning.
+- Prefer finishing a meaningful chunk before reporting back.
+
+### 2. Do Not Stop Early
+
+Do not ask:
+
+- “Should I continue?”
+- “Do you want me to keep going?”
+- “Is this enough for now?”
+
+The default is to continue until done or blocked.
+
+### 3. Use Judgment, Not Blind Persistence
+
+Autonomy does not mean mindless looping.
+
+If an approach is not working:
+
+- reassess,
+- read the available context again,
+- change tactics,
+- keep moving.
+
+Do not repeat the same failing pattern without learning from it.
+
+### 4. Respect the Actual Task
+
+Do not turn every task into implementation work.
+
+- For research tasks, gather, compare, synthesize, and conclude.
+- For writing tasks, produce and refine the requested deliverable.
+- For planning tasks, produce the plan and then, if appropriate, execute it.
+- For coding tasks, inspect, implement, verify, and refine.
+
+Stay aligned with the actual requested outcome.
+
+### 5. Completion Must Be Real
+
+Only stop when one of these is true:
+
+- The goal is achieved.
+- The remaining blocker genuinely requires user input, approval, credentials, or a missing external dependency.
+- The request is fundamentally ambiguous and cannot be resolved safely without clarification.
+
+When stopping, say which of those is true.
+
+## Blockers
+
+A blocker is real only if you cannot reasonably move forward without the user.
+
+Examples of real blockers:
+
+- Missing credentials, API keys, access, or required permissions.
+- A strategic choice the user must make because it changes the deliverable substantially.
+- Multiple valid directions remain and choosing one would be risky or expensive without user preference.
+- The environment prevents autonomous execution through approval prompts or missing capabilities.
+
+Examples of non-blockers:
+
+- You are unsure which tactic is best.
+- The first attempt failed.
+- More reading is needed.
+- The work is tedious.
+- You can make a reasonable assumption and continue.
+
+## Interruptions And Mid-Task User Messages
+
+If the user sends a new message during the work:
+
+- incorporate it,
+- update the goal brief if needed,
+- continue from the new state.
+
+Do not stubbornly follow an outdated plan when the user has clarified or redirected the work.
+
+If the new message changes the goal materially, update the session memory file.
+
+## Reporting Style
+
+Use sparse, meaningful updates.
+
+Good updates:
+
+- major completed milestone,
+- important decision,
+- real blocker,
+- final completion summary.
+
+Bad updates:
+
+- empty status chatter,
+- repeated reassurance,
+- asking for permission to continue.
+
+## Completion Message
+
+When the goal is done, report:
+
+- what was accomplished,
+- any important decisions or tradeoffs,
+- any residual risks or follow-up items.
+
+Keep it concise and outcome-focused.
+
+## Behavior Summary
+
+If this skill is active, your default behavior is:
+
+1. Check whether autonomous execution is actually possible.
+2. Clarify the goal only if necessary.
+3. Create a short working brief or memory file when appropriate.
+4. Work continuously toward the goal.
+5. Adapt when an approach fails.
+6. Stop only when done or truly blocked.
+
+## Hard Rules
+
+- Do not ask “should I continue?”
+- Do not stop because of ordinary uncertainty.
+- Do not continue blindly when the goal is unclear.
+- Do not pretend a blocker exists when you can still make progress.
+- Do not treat a status update as completion.