Claude Skill

teamwork-init

Use when the user asks to add or refresh concise project-local Teamwork instructions in one named project; do not use to install global tools or create workflow records.

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download jinplu-teamwork-skills_teamwork-init-8f23dcd.zip · 2 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-init

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 Init

Init adds one small managed block to the project's agent instruction file, plus the small import bridge a host needs to read that block. It creates no document database, schema, case directory, runtime state, or migration path.

Method

Resolve a trustworthy Teamwork package source: read ~/.teamwork/install.json root; use that path if it contains VERSION, skills/, and install.sh. If the pointer is missing or invalid, ask the user for the repository path. Do not search the home directory. Then resolve the authorized project root and read its instruction hierarchy.
Preserve all user-owned content outside the Teamwork managed markers.
Run ./install.sh --project-root <root> init-project from that resolved package source.
Re-read the resulting project instruction surfaces and report each exact changed surface or the observed no-op.

The command is idempotent: an existing Teamwork block is refreshed in place, and an instruction file that already reaches the block is left unchanged. Ambiguous duplicate markers or an unreadable target are real file-ownership conflicts; version, schema, readiness, and agent availability are not Init preconditions.

Init never creates an empty docs/teamwork tree. Document directories appear only when a Skill checkpoint asks Writer to write a file there. When Init observes no change, report the observed no-op. Create or update a durable report only when that result is reusable or the user explicitly requests it.

Persistence

Persistence is optional. Write a report only when the observed result is reusable across sessions or the user explicitly requests it. When that optional checkpoint fires, write the document in the same response cycle from references/report.md at docs/teamwork/reports/<slug>.md (reuse the existing path for the same project-operation identity). Optional triggers: Init completes with an observed AGENTS.md change worth reusing; Init stops on a real file-ownership conflict worth reusing; or a no-op result is reusable or explicitly requested. Init never blocks on a report.

Files (teamwork)

agents

openai.yaml 223 B

interface:
  display_name: "Teamwork Init"
  short_description: "Add or refresh project-local Teamwork context"
  default_prompt: "Use $teamwork-init to add or refresh concise Teamwork context for this exact project root."

references

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.3 KB

---
name: teamwork-init
description: Use when the user asks to add or refresh concise project-local Teamwork instructions in one named project; do not use to install global tools or create workflow records.
---

# Teamwork Init

Init adds one small managed block to the project's agent instruction file, plus
the small import bridge a host needs to read that block. It creates no document
database, schema, case directory, runtime state, or migration path.

## Method

1. Resolve a trustworthy Teamwork package source: read
   `~/.teamwork/install.json` `root`; use that path if it contains `VERSION`,
   `skills/`, and `install.sh`. If the pointer is missing or invalid, ask the
   user for the repository path. Do not search the home directory. Then resolve
   the authorized project root and read its instruction hierarchy.
2. Preserve all user-owned content outside the Teamwork managed markers.
3. Run `./install.sh --project-root <root> init-project` from that resolved
   package source.
4. Re-read the resulting project instruction surfaces and report each exact
   changed surface or the observed no-op.

The command is idempotent: an existing Teamwork block is refreshed in place, and
an instruction file that already reaches the block is left unchanged.
Ambiguous duplicate markers or an unreadable target are real file-ownership
conflicts; version, schema, readiness, and agent availability are not Init
preconditions.

Init never creates an empty `docs/teamwork` tree. Document directories appear only
when a Skill checkpoint asks Writer to write a file there. When Init observes
no change, report the observed no-op. Create or update a durable report only
when that result is reusable or the user explicitly requests it.

## Persistence

Persistence is optional. Write a report only when the observed result is reusable
across sessions or the user explicitly requests it. When that optional
checkpoint fires, write the document in the same response cycle from
`references/report.md` at
`docs/teamwork/reports/<slug>.md` (reuse the existing path for the
same project-operation identity). Optional triggers: Init completes with an
observed `AGENTS.md` change worth reusing; Init stops on a real file-ownership
conflict worth reusing; or a no-op result is reusable or explicitly requested.
Init never blocks on a report.