Skip to content

fix: make skills ask focused questions - #201

Merged
Astro-Han merged 1 commit into
devfrom
fix/skill-questions
Apr 23, 2026
Merged

fix: make skills ask focused questions#201
Astro-Han merged 1 commit into
devfrom
fix/skill-questions

Conversation

@Astro-Han

@Astro-Han Astro-Han commented Apr 23, 2026

Copy link
Copy Markdown
Owner

Summary

Update the three bundled productivity skills so clarifying questions are routed through the question tool with focused 2 to 4 question rounds, recommended defaults, multiple-choice guidance, and clearer stop conditions. Update the bundled skill test so it protects this intended behavior instead of blocking question tool references.

Why

The document, data, and writing skills all said to ask clarifying questions first, but they did not bind that behavior to the question tool or give weaker models enough structure to decide when to ask, when to use a default, and when to stop. This made proactive questioning unstable and could also make writing over-ask without collecting structured answers.

Related Issue

Part of #188.

How To Verify

Ran targeted Bun tests for bundled skill loading, question tool execution, and pending question handling from packages/opencode. Also ran git diff check.

bun test --timeout 30000 test/skill/skill.test.ts test/tool/question.test.ts test/question/question.test.ts
git diff --check

Screenshots or Recordings

Not applicable. This changes skill instructions and tests only.

Checklist

  • I linked the related issue, or stated why there is no issue
  • This PR has type, scope, and priority labels, or I requested maintainer labeling
  • I listed the relevant verification steps, including tests when behavior changed
  • I manually checked visible UI or copy changes when needed, with screenshots or recordings
  • I considered macOS and Windows impact for desktop, packaging, updater, signing, paths, shell, or permissions changes
  • I called out docs, release notes, dependencies, permissions, credentials, deletion behavior, or generated/local file changes when relevant
  • I am targeting dev, and my PR title and commit messages use Conventional Commits in English

Summary by CodeRabbit

  • New Features

    • Skills now use a structured clarification process (typically 2–4 focused questions) before main work and include explicit decision rules for when clarification is required versus when defaults apply
    • Added “Success check” prompts to define intended post-output use
  • Documentation

    • Clarified workflows for data analysis, document processing, and writing to emphasize goal-focused questioning and preservation of constraints
  • Tests

    • Updated tests to expect the new clarification content and success/decision fields

@Astro-Han Astro-Han added enhancement New feature or request P2 Medium priority harness Model harness, prompts, tool descriptions, and session mechanics labels Apr 23, 2026
@coderabbitai

coderabbitai Bot commented Apr 23, 2026

Copy link
Copy Markdown
Contributor

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: c5a7bb10-d77a-44d8-a5c6-b6bc68247a28

📥 Commits

Reviewing files that changed from the base of the PR and between ecdbb58 and b269696.

📒 Files selected for processing (4)
  • packages/opencode/test/skill/skill.test.ts
  • skills/data-analysis/SKILL.md
  • skills/document-processing/SKILL.md
  • skills/writing-assistant/SKILL.md
📜 Recent review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (12)
  • GitHub Check: unit-windows-desktop
  • GitHub Check: unit-windows-opencode-server-tools
  • GitHub Check: unit-windows-opencode-session
  • GitHub Check: unit-windows-opencode-config-project
  • GitHub Check: unit-windows-app
  • GitHub Check: unit-desktop
  • GitHub Check: typecheck
  • GitHub Check: unit-opencode
  • GitHub Check: unit-app
  • GitHub Check: smoke-macos-arm64
  • GitHub Check: analyze-js-ts
  • GitHub Check: e2e-artifacts
🧰 Additional context used
📓 Path-based instructions (2)
packages/opencode/**/*.ts

📄 CodeRabbit inference engine (packages/opencode/AGENTS.md)

