plugins/teamcraft-jcg/skills/sync-claude-md/SKILL.md
Audit and update CLAUDE.md, .claude/rules/, and .teamcraft/project.md to reflect the current state of the project. Run anytime — mid-ticket, end of sprint, pure maintenance, or first-time setup for a project with none of these files. Developer drives what changes; skill provides the analysis.
npx skillsauth add codingthefuturewithai/claude-code-primitives teamcraft-jcg:sync-claude-mdInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Keep CLAUDE.md, .claude/rules/, and .teamcraft/project.md accurate and lean. Remove entries that are now discoverable from the codebase. Add new non-obvious things the team has learned. Incorporate lessons from recent work, newly established conventions, or developer input. Works for any project at any point — including projects with none of these files.
.teamcraft/project.md stays minimal. If it doesn't exist, offer to create it. If Confluence page IDs or GitHub repo reference have changed, update them.CLAUDE.md starts with @.teamcraft/project.md — verify this import is present.Establish what the developer wants to accomplish. The common scenarios: capturing lessons learned from a recent ticket, recording newly established team conventions, a periodic audit to trim stale entries, or initial setup for a project that has none of these files.
Read what exists: .teamcraft/project.md, CLAUDE.md, .claude/rules/*.md. Read key project config files to understand what the codebase now reveals — dependencies, structure, patterns. This is the basis for identifying what in CLAUDE.md has become redundant.
If Confluence artifacts are referenced in project.md (tech decisions page ID, conventions page ID), offer to load them as context using mcp__sooperset-mcp-atlassian__confluence_get_page. The developer may also have input that doesn't come from any document — lessons learned during recent work, gotchas discovered, architectural changes made.
Assess CLAUDE.md and rules files against the current codebase and developer input:
Candidates for removal: entries that are now visible in the code, config files, or README — things Claude Code can discover for itself.
Candidates for addition: lessons learned from recent work, newly established conventions, non-obvious constraints discovered, architectural decisions that look wrong without context, anything the developer reports Claude Code keeps getting wrong.
Candidates for update: entries that are partially correct but need refinement as the project has evolved.
Present additions and removals separately. The developer confirms, amends, or overrides each. Nothing is written until confirmed.
If none of these files exist, offer to create them — this skill functions as a first-time setup in that case. To create .teamcraft/project.md, identify the GitHub repo from git remote: git remote -v via Bash. For the Jira project, use mcp__sooperset-mcp-atlassian__jira_get_all_projects to surface available projects and ask the developer to confirm which one. Never assume. See references/example-project-manifest.md for the correct jcg manifest format. See references/example-claude-md.md for correct CLAUDE.md format and content.
Confirm what was written. Remind the developer this is a living system — run this skill whenever lessons are learned or the codebase evolves significantly enough that CLAUDE.md entries may have become stale or new ones are warranted.
development
Plan a time-boxed iteration (sprint, cycle, milestone) from the backlog and the PRD/roadmap behind it — gather the goal, the window, and the team's real capacity, then select, sequence, and size a committed set of work items to fit. Writes an `iteration` label onto each chosen work item. Use when the user says 'plan a sprint', 'plan the next iteration', 'plan our cycle', 'sprint planning', 'iteration planning', 'plan the next two weeks', 'set up a milestone', 'what should we take on this sprint', 'plan from the PRD', or otherwise wants to commit a scoped, time-boxed batch of work rather than create issues one at a time. This is the planning layer between requirements and the build loop — distinct from create-issue (one item) and pick-next-issue (pick one to build now).
tools
Capture feedback about Teamcraft itself and turn it into a well-structured GitHub issue on the plugin's repo. Vets whether the problem is really a Teamcraft skill defect (vs. misuse, the harness, or the user's own project) by root-causing against the actual skill source, then helps the developer decide whether to file and publishes via the GitHub CLI. Use when the user says 'improve teamcraft', 'a teamcraft skill did the wrong thing', 'file feedback on teamcraft', 'report a teamcraft bug', 'I have an idea to make teamcraft better', or when a Teamcraft skill clearly misbehaved and the user wants that captured upstream.
tools
Learn the Teamcraft plugin itself — how its workflow, skills, and artifacts fit together. A guided overview for a human getting started, or a system map for Claude orienting itself to how Teamcraft works before working in a Teamcraft repo. Teaching only; needs no project or environment access. Use when someone wants to understand Teamcraft (the tool, not their specific project), asks "how does Teamcraft work", "explain the workflow", "which skill do I use for X", or when Claude needs the big picture of how the skills hook together.
tools
--- name: teamcraft:work-board description: Launch (or re-launch) the user's live, multi-project work board. The dashboard is a single HTML file copied to a stable user-side location at ~/.claude/teamcraft-board.html and opened in the user's default browser. It has two views via a header toggle — a drag-and-drop Kanban Board and a live Status tab (analytics: work by status, throughput, cycle time, aging, blocked chains, recomputed on every poll). Each project is added via a header dropdown; the