Groundwork logo

Groundwork

Community
samsantosb
groundwork

One-time per-project setup for the ship-it pipeline — detects tracker, repo, reviewer and notifier, asks the minimum, writes docs/agents/ config so no other skill ever asks again.

Overview

Publishersamsantosb
Repositoryship-it
Skill namegroundwork
Stars
80
Forks
5
Bundled files
Instructions only
LicenseMIT
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • Self-contained

    Everything the model needs lives in the instructions — no extra files to sync.

  • Open source

    Published by samsantosb on GitHub. Read the source before you install it.

Installation

Install the Groundwork AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/samsantosb/ship-it/tree/main/skills/groundwork
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/samsantosb/ship-it.git /tmp/ship-it
mkdir -p .claude/skills
cp -r /tmp/ship-it/skills/groundwork .claude/skills/groundwork
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Groundwork in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Groundwork on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Groundwork is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

Skill: groundwork

Lays the groundwork every other skill stands on: the per-project configuration (${CLAUDE_PLUGIN_ROOT}/shared/workflow-context.md). Runs once per project; rerunning updates the existing config instead of duplicating it. groundwork writes config as its job — the "offer to persist" write-back protocol governs the other skills when they resolve roles ad hoc. Respond in the conversation language (docs/agents/language.md; not yet configured → mirror the user's language).

Load before acting: ${CLAUDE_PLUGIN_ROOT}/shared/workflow-context.md (the config this skill writes) and ${CLAUDE_PLUGIN_ROOT}/shared/guardrails.md — this skill writes project files; the loading contract applies.

Process

1 — Detect (silent, no questions yet)

Run the capability detection from ${CLAUDE_PLUGIN_ROOT}/shared/workflow-context.md for all four roles plus validation:

  • Tracker: tracker MCPs by capability signature (never by server prefix); git remote -v; gh auth status / glab auth status; existing tasks/ directory.
  • Repo: git rev-parse --show-toplevel; remote host; base branch — gh repo view --json defaultBranchRef -q .defaultBranchRef.name, falling back to git symbolic-ref refs/remotes/origin/HEAD, then git ls-remote --symref origin HEAD, then assume main. If the assumed base doesn't exist locally either (fresh git init), record the current local branch instead and flag the mismatch in tracker.md and the handoff.
  • Reviewer: .coderabbit.yaml present, or gh pr list --search "reviewed-by:coderabbitai" --state all --limit 5 returning results (swap the login to probe other known bots). Treat a failed command and an empty result the same — both mean "no bot detected" (gh subcommands are inconsistent here: some exit 1, some exit 0 with empty output). Detected bot → watch: on by default; otherwise self-review, no watch.
  • Notifier: notifier MCPs by capability signature; otherwise chat.
  • Validation: package.json scripts — root and per workspace (monorepo signals: workspaces field, pnpm-workspace.yaml, turbo.json; workspaces declared but empty → record root commands and note it). Makefile; commands declared in CLAUDE.md/AGENTS.md. PR size budget: grep guideline files (CLAUDE.md, GUIDELINES.md, CONTRIBUTING.md) for a declared max-PR-size rule; not found → this is always asked in step 2 (recommended option: "500 changed production lines") — never silently omitted.
  • Labels: gh label list (or tracker equivalent); scan .github/workflows/*.yml for jobs that fail on missing labels — those labels become the required set in labels.md.
  • Observability: dependencies and config files (newrelic, datadog, @sentry/*, prom-client, OpenTelemetry SDKs, winston/pino); dashboards-as-code in infra/; guideline files. Not detected → leave for lazy resolution (create-tasks asks the first time a card needs it).
  • Guardrails (Layer 2): guideline files (CLAUDE.md, AGENTS.md, GUIDELINES.md, CONTRIBUTING.md) for stated conventions; generated-code markers ("do not edit" headers, codegen output dirs) → propose protected entries.
  • Language: the language the user has been writing in this session — becomes the recommended answer for the conversation-language question in step 2; never silently assumed into config.

If docs/agents/ already exists, load it and treat this run as a review — a three-way reconcile: keep user-edited values unless they name a resource that no longer exists; show removals and additions as one diff; confirm before deleting any key. The ## Agent skills section update in step 4 follows the same never-overwrite-silently rule.

2 — Propose and ask (one batched round; zero only when existing config already answers everything)

Present one summary of detected values. If every open choice resolved by detection or pre-existing config, skip the ask entirely. Otherwise, a single AskUserQuestion (up to 4 questions) covering only the genuinely open choices, detected option first marked "(Recommended)". Typical open choices:

  • Tracker when several are viable (e.g. Linear MCP connected and GitHub remote): which platform owns the cards?
  • GitHub/GitLab with no tracker MCP: GitHub Issues (recommended) or local Markdown?
  • Notifier target when a notifier exists (which channel / DM?).
  • PR size budget when no guideline declares one — free numeric choice: offer "500 changed production lines (Recommended)" as the anchor and accept whatever number the team wants (no allowed range — the value is the team's call). Always asked when not detected.
  • Conversation language — always asked when not already configured: which language should the pipeline use to talk to you? Recommended option = the language the user is writing in. Skill files are English; the conversation doesn't have to be — the answer goes to docs/agents/language.md so every skill in every future session opens in the right language.

3 — Write config

Write docs/agents/ in the project (create the directory if missing). Short prose header + a fenced block of values per file — human-readable, PR-reviewable. Templates:

tracker.md

platform: github-issues        # linear | jira | notion | github-issues | gitlab | markdown | ...
scope: acme/acme-api           # workspace/project/team — or the cards directory for markdown
product_docs: docs/product/
base_branch: main
language: user                 # artifact language: user (default) | en | pt-BR | ... — for teams whose cards must be readable by everyone
# Mode A (tracker MCP) only — map lifecycle states to the platform's real state names:
# states: { todo: "Backlog", in-progress: "In Progress", in-review: "In Review", done: "Done" }

labels.md — write the complete role map from ${CLAUDE_PLUGIN_ROOT}/shared/pr-flow.md § Labels (all state, category and chaos:* roles — omitting rows breaks the "never ask again" promise later), mapping each role to this repo's actual labels; default role = label name. Include the required: set detected in step 1. Pure Markdown tracker with no remote → labels have no platform to live on; write the file as an explicit n/a (markdown mode — frontmatter labels are free-form) instead of a map nobody consumes.

reviewer.md

reviewer: self-review          # <bot login> | self-review | human-only
watch: off                     # on = do-task chains into /watch-pr after opening the PR
escalation: none               # team/handle to request review from when a PR ships over budget (e.g. org/tech-leads)

notifier.md

channel: chat                  # chat | slack | discord | teams | email
target: none                   # channel/DM id when not chat — personal ids go to user memory, never here

language.md

conversation: pt-BR            # language every skill uses to talk to the invoking user — asked by groundwork, never silently assumed. Artifact language (cards/PR comments) lives in tracker.md

validation.md

lint: npm run lint
typecheck: npm run typecheck
test: npm run test
pr_size_budget: 500            # max changed production lines per PR (tests/fixtures/generated excluded)
guidelines: AGENTS.md          # files every implementation must read first (groundwork step 4 guarantees it exists)

observability.md (write when detected; otherwise create-tasks resolves it lazily — full chain in workflow-context § Observability)

platform: none                 # newrelic | datadog | grafana | sentry | cloudwatch | otel | none
logger: console                # detected logger — or pino (Node default suggestion) — or console if the user declined
conventions: none              # event naming, dashboards-as-code location, alert policy dir

guardrails.md (optional — write only when the project has rules beyond the universal invariants in ${CLAUDE_PLUGIN_ROOT}/shared/guardrails.md)

protected: []                  # extra paths skills must never edit (generated code, vendored dirs)
forbidden: []                  # extra operations beyond the universal invariants
notes: none

Personal facts the user gave you (their Slack member ID, DM preferences) go to user memory, never into the repo.

4 — Wire it into every session (every agent)

Write the ## Agent skills section into the project's AGENTS.md (the cross-agent standard — opencode, Codex, Gemini CLI, Cursor and others auto-read it) and into CLAUDE.md (what Claude Code auto-loads). Same stanza in both, created when missing, kept in sync on reruns — and never rewrite anything else in either file:

markdown
## Agent skills

This project is configured for the ship-it pipeline.
Role config lives in docs/agents/ (tracker, labels, reviewer, notifier, validation).
Skills must read it instead of asking. Learned project rules are written back there.
Conversation language: pt-BR (source of truth: docs/agents/language.md).

This is what makes the config load in every future session — the write-back loop's entry point. The conversation-language line is a deliberate exception to "index only, no values inline": CLAUDE.md/AGENTS.md are auto-loaded at session start, so mirroring the language there means the very first reply is already in the right language — before any skill loads config. docs/agents/language.md stays the source of truth; on reruns the stanza line is regenerated from it.

5 — Handoff

Report: each role → resolved value → source (config — pre-existing / detected / asked / default), files written, and the pipeline order (/create-product → /create-tasks → /do-task → /chaos-engineering). If the notifier resolved to chat, add the fleet warning: unattended/automode runs that park will notify nobody — configure a real notifier before running fleets (autonomy.md). If the user wanted a platform whose MCP isn't connected, give the registration instructions for their environment and remind them a session restart is required — config already written survives the restart.

Guardrails (this skill, on top of shared/guardrails.md)

  • Never create labels, projects or channels on any platform — groundwork only maps what exists.
  • Never store tokens/secrets in docs/agents/ — connection auth belongs to MCP/CLI config.
  • CLAUDE.md/AGENTS.md edits are append/update of the ## Agent skills section only; never rewrite the rest.

Frequently asked questions

What does the Groundwork AI skill do?

One-time per-project setup for the ship-it pipeline — detects tracker, repo, reviewer and notifier, asks the minimum, writes docs/agents/ config so no other skill ever asks again.

Why use Groundwork on TypingMind?

Because you install it once and use it with any model. Groundwork is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Groundwork in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/samsantosb/ship-it/tree/main/skills/groundwork. TypingMind reads its SKILL.md and installs it as a skill you can enable per chat.

Which AI models can use Groundwork?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Groundwork?

As many as you like. As long as a model supports skills, you can use Groundwork with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Groundwork AI skill free?

Yes. It is published on GitHub by samsantosb under the MIT license. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