packages/opencode/**/*.ts: Use Effect.gen(function* () { ... }) for Effect composition
Use Effect.fn("Domain.method") for named/traced effects and Effect.fnUntraced for internal helpers; these accept pipeable operators as extra arguments to avoid unnecessary outer .pipe() wrappers
Use Effect.callback for callback-based APIs
Prefer DateTime.nowAsDate over new Date(yield* Clock.currentTimeMillis) when you need a Date in Effect code
Use Schema.Class for multi-field data in Effect schemas
Use branded schemas (Schema.brand) for single-value types in Effect
Use Schema.TaggedErrorClass for typed errors in Effect schemas
Use Schema.Defect instead of unknown for defect-like causes in Effect code
In Effect.gen / Effect.fn, prefer yield* new MyError(...) over yield* Effect.fail(new MyError(...)) for direct early-failure branches
Use makeRuntime from src/effect/run-service.ts for all services; it returns { runPromise, runFork, runCallback } backed by a shared memoMap that deduplicates layers
Use InstanceState from src/effect/instance-state.ts for per-directory or per-project state that needs per-instance cleanup; do work directly in the InstanceState.make closure where ScopedCache handles run-once semantics
Use Effect.addFinalizer or Effect.acquireRelease inside the InstanceState.make closure for cleanup (subscriptions, process teardown, etc.)
Use Effect.forkScoped inside the InstanceState.make closure for background stream consumers — the fiber is interrupted when the instance is disposed
Prefer FileSystem.FileSystem instead of raw fs/promises for effectful file I/O in Effect services
Prefer ChildProcessSpawner.ChildProcessSpawner with ChildProcess.make(...) instead of custom process wrappers in Effect services
Prefer HttpClient.HttpClient instead of raw fetch in Effect services
Prefer Path.Path, Config, Clock, and DateTime services when those concerns are already inside Effect code
For backgroun...

Files:

  • packages/opencode/test/skill/skill.test.ts
packages/opencode/test/**/*.test.{ts,tsx}

📄 CodeRabbit inference engine (packages/opencode/test/AGENTS.md)

packages/opencode/test/**/*.test.{ts,tsx}: Use the tmpdir function from fixture/fixture.ts to create temporary directories for tests with automatic cleanup. Use await using syntax to ensure automatic cleanup when the variable goes out of scope.
When using the tmpdir function with git repository support, pass the git: true option to initialize a git repo with a root commit.
Use the config option in tmpdir to write an opencode.json config file during test setup by passing a partial Config.Info object.
Use the init option in tmpdir to define custom setup functions that can return extra data accessible via tmp.extra, and use the dispose option for custom cleanup logic.
Use testEffect(...) from test/lib/effect.ts for tests that exercise Effect services or Effect-based workflows.
Use it.effect(...) when the test should run with TestClock and TestConsole. Use it.live(...) when the test depends on real time, filesystem mtimes, child processes, git, locks, or other live OS behavior.
Prefer Effect-aware helpers from fixture/fixture.ts over building manual runtimes in tests: use tmpdirScoped() for scoped temp directories, provideInstance(dir)(effect) for low-level binding without directory creation, provideTmpdirInstance(...) for single temp instance binding, or provideTmpdirServer(...) for tests that also need the test LLM server.
Define const it = testEffect(...) near the top of the test file and keep the test body inside Effect.gen(function* () { ... }). Yield services directly with yield* MyService.Service or yield* MyTool.
Avoid custom ManagedRuntime, attach(...), or ad hoc run(...) wrappers in Effect tests when testEffect(...) already provides the runtime.
When a test needs instance-local state, prefer provideTmpdirInstance(...) or provideInstance(...) over manual Instance.provide(...) inside Promise-style tests.

Files:

  • packages/opencode/test/skill/skill.test.ts
