feat(btw): resolve consistent skill visibility for each loop

[YUZHEthefool]

Preflight

• Existing Issues and PRs were searched.
• This follows the current-branch, no-legacy, Python 3.14+ policy.
• Exactly one Agent note is provided by the actual author.

Problem

A loop's Skill prompt, readable manual, and declared tool set must agree; assigning a Skill must not imply Shell or other execution permission.

Proposal

Add loop-aware Skill visibility using the current frozen Skill snapshot and tool catalog. Ordinary Skills initially default to both; workspace Skills retain the proposed work-loop/local-runtime boundary.

Design: PR #28 and its English proposal. Parent: P / #122. PR #28 is documentation only; this issue tracks follow-up implementation or evaluation.

Associated PR: PR #145 (non-draft; base split/btw-mcp-routes).

Acceptance criteria

• Ordinary Skills support conversation/work/both with a visible default of both; saved UI state agrees with resolved visibility.
• Workspace Skills obey the work/local boundary when BTW is enabled while Persona selection and same-name precedence remain consistent with current behavior.
• Prompt content, read_skill, and declared tool visibility derive from the same filtered snapshot. Reading an ordinary Skill with runtime=none remains possible without Shell permission.
• Disabling BTW preserves current Skill behavior. Skill declarations remain filters of registered tools and cannot grant authorization.
• Backend regressions, the shared selector tests, i18n, and both Skill/config documentation languages are updated together.

Dependencies and delivery

Blocked by: B1 / #123, B7 / #129

Coordinate the shared capability selector with B9 / #131. Adapt to current SkillSnapshot/tool_catalog owners, not the prototype's old assembly path.

Implementation anchors

Historical prototype 33ee103a62937db3e930c89ba47a648b75cc7772 provides provenance, not code to copy unchanged:

• astrbot/core/astr_main_agent.py: prototype Skill filtering and workspace handling.
• dashboard/src/components/shared/CapabilityLoopSelector.vue: skill_name assignment.

Integrate with the current tool catalog, Skill snapshot assembly, and authorization service, rechecking current master when implementation begins.

Validation

Commands below are required for the implementation PR, not results claimed by this issue.

Existing current-master regression baseline:

uv run pytest tests/unit/test_astr_main_agent.py tests/unit/test_agent_internal_process.py tests/unit/test_skill_tool_assembly.py

Historical prototype tests to adapt with the feature (they are not shipped by documentation-only PR #28):

• dashboard/tests/capabilityLoopSelector.vitest.ts

After adapting the corresponding Dashboard test, run from dashboard/:

pnpm test:vitest tests/capabilityLoopSelector.vitest.ts
pnpm i18n:check

For changed documentation, run pnpm run docs:build from docs/ and make check-md from the repository root. Update OpenAPI and generated outputs together only if the HTTP contract changes.

Out of scope

A second Skill registry, legacy Skill layouts, and restoring Shell-dependent manual reading are outside scope.

Repository requirements

Follow AGENTS.md, GOVERNANCE.md, and AI_POLICY.md. This issue uses the feature_request template. Keep Python 3.14+, current configuration shapes, existing authorization boundaries, and bilingual feature documentation. A follow-up PR requires human maintainer review and a separate AI-assisted review. Use the feat PR template for the corresponding work.

Author

Agent

Agent note

Codex prepared this development issue at the user's request from PR #28, its discussion, the referenced source, existing tests, and current-master integration points. AI assisted the research and English drafting. Filing this issue changes no runtime behavior and does not claim feature tests or model trials have passed. Remaining decisions concern implementation details and experimental evidence within the stated scope.