Skip to main content

council

Trigger this if the user says 'council'.

소스 정보

저장소
t3dotgg/tstack
최근 소스 활동
2026년 11월 11일 11:33
감지된 SKILL.md 언어
영어
스타
3,492
포크
263

council: Three-Provider Parallel Review

Spins three high-effort flagship models from different providers in parallel for review or feedback after known fixes and checks.

Uses

Trigger when the user says council; usually for review or feedback before an audit.

Prerequisites

Fix known issues and run relevant checks first; resolve models via orchestrator_capabilities when in T3 Code.

How to use

Pick one strong model per provider (or named members), delegate in parallel, then synthesize feedback.

Limitations

If discarding the implementation to explore new ideas, skip fixes on code being replaced.

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
council
description
Trigger this if the user says 'council'.
# Council Before an audit, address outstanding PR comments, fix known issues, and run relevant checks. Give council the updated implementation; do not defer known fixes until reviews return. If the user wants to discard the implementation and explore new ideas, skip fixes to code being replaced. Bring in three delegates to help with the user's request, usually for review or feedback. Use one strong model from each of three different providers, at high reasoning effort. If the user's instructions name council members, use those. Otherwise pick the latest flagship model from each provider, for example Claude Opus, GPT Sol, and Gemini Pro. In T3 Code, use `orchestrator_capabilities` to resolve the models, then `delegate_task` to start one delegate per model in parallel. Elsewhere, use the harness's subagent tools. If you cannot reach three providers, or a named member is unavailable, report it instead of substituting. Give each delegate the request and relevant context. For review or feedback, keep their work read-only. Collect their responses and summarize the useful findings, disagreements, and recommended next steps. Do not wait idle. When a result arrives, check its findings against the code at once and decide what to fix while the other delegates run. Do not edit files while a delegate still reviews the same checkout. If the user's instructions mark a delegate as non-blocking, do not wait for it; treat a late result as feedback and do not record its score. For a code review, ask each delegate for a score out of 10. Count each full review pass as one round. A fresh review after fixes starts a new round. If the work ends in a pull request, put the results in the PR description. Put this section before the model and harness line at the end: ```markdown ## Council review Rounds: 2 | Delegate | Round 1 | Round 2 | | --- | --- | --- | | Claude Opus | 7/10 | 9/10 | | GPT Sol | 8/10 | 10/10 | | Gemini Pro | 7/10 | 9/10 | ``` If a delegate gives no score, write `no score`. Do not invent one. If the PR is open, edit the description. Do not post a comment for this. If there is no PR, put the same results in the final reply only. If you agree with their recommendations, make the changes and request a fresh review after. Continue this process until all delegates are satisfied with the outcome. Do not let repeated reviews result in scope creep. It is your job to fight to keep scope limited.
GitHub에서 보기