🧠 Learnings (4)
📚 Learning: 2026-04-22T08:49:44.563Z
Learnt from: Astro-Han
Repo: Astro-Han/pawwork PR: 126
File: packages/desktop-electron/src/main/index-sidecar-source.test.ts:3-11
Timestamp: 2026-04-22T08:49:44.563Z
Learning: In `packages/desktop-electron/src/main/index-sidecar-source.test.ts` (Astro-Han/pawwork), the test intentionally uses `expect(source).toContain` / `expect(source).not.toContain` string matching against the raw `index.ts` source text as a lightweight sidecar contract guard. The maintainer has explicitly chosen not to introduce an AST parser (e.g., `babel/parser` or acorn) for this purpose. Do not flag these string-based assertions as fragile or suggest converting them to AST-based matching.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
📚 Learning: 2026-04-20T14:36:31.017Z
Learnt from: CR
Repo: Astro-Han/pawwork PR: 0
File: packages/opencode/test/AGENTS.md:0-0
Timestamp: 2026-04-20T14:36:31.017Z
Learning: Applies to packages/opencode/test/**/*.test.{ts,tsx} : Define `const it = testEffect(...)` near the top of the test file and keep the test body inside `Effect.gen(function* () { ... })`. Yield services directly with `yield* MyService.Service` or `yield* MyTool`.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
📚 Learning: 2026-04-20T14:36:04.099Z
Learnt from: CR
Repo: Astro-Han/pawwork PR: 0
File: packages/app/e2e/AGENTS.md:0-0
Timestamp: 2026-04-20T14:36:04.099Z
Learning: Applies to packages/app/e2e/**/*.spec.ts : Use locator assertions like `toBeVisible()`, `toHaveCount(0)`, and `toHaveAttribute(...)` for normal UI state verification

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
📚 Learning: 2026-04-23T08:51:00.819Z
Learnt from: Astro-Han
Repo: Astro-Han/pawwork PR: 186
File: packages/opencode/test/plugin/workspace-adaptor.test.ts:139-144
Timestamp: 2026-04-23T08:51:00.819Z
Learning: For pawwork tests under packages/opencode/test/**, auth.json teardown may intentionally combine `Filesystem.write` (from `packages/opencode/src/util/filesystem.ts`) with `node:fs/promises` `unlink` for cleanup. Do not flag this as inconsistent style; it is the established/intentional pattern because `Filesystem` does not provide a `remove`/`unlink` helper.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
🔇 Additional comments (8)
skills/document-processing/SKILL.md (2)

11-21: Strong gate update for focused clarifications.

The new rule set is clear, actionable, and aligns with the PR objective to avoid over-asking while still protecting critical constraints.


25-37: Step-1 checklist is well-structured and complete.

Adding **Success check** improves output targeting and should reduce unnecessary follow-up rounds.

packages/opencode/test/skill/skill.test.ts (2)

502-513: Contract assertions now correctly guard the new question-tool behavior.

These checks meaningfully enforce focused-round and stopping-rule wording in bundled skills.


521-535: Great coverage of newly introduced clarification anchors.

Adding these explicit expectations strengthens regression protection for all three bundled productivity skills.

skills/data-analysis/SKILL.md (2)

11-21: Gate logic is precise and decision-oriented.

The criteria for when to ask vs default are clear and well-tuned for analysis tasks.


25-37: Step-1 inputs are materially improved.

**Decision use** is a strong addition that should improve analysis quality and right-size caution.

skills/writing-assistant/SKILL.md (2)

11-21: Gate update improves safety and control for drafting.

The revised ask/default/stop logic is clear and should make behavior more consistent across model quality levels.


25-37: Clarify checklist is stronger and outcome-focused.

**Success check** plus conditional key-point questioning should improve first-draft relevance.


📝 Walkthrough

Walkthrough

This PR updates three productivity skill docs to require structured clarification via a question tool (with limited, focused question rounds and explicit decision rules) and updates a bundled-skills test to assert these tooling and phrasing changes.

Changes

Cohort / File(s) Summary
Test Verification
packages/opencode/test/skill/skill.test.ts
Test updated to assert presence of the backticked question tool and explicit instruction phrasing about question counts, recommended-answer guidance, stopping conditions, decision-rule wording, and required "Must ask"/formatting directives in bundled skills.
Skill Documentation — Data Analysis
skills/data-analysis/SKILL.md
Gate text revised to focus on the decision the analysis must support; adds Decision use input; requires use of question tool for missing context with 2–4 focused questions, rules for when answers are mandatory vs defaults, and guidance for single multiple-choice questions.
Skill Documentation — Document Processing
skills/document-processing/SKILL.md
Clarification step reworked to require discovering preservations/constraints before file operations; enforces question tool use with structured 2–4 focused questions, supports recommended defaults/multiple-selection, and adds a Success check prompt to the Step 1 checklist.
Skill Documentation — Writing Assistant
skills/writing-assistant/SKILL.md
Drafting gate updated to require goal/audience/source material checks; mandates question tool for missing context with focused multi-question rounds (2–4), clarifies mandatory vs defaultable questions, makes "Key points" conditional, and adds a Success check item.

Sequence Diagram(s)

sequenceDiagram
    actor User
    participant SkillGate as Skill Gate
    participant QTool as Question Tool
    participant SkillMain as Skill Main Logic

    User->>SkillGate: Invoke skill with request
    SkillGate->>SkillGate: Evaluate context & Decision use / Success check
    alt Mandatory clarification needed
        SkillGate->>QTool: Ask 2–4 focused questions
        QTool->>User: Present questions
        User->>QTool: Provide answers
        QTool->>SkillGate: Return clarified context
    else Use safe defaults or single-choice prompt
        SkillGate->>SkillGate: Apply defaults or ask MCQ
    end
    SkillGate->>SkillMain: Proceed with clarified context
    SkillMain->>User: Deliver output
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Poem

🐰 I hop and ask before I start,

Two to four questions, straight and smart,
Decisions clear, defaults in place,
Now skills proceed with steadier pace,
—the rabbit nods, satisfied and calm.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title 'fix: make skills ask focused questions' directly summarizes the main change—routing skill clarifying questions through the question tool with focused, structured rounds.
Description check ✅ Passed The PR description covers all required template sections: a clear summary of changes, explanation of the problem and goals, linked related issue (#188), specific verification steps with commands, acknowledgment that UI changes don't apply, and a completed checklist.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/skill-questions

Comment @coderabbitai help to get the list of available commands and usage tips.

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request updates the clarification guidelines for the Data Analysis, Document Processing, and Writing Assistant skills to standardize the use of the question tool. It introduces a 2-4 question guideline for clarification rounds, provides decision rules for when to ask questions versus using defaults, and updates the test suite to reflect these changes. The review feedback suggests relaxing the rigid question count to typically 2-4 to avoid redundancy and refining the writing assistant's logic to ensure it still checks for additional user details even when the initial input seems sufficient.

Comment thread skills/data-analysis/SKILL.md Outdated
Comment thread skills/document-processing/SKILL.md Outdated
Comment thread skills/writing-assistant/SKILL.md Outdated
Comment thread skills/writing-assistant/SKILL.md

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@packages/opencode/test/skill/skill.test.ts`:
- Around line 502-513: The test strengthens shared assertions for skill docs but
misses checks for the new clarification anchors; update the assertions that
inspect the generated content (the same block that currently checks for
"`question` tool", "2-4 questions", etc.) to also assert content contains the
new anchors "**Success check**" and "**Decision use**" (match the exact bolded
phrases) so the contract test will fail if those prompt sections are removed or
renamed.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 54aacd96-cee6-4394-8ea7-676b65e37ec1

📥 Commits

Reviewing files that changed from the base of the PR and between bb59ad5 and ecdbb58.

📒 Files selected for processing (4)
  • packages/opencode/test/skill/skill.test.ts
  • skills/data-analysis/SKILL.md
  • skills/document-processing/SKILL.md
  • skills/writing-assistant/SKILL.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
  • GitHub Check: unit-windows-app
  • GitHub Check: unit-opencode
  • GitHub Check: unit-windows-opencode-session
  • GitHub Check: unit-windows-desktop
  • GitHub Check: unit-windows-opencode-config-project
  • GitHub Check: unit-windows-opencode-server-tools
  • GitHub Check: smoke-macos-arm64
  • GitHub Check: e2e-artifacts
  • GitHub Check: analyze-js-ts
🧰 Additional context used
📓 Path-based instructions (2)
packages/opencode/**/*.ts

