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 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—`AGENTS.md`, `HUMAN.md` (the tool-agnostic rules + human guide), and
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. The Stage-2 planner agents
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
- | `--claude` | `.claude/agents/*.md`, `.claude/skills/**/SKILL.md`, `CLAUDE.md` (`@AGENTS.md` stub) |
34
- | `--codex` | `.codex/agents/*.toml`, `.agents/skills/**/SKILL.md` |
35
- | `--copilot` | `.github/agents/*.agent.md`, `.github/skills/**/SKILL.md`, `.github/copilot-instructions.md` |
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/AGENTS.md`, `src/HUMAN.md` — canonical agent network and human workflow rules.
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
- - `AGENTS.md`, `HUMAN.md` (repo root) — this repository's own self-hosted copies, used by the agent network running against this repo.
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 `AGENTS.md`. Not published to npm.
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` after editing. Run this after changing `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 --force --dest .` to regenerate this repo's root self-hosted copies from `src/`.
82
- 4. Run `node src/bin/ai-bootstrap.js --all --dry-run --dest <scratch-dir>` to sanity-check the CLI packages everything correctly.
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.4",
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/AGENTS.md",
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; then verifies every agent's configured model exists in Codex and, for any missing model, prompts the user to pick the closest available match and rewrites the agent files. Never commits.
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 three phases. This skill only edits agent and skill files and MCP config; it never touches source code and never commits.
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 `AGENTS.md` (Steps 1-4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
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 `model` value that is NOT in the available set:
23
- - Determine the closest available match - prefer another model in the same tier/family, else the next tier down, else the nearest capability.
24
- - Use a dropdown prompt (multiple choice) listing the available models, pre-selecting the closest match, and ask the user to confirm the replacement for that tier.
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, the plans location already matches, and every configured model is available.
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 `AGENTS.md` for the discovery and policy-check flow.
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 `AGENTS.md` for the discovery and policy-check flow.
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; then verifies every agent's configured model exists in Claude Code and, for any missing model, prompts the user to pick the closest available match and rewrites the agent files. Never commits.
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 three phases. This skill only edits agent and skill files and MCP config; it never touches source code and never commits.
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 `AGENTS.md` (Steps 1–4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
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 `model:` value that is NOT in the available set:
23
- - Determine the closest available match — prefer another model in the same tier/family, else the next tier down, else the nearest capability.
24
- - Use a dropdown prompt (multiple choice) listing the available models, pre-selecting the closest match, and ask the user to confirm the replacement for that tier.
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, the plans location already matches, and every configured model is available.
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 `AGENTS.md` for the discovery and policy-check flow.
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 `AGENTS.md` for the discovery and policy-check flow.
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 `AGENTS.md` for the discovery and policy-check flow.
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 `AGENTS.md` for the discovery and policy-check flow.
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; then verifies every agent's configured model exists in GitHub Copilot CLI and, for any missing model, prompts the user to pick the closest available match and rewrites the agent files. Never commits.
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 three phases. This skill only edits agent and skill files and MCP config; it never touches source code and never commits.
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 `AGENTS.md` (Steps 1–4). Inspect repo docs, IAC/config, and dependency manifests to infer the platform footprint and map it to candidate servers.
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 `model:` value that is NOT in the available set:
23
- - Determine the closest available match — prefer another model in the same tier/family, else the next tier down, else the nearest capability. For a missing role override (`gpt-5.4` on infra), offer the closest available GPT model first.
24
- - Use a dropdown prompt (multiple choice) listing the available models, pre-selecting the closest match, and ask the user to confirm the replacement for that tier or role.
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, the plans location already matches, and every configured model is available.
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 `AGENTS.md`, `HUMAN.md`, and the fully materialised agent/skill
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 `AGENTS.md`, `HUMAN.md`, and your tool's agent/skill files are present in the repo.
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. **`/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.
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. Drop it into any repository and reference it from your AI tool's config entry-point (e.g. `CLAUDE.md` via `@AGENTS.md`, `.github/copilot-instructions.md`, `.opencode/instructions.md`) to immediately apply these rules and bootstrap the agent network.
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. Then verifies every agent's configured model exists in the current tool and, for any missing model, prompts the user to pick the closest available match from a dropdown and rewrites the agent files.
131
- **Pipeline:** MCP discovery → user approval → install + wire agents → plans-location discovery → user confirmation → rewrite plan-location references → model availability check → user picks replacements → rewrite agent files.
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
 
@@ -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), CLAUDE.md
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 alongside any tool flag:
23
- AGENTS.md, HUMAN.md (tool-agnostic rules + human guide)
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 = { created: [], overwritten: [], "skipped-exists": [], "missing-source": [] };
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, ${results.length} total.`
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 AGENTS.md / HUMAN.md, then start your AI tool in ${destRoot} to begin.`
125
+ `\nDone. Open MARCOS-AI-BOOTSTRAP.md / HUMAN.md, then start your AI tool in ${destRoot} to begin.`
111
126
  );
112
127
  }
113
128
  }
@@ -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/AGENTS.md -> AGENTS.md, src/.github/
11
- // agents/foo -> .github/agents/foo). This repo's own root-level self-hosting
12
- // copies (AGENTS.md, .claude/, .github/agents, ...) are generated from these
13
- // src/ sources and are not themselves published to npm.
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/AGENTS.md", dest: "AGENTS.md" },
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
- entry: {
34
- file: "CLAUDE.md",
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; no separate
42
- // config entry-point file is required.
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
- content:
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/AGENTS.md -> AGENTS.md).
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
- * Write a small generated entry-point file (e.g. CLAUDE.md,
101
- * .github/copilot-instructions.md) rather than copying from the package.
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 writeEntry(entry, destRoot, { force, dryRun }) {
130
+ function appendEntry(entry, destRoot, { dryRun }) {
104
131
  const dest = path.join(destRoot, entry.file);
105
- const exists = fs.existsSync(dest);
106
- if (exists && !force) {
107
- return { relPath: entry.file, status: "skipped-exists" };
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, entry.content, "utf8");
148
+ fs.writeFileSync(dest, block, "utf8");
112
149
  }
113
- return { relPath: entry.file, status: exists ? "overwritten" : "created" };
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(writeEntry(tool.entry, destRoot, { force, dryRun }));
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 };