Claude Skill

teamwork-collaborate

Use when the user explicitly wants to discuss, brainstorm, compare options, or make a material preference decision, or when unclear intent needs guided clarification; do not use for clear execution or a single discoverable detail.

LLM Mart · 0 points · 0 18 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download jinplu-teamwork-skills_teamwork-collaborate-8f23dcd.zip · 4 KB

jinplu/teamwork 12 0 forks MIT Updated 9d ago

Part of jinplu/teamwork — 8 skills

Install

skills CLI npx skills add https://github.com/JinPLu/Teamwork/tree/main/skills/teamwork-collaborate

Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jinplu-teamwork@llmmart

Git git clone https://github.com/JinPLu/Teamwork.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jinplu/teamwork collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Teamwork Collaborate

Root owns the conversation. Keep clear work native and activate Collaborate when the user wants to think together, when an unresolved preference would materially change the result, or when unclear intent needs guided clarification.

Method

Rebuild the full decision surface first: the final goal, prior work on this question, settled constraints and recorded rejections, and the unknowns that would change the goal, direction, or acceptance. Start from facts, constraints, and the goal. Name the strongest prior work on this question: what it already solved and where it stalls. Do not invent a stack from zero. Map the discussion from goal to stage to questions with a concise tree or list; use Mermaid when the option space needs that structure.
A stage is one dependency layer of user-owned decisions. Ask every independent, valuable question for that stage together and defer dependents later; host UI limits are not Teamwork limits.
Develop only meaningfully different options. For each, explain the main benefit, cost, assumption, and consequence. Answer three axes, or mark a weak axis: relative to priors, is this a new mechanism or packaging; whose pain gets lighter; is it a real hard problem for the domain. Practice first: unobserved local results are not done. Tests on disk are not verification. Practice first forbids claiming an unobserved result; it does not require proxy experiments before an authorized real attempt.
Resolve discoverable facts directly. Ask the user only for preferences or authority that cannot be discovered. Remaining questions that would not change the next step are not this stage. Use subagents only for bounded evidence gathering or a genuinely independent challenge. Settled user constraints must include recorded rejections and decisions, and the requested return must not change the topic.
When this turn involves experiment scheduling, GPU or other scarce compute, or a paper / contribution table slot, follow references/experiment.md. Otherwise skip Experiment.
Recommend a direction when the evidence distinguishes one. Lead with the claim, then checkable behavior. Define a new term in one sentence. No slogans; do not paper over holes with coinages. Record the user's decision and advance to the next dependent stage. Recorded rejections and decisions are the mainline; research or a subagent return must not restate them as a new question. After research, do not rewrite the question. Quote the user's decision or rejection; do not paraphrase it into a new problem. Do not reopen settled dimensions; update only what the evidence changed. A fluent next step is not convergence. If a new direction is weak on the three axes, improve the anchored problem instead of reopening it.
End with the decision, unresolved points, and the next authorized action. When the direction is decided and the user authorizes execution, the discussion ends at that real action; do not open a new evidence gate or a new planning door. The next turn on the same subject reads the discussion document's current synthesis first when that document exists.

Persistence

When a listed checkpoint fires, write in the same response cycle. If separate stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from references/discussion.md at docs/teamwork/discussions/<slug>.md. Same identity means the same final goal plus the same subject; reuse that path and name the document you read. A different subject gets a new path.

Checkpoints: a decision, recommendation, or unresolved question batch that will change later work. An ordinary next action by itself does not write a document. Keep user quotes separate from the working understanding.

Session recall may be used on the next turn only after a write is observed unavailable or failed, and that recall must be marked as not persisted. A missing document is not a license to skip a fired checkpoint write.

Files (teamwork)

agents

openai.yaml 242 B

interface:
  display_name: "Teamwork Collaborate"
  short_description: "Clarify intent and shape decisions together"
  default_prompt: "Use $teamwork-collaborate to discuss this with me, clarify what matters, and help me choose a direction."

references

discussion.md 1.2 KB

---
status: active
superseded-by:
created: <YYYY-MM-DD>
updated: <YYYY-MM-DD>
---

# Discussion: <subject>

## Identity and final goal

- Subject identity: <stable identity>
- Final goal: <owner-certified goal>
- Authoritative owner: <owner>

## Decision map

<goal to current stage to independent questions to next dependent stage; a
concise tree or list is enough when the option space is simple, otherwise
Mermaid>

## Current stage

<stage and settled context>

## Current question batch

<all independent valuable questions for this stage; no fixed count>

## Options and recommendation

<meaningfully different options and owner-certified recommendation>

## Decisions and open points

<user decisions, unresolved points, and next authorized action>

## Experiment slot

<This experiment feeds which contribution slot: main table / appendix hygiene /
exploratory probe / unused.>

## User quotes

<user's original wording, especially recorded rejections and decisions>

## Working understanding

<model understanding; do not write this as the user's wording>

## History

<Append only. Never rewrite or remove; a correction is a new dated entry.>

### <date/time — semantic change>

<decision or synthesis delta>

experiment.md 2.5 KB

# Experiment (condition-gated)

Enable this reference when the current work involves experiment scheduling,
GPU or other scarce compute reservation, or a paper / contribution table slot.
Skip it for ordinary preference discussion.

Before running any experiment or applying for / occupying scarce compute,
write the intended slot so the user can check it at any time:

> **This experiment feeds which contribution slot: main table / appendix hygiene /
> exploratory probe / unused.**

"Unused" must not take large-scale scarce compute. Uncertain slot = unused.

The slot decides what may be claimed and whether scale-up is worth it. It does
not decide whether the first authorized, in-budget real attempt may run.

| Slot | Criterion |
| --- | --- |
| Main table | Controllable, repeatable evidence with independent ground truth for the claim the paper would assert; or a fixed-consumer ranking / false-release / regret metric the reader can audit |
| Appendix hygiene | Contract calibration, unit / coordinate / timing cleanup. Short, cheap, and parallel; not a contribution and not an execution gate |
| Exploratory probe | Mechanism smoke: small scale + same-budget control + explicit kill; state "mechanism not selected; measuring headroom only". Parallel and non-blocking unless it is itself the authorized attempt |

Hard rules when this gate is active:

- Do not treat observational logs without controllable counterfactual ground
  truth as main-table evidence; use them for appearance, distribution, or
  qualitative failure buckets only.
- Do not reopen a settled mainline because something "runs."
- Cross-domain or cross-embodiment mismatch results stay exploratory; they do
  not count as repeatable gap evidence for a settled claim.
- Large-scale expansion still needs user budget and claim-grade evidence. That
  is not a bar on an authorized, in-budget first outcome-bearing attempt.

Stop conditions (hit any, stop the matching claim or scale-up; do not force
the story through). They do not stop the whole project, and they do not stop
an authorized, in-budget first outcome-bearing attempt:

1. A contract or instrumentation error already explains the anomaly → withdraw
   that case as model-failure evidence.
2. On controllable paired setups, a strong baseline already crosses the claimed
   critical boundary → the problem does not hold; stop that claim.
3. A simple same-budget baseline (state / rule / retrieval / critic) ties the
   proposed system → do not claim the proposed system is irreplaceable.

SKILL.md 4.3 KB

---
name: teamwork-collaborate
description: Use when the user explicitly wants to discuss, brainstorm, compare options, or make a material preference decision, or when unclear intent needs guided clarification; do not use for clear execution or a single discoverable detail.
---

# Teamwork Collaborate

Root owns the conversation. Keep clear work native and activate Collaborate when
the user wants to think together, when an unresolved preference would materially
change the result, or when unclear intent needs guided clarification.

## Method

1. Rebuild the full decision surface first: the final goal, prior work on this
   question, settled constraints and recorded rejections, and the unknowns that
   would change the goal, direction, or acceptance. Start from facts,
   constraints, and the goal. Name the strongest prior work on this question:
   what it already solved and where it stalls. Do not invent a stack from zero.
   Map the discussion from goal to stage to questions with a concise tree or
   list; use Mermaid when the option space needs that structure.
2. A stage is one dependency layer of user-owned decisions. Ask every
   independent, valuable question for that stage together and defer dependents
   later; host UI limits are not Teamwork limits.
3. Develop only meaningfully different options. For each, explain the main
   benefit, cost, assumption, and consequence. Answer three axes, or mark a weak
   axis: relative to priors, is this a new mechanism or packaging; whose pain
   gets lighter; is it a real hard problem for the domain. Practice first:
   unobserved local results are not done. Tests on disk are not verification.
   Practice first forbids claiming an unobserved result; it does not require
   proxy experiments before an authorized real attempt.
4. Resolve discoverable facts directly. Ask the user only for preferences or
   authority that cannot be discovered. Remaining questions that would not
   change the next step are not this stage. Use subagents only for bounded
   evidence gathering or a genuinely independent challenge. Settled user
   constraints must include recorded rejections and decisions, and the
   requested return must not change the topic.
5. When this turn involves experiment scheduling, GPU or other scarce compute, or
   a paper / contribution table slot, follow `references/experiment.md`.
   Otherwise skip Experiment.
6. Recommend a direction when the evidence distinguishes one. Lead with the
   claim, then checkable behavior. Define a new term in one sentence. No
   slogans; do not paper over holes with coinages. Record the user's decision
   and advance to the next dependent stage. Recorded rejections and decisions
   are the mainline; research or a subagent return must not restate them as a
   new question. After research, do not rewrite the question. Quote the user's
   decision or rejection; do not paraphrase it into a new problem. Do not
   reopen settled dimensions; update only what the evidence changed. A fluent
   next step is not convergence. If a new direction is weak on the three axes,
   improve the anchored problem instead of reopening it.
7. End with the decision, unresolved points, and the next authorized action.
   When the direction is decided and the user authorizes execution, the
   discussion ends at that real action; do not open a new evidence gate or a
   new planning door. The next turn on the same subject reads the discussion
   document's current synthesis first when that document exists.

## Persistence

When a listed checkpoint fires, write in the same response cycle. If separate
stable identities each cross a checkpoint, write each to its own path.

Cross-chat memory lives in one Markdown document from `references/discussion.md`
at `docs/teamwork/discussions/<slug>.md`. Same identity means the
same final goal plus the same subject; reuse that path and name the document you
read. A different subject gets a new path.

Checkpoints: a decision, recommendation, or unresolved question batch that will
change later work. An ordinary next action by itself does not write a document.
Keep user quotes separate from the working understanding.

Session recall may be used on the next turn only after a write is observed
unavailable or failed, and that recall must be marked as not persisted. A
missing document is not a license to skip a fired checkpoint write.