📄 CodeRabbit inference engine (packages/opencode/AGENTS.md)

packages/opencode/**/*.ts: Use Effect.gen(function* () { ... }) for Effect composition
Use Effect.fn("Domain.method") for named/traced effects and Effect.fnUntraced for internal helpers; these accept pipeable operators as extra arguments to avoid unnecessary outer .pipe() wrappers
Use Effect.callback for callback-based APIs
Prefer DateTime.nowAsDate over new Date(yield* Clock.currentTimeMillis) when you need a Date in Effect code
Use Schema.Class for multi-field data in Effect schemas
Use branded schemas (Schema.brand) for single-value types in Effect
Use Schema.TaggedErrorClass for typed errors in Effect schemas
Use Schema.Defect instead of unknown for defect-like causes in Effect code
In Effect.gen / Effect.fn, prefer yield* new MyError(...) over yield* Effect.fail(new MyError(...)) for direct early-failure branches
Use makeRuntime from src/effect/run-service.ts for all services; it returns { runPromise, runFork, runCallback } backed by a shared memoMap that deduplicates layers
Use InstanceState from src/effect/instance-state.ts for per-directory or per-project state that needs per-instance cleanup; do work directly in the InstanceState.make closure where ScopedCache handles run-once semantics
Use Effect.addFinalizer or Effect.acquireRelease inside the InstanceState.make closure for cleanup (subscriptions, process teardown, etc.)
Use Effect.forkScoped inside the InstanceState.make closure for background stream consumers — the fiber is interrupted when the instance is disposed
Prefer FileSystem.FileSystem instead of raw fs/promises for effectful file I/O in Effect services
Prefer ChildProcessSpawner.ChildProcessSpawner with ChildProcess.make(...) instead of custom process wrappers in Effect services
Prefer HttpClient.HttpClient instead of raw fetch in Effect services
Prefer Path.Path, Config, Clock, and DateTime services when those concerns are already inside Effect code
For backgroun...

