Scaffold the repository-level configuration needed by the engineering skills:
- Issue tracker — where issues are stored (GitHub by default; local markdown is also supported out of the box)
- Taxonomy labels — the actual label strings corresponding to the five standard taxonomy roles
- Domain documentation ——
CONTEXT.mdand ADRs, and the reading rules
This is a prompt-driven skill, not a deterministic script. Explore first, present what you found, confirm with the user, then write the files.
Process
1. Explore
Look at the current repository to understand the initial state. Read what already exists; do not assume:
git remote -vand.git/config— is this a GitHub repository? Which one specifically?- In the repository root,
AGENTS.mdandCLAUDE.md— do they exist? Do they already contain a## Agent skillssection? - In the repository root,
CONTEXT.mdandCONTEXT-MAP.md docs/adr/and anysrc/*/docs/adr/directoriesdocs/agents/— does output from previous runs of this skill already exist?.scratch/— a sign that a local markdown issue tracking scheme is already in use
2. Present findings and ask questions
Summarize what already exists and what is missing. Thenone by oneguide the user through three decisions — present only one section at a time, and move on to the next only after getting the user's answer. Do not throw all three at them at once.
Assume the user does not know what these terms mean. Start each section with a brief explanation (what it is, why these skills need it, what changes depending on the choice), then show the options and defaults.
Part A — Issue tracker.
Explanation: The issue tracker is where this repository's issues are stored.
to-issues、triage、to-prdandqaand other skills read from and write to it — they need to know whether to callgh issue create, write markdown files into the.scratch/directory, or follow some other workflow you describe. Choose where you actually track work for this repository.
Default preference: These skills are designed for GitHub. If git remote points to GitHub, recommend GitHub. If git remote points to GitLab (gitlab.com or a self-hosted address), recommend GitLab. Otherwise (or if the user has a preference), offer the following options:
- GitHub — issues are stored in the repository's GitHub Issues (using
ghCLI) - GitLab — issues are stored in the repository's GitLab Issues (using
glabCLI) - Local markdown — issues are stored as files in this repository under
.scratch/<feature>/(suitable for personal projects or projects with no remote repository) - Other(Jira, Linear, etc.) — ask the user to describe the workflow in a paragraph, and the skill will record it as free text
Part B — Taxonomy label vocabulary.
Explanation: When
triageWhen the skill processes an incoming issue, it moves the issue through a state machine—needs triage, waiting for the reporter's reply, can be picked up by an AFK agent, needs human implementation, or won't fix. To do this, it needs to apply labels consistent withthe labels you actually have configured. If your repository already uses different label names (for examplebug:triageinstead ofneeds-triage), map them here so the skill uses the correct labels instead of creating duplicate labels.
Five standard roles:
needs-triage— maintainer needs to triageneeds-info— waiting for the reporter to provide more informationready-for-agent— spec is complete and AFK-ready (an agent can pick it up without human context)ready-for-human— needs human implementationwontfix— won't fix
Default: each role's label string equals its name. Ask the user whether any need to be overridden. If their issue tracker has no labels yet, the defaults are fine.
Part C — Domain documentation.
Explanation: some skills (
improve-codebase-architecture、diagnose、tdd) read theCONTEXT.mdfile to learn the project's domain language, anddocs/adr/to learn past architecture decisions. They need to know whether the repository uses a single global context or multiple contexts (for example a monorepo with both frontend and backend contexts), so they can look in the right places.
Confirm the layout:
- Single context — there is only one
CONTEXT.md+docs/adr/at the repository root. Most repositories are like this. - Multiple contexts — the
CONTEXT-MAP.mdat the root points to separateCONTEXT.mdfiles (usually used for monorepos).
3. Confirm and edit
Show the user the following draft:
- The
CLAUDE.md/AGENTS.mdblock to add to## Agent skills(for selection rules, see step 4) docs/agents/issue-tracker.md、docs/agents/triage-labels.md、docs/agents/domain.mdcontents of
Let the user modify it before writing.
4. Write
Choose the file to edit:
- If
CLAUDE.mdexists, edit it. - Otherwise, if
AGENTS.mdexists, edit it. - If neither exists, ask the user which one to create—do not choose for the user.
Never create CLAUDE.md when AGENTS.mdalready exists (or vice versa)—always edit the one that already exists.
If the selected file already has a ## Agent skills block, update its contents in place instead of appending another duplicate block. Do not overwrite the user's modifications to surrounding paragraphs.
The contents of the block:
## Agent skills
### Issue tracker
[对 issue 跟踪位置的一句话总结]。详见 `docs/agents/issue-tracker.md`。
### Triage labels
[对标签词汇的一句话总结]。详见 `docs/agents/triage-labels.md`。
### Domain docs
[对布局的一句话总结——"单上下文"或"多上下文"]。详见 `docs/agents/domain.md`。
Then, using the seed templates in this skill folder as a starting point, write three documentation files:
- issue-tracker-github.md — GitHub issue tracker
- issue-tracker-gitlab.md — GitLab issue tracker
- issue-tracker-local.md — local markdown issue tracker
- triage-labels.md — label mapping
- domain.md — domain documentation consumption rules + layout
For "other" issue trackers, write docs/agents/issue-tracker.md。
5. Finish
Tell the user setup is complete and which engineering skills will now read these files. Remind them that they can edit docs/agents/*.mddirectly in the future—they only need to rerun this skill if they want to switch issue trackers or reconfigure from scratch.