teamwork-goal
Use when the user explicitly asks to persist until a verifiable result, fix until green, monitor through completion, or stay within a stated budget; do not infer persistence from difficulty.
Install
npx skills add https://github.com/JinPLu/Teamwork/tree/main/skills/teamwork-goal
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jinplu-teamwork@llmmart
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 Goal
Goal adds persistence to the underlying task; it does not add a second workflow.
Method
- State the concrete objective, success signal, applicable scope, and any user budget. A success signal is the directly observable result that shows the requested outcome is achieved. Example: the authorized command or user-stated completion condition is observed on the real path.
- Perform the next useful action and observe the result.
- Continue until the success signal is directly observed, the user interrupts, or a genuine external blocker prevents further progress.
- Change approach when evidence invalidates the current one. Do not repeat a failed action without a new reason.
- Report success with the observed evidence, or report the exact blocker and what would unblock it.
Carry compact Invariants through every retry: the original objective, protected constraints, and stop or budget state. After each attempt, keep an Attempt Record with the previous result, the new reason to continue or stop, and the current stop or budget state. These records live in the working context and, when a checkpoint fires, in the report; they are not a workflow database.
Tests support the goal but do not replace the real success signal when that signal is available.
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/report.md
at docs/teamwork/reports/<slug>.md. Same identity means the same
continuing objective; reuse that path and name the document you read. A
different subject gets a new path.
Experiment checkpoints write from references/experiment-record.md at
docs/teamwork/experiments/<slug>.md. Same identity means the same
falsifiable claim; reuse that path and name the document you read. A
different claim gets a new path. Probe declarations need only a claim draft,
kill criterion, and budget. The full declaration is for main-table or
appendix-hygiene eligibility, not a run gate. Slot criteria are in
../teamwork-collaborate/references/experiment.md. Post-run HARKing is the
diff between the frozen declared claim and a post-hoc claim; Reviewer or
Challenger is the right role for that adjudication, and it is not a
mandatory ceremony.
Checkpoints: the success signal is directly observed; a genuine external blocker stops progress; or the user interrupts after material progress worth reusing. An experiment declaration, adjudication, result, or tombstone is also a checkpoint.
Files (teamwork)
-
agents
-
openai.yaml 216 B
interface: display_name: "Teamwork Goal" short_description: "Keep working toward a verifiable result" default_prompt: "Use $teamwork-goal to keep progressing on this task until its real success signal passes."
-
-
references
-
experiment-record.md 2.5 KB
--- status: active superseded-by: created: <YYYY-MM-DD> updated: <YYYY-MM-DD> declared-slot: adjudicated-slot: --- # Experiment: <claim draft> ## Declaration Frozen once written. Do not edit this section after the first save. ### Probe (minimum to run) A probe may run with only these three fields. The full declaration below is required for main-table or appendix-hygiene eligibility, not for running. - Claim draft: <one falsifiable sentence> - Kill criterion: <when to stop the matching claim or scale-up> - Budget: <compute / time / money> ### Full declaration (main-table / appendix-hygiene) - Falsifiable claim: <one sentence> - Declared slot: <main table / appendix hygiene / exploratory probe / unused> - Primary metric: <formula over valid outputs; include parse rules> - Decision threshold: <pass / fail rule> - Kill criterion: <stop the matching claim or scale-up> - Outcome-neutral checks: <pre-result instrumentation and sanity> - Budget: <compute / time / money> - Config: - Model IDs / checkpoint hashes: <ids> - Seeds: <seeds> - Hyperparameter search range and selection method: <range and rule> - Exact reproduce command: <command> ## Adjudication Fill after the run. Reviewer or Challenger is the right role for this adjudication; it is not a mandatory ceremony. HARKing detector: diff the frozen declared claim against any post-hoc claim. Registered Reports Stage 2: 1. Can the observed data test the frozen declared claim? 2. Is the reported claim the same as the frozen declaration (no silent shift)? 3. Were the declared procedures, metric, and parse rules followed, with deviations labelled? 4. Are any unregistered analyses labelled exploratory rather than confirmatory? 5. Is the conclusion licensed by the declared claim and the observed result, including a negative or killed outcome? Mayo severity: If this claim were false, would this experiment probably have shown it? - Adjudicated slot: <main table / appendix hygiene / exploratory probe / unused / tombstone> - Rationale: <why this slot, including any demotion> Demotion needs no permission. Promotion to main table requires all five Stage 2 questions passing. ## Result / tombstone - Numbers with error-bar provenance (std vs SEM, and the variability source): <values> - Run IDs: <ids> - Reproduce command: <command> - If killed: which assumption broke, and revisit conditions: <or none> ## History <Append only. Never rewrite or remove; a correction is a new dated entry.> ### <date/time — semantic change> <declaration freeze, adjudication, result, or tombstone delta> -
report.md 1.1 KB
--- status: active superseded-by: created: <YYYY-MM-DD> updated: <YYYY-MM-DD> --- # Report: <subject> ## Current synthesis <requested outcome and directly observed result; label it complete, partial, unobserved, or blocked only as certified by the result owner> ## Identity and request - Subject identity: <stable continuing objective or operation> - Authoritative owner: <result owner> - Requested outcome and scope: <authorized requested result> ## Observed outcome and completion boundary <only what was directly observed; include the success signal, observation method, and scope for any completion claim> ## Decisive evidence <evidence supporting the observed outcome> ## Resulting state and material changes <current state and material changes, not an activity log> ## Remaining action, blocker, and nonclaims <smallest remaining action, exact blocker, or none observed; state any material completion, release, activation, or real-runtime result that is not supported> ## History <Append only. Never rewrite or remove; a correction is a new dated entry.> ### <date/time — semantic change> <result-state delta, not an activity log>
-
-
SKILL.md 2.8 KB
--- name: teamwork-goal description: Use when the user explicitly asks to persist until a verifiable result, fix until green, monitor through completion, or stay within a stated budget; do not infer persistence from difficulty. --- # Teamwork Goal Goal adds persistence to the underlying task; it does not add a second workflow. ## Method 1. State the concrete objective, success signal, applicable scope, and any user budget. A success signal is the directly observable result that shows the requested outcome is achieved. Example: the authorized command or user-stated completion condition is observed on the real path. 2. Perform the next useful action and observe the result. 3. Continue until the success signal is directly observed, the user interrupts, or a genuine external blocker prevents further progress. 4. Change approach when evidence invalidates the current one. Do not repeat a failed action without a new reason. 5. Report success with the observed evidence, or report the exact blocker and what would unblock it. Carry compact Invariants through every retry: the original objective, protected constraints, and stop or budget state. After each attempt, keep an Attempt Record with the previous result, the new reason to continue or stop, and the current stop or budget state. These records live in the working context and, when a checkpoint fires, in the report; they are not a workflow database. Tests support the goal but do not replace the real success signal when that signal is available. ## 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/report.md` at `docs/teamwork/reports/<slug>.md`. Same identity means the same continuing objective; reuse that path and name the document you read. A different subject gets a new path. Experiment checkpoints write from `references/experiment-record.md` at `docs/teamwork/experiments/<slug>.md`. Same identity means the same falsifiable claim; reuse that path and name the document you read. A different claim gets a new path. Probe declarations need only a claim draft, kill criterion, and budget. The full declaration is for main-table or appendix-hygiene eligibility, not a run gate. Slot criteria are in `../teamwork-collaborate/references/experiment.md`. Post-run HARKing is the diff between the frozen declared claim and a post-hoc claim; Reviewer or Challenger is the right role for that adjudication, and it is not a mandatory ceremony. Checkpoints: the success signal is directly observed; a genuine external blocker stops progress; or the user interrupts after material progress worth reusing. An experiment declaration, adjudication, result, or tombstone is also a checkpoint.
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.