marcos-ai-bootstrap 0.1.4 → 0.1.6
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +16 -13
- package/package.json +2 -2
- package/src/.agents/skills/initialize/SKILL.md +34 -8
- package/src/.agents/skills/pr/SKILL.md +39 -0
- package/src/.claude/agents/infra-claude.md +1 -1
- package/src/.claude/agents/planner-claude.md +1 -1
- package/src/.claude/skills/initialize/SKILL.md +34 -8
- package/src/.claude/skills/pr/SKILL.md +39 -0
- package/src/.codex/agents/infra-codex.toml +1 -1
- package/src/.codex/agents/planner-codex.toml +1 -1
- package/src/.github/agents/infra-copilot.agent.md +1 -1
- package/src/.github/agents/planner-copilot.agent.md +1 -1
- package/src/.github/skills/initialize/SKILL.md +34 -8
- package/src/.github/skills/pr/SKILL.md +39 -0
- package/src/HUMAN.md +5 -3
- package/src/{AGENTS.md → MARCOS-AI-BOOTSTRAP.md} +9 -4
- package/src/bin/ai-bootstrap.js +22 -7
- package/src/lib/materialize.js +67 -27
package/README.md
CHANGED
|
@@ -23,16 +23,20 @@ npx marcos-ai-bootstrap --all # every tool at once
|
|
|
23
23
|
```
|
|
24
24
|
|
|
25
25
|
Run it from the root of the repository you want to bootstrap. It writes three always-present
|
|
26
|
-
core files—`
|
|
26
|
+
core files—`MARCOS-AI-BOOTSTRAP.md`, `HUMAN.md` (the full tool-agnostic rules + human guide), and
|
|
27
27
|
`documents/templates/plan-template.md` (an empty scaffold for future implementation plans)—alongside
|
|
28
|
-
the agent/skill files for whichever tool(s) you selected.
|
|
28
|
+
the agent/skill files for whichever tool(s) you selected. It always wires the universal `AGENTS.md`
|
|
29
|
+
entry-point with an `@MARCOS-AI-BOOTSTRAP.md` include, and also appends the tool-native include to
|
|
30
|
+
your selected tool's instruction file (creating each only if absent, never overwriting existing content).
|
|
31
|
+
The Stage-2 planner agents
|
|
29
32
|
(planner-copilot, planner-claude, planner-codex) read the plan template before writing plans.
|
|
30
33
|
|
|
31
34
|
| Flag | Writes |
|
|
32
35
|
|---|---|
|
|
33
|
-
|
|
|
34
|
-
| `--
|
|
35
|
-
| `--
|
|
36
|
+
| _(always)_ | `MARCOS-AI-BOOTSTRAP.md`, `HUMAN.md`, `documents/templates/plan-template.md`, and `AGENTS.md` (the universal entry-point, append `@MARCOS-AI-BOOTSTRAP.md` include) |
|
|
37
|
+
| `--claude` | `.claude/agents/*.md`, `.claude/skills/**/SKILL.md`, `CLAUDE.md` (append `@MARCOS-AI-BOOTSTRAP.md` include) |
|
|
38
|
+
| `--codex` | `.codex/agents/*.toml`, `.agents/skills/**/SKILL.md` (Codex reads the always-written `AGENTS.md`) |
|
|
39
|
+
| `--copilot` | `.github/agents/*.agent.md`, `.github/skills/**/SKILL.md`, `.github/copilot-instructions.md` (append `@../MARCOS-AI-BOOTSTRAP.md` include) |
|
|
36
40
|
| `--all` | all of the above |
|
|
37
41
|
|
|
38
42
|
### Options
|
|
@@ -60,27 +64,26 @@ marcos-ai-bootstrap --all
|
|
|
60
64
|
**Everything the CLI materialises into a target repo is shipped from `src/`; `src/` is the single source of truth.**
|
|
61
65
|
|
|
62
66
|
**Shipped source of truth files (in `src/`):**
|
|
63
|
-
- `src/
|
|
67
|
+
- `src/MARCOS-AI-BOOTSTRAP.md`, `src/HUMAN.md` — canonical agent network and human workflow rules.
|
|
64
68
|
- `src/documents/templates/plan-template.md` — canonical plan template scaffold.
|
|
65
69
|
- `src/.claude/agents/`, `src/.claude/skills/`, `src/.codex/agents/`, `src/.codex/`, `src/.github/agents/`, `src/.github/skills/`, `src/.agents/skills/` — tool agent/skill template files materialised by the CLI.
|
|
66
70
|
|
|
67
71
|
**Self-hosted copies (repo root) — NOT published to npm:**
|
|
68
|
-
- `
|
|
72
|
+
- `MARCOS-AI-BOOTSTRAP.md`, `HUMAN.md` (repo root) — this repository's own self-hosted rules copies, used by the agent network running against this repo. The root `AGENTS.md`, `CLAUDE.md`, and `.github/copilot-instructions.md` are thin entry-points that `@`-include `MARCOS-AI-BOOTSTRAP.md`.
|
|
69
73
|
- `documents/templates/plan-template.md`, `.claude/`, `.codex/`, `.github/agents/`, `.github/skills/`, `.agents/skills/` — regenerated from `src/` for this repo's own agents (not shipped).
|
|
70
74
|
- `.github/workflows/` — this repo's own CI/CD; not shipped.
|
|
71
75
|
|
|
72
76
|
**Tooling:**
|
|
73
77
|
- `src/bin/ai-bootstrap.js`, `src/lib/materialize.js` — the CLI implementation.
|
|
74
|
-
- `src/AGENTS-BOOTSTRAP.md` — maintainer-only source of truth for each tool's materialised agent/skill prompt bodies and model tier mappings. References the MCP server discovery flow from the shipped `
|
|
75
|
-
- `src/extract-agents.py` — maintainer tool: regenerates the shipped agent/skill template files under `src/.claude/`, `src/.codex/`, `src/.github/agents/`, `src/.github/skills/`, `src/.agents/skills/` from `src/AGENTS-BOOTSTRAP.md`
|
|
78
|
+
- `src/AGENTS-BOOTSTRAP.md` — maintainer-only source of truth for each tool's materialised agent/skill prompt bodies and model tier mappings. References the MCP server discovery flow from the shipped `MARCOS-AI-BOOTSTRAP.md`. Not published to npm.
|
|
79
|
+
- `src/extract-agents.py` — maintainer tool: regenerates the shipped agent/skill template files under `src/.claude/`, `src/.codex/`, `src/.github/agents/`, `src/.github/skills/`, `src/.agents/skills/` from `src/AGENTS-BOOTSTRAP.md`, then syncs this repo's root self-hosted copies from `src/` (unless `--src-only` is passed). Run this after changing `src/AGENTS-BOOTSTRAP.md`.
|
|
76
80
|
|
|
77
81
|
## Maintaining this repo
|
|
78
82
|
|
|
79
83
|
1. Edit `src/AGENTS-BOOTSTRAP.md` (the source of truth for agent/skill prompt bodies).
|
|
80
|
-
2. Run `python src/extract-agents.py` to regenerate the shipped agent/skill templates under `src/.claude/`, `src/.codex/`, `src/.github/agents/`, `src/.github/skills/`, `src/.agents/skills
|
|
81
|
-
3. Run `node src/bin/ai-bootstrap.js --all --
|
|
82
|
-
4.
|
|
83
|
-
5. Commit the changes.
|
|
84
|
+
2. Run `python src/extract-agents.py` to regenerate the shipped agent/skill templates under `src/.claude/`, `src/.codex/`, `src/.github/agents/`, `src/.github/skills/`, `src/.agents/skills/` **and** sync this repo's root self-hosted copies from `src/` (it invokes the CLI for you). Pass `--src-only` to write `src/` alone.
|
|
85
|
+
3. Run `node src/bin/ai-bootstrap.js --all --dry-run --dest <scratch-dir>` to sanity-check the CLI packages everything correctly.
|
|
86
|
+
4. Commit the changes.
|
|
84
87
|
|
|
85
88
|
## Releasing to npm
|
|
86
89
|
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "marcos-ai-bootstrap",
|
|
3
|
-
"version": "0.1.
|
|
3
|
+
"version": "0.1.6",
|
|
4
4
|
"description": "Materialise the AI-Bootstrap agent/skill network (Claude Code, Codex, GitHub Copilot CLI) into any repository from the command line.",
|
|
5
5
|
"bin": {
|
|
6
6
|
"marcos-ai-bootstrap": "src/bin/ai-bootstrap.js"
|
|
@@ -9,7 +9,7 @@
|
|
|
9
9
|
"files": [
|
|
10
10
|
"src/bin",
|
|
11
11
|
"src/lib",
|
|
12
|
-
"src/
|
|
12
|
+
"src/MARCOS-AI-BOOTSTRAP.md",
|
|
13
13
|
"src/HUMAN.md",
|
|
14
14
|
"src/documents/templates",
|
|
15
15
|
"src/.claude",
|
|
@@ -1,13 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: initialize
|
|
3
|
-
description: One-time environment reconciliation. Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location;
|
|
3
|
+
description: One-time environment reconciliation. First wires this tool's instruction file to the shipped MARCOS-AI-BOOTSTRAP.md rules (appending an @-include, never overwriting; creating the file if absent). Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location; scans past PRs, branch names, and commit history and, after user confirmation, customises the `pr` skill's convention profile; then always prompts the user to choose the model for each tier/role (pre-selecting the current model, or the closest available match when it is unavailable) and rewrites the agent files. Never commits.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in
|
|
6
|
+
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in the phases below. This skill only edits agent and skill files, the tool's instruction entry-point, and MCP config; it never touches source code and never commits.
|
|
7
|
+
|
|
8
|
+
## Phase 0 - Rules-file include wiring
|
|
9
|
+
|
|
10
|
+
The full agent rules ship as `MARCOS-AI-BOOTSTRAP.md` at the repo root. Ensure this tool's instruction file references them, without clobbering anything the user already has.
|
|
11
|
+
|
|
12
|
+
1. Locate the instruction file: `AGENTS.md`.
|
|
13
|
+
2. If it exists and already references `MARCOS-AI-BOOTSTRAP.md`, leave it untouched.
|
|
14
|
+
3. If it exists but does not reference it, APPEND (never overwrite) a short block:
|
|
15
|
+
> # Marcos AI-Bootstrap
|
|
16
|
+
>
|
|
17
|
+
> This repository uses the Marcos AI-Bootstrap agent/skill network. See `@MARCOS-AI-BOOTSTRAP.md` for the agent rules, the MCP server flow, and the canonical agent/skill roles.
|
|
18
|
+
4. If it does not exist, create it containing that block.
|
|
7
19
|
|
|
8
20
|
## Phase 1 - MCP server discovery & wiring
|
|
9
21
|
|
|
10
|
-
1. Run the discovery -> policy-check -> install/verify flow from the "MCP Servers" section of `
|
|
22
|
+
1. Run the discovery -> policy-check -> install/verify flow from the "MCP Servers" section of `MARCOS-AI-BOOTSTRAP.md` (Steps 1-4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
|
|
11
23
|
2. Present the candidate servers to the user. Apply the Step 2 policy check and honour the most restrictive source. Never install a policy-blocked server. Install only servers the user explicitly confirms.
|
|
12
24
|
3. Configure each approved server in `~/.codex/config.toml` (or the project-scoped `.codex`) under `[mcp_servers.<name>]`, then verify with `codex mcp list`.
|
|
13
25
|
4. Wire the approved servers into the agents:
|
|
@@ -19,9 +31,9 @@ You are the initialize orchestrator. Reconcile this repo's agent network with th
|
|
|
19
31
|
|
|
20
32
|
1. Enumerate the models Codex currently exposes. Build the set of available model IDs.
|
|
21
33
|
2. For each file in `.codex/agents/*.toml`, read the `model = "..."` value and its intended tier (High / Standard / Fast) from the tier table below.
|
|
22
|
-
3. For every
|
|
23
|
-
-
|
|
24
|
-
- Use a dropdown prompt (multiple choice) listing
|
|
34
|
+
3. For every tier (High / Standard / Fast), ALWAYS prompt the user to choose the model - even when the currently configured model is available:
|
|
35
|
+
- Pick the pre-selected default: the currently configured model if it is in the available set; otherwise the closest available match - prefer another model in the same tier/family, else the next tier down, else the nearest capability.
|
|
36
|
+
- Use a dropdown prompt (multiple choice) listing every available model, pre-selecting the default from the previous step, and ask the user to confirm or change the model for that tier.
|
|
25
37
|
- Rewrite the agent file's `model = "..."` line with the chosen model. Apply the same choice to every agent sharing that tier so the default profile stays consistent.
|
|
26
38
|
4. Report the final tier -> model mapping and the list of edited files.
|
|
27
39
|
|
|
@@ -41,10 +53,24 @@ You are the initialize orchestrator. Reconcile this repo's agent network with th
|
|
|
41
53
|
4. On confirmation, update every reference to the plans directory so the agents write to and read from the correct place: the `planner-codex` and `planner-discovery-codex` agents, the `planner` and `implement` skills, and the `docs-codex` agent's plan-document references. Leave all other paths untouched.
|
|
42
54
|
5. Report the resolved plans location and the list of edited files.
|
|
43
55
|
|
|
56
|
+
## Phase 4 - PR & contribution convention discovery
|
|
57
|
+
|
|
58
|
+
Customise the `pr` skill so it matches how THIS repository actually works, learned from its own history rather than assumed defaults.
|
|
59
|
+
|
|
60
|
+
1. Gather evidence of the repo's conventions:
|
|
61
|
+
- **Past PRs** - `gh pr list --state merged --limit 50 --json number,title,headRefName,body`. Infer PR-title patterns (Conventional Commits, ticket prefixes like `[ABC-123]`, sentence vs lower case), branch-name patterns (prefixes, separators, casing), and PR-body structure (required sections, checklists).
|
|
62
|
+
- **Commit subjects** - `git --no-pager log origin/<default-branch> --format='%s' -n 100`. Infer the commit-message convention.
|
|
63
|
+
- **Contribution config** - `CONTRIBUTING.md`, `.github/pull_request_template.md` (and `PULL_REQUEST_TEMPLATE/`), `.gitmessage`, commit-lint config (`commitlint.config.*`, `.commitlintrc*`, `.czrc`), and any release automation (`release-please*`, `.releaserc*`, `semantic-release`) that constrains commit/PR format.
|
|
64
|
+
- **Repo settings** - `gh repo view --json defaultBranchRef,mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed` for the default branch and allowed merge methods.
|
|
65
|
+
2. Synthesise a concise convention profile: branch-name rules, commit-message rules, PR-title rules, PR-body/template rules, and any release-automation constraints. Prefer the dominant observed pattern; where history is sparse or inconsistent, fall back to the general Conventional Commits defaults and say so explicitly.
|
|
66
|
+
3. Present the inferred profile to the user for confirmation or edits. Do not rewrite the skill without confirmation.
|
|
67
|
+
4. On confirmation, rewrite ONLY the "Repository conventions" block of `.agents/skills/pr/SKILL.md` - the text between the `<!-- CONVENTIONS:START -->` and `<!-- CONVENTIONS:END -->` markers - with the confirmed profile. Leave the rest of the skill untouched.
|
|
68
|
+
5. Report the resolved convention profile and confirm the `pr` skill was updated.
|
|
69
|
+
|
|
44
70
|
## Guardrails
|
|
45
71
|
- Never commit or push - you edit agent and skill files and MCP config; the user commits.
|
|
46
72
|
- Never install an MCP server that policy blocks or that the user has not approved.
|
|
47
73
|
- Never let an MCP server perform mutating operations against shared or production environments; the infra guardrails still apply.
|
|
48
74
|
- Never change the plans location without explicit user confirmation.
|
|
49
|
-
- Only edit files under `.codex/agents/`, `.agents/skills/`, and the tool's MCP config. Do not modify source code.
|
|
50
|
-
- Idempotent: re-running makes no changes when servers are already wired
|
|
75
|
+
- Only edit files under `.codex/agents/`, `.agents/skills/`, the tool's instruction entry-point (`AGENTS.md`), and the tool's MCP config. Do not modify source code.
|
|
76
|
+
- Idempotent for MCP wiring and the plans location: re-running makes no changes when servers are already wired and the plans location already matches. Model selection is always offered - re-running re-prompts for each tier, but keeping the current selection leaves the files unchanged.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr
|
|
3
|
+
description: Open a pull request that follows this repository's conventions for branch names, commit messages, and PR titles and bodies. Verifies you are on a working branch, checks and repairs the branch/commits/title against the active convention profile, pushes, and opens the PR with the GitHub CLI. Never merges the PR.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are the pr orchestrator. Open a pull request that conforms to this repository's contribution conventions, then hand off to the user to merge. Never merge the PR yourself and never push to the default branch.
|
|
7
|
+
|
|
8
|
+
## Convention profile
|
|
9
|
+
|
|
10
|
+
Apply the rules in the "Repository conventions" section below. While that section still holds the shipped defaults, fall back to these widely-used best-practice defaults:
|
|
11
|
+
|
|
12
|
+
- **Branch names:** short, kebab-case, prefixed by change type - `feat/`, `fix/`, `chore/`, `docs/`, `refactor/`, `test/`. Never commit on the default branch.
|
|
13
|
+
- **Commit messages:** Conventional Commits - `<type>[optional scope][!]: <description>` in the imperative mood, subject <= 72 chars. Types: `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `style`, `revert`. A `!` or `BREAKING CHANGE:` footer marks a breaking change. Validation regex: `^(feat|fix|perf|refactor|docs|test|build|ci|chore|style|revert)(\([^)]+\))?!?: .+`
|
|
14
|
+
- **PR title:** one-line summary in the same style as the commit convention.
|
|
15
|
+
- **PR body:** what changed and why, linked issues, and user-facing impact / testing notes. Honour `.github/pull_request_template.md` if present.
|
|
16
|
+
- **Release automation:** some tools (release-please, semantic-release) only cut a release when a recognised commit type lands on the default branch. If this repo uses one, ensure at least one release-triggering commit (typically `feat`/`fix` or a breaking change) is present when a release is intended.
|
|
17
|
+
|
|
18
|
+
## Repository conventions
|
|
19
|
+
|
|
20
|
+
<!-- CONVENTIONS:START -->
|
|
21
|
+
_Not yet customised. Run the `initialize` skill to scan this repository's history (past PRs, branch names, commit subjects, and any CONTRIBUTING / PR-template / commit-lint config) and replace this block with the repo's actual conventions. Until then, the general defaults above apply._
|
|
22
|
+
<!-- CONVENTIONS:END -->
|
|
23
|
+
|
|
24
|
+
## Steps
|
|
25
|
+
|
|
26
|
+
1. **Determine the default branch** - `git symbolic-ref --quiet refs/remotes/origin/HEAD` (fallback `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`); call it `<base>`.
|
|
27
|
+
2. **Branch check** - Confirm the current branch is not `<base>` (`git branch --show-current`). If it is, STOP and ask the user to create a working branch that matches the branch-name convention.
|
|
28
|
+
3. **Branch-name check** - Validate the current branch name against the active convention; if it does not match, offer to rename it (`git branch -m <new>`) before pushing.
|
|
29
|
+
4. **Commit check** - List commits not yet on `<base>` (`git --no-pager log origin/<base>..HEAD --format='%H %s'`) and validate each subject against the commit convention. If any fail, propose compliant rewrites and, only on explicit user confirmation, reword them (`git commit --amend` for the tip, `git rebase -i origin/<base>` for earlier commits). Never reword commits already on `<base>`. If a release is intended and the convention requires a release-triggering type, ensure at least one such commit exists.
|
|
30
|
+
5. **Push** - `git push -u origin <branch>`. Never push to `<base>`. Force-push only to complete a reword/rebase the user explicitly approved, and never with `--no-verify`.
|
|
31
|
+
6. **PR title & body** - Derive a title matching the PR-title convention and a body matching the PR-body convention (and template, if any); validate before submitting.
|
|
32
|
+
7. **Open the PR** - `gh pr create --base <base> --title "<title>" --body "<body>"`.
|
|
33
|
+
8. **Report** - Print the PR URL plus any repo-specific merge/release guidance from the conventions section.
|
|
34
|
+
|
|
35
|
+
## Guardrails
|
|
36
|
+
- Never merge the PR - opening it is the final step; the user merges.
|
|
37
|
+
- Never push to, or commit on, the default branch.
|
|
38
|
+
- Force-push only to complete a reword/rebase the user explicitly approved.
|
|
39
|
+
- Never use `--no-verify`.
|
|
@@ -11,7 +11,7 @@ You are the infra agent. You modify infrastructure as code only.
|
|
|
11
11
|
- Never commit to main. Always work on the branch specified in the task.
|
|
12
12
|
- Never run manual CLI commands (az, aws, gcloud, kubectl) against shared or production environments.
|
|
13
13
|
- All changes must be made in IAC files and applied through the deployment pipeline.
|
|
14
|
-
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `
|
|
14
|
+
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
15
15
|
- Validate IAC (e.g. az bicep build) before declaring done.
|
|
16
16
|
- Delegate documentation updates to the docs agent.
|
|
17
17
|
- Do not change application code — that belongs to the code agent.
|
|
@@ -9,7 +9,7 @@ You are the planner. You run Stage 2 of the two-stage planning process.
|
|
|
9
9
|
|
|
10
10
|
## Your job
|
|
11
11
|
Take the approved outline from Stage 1 and produce a complete implementation plan written to documents/plans/<YYYYMMDD>-<topic>.md (e.g. documents/plans/20260408-calendar.md).
|
|
12
|
-
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `
|
|
12
|
+
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
13
13
|
|
|
14
14
|
## Plan template
|
|
15
15
|
Before drafting, read `documents/templates/plan-template.md` and follow its
|
|
@@ -1,13 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: initialize
|
|
3
|
-
description: One-time environment reconciliation. Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location;
|
|
3
|
+
description: One-time environment reconciliation. First wires this tool's instruction file to the shipped MARCOS-AI-BOOTSTRAP.md rules (appending an @-include, never overwriting; creating the file if absent). Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location; scans past PRs, branch names, and commit history and, after user confirmation, customises the `pr` skill's convention profile; then always prompts the user to choose the model for each tier/role (pre-selecting the current model, or the closest available match when it is unavailable) and rewrites the agent files. Never commits.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in
|
|
6
|
+
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in the phases below. This skill only edits agent and skill files, the tool's instruction entry-point, and MCP config; it never touches source code and never commits.
|
|
7
|
+
|
|
8
|
+
## Phase 0 — Rules-file include wiring
|
|
9
|
+
|
|
10
|
+
The full agent rules ship as `MARCOS-AI-BOOTSTRAP.md` at the repo root. Ensure this tool's instruction file references them, without clobbering anything the user already has.
|
|
11
|
+
|
|
12
|
+
1. Locate the instruction file: `CLAUDE.md`.
|
|
13
|
+
2. If it exists and already references `MARCOS-AI-BOOTSTRAP.md`, leave it untouched.
|
|
14
|
+
3. If it exists but does not reference it, APPEND (never overwrite) a short block:
|
|
15
|
+
> # Marcos AI-Bootstrap
|
|
16
|
+
>
|
|
17
|
+
> This repository uses the Marcos AI-Bootstrap agent/skill network. See `@MARCOS-AI-BOOTSTRAP.md` for the agent rules, the MCP server flow, and the canonical agent/skill roles.
|
|
18
|
+
4. If it does not exist, create it containing that block.
|
|
7
19
|
|
|
8
20
|
## Phase 1 — MCP server discovery & wiring
|
|
9
21
|
|
|
10
|
-
1. Run the discovery → policy-check → install/verify flow from the "MCP Servers" section of `
|
|
22
|
+
1. Run the discovery → policy-check → install/verify flow from the "MCP Servers" section of `MARCOS-AI-BOOTSTRAP.md` (Steps 1–4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
|
|
11
23
|
2. Present the candidate servers to the user. Apply the Step 2 policy check and honour the most restrictive source. Never install a policy-blocked server. Install only servers the user explicitly confirms.
|
|
12
24
|
3. Install each approved server with `claude mcp add <name> -- <command...>` and verify with `claude mcp list`.
|
|
13
25
|
4. Wire the approved servers into the agents:
|
|
@@ -19,9 +31,9 @@ You are the initialize orchestrator. Reconcile this repo's agent network with th
|
|
|
19
31
|
|
|
20
32
|
1. Enumerate the models Claude Code currently exposes (the `/model` picker / managed settings). Build the set of available model IDs.
|
|
21
33
|
2. For each file in `.claude/agents/*.md`, read the `model:` frontmatter value and its intended tier (High / Standard / Fast) from the tier table below.
|
|
22
|
-
3. For every
|
|
23
|
-
-
|
|
24
|
-
- Use a dropdown prompt (multiple choice) listing
|
|
34
|
+
3. For every tier (High / Standard / Fast), ALWAYS prompt the user to choose the model — even when the currently configured model is available:
|
|
35
|
+
- Pick the pre-selected default: the currently configured model if it is in the available set; otherwise the closest available match — prefer another model in the same tier/family, else the next tier down, else the nearest capability.
|
|
36
|
+
- Use a dropdown prompt (multiple choice) listing every available model, pre-selecting the default from the previous step, and ask the user to confirm or change the model for that tier.
|
|
25
37
|
- Rewrite the agent file's `model:` line with the chosen model. Apply the same choice to every agent sharing that tier so the default profile stays consistent.
|
|
26
38
|
4. Report the final tier → model mapping and the list of edited files.
|
|
27
39
|
|
|
@@ -41,10 +53,24 @@ You are the initialize orchestrator. Reconcile this repo's agent network with th
|
|
|
41
53
|
4. On confirmation, update every reference to the plans directory so the agents write to and read from the correct place: the `planner-claude` and `planner-discovery-claude` agents, the `planner` and `implement` skills, and the `docs-claude` agent's plan-document references. Leave all other paths untouched.
|
|
42
54
|
5. Report the resolved plans location and the list of edited files.
|
|
43
55
|
|
|
56
|
+
## Phase 4 — PR & contribution convention discovery
|
|
57
|
+
|
|
58
|
+
Customise the `pr` skill so it matches how THIS repository actually works, learned from its own history rather than assumed defaults.
|
|
59
|
+
|
|
60
|
+
1. Gather evidence of the repo's conventions:
|
|
61
|
+
- **Past PRs** — `gh pr list --state merged --limit 50 --json number,title,headRefName,body`. Infer PR-title patterns (Conventional Commits, ticket prefixes like `[ABC-123]`, sentence vs lower case), branch-name patterns (prefixes, separators, casing), and PR-body structure (required sections, checklists).
|
|
62
|
+
- **Commit subjects** — `git --no-pager log origin/<default-branch> --format='%s' -n 100`. Infer the commit-message convention.
|
|
63
|
+
- **Contribution config** — `CONTRIBUTING.md`, `.github/pull_request_template.md` (and `PULL_REQUEST_TEMPLATE/`), `.gitmessage`, commit-lint config (`commitlint.config.*`, `.commitlintrc*`, `.czrc`), and any release automation (`release-please*`, `.releaserc*`, `semantic-release`) that constrains commit/PR format.
|
|
64
|
+
- **Repo settings** — `gh repo view --json defaultBranchRef,mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed` for the default branch and allowed merge methods.
|
|
65
|
+
2. Synthesise a concise convention profile: branch-name rules, commit-message rules, PR-title rules, PR-body/template rules, and any release-automation constraints. Prefer the dominant observed pattern; where history is sparse or inconsistent, fall back to the general Conventional Commits defaults and say so explicitly.
|
|
66
|
+
3. Present the inferred profile to the user for confirmation or edits. Do not rewrite the skill without confirmation.
|
|
67
|
+
4. On confirmation, rewrite ONLY the "Repository conventions" block of `.claude/skills/pr/SKILL.md` — the text between the `<!-- CONVENTIONS:START -->` and `<!-- CONVENTIONS:END -->` markers — with the confirmed profile. Leave the rest of the skill untouched.
|
|
68
|
+
5. Report the resolved convention profile and confirm the `pr` skill was updated.
|
|
69
|
+
|
|
44
70
|
## Guardrails
|
|
45
71
|
- Never commit or push — you edit agent and skill files and MCP config; the user commits.
|
|
46
72
|
- Never install an MCP server that policy blocks or that the user has not approved.
|
|
47
73
|
- Never let an MCP server perform mutating operations against shared or production environments; the infra guardrails still apply.
|
|
48
74
|
- Never change the plans location without explicit user confirmation.
|
|
49
|
-
- Only edit files under `.claude/agents/`, `.claude/skills/`, and the tool's MCP config. Do not modify source code.
|
|
50
|
-
- Idempotent: re-running makes no changes when servers are already wired
|
|
75
|
+
- Only edit files under `.claude/agents/`, `.claude/skills/`, the tool's instruction entry-point (`CLAUDE.md`), and the tool's MCP config. Do not modify source code.
|
|
76
|
+
- Idempotent for MCP wiring and the plans location: re-running makes no changes when servers are already wired and the plans location already matches. Model selection is always offered — re-running re-prompts for each tier, but keeping the current selection leaves the files unchanged.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr
|
|
3
|
+
description: Open a pull request that follows this repository's conventions for branch names, commit messages, and PR titles and bodies. Verifies you are on a working branch, checks and repairs the branch/commits/title against the active convention profile, pushes, and opens the PR with the GitHub CLI. Never merges the PR.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are the pr orchestrator. Open a pull request that conforms to this repository's contribution conventions, then hand off to the user to merge. Never merge the PR yourself and never push to the default branch.
|
|
7
|
+
|
|
8
|
+
## Convention profile
|
|
9
|
+
|
|
10
|
+
Apply the rules in the "Repository conventions" section below. While that section still holds the shipped defaults, fall back to these widely-used best-practice defaults:
|
|
11
|
+
|
|
12
|
+
- **Branch names:** short, kebab-case, prefixed by change type — `feat/`, `fix/`, `chore/`, `docs/`, `refactor/`, `test/`. Never commit on the default branch.
|
|
13
|
+
- **Commit messages:** Conventional Commits — `<type>[optional scope][!]: <description>` in the imperative mood, subject <= 72 chars. Types: `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `style`, `revert`. A `!` or `BREAKING CHANGE:` footer marks a breaking change. Validation regex: `^(feat|fix|perf|refactor|docs|test|build|ci|chore|style|revert)(\([^)]+\))?!?: .+`
|
|
14
|
+
- **PR title:** one-line summary in the same style as the commit convention.
|
|
15
|
+
- **PR body:** what changed and why, linked issues, and user-facing impact / testing notes. Honour `.github/pull_request_template.md` if present.
|
|
16
|
+
- **Release automation:** some tools (release-please, semantic-release) only cut a release when a recognised commit type lands on the default branch. If this repo uses one, ensure at least one release-triggering commit (typically `feat`/`fix` or a breaking change) is present when a release is intended.
|
|
17
|
+
|
|
18
|
+
## Repository conventions
|
|
19
|
+
|
|
20
|
+
<!-- CONVENTIONS:START -->
|
|
21
|
+
_Not yet customised. Run the `initialize` skill to scan this repository's history (past PRs, branch names, commit subjects, and any CONTRIBUTING / PR-template / commit-lint config) and replace this block with the repo's actual conventions. Until then, the general defaults above apply._
|
|
22
|
+
<!-- CONVENTIONS:END -->
|
|
23
|
+
|
|
24
|
+
## Steps
|
|
25
|
+
|
|
26
|
+
1. **Determine the default branch** — `git symbolic-ref --quiet refs/remotes/origin/HEAD` (fallback `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`); call it `<base>`.
|
|
27
|
+
2. **Branch check** — Confirm the current branch is not `<base>` (`git branch --show-current`). If it is, STOP and ask the user to create a working branch that matches the branch-name convention.
|
|
28
|
+
3. **Branch-name check** — Validate the current branch name against the active convention; if it does not match, offer to rename it (`git branch -m <new>`) before pushing.
|
|
29
|
+
4. **Commit check** — List commits not yet on `<base>` (`git --no-pager log origin/<base>..HEAD --format='%H %s'`) and validate each subject against the commit convention. If any fail, propose compliant rewrites and, only on explicit user confirmation, reword them (`git commit --amend` for the tip, `git rebase -i origin/<base>` for earlier commits). Never reword commits already on `<base>`. If a release is intended and the convention requires a release-triggering type, ensure at least one such commit exists.
|
|
30
|
+
5. **Push** — `git push -u origin <branch>`. Never push to `<base>`. Force-push only to complete a reword/rebase the user explicitly approved, and never with `--no-verify`.
|
|
31
|
+
6. **PR title & body** — Derive a title matching the PR-title convention and a body matching the PR-body convention (and template, if any); validate before submitting.
|
|
32
|
+
7. **Open the PR** — `gh pr create --base <base> --title "<title>" --body "<body>"`.
|
|
33
|
+
8. **Report** — Print the PR URL plus any repo-specific merge/release guidance from the conventions section.
|
|
34
|
+
|
|
35
|
+
## Guardrails
|
|
36
|
+
- Never merge the PR — opening it is the final step; the user merges.
|
|
37
|
+
- Never push to, or commit on, the default branch.
|
|
38
|
+
- Force-push only to complete a reword/rebase the user explicitly approved.
|
|
39
|
+
- Never use `--no-verify`.
|
|
@@ -10,7 +10,7 @@ You are the infra agent. You modify infrastructure as code only.
|
|
|
10
10
|
- Never commit to main. Always work on the branch specified in the task.
|
|
11
11
|
- Never run manual CLI commands (az, aws, gcloud, kubectl) against shared or production environments.
|
|
12
12
|
- All changes must be made in IAC files and applied through the deployment pipeline.
|
|
13
|
-
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `
|
|
13
|
+
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
14
14
|
- Validate IAC (e.g. az bicep build) before declaring done.
|
|
15
15
|
- Delegate documentation updates to the docs agent.
|
|
16
16
|
- Do not change application code — that belongs to the code agent.
|
|
@@ -8,7 +8,7 @@ You are the planner. You run Stage 2 of the two-stage planning process.
|
|
|
8
8
|
|
|
9
9
|
## Your job
|
|
10
10
|
Take the approved outline from Stage 1 and produce a complete implementation plan written to documents/plans/<YYYYMMDD>-<topic>.md (e.g. documents/plans/20260408-calendar.md).
|
|
11
|
-
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `
|
|
11
|
+
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
12
12
|
|
|
13
13
|
## Plan template
|
|
14
14
|
Before drafting, read `documents/templates/plan-template.md` and follow its
|
|
@@ -11,7 +11,7 @@ You are the infra-copilot agent. You modify infrastructure as code only.
|
|
|
11
11
|
- Never commit to main. Always work on the branch specified in the task.
|
|
12
12
|
- Never run manual CLI commands (az, aws, gcloud, kubectl) against shared or production environments.
|
|
13
13
|
- All changes must be made in IAC files and applied through the deployment pipeline.
|
|
14
|
-
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `
|
|
14
|
+
- Use the discovered, policy-approved MCP servers that match the platform a task touches (e.g. `azure` for Azure/IAC, `cloudflare` for Workers/DNS/edge) plus any read-only docs server for reference material, whenever they are available. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
15
15
|
- Validate IAC (e.g. az bicep build) before declaring done.
|
|
16
16
|
- Delegate documentation updates to the docs-copilot agent.
|
|
17
17
|
- Do not change application code — that belongs to the code-copilot agent.
|
|
@@ -9,7 +9,7 @@ You are the planner-copilot agent. You run Stage 2 of the two-stage planning pro
|
|
|
9
9
|
|
|
10
10
|
## Your job
|
|
11
11
|
Take the approved outline from Stage 1 and produce a complete implementation plan written to documents/plans/<YYYYMMDD>-<topic>.md (e.g. documents/plans/20260408-calendar.md).
|
|
12
|
-
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `
|
|
12
|
+
Before drafting the plan, check whether any discovered, policy-approved MCP servers are relevant to the task; initialize or use the relevant ones where available, and incorporate what you learn into the plan. Query the server that matches each platform the plan touches (e.g. `azure` for Azure/IAC work, `cloudflare` for Cloudflare Workers/DNS/edge work) and fold its findings into the plan. See the MCP Servers section of `MARCOS-AI-BOOTSTRAP.md` for the discovery and policy-check flow.
|
|
13
13
|
|
|
14
14
|
## Plan template
|
|
15
15
|
Before drafting, read `documents/templates/plan-template.md` and follow its
|
|
@@ -1,13 +1,25 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: initialize
|
|
3
|
-
description: One-time environment reconciliation. Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location;
|
|
3
|
+
description: One-time environment reconciliation. First wires this tool's instruction file to the shipped MARCOS-AI-BOOTSTRAP.md rules (appending an @-include, never overwriting; creating the file if absent). Discovers applicable MCP servers and, with user approval, installs and wires them into the infra/planner agents; discovers where plan documents actually live and, after user confirmation, wires the planner/implement/docs agents to that location; scans past PRs, branch names, and commit history and, after user confirmation, customises the `pr` skill's convention profile; then always prompts the user to choose the model for each tier/role (pre-selecting the current model, or the closest available match when it is unavailable) and rewrites the agent files. Never commits.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in
|
|
6
|
+
You are the initialize orchestrator. Reconcile this repo's agent network with the current environment in the phases below. This skill only edits agent and skill files, the tool's instruction entry-point, and MCP config; it never touches source code and never commits.
|
|
7
|
+
|
|
8
|
+
## Phase 0 — Rules-file include wiring
|
|
9
|
+
|
|
10
|
+
The full agent rules ship as `MARCOS-AI-BOOTSTRAP.md` at the repo root. Ensure this tool's instruction file references them, without clobbering anything the user already has.
|
|
11
|
+
|
|
12
|
+
1. Locate the instruction file: `.github/copilot-instructions.md`.
|
|
13
|
+
2. If it exists and already references `MARCOS-AI-BOOTSTRAP.md`, leave it untouched.
|
|
14
|
+
3. If it exists but does not reference it, APPEND (never overwrite) a short block:
|
|
15
|
+
> # Marcos AI-Bootstrap
|
|
16
|
+
>
|
|
17
|
+
> This repository uses the Marcos AI-Bootstrap agent/skill network. See `@../MARCOS-AI-BOOTSTRAP.md` for the agent rules, the MCP server flow, and the canonical agent/skill roles.
|
|
18
|
+
4. If it does not exist, create it containing that block.
|
|
7
19
|
|
|
8
20
|
## Phase 1 — MCP server discovery & wiring
|
|
9
21
|
|
|
10
|
-
1. Run the discovery → policy-check → install/verify flow from the "MCP Servers" section of `
|
|
22
|
+
1. Run the discovery → policy-check → install/verify flow from the "MCP Servers" section of `MARCOS-AI-BOOTSTRAP.md` (Steps 1–4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
|
|
11
23
|
2. Present the candidate servers to the user. Apply the Step 2 policy check and honour the most restrictive source. Never install a policy-blocked server. Install only servers the user explicitly confirms.
|
|
12
24
|
3. Configure each approved server in `~/.copilot/mcp-config.json` (or the project-scoped equivalent) under `mcpServers`, then verify with `/mcp`.
|
|
13
25
|
4. Wire the approved servers into the agents:
|
|
@@ -19,9 +31,9 @@ You are the initialize orchestrator. Reconcile this repo's agent network with th
|
|
|
19
31
|
|
|
20
32
|
1. Enumerate the models Copilot CLI currently exposes (the `/model` picker). Build the set of available model IDs.
|
|
21
33
|
2. For each file in `.github/agents/*.agent.md`, read the `model:` frontmatter value and its intended tier (High / Standard / Fast) from the tier table below. Note the `infra-copilot` role-specific override (`gpt-5.4`).
|
|
22
|
-
3. For every `
|
|
23
|
-
-
|
|
24
|
-
- Use a dropdown prompt (multiple choice) listing
|
|
34
|
+
3. For every tier (High / Standard / Fast) and the `infra-copilot` role override, ALWAYS prompt the user to choose the model — even when the currently configured model is available:
|
|
35
|
+
- Pick the pre-selected default: the currently configured model if it is in the available set; otherwise the closest available match — prefer another model in the same tier/family, else the next tier down, else the nearest capability. For the `infra-copilot` role override (`gpt-5.4`), offer the closest available GPT model first.
|
|
36
|
+
- Use a dropdown prompt (multiple choice) listing every available model, pre-selecting the default from the previous step, and ask the user to confirm or change the model for that tier or role.
|
|
25
37
|
- Rewrite the agent file's `model:` line with the chosen model. Apply the same choice to every agent sharing that tier so the mixed default profile stays consistent.
|
|
26
38
|
4. Report the final tier/role → model mapping and the list of edited files.
|
|
27
39
|
|
|
@@ -43,10 +55,24 @@ Role-specific override: `infra-copilot` uses `gpt-5.4`.
|
|
|
43
55
|
4. On confirmation, update every reference to the plans directory so the agents write to and read from the correct place: the `planner-copilot` and `planner-discovery-copilot` agents, the `planner` and `implement` skills, and the `docs-copilot` agent's plan-document references. Leave all other paths untouched.
|
|
44
56
|
5. Report the resolved plans location and the list of edited files.
|
|
45
57
|
|
|
58
|
+
## Phase 4 — PR & contribution convention discovery
|
|
59
|
+
|
|
60
|
+
Customise the `pr` skill so it matches how THIS repository actually works, learned from its own history rather than assumed defaults.
|
|
61
|
+
|
|
62
|
+
1. Gather evidence of the repo's conventions:
|
|
63
|
+
- **Past PRs** — `gh pr list --state merged --limit 50 --json number,title,headRefName,body`. Infer PR-title patterns (Conventional Commits, ticket prefixes like `[ABC-123]`, sentence vs lower case), branch-name patterns (prefixes, separators, casing), and PR-body structure (required sections, checklists).
|
|
64
|
+
- **Commit subjects** — `git --no-pager log origin/<default-branch> --format='%s' -n 100`. Infer the commit-message convention.
|
|
65
|
+
- **Contribution config** — `CONTRIBUTING.md`, `.github/pull_request_template.md` (and `PULL_REQUEST_TEMPLATE/`), `.gitmessage`, commit-lint config (`commitlint.config.*`, `.commitlintrc*`, `.czrc`), and any release automation (`release-please*`, `.releaserc*`, `semantic-release`) that constrains commit/PR format.
|
|
66
|
+
- **Repo settings** — `gh repo view --json defaultBranchRef,mergeCommitAllowed,squashMergeAllowed,rebaseMergeAllowed` for the default branch and allowed merge methods.
|
|
67
|
+
2. Synthesise a concise convention profile: branch-name rules, commit-message rules, PR-title rules, PR-body/template rules, and any release-automation constraints. Prefer the dominant observed pattern; where history is sparse or inconsistent, fall back to the general Conventional Commits defaults and say so explicitly.
|
|
68
|
+
3. Present the inferred profile to the user for confirmation or edits. Do not rewrite the skill without confirmation.
|
|
69
|
+
4. On confirmation, rewrite ONLY the "Repository conventions" block of `.github/skills/pr/SKILL.md` — the text between the `<!-- CONVENTIONS:START -->` and `<!-- CONVENTIONS:END -->` markers — with the confirmed profile. Leave the rest of the skill untouched.
|
|
70
|
+
5. Report the resolved convention profile and confirm the `pr` skill was updated.
|
|
71
|
+
|
|
46
72
|
## Guardrails
|
|
47
73
|
- Never commit or push — you edit agent and skill files and MCP config; the user commits.
|
|
48
74
|
- Never install an MCP server that policy blocks or that the user has not approved.
|
|
49
75
|
- Never let an MCP server perform mutating operations against shared or production environments; the infra guardrails still apply.
|
|
50
76
|
- Never change the plans location without explicit user confirmation.
|
|
51
|
-
- Only edit files under `.github/agents/`, `.github/skills/`, and the tool's MCP config. Do not modify source code.
|
|
52
|
-
- Idempotent: re-running makes no changes when servers are already wired
|
|
77
|
+
- Only edit files under `.github/agents/`, `.github/skills/`, the tool's instruction entry-point (`.github/copilot-instructions.md`), and the tool's MCP config. Do not modify source code.
|
|
78
|
+
- Idempotent for MCP wiring and the plans location: re-running makes no changes when servers are already wired and the plans location already matches. Model selection is always offered — re-running re-prompts for each tier/role, but keeping the current selection leaves the files unchanged.
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pr
|
|
3
|
+
description: Open a pull request that follows this repository's conventions for branch names, commit messages, and PR titles and bodies. Verifies you are on a working branch, checks and repairs the branch/commits/title against the active convention profile, pushes, and opens the PR with the GitHub CLI. Never merges the PR.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
You are the pr orchestrator. Open a pull request that conforms to this repository's contribution conventions, then hand off to the user to merge. Never merge the PR yourself and never push to the default branch.
|
|
7
|
+
|
|
8
|
+
## Convention profile
|
|
9
|
+
|
|
10
|
+
Apply the rules in the "Repository conventions" section below. While that section still holds the shipped defaults, fall back to these widely-used best-practice defaults:
|
|
11
|
+
|
|
12
|
+
- **Branch names:** short, kebab-case, prefixed by change type — `feat/`, `fix/`, `chore/`, `docs/`, `refactor/`, `test/`. Never commit on the default branch.
|
|
13
|
+
- **Commit messages:** Conventional Commits — `<type>[optional scope][!]: <description>` in the imperative mood, subject <= 72 chars. Types: `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `style`, `revert`. A `!` or `BREAKING CHANGE:` footer marks a breaking change. Validation regex: `^(feat|fix|perf|refactor|docs|test|build|ci|chore|style|revert)(\([^)]+\))?!?: .+`
|
|
14
|
+
- **PR title:** one-line summary in the same style as the commit convention.
|
|
15
|
+
- **PR body:** what changed and why, linked issues, and user-facing impact / testing notes. Honour `.github/pull_request_template.md` if present.
|
|
16
|
+
- **Release automation:** some tools (release-please, semantic-release) only cut a release when a recognised commit type lands on the default branch. If this repo uses one, ensure at least one release-triggering commit (typically `feat`/`fix` or a breaking change) is present when a release is intended.
|
|
17
|
+
|
|
18
|
+
## Repository conventions
|
|
19
|
+
|
|
20
|
+
<!-- CONVENTIONS:START -->
|
|
21
|
+
_Not yet customised. Run the `initialize` skill to scan this repository's history (past PRs, branch names, commit subjects, and any CONTRIBUTING / PR-template / commit-lint config) and replace this block with the repo's actual conventions. Until then, the general defaults above apply._
|
|
22
|
+
<!-- CONVENTIONS:END -->
|
|
23
|
+
|
|
24
|
+
## Steps
|
|
25
|
+
|
|
26
|
+
1. **Determine the default branch** — `git symbolic-ref --quiet refs/remotes/origin/HEAD` (fallback `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`); call it `<base>`.
|
|
27
|
+
2. **Branch check** — Confirm the current branch is not `<base>` (`git branch --show-current`). If it is, STOP and ask the user to create a working branch that matches the branch-name convention.
|
|
28
|
+
3. **Branch-name check** — Validate the current branch name against the active convention; if it does not match, offer to rename it (`git branch -m <new>`) before pushing.
|
|
29
|
+
4. **Commit check** — List commits not yet on `<base>` (`git --no-pager log origin/<base>..HEAD --format='%H %s'`) and validate each subject against the commit convention. If any fail, propose compliant rewrites and, only on explicit user confirmation, reword them (`git commit --amend` for the tip, `git rebase -i origin/<base>` for earlier commits). Never reword commits already on `<base>`. If a release is intended and the convention requires a release-triggering type, ensure at least one such commit exists.
|
|
30
|
+
5. **Push** — `git push -u origin <branch>`. Never push to `<base>`. Force-push only to complete a reword/rebase the user explicitly approved, and never with `--no-verify`.
|
|
31
|
+
6. **PR title & body** — Derive a title matching the PR-title convention and a body matching the PR-body convention (and template, if any); validate before submitting.
|
|
32
|
+
7. **Open the PR** — `gh pr create --base <base> --title "<title>" --body "<body>"`.
|
|
33
|
+
8. **Report** — Print the PR URL plus any repo-specific merge/release guidance from the conventions section.
|
|
34
|
+
|
|
35
|
+
## Guardrails
|
|
36
|
+
- Never merge the PR — opening it is the final step; the user merges.
|
|
37
|
+
- Never push to, or commit on, the default branch.
|
|
38
|
+
- Force-push only to complete a reword/rebase the user explicitly approved.
|
|
39
|
+
- Never use `--no-verify`.
|
package/src/HUMAN.md
CHANGED
|
@@ -10,14 +10,15 @@ Fastest path — use the `marcos-ai-bootstrap` CLI (no AI turn required, works i
|
|
|
10
10
|
npx marcos-ai-bootstrap --copilot # or --claude, --codex, or --all
|
|
11
11
|
```
|
|
12
12
|
|
|
13
|
-
This instantly writes `
|
|
13
|
+
This instantly writes `MARCOS-AI-BOOTSTRAP.md`, `HUMAN.md`, an `@MARCOS-AI-BOOTSTRAP.md` include in
|
|
14
|
+
your tool's instruction file, and the fully materialised agent/skill
|
|
14
15
|
files for the tool(s) you chose into the current directory. That's it — the agents and
|
|
15
16
|
skills are ready to use immediately. See the root `README.md` for all flags (`--force`,
|
|
16
17
|
`--dry-run`, `--dest`).
|
|
17
18
|
|
|
18
19
|
Once the files are written:
|
|
19
20
|
|
|
20
|
-
1. Confirm `
|
|
21
|
+
1. Confirm `MARCOS-AI-BOOTSTRAP.md`, `HUMAN.md`, and your tool's agent/skill files are present in the repo.
|
|
21
22
|
2. Switch to your most powerful model at medium effort using **`/model`** e.g. opus 4.8 @ medium effort
|
|
22
23
|
3. Run the **`/initialize`** skill once to reconcile MCP servers, plan-document location, and model IDs with your environment.
|
|
23
24
|
4. **`/clear`** — Clear the context window.
|
|
@@ -28,4 +29,5 @@ Once the files are written:
|
|
|
28
29
|
1. **`/planner`** — Give a basic outline of what you want to build. The agent asks clarifying questions and iterates until it has a complete plan for the feature, bugfix, or chore.
|
|
29
30
|
2. **`/clear`** — Clear the context window.
|
|
30
31
|
3. **`/implement`** — Paste the path to the plan that was created, e.g. `documents/plans/20260101-plan.md`.
|
|
31
|
-
4. **`/
|
|
32
|
+
4. **`/pr`** — Open a pull request with Conventional Commit messages so the release-please workflow can cut a release once merged.
|
|
33
|
+
5. **`/watch-ci`** — Paste the PR or GitHub Actions run. It watches the build to make sure everything passes, fixing bugs in real time if needed.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Agent Rules
|
|
2
2
|
|
|
3
|
-
This file is tool-agnostic
|
|
3
|
+
This file is tool-agnostic and ships as `MARCOS-AI-BOOTSTRAP.md` at the repo root. Reference it from your AI tool's instruction entry-point (e.g. `CLAUDE.md` or `AGENTS.md` via `@MARCOS-AI-BOOTSTRAP.md`, or `.github/copilot-instructions.md` via `@../MARCOS-AI-BOOTSTRAP.md`) so these rules apply without overwriting instructions you already have. The `marcos-ai-bootstrap` CLI and the `initialize` skill append that reference for you (creating the entry-point file if it does not exist).
|
|
4
4
|
|
|
5
5
|
The agent and skill files for your specific tool are materialised into the repository by the `marcos-ai-bootstrap` CLI (under `.claude/`, `.codex/`, `.github/`, or `.agents/`). This file is the tool-agnostic source of truth for the rules, the MCP server flow, and the canonical agent/skill roles.
|
|
6
6
|
|
|
@@ -127,9 +127,14 @@ Canonical skills:
|
|
|
127
127
|
**Guardrails:** Never commits or pushes — agents edit files, the user commits. Never works on `main` (uses the plan's branch). Honours each phase's agent designation exactly; stops on a failed phase.
|
|
128
128
|
|
|
129
129
|
### initialize
|
|
130
|
-
**Purpose:** One-time environment reconciliation. Discovers applicable MCP servers (via the MCP Servers discovery → policy-check → install flow) and, with user approval, installs and wires them into the `infra` and `planner` agents. Discovers where plan documents actually live in the repo and, after explicit user confirmation, wires the `planner`, `implement`, and `docs` agents/skills to that location.
|
|
131
|
-
**Pipeline:** MCP discovery → user approval → install + wire agents → plans-location discovery → user confirmation → rewrite plan-location references →
|
|
132
|
-
**Guardrails:** Never commits or pushes. Only edits agent/skill files and MCP config — never source code. Never installs a policy-blocked or unapproved server. Never changes the plans location without explicit user confirmation. Idempotent.
|
|
130
|
+
**Purpose:** One-time environment reconciliation. First ensures the tool's instruction file (`CLAUDE.md`, `AGENTS.md`, or `.github/copilot-instructions.md`) references the shipped `MARCOS-AI-BOOTSTRAP.md` rules — appending a short `@MARCOS-AI-BOOTSTRAP.md` include (never overwriting existing content), or creating the file if it does not exist. Discovers applicable MCP servers (via the MCP Servers discovery → policy-check → install flow) and, with user approval, installs and wires them into the `infra` and `planner` agents. Discovers where plan documents actually live in the repo and, after explicit user confirmation, wires the `planner`, `implement`, and `docs` agents/skills to that location. Scans the repository's history (past merged PRs, branch names, commit subjects, and any CONTRIBUTING / PR-template / commit-lint / release-automation config) and, after user confirmation, customises the `pr` skill's convention profile to match. Then always prompts the user, via a dropdown, to choose the model for each tier/role — pre-selecting the currently configured model when it is available, or the closest available match when it is not — and rewrites the agent files.
|
|
131
|
+
**Pipeline:** rules-file include wiring → MCP discovery → user approval → install + wire agents → plans-location discovery → user confirmation → rewrite plan-location references → PR/commit-convention discovery → user confirmation → customise the `pr` skill → enumerate available models → user chooses model per tier/role (always) → rewrite agent files.
|
|
132
|
+
**Guardrails:** Never commits or pushes. Only edits agent/skill files, the tool's instruction entry-point, and MCP config — never source code. Appends to (never clobbers) an existing instruction file. Never installs a policy-blocked or unapproved server. Never changes the plans location or `pr` conventions without explicit user confirmation. Idempotent for include wiring, MCP wiring, and the plans location; model selection is always offered, but keeping the current choice leaves files unchanged.
|
|
133
|
+
|
|
134
|
+
### pr
|
|
135
|
+
**Purpose:** Open a pull request that follows THIS repository's contribution conventions — branch names, commit-message format, PR title, and PR body — defaulting to widely-used best practices (kebab-case typed branches, Conventional Commits) until the `initialize` skill customises the convention profile from the repo's own history. Prevents malformed PRs and, where release automation (e.g. release-please) is in use, the failure mode where a non-conventional commit lands on the default branch and the release is silently skipped.
|
|
136
|
+
**Pipeline:** resolve the default branch → branch check (never the default branch) → validate/repair the branch name and commit subjects against the active convention → push → derive and validate a conventional PR title and body → `gh pr create` → report the PR URL and any repo-specific merge/release guidance.
|
|
137
|
+
**Guardrails:** Never merges the PR — opening it is the final step; the user merges. Never pushes to or commits on the default branch. Force-pushes only to complete a reword/rebase the user explicitly approved. Never uses `--no-verify`.
|
|
133
138
|
|
|
134
139
|
---
|
|
135
140
|
|
package/src/bin/ai-bootstrap.js
CHANGED
|
@@ -13,14 +13,19 @@ Usage:
|
|
|
13
13
|
marcos-ai-bootstrap [--claude] [--codex] [--copilot] [--all] [options]
|
|
14
14
|
|
|
15
15
|
Tool flags (combine as many as you like):
|
|
16
|
-
--claude Claude Code agents (.claude/agents), skills (.claude/skills),
|
|
16
|
+
--claude Claude Code agents (.claude/agents), skills (.claude/skills),
|
|
17
|
+
CLAUDE.md (@MARCOS-AI-BOOTSTRAP.md include, appended if it exists)
|
|
17
18
|
--codex Codex agents (.codex/agents), skills (.agents/skills)
|
|
19
|
+
(Codex reads the always-written root AGENTS.md)
|
|
18
20
|
--copilot GitHub Copilot CLI agents (.github/agents), skills (.github/skills),
|
|
19
|
-
.github/copilot-instructions.md
|
|
21
|
+
.github/copilot-instructions.md (@../MARCOS-AI-BOOTSTRAP.md include)
|
|
20
22
|
--all All of the above
|
|
21
23
|
|
|
22
|
-
Always written
|
|
23
|
-
|
|
24
|
+
Always written (regardless of tool flags):
|
|
25
|
+
MARCOS-AI-BOOTSTRAP.md, HUMAN.md (the full tool-agnostic rules + human guide)
|
|
26
|
+
AGENTS.md universal entry-point wired with @MARCOS-AI-BOOTSTRAP.md
|
|
27
|
+
(created if absent; the include is appended to an existing
|
|
28
|
+
file without overwriting your content)
|
|
24
29
|
|
|
25
30
|
Options:
|
|
26
31
|
--dest <path> Target directory (default: current working directory)
|
|
@@ -90,24 +95,34 @@ function main() {
|
|
|
90
95
|
`${opts.dryRun ? "[dry-run] " : ""}Materialising ${toolLabels} into ${destRoot}\n`
|
|
91
96
|
);
|
|
92
97
|
|
|
93
|
-
const byStatus = {
|
|
98
|
+
const byStatus = {
|
|
99
|
+
created: [],
|
|
100
|
+
overwritten: [],
|
|
101
|
+
appended: [],
|
|
102
|
+
"already-wired": [],
|
|
103
|
+
"skipped-exists": [],
|
|
104
|
+
"missing-source": [],
|
|
105
|
+
};
|
|
94
106
|
for (const r of results) {
|
|
95
107
|
(byStatus[r.status] || (byStatus[r.status] = [])).push(r.relPath);
|
|
96
108
|
}
|
|
97
109
|
|
|
98
110
|
for (const r of byStatus.created) console.log(` created ${r}`);
|
|
99
111
|
for (const r of byStatus.overwritten) console.log(` overwritten ${r}`);
|
|
112
|
+
for (const r of byStatus.appended) console.log(` appended ${r} (@MARCOS-AI-BOOTSTRAP.md include added)`);
|
|
113
|
+
for (const r of byStatus["already-wired"]) console.log(` ok ${r} (already references MARCOS-AI-BOOTSTRAP.md)`);
|
|
100
114
|
for (const r of byStatus["skipped-exists"]) console.log(` skipped ${r} (already exists, use --force to overwrite)`);
|
|
101
115
|
for (const r of byStatus["missing-source"]) console.log(` MISSING ${r} (not bundled in this package)`);
|
|
102
116
|
|
|
103
117
|
console.log(
|
|
104
118
|
`\n${byStatus.created.length} created, ${byStatus.overwritten.length} overwritten, ` +
|
|
105
|
-
`${byStatus["skipped-exists"].length} skipped,
|
|
119
|
+
`${byStatus.appended.length} appended, ${byStatus["skipped-exists"].length} skipped, ` +
|
|
120
|
+
`${results.length} total.`
|
|
106
121
|
);
|
|
107
122
|
|
|
108
123
|
if (!opts.dryRun) {
|
|
109
124
|
console.log(
|
|
110
|
-
`\nDone. Open
|
|
125
|
+
`\nDone. Open MARCOS-AI-BOOTSTRAP.md / HUMAN.md, then start your AI tool in ${destRoot} to begin.`
|
|
111
126
|
);
|
|
112
127
|
}
|
|
113
128
|
}
|
package/src/lib/materialize.js
CHANGED
|
@@ -7,18 +7,21 @@ const PACKAGE_ROOT = path.resolve(__dirname, "..", "..");
|
|
|
7
7
|
|
|
8
8
|
// Everything the CLI materialises into a target repo ships from a single
|
|
9
9
|
// source-of-truth directory: src/. The destination path is the source path with
|
|
10
|
-
// the leading "src/" stripped (e.g. src/
|
|
11
|
-
// agents/foo -> .github/agents/foo). This
|
|
12
|
-
//
|
|
13
|
-
//
|
|
10
|
+
// the leading "src/" stripped (e.g. src/MARCOS-AI-BOOTSTRAP.md ->
|
|
11
|
+
// MARCOS-AI-BOOTSTRAP.md, src/.github/agents/foo -> .github/agents/foo). This
|
|
12
|
+
// repo's own root-level self-hosting copies are generated from these src/
|
|
13
|
+
// sources and are not themselves published to npm.
|
|
14
14
|
const SRC_DIR = "src";
|
|
15
15
|
|
|
16
16
|
const toPosix = (p) => p.split(path.sep).join("/");
|
|
17
17
|
|
|
18
18
|
// Canonical, shipped source-of-truth core files. Each entry maps the
|
|
19
|
-
// package-relative source (under src/) to the target-relative destination.
|
|
19
|
+
// package-relative source (under src/) to the target-relative destination. The
|
|
20
|
+
// full agent rules ship as MARCOS-AI-BOOTSTRAP.md so they never collide with a
|
|
21
|
+
// user's own AGENTS.md / CLAUDE.md; the tool entry-points below only *reference*
|
|
22
|
+
// this file via an appended @-include.
|
|
20
23
|
const CORE_FILES = [
|
|
21
|
-
{ src: "src/
|
|
24
|
+
{ src: "src/MARCOS-AI-BOOTSTRAP.md", dest: "MARCOS-AI-BOOTSTRAP.md" },
|
|
22
25
|
{ src: "src/HUMAN.md", dest: "HUMAN.md" },
|
|
23
26
|
{
|
|
24
27
|
src: "src/documents/templates/plan-template.md",
|
|
@@ -26,30 +29,51 @@ const CORE_FILES = [
|
|
|
26
29
|
},
|
|
27
30
|
];
|
|
28
31
|
|
|
32
|
+
// The short block appended to a tool's instruction file. `ref` is the tool-
|
|
33
|
+
// correct @-include path to MARCOS-AI-BOOTSTRAP.md (relative to the entry file).
|
|
34
|
+
function includeBlock(ref) {
|
|
35
|
+
return (
|
|
36
|
+
"# Marcos AI-Bootstrap\n\n" +
|
|
37
|
+
"This repository uses the Marcos AI-Bootstrap agent/skill network. See " +
|
|
38
|
+
ref +
|
|
39
|
+
" for the agent rules, the MCP server flow, and the canonical agent/skill roles.\n"
|
|
40
|
+
);
|
|
41
|
+
}
|
|
42
|
+
|
|
43
|
+
// Marker used to detect an already-wired instruction file (idempotency).
|
|
44
|
+
const INCLUDE_MARKER = "MARCOS-AI-BOOTSTRAP.md";
|
|
45
|
+
|
|
46
|
+
// AGENTS.md is the broadest cross-tool convention (read by Codex, the Copilot
|
|
47
|
+
// coding agent, Cursor, Aider, and a growing set of others). It is therefore
|
|
48
|
+
// wired on every invocation, regardless of which tool flags were passed, as a
|
|
49
|
+
// thin @-include of the shipped rules. Tool-native entry-points (CLAUDE.md,
|
|
50
|
+
// .github/copilot-instructions.md) are still written alongside it. Codex reads
|
|
51
|
+
// this same file, so it no longer needs a separate tool-specific entry.
|
|
52
|
+
const CORE_ENTRY = { file: "AGENTS.md", include: "@MARCOS-AI-BOOTSTRAP.md" };
|
|
53
|
+
|
|
29
54
|
const TOOLS = {
|
|
30
55
|
claude: {
|
|
31
56
|
label: "Claude Code",
|
|
32
57
|
dirs: [".claude/agents", ".claude/skills"],
|
|
33
|
-
|
|
34
|
-
|
|
35
|
-
content: "@AGENTS.md\n",
|
|
36
|
-
},
|
|
58
|
+
// Claude reads CLAUDE.md; @-imports resolve relative to it (repo root).
|
|
59
|
+
entry: { file: "CLAUDE.md", include: "@MARCOS-AI-BOOTSTRAP.md" },
|
|
37
60
|
},
|
|
38
61
|
codex: {
|
|
39
62
|
label: "Codex",
|
|
40
63
|
dirs: [".codex/agents", ".agents/skills"],
|
|
41
|
-
// Codex loads AGENTS.md directly from the workspace root
|
|
42
|
-
//
|
|
64
|
+
// Codex loads AGENTS.md directly from the workspace root, which is now
|
|
65
|
+
// always written as the universal CORE_ENTRY, so no tool-specific entry is
|
|
66
|
+
// needed here.
|
|
67
|
+
entry: null,
|
|
43
68
|
},
|
|
44
69
|
copilot: {
|
|
45
70
|
label: "GitHub Copilot CLI",
|
|
46
71
|
dirs: [".github/agents", ".github/skills"],
|
|
72
|
+
// Copilot reads .github/copilot-instructions.md; the rules file sits one
|
|
73
|
+
// directory up at the repo root.
|
|
47
74
|
entry: {
|
|
48
75
|
file: path.join(".github", "copilot-instructions.md"),
|
|
49
|
-
|
|
50
|
-
"# Copilot instructions\n\n" +
|
|
51
|
-
"See [AGENTS.md](../AGENTS.md) for the agent rules and the agent/skill " +
|
|
52
|
-
"network that has been materialised into this repository.\n",
|
|
76
|
+
include: "@../MARCOS-AI-BOOTSTRAP.md",
|
|
53
77
|
},
|
|
54
78
|
},
|
|
55
79
|
};
|
|
@@ -73,7 +97,7 @@ function listFiles(dir) {
|
|
|
73
97
|
|
|
74
98
|
/**
|
|
75
99
|
* Copy a single file from the package root to the destination root. The source
|
|
76
|
-
* and destination relative paths may differ (e.g. src/
|
|
100
|
+
* and destination relative paths may differ (e.g. src/MARCOS-AI-BOOTSTRAP.md -> MARCOS-AI-BOOTSTRAP.md).
|
|
77
101
|
* Returns a status object keyed by the destination path.
|
|
78
102
|
*/
|
|
79
103
|
function copyOne(srcRel, destRel, destRoot, { force, dryRun }) {
|
|
@@ -97,20 +121,33 @@ function copyOne(srcRel, destRel, destRoot, { force, dryRun }) {
|
|
|
97
121
|
}
|
|
98
122
|
|
|
99
123
|
/**
|
|
100
|
-
*
|
|
101
|
-
* .github/copilot-instructions.md)
|
|
124
|
+
* Wire a tool's instruction entry-point (e.g. CLAUDE.md,
|
|
125
|
+
* .github/copilot-instructions.md, AGENTS.md) to the shipped
|
|
126
|
+
* MARCOS-AI-BOOTSTRAP.md rules. Never overwrites existing user content: if the
|
|
127
|
+
* file already references the rules file it is left untouched; otherwise the
|
|
128
|
+
* include block is appended. The file is created with just the block if absent.
|
|
102
129
|
*/
|
|
103
|
-
function
|
|
130
|
+
function appendEntry(entry, destRoot, { dryRun }) {
|
|
104
131
|
const dest = path.join(destRoot, entry.file);
|
|
105
|
-
const
|
|
106
|
-
|
|
107
|
-
|
|
132
|
+
const block = includeBlock(entry.include);
|
|
133
|
+
|
|
134
|
+
if (fs.existsSync(dest)) {
|
|
135
|
+
const current = fs.readFileSync(dest, "utf8");
|
|
136
|
+
if (current.includes(INCLUDE_MARKER)) {
|
|
137
|
+
return { relPath: entry.file, status: "already-wired" };
|
|
138
|
+
}
|
|
139
|
+
if (!dryRun) {
|
|
140
|
+
const sep = current.length === 0 || current.endsWith("\n") ? "\n" : "\n\n";
|
|
141
|
+
fs.appendFileSync(dest, sep + block);
|
|
142
|
+
}
|
|
143
|
+
return { relPath: entry.file, status: "appended" };
|
|
108
144
|
}
|
|
145
|
+
|
|
109
146
|
if (!dryRun) {
|
|
110
147
|
fs.mkdirSync(path.dirname(dest), { recursive: true });
|
|
111
|
-
fs.writeFileSync(dest,
|
|
148
|
+
fs.writeFileSync(dest, block, "utf8");
|
|
112
149
|
}
|
|
113
|
-
return { relPath: entry.file, status:
|
|
150
|
+
return { relPath: entry.file, status: "created" };
|
|
114
151
|
}
|
|
115
152
|
|
|
116
153
|
/**
|
|
@@ -132,6 +169,9 @@ function materialize(tools, opts = {}) {
|
|
|
132
169
|
results.push(copyOne(cf.src, cf.dest, destRoot, { force, dryRun }));
|
|
133
170
|
}
|
|
134
171
|
|
|
172
|
+
// AGENTS.md is wired on every invocation as the universal entry-point.
|
|
173
|
+
results.push(appendEntry(CORE_ENTRY, destRoot, { dryRun }));
|
|
174
|
+
|
|
135
175
|
for (const toolName of tools) {
|
|
136
176
|
const tool = TOOLS[toolName];
|
|
137
177
|
if (!tool) continue;
|
|
@@ -147,11 +187,11 @@ function materialize(tools, opts = {}) {
|
|
|
147
187
|
}
|
|
148
188
|
}
|
|
149
189
|
if (tool.entry) {
|
|
150
|
-
results.push(
|
|
190
|
+
results.push(appendEntry(tool.entry, destRoot, { dryRun }));
|
|
151
191
|
}
|
|
152
192
|
}
|
|
153
193
|
|
|
154
194
|
return { results, tools, destRoot };
|
|
155
195
|
}
|
|
156
196
|
|
|
157
|
-
module.exports = { materialize, TOOLS, CORE_FILES, PACKAGE_ROOT };
|
|
197
|
+
module.exports = { materialize, TOOLS, CORE_FILES, CORE_ENTRY, PACKAGE_ROOT };
|