Files:

  • packages/opencode/test/skill/skill.test.ts
packages/opencode/test/**/*.test.{ts,tsx}

📄 CodeRabbit inference engine (packages/opencode/test/AGENTS.md)

packages/opencode/test/**/*.test.{ts,tsx}: Use the tmpdir function from fixture/fixture.ts to create temporary directories for tests with automatic cleanup. Use await using syntax to ensure automatic cleanup when the variable goes out of scope.
When using the tmpdir function with git repository support, pass the git: true option to initialize a git repo with a root commit.
Use the config option in tmpdir to write an opencode.json config file during test setup by passing a partial Config.Info object.
Use the init option in tmpdir to define custom setup functions that can return extra data accessible via tmp.extra, and use the dispose option for custom cleanup logic.
Use testEffect(...) from test/lib/effect.ts for tests that exercise Effect services or Effect-based workflows.
Use it.effect(...) when the test should run with TestClock and TestConsole. Use it.live(...) when the test depends on real time, filesystem mtimes, child processes, git, locks, or other live OS behavior.
Prefer Effect-aware helpers from fixture/fixture.ts over building manual runtimes in tests: use tmpdirScoped() for scoped temp directories, provideInstance(dir)(effect) for low-level binding without directory creation, provideTmpdirInstance(...) for single temp instance binding, or provideTmpdirServer(...) for tests that also need the test LLM server.
Define const it = testEffect(...) near the top of the test file and keep the test body inside Effect.gen(function* () { ... }). Yield services directly with yield* MyService.Service or yield* MyTool.
Avoid custom ManagedRuntime, attach(...), or ad hoc run(...) wrappers in Effect tests when testEffect(...) already provides the runtime.
When a test needs instance-local state, prefer provideTmpdirInstance(...) or provideInstance(...) over manual Instance.provide(...) inside Promise-style tests.

Files:

  • packages/opencode/test/skill/skill.test.ts
🧠 Learnings (3)
📚 Learning: 2026-04-22T08:49:44.563Z
Learnt from: Astro-Han
Repo: Astro-Han/pawwork PR: 126
File: packages/desktop-electron/src/main/index-sidecar-source.test.ts:3-11
Timestamp: 2026-04-22T08:49:44.563Z
Learning: In `packages/desktop-electron/src/main/index-sidecar-source.test.ts` (Astro-Han/pawwork), the test intentionally uses `expect(source).toContain` / `expect(source).not.toContain` string matching against the raw `index.ts` source text as a lightweight sidecar contract guard. The maintainer has explicitly chosen not to introduce an AST parser (e.g., `babel/parser` or acorn) for this purpose. Do not flag these string-based assertions as fragile or suggest converting them to AST-based matching.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
📚 Learning: 2026-04-20T14:36:31.017Z
Learnt from: CR
Repo: Astro-Han/pawwork PR: 0
File: packages/opencode/test/AGENTS.md:0-0
Timestamp: 2026-04-20T14:36:31.017Z
Learning: Applies to packages/opencode/test/**/*.test.{ts,tsx} : Define `const it = testEffect(...)` near the top of the test file and keep the test body inside `Effect.gen(function* () { ... })`. Yield services directly with `yield* MyService.Service` or `yield* MyTool`.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
📚 Learning: 2026-04-23T08:51:00.819Z
Learnt from: Astro-Han
Repo: Astro-Han/pawwork PR: 186
File: packages/opencode/test/plugin/workspace-adaptor.test.ts:139-144
Timestamp: 2026-04-23T08:51:00.819Z
Learning: For pawwork tests under packages/opencode/test/**, auth.json teardown may intentionally combine `Filesystem.write` (from `packages/opencode/src/util/filesystem.ts`) with `node:fs/promises` `unlink` for cleanup. Do not flag this as inconsistent style; it is the established/intentional pattern because `Filesystem` does not provide a `remove`/`unlink` helper.

Applied to files:

  • packages/opencode/test/skill/skill.test.ts
🔇 Additional comments (3)
skills/document-processing/SKILL.md (1)

11-37: Clarify-first gate and decision rule are well-structured.

Good improvement: this now explicitly binds clarifications to the question tool, limits over-asking, and defines clear ask-vs-default behavior before file operations.

skills/writing-assistant/SKILL.md (1)

11-38: Gate constraints are clearer and safer for drafting quality.

The updated question protocol, decision rule, and stop condition should materially reduce speculative drafting while keeping momentum.

skills/data-analysis/SKILL.md (1)

11-37: Decision-oriented clarification update looks solid.

This improves analysis quality by tying question rounds to decision impact and clear stop/default rules.

Comment thread packages/opencode/test/skill/skill.test.ts
@Astro-Han
Astro-Han force-pushed the fix/skill-questions branch from ecdbb58 to b269696 Compare April 23, 2026 20:29
@Astro-Han
Astro-Han merged commit 70063ff into dev Apr 23, 2026
25 checks passed
@Astro-Han
Astro-Han deleted the fix/skill-questions branch April 23, 2026 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request harness Model harness, prompts, tool descriptions, and session mechanics P2 Medium priority

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant