@phuc1403/musketeer 0.8.0 → 0.10.0

package/template/.claude/skills/context-map/reference/Semantic Rules.md

@@ -1,33 +1,33 @@
-The following semantic rules are either implicitly given by the domain model on which the language is based (see above), or enforced by corresponding semantic checkers.
-
-Note that the model and the semantic rules express how we understand the DDD patterns and how they can be combined, and how we applied DDD on projects ourselves. Rationale: the literature is somewhat ambiguous.
-
-# 1: Permitted Upstream Roles
-The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
-
-# 2: Permitted Downstream Roles
-The patterns ACL and CF can only be applied by the downstream context in an upstream-downstream relationship. These patterns solve a downstream problem, namely how to deal with a dependency to another context. It is always the downstream context that has to integrate the upstream model.
-
-# 3: Protect or Conform
-The patterns ACL and CF cannot be applied jointly, but provide alternatives. The downstream either conforms (CF) or protects itself with an ACL.
-
-# 4: Integrity of Symmetric Relationships
-The patterns OHS, PL, ACL and CF are not applicable in symmetric relationships (Partnership and Shared Kernel), since doing so would lead to contradictions with the pattern definitions. In a Shared Kernel relationship, the two contexts communicate over shared code such as a library. Both contexts manage the shared code together, which clearly contradicts with the mentioned four pattern definitions. An OHS indicates a directed provider/consumer behavior which is not the case here. There is no need for a common inter-context language (PL), since the two contexts simply share the same model. An ACL is not required either since the two participants share the model anyway. And neither context has to conform to the model of the other since it is one shared model. In a Partnership relationship both contexts depend on each other, which means they can only succeed or fail together.
-
-# 5: Customer vs. Conformist
-The CF pattern is not applicable within a customer-supplier relationship. In a customer-supplier relationship the customer has influence on the supplier and can at least negotiate regarding priorities of the requirements and the implementation. A conformist in contrast has no influence and simply decides to conform to what the upstream provides.
-
-# 6: Generic vs. Custom Service
-The OHS pattern is not applicable within a customer-supplier relationship. Whereas the customer-supplier pattern implies that the involved teams work closely together, meaning that the upstream respects the downstreams requirements in his planning sessions, the OHS pattern indicates that the upstream team decides to implement one API in a one for all approach. This is contradictory since it is unlikely that such an upstream implementing an OHS is able to have a close customer-supplier relationship with all its downstreams. From personal practical experience a customer-supplier relationship leads to individual requirements of single customers. As soon as the supplier implements a customer-specific API feature it is by pattern definition no longer an OHS.
-
-# 7: Protect or Cooperate
-The ACL pattern should not be used within a customer-supplier relationship. Changes of the supplier should be in-sync with the needs of the customer. Protection should be unnecessary. Note that this is only a soft rule since the combination is possible but not common. Our tool issues a warning rather than an error message if it detects a violation of the rule.
-
-# 8: ORGANIZATIONAL Context Maps
-A context map of the type ORGANIZATIONAL (team map), can only contain bounded contexts of the type TEAM. This checker provides consistency within team maps. On such a map a bounded context represents a team and not a classical bounded context such as a system, feature or application.
-
-# 9: SYSTEM LANDSCAPES
-A bounded context of the type TEAM can not be contained by a context map of the type SYSTEM_LANDSCAPE. This checker provides consistency within context maps. Can be seen as the inverse case of rule #8.
-
-# 10: Teams realize Bounded Contexts
+The following semantic rules are either implicitly given by the domain model on which the language is based (see above), or enforced by corresponding semantic checkers.
+
+Note that the model and the semantic rules express how we understand the DDD patterns and how they can be combined, and how we applied DDD on projects ourselves. Rationale: the literature is somewhat ambiguous.
+
+# 1: Permitted Upstream Roles
+The patterns OHS and PL can only be implemented by the upstream context in an upstream-downstream relationship. The upstream context always provides and exposes a certain functionality. The downstream context uses and consumes this services and does not expose parts of his/her own domain model. If this was the case and the upstream used this functionality, the definition that the upstream is independent of the downstream would be contradicted.
+
+# 2: Permitted Downstream Roles
+The patterns ACL and CF can only be applied by the downstream context in an upstream-downstream relationship. These patterns solve a downstream problem, namely how to deal with a dependency to another context. It is always the downstream context that has to integrate the upstream model.
+
+# 3: Protect or Conform
+The patterns ACL and CF cannot be applied jointly, but provide alternatives. The downstream either conforms (CF) or protects itself with an ACL.
+
+# 4: Integrity of Symmetric Relationships
+The patterns OHS, PL, ACL and CF are not applicable in symmetric relationships (Partnership and Shared Kernel), since doing so would lead to contradictions with the pattern definitions. In a Shared Kernel relationship, the two contexts communicate over shared code such as a library. Both contexts manage the shared code together, which clearly contradicts with the mentioned four pattern definitions. An OHS indicates a directed provider/consumer behavior which is not the case here. There is no need for a common inter-context language (PL), since the two contexts simply share the same model. An ACL is not required either since the two participants share the model anyway. And neither context has to conform to the model of the other since it is one shared model. In a Partnership relationship both contexts depend on each other, which means they can only succeed or fail together.
+
+# 5: Customer vs. Conformist
+The CF pattern is not applicable within a customer-supplier relationship. In a customer-supplier relationship the customer has influence on the supplier and can at least negotiate regarding priorities of the requirements and the implementation. A conformist in contrast has no influence and simply decides to conform to what the upstream provides.
+
+# 6: Generic vs. Custom Service
+The OHS pattern is not applicable within a customer-supplier relationship. Whereas the customer-supplier pattern implies that the involved teams work closely together, meaning that the upstream respects the downstreams requirements in his planning sessions, the OHS pattern indicates that the upstream team decides to implement one API in a one for all approach. This is contradictory since it is unlikely that such an upstream implementing an OHS is able to have a close customer-supplier relationship with all its downstreams. From personal practical experience a customer-supplier relationship leads to individual requirements of single customers. As soon as the supplier implements a customer-specific API feature it is by pattern definition no longer an OHS.
+
+# 7: Protect or Cooperate
+The ACL pattern should not be used within a customer-supplier relationship. Changes of the supplier should be in-sync with the needs of the customer. Protection should be unnecessary. Note that this is only a soft rule since the combination is possible but not common. Our tool issues a warning rather than an error message if it detects a violation of the rule.
+
+# 8: ORGANIZATIONAL Context Maps
+A context map of the type ORGANIZATIONAL (team map), can only contain bounded contexts of the type TEAM. This checker provides consistency within team maps. On such a map a bounded context represents a team and not a classical bounded context such as a system, feature or application.
+
+# 9: SYSTEM LANDSCAPES
+A bounded context of the type TEAM can not be contained by a context map of the type SYSTEM_LANDSCAPE. This checker provides consistency within context maps. Can be seen as the inverse case of rule #8.
+
+# 10: Teams realize Bounded Contexts
 Only teams can realize bounded contexts. This checker ensures that the realize keyword can only be used for bounded contexts of the type TEAM. The keyword is added to the language definition in order to reference the bounded contexts a team is realizing. It would not make sense for a classical bounded context (system, feature or application).

package/template/.claude/skills/git/SKILL.md

@@ -1,115 +1,131 @@
----
-name: ck:git
-description: "Git operations with conventional commits. Use for staging, committing, pushing, PRs, merges. Auto-splits commits by type/scope. Security scans for secrets."
-argument-hint: "cm|cp|pr|merge [args]"
-metadata:
-  author: claudekit
-  version: "1.0.0"
----
-
-# Git Operations
-
-## Default (No Arguments)
-
-If invoked without arguments, use `AskUserQuestion` to present available git operations:
-
-| Operation | Description |
-|-----------|-------------|
-| `cm` | Stage files & create commits |
-| `cp` | Stage files, create commits and push |
-| `pr` | Create Pull Request |
-| `merge` | Merge branches |
-
-Present as options via `AskUserQuestion` with header "Git Operation", question "What would you like to do?".
-
-Execute git workflows via `git-manager` subagent to isolate verbose output.
-
-**IMPORTANT:**
-- Sacrifice grammar for the sake of concision.
-- Ensure token efficiency while maintaining high quality.
-- Pass these rules to subagents.
-
-## Arguments
-- `cm`: Stage files & create commits
-- `cp`: Stage files, create commits and push
-- `pr`: Create Pull Request [to-branch] [from-branch]
-  - `to-branch`: Target branch (default: main)
-  - `from-branch`: Source branch (default: current branch)
-- `merge`: Merge [to-branch] [from-branch]
-  - `to-branch`: Target branch (default: main)
-  - `from-branch`: Source branch (default: current branch)
-
-## Quick Reference
-
-| Task | Reference |
-|------|-----------|
-| Commit | `references/workflow-commit.md` |
-| Push | `references/workflow-push.md` |
-| Pull Request | `references/workflow-pr.md` |
-| Merge | `references/workflow-merge.md` |
-| Standards | `references/commit-standards.md` |
-| Safety | `references/safety-protocols.md` |
-| Branches | `references/branch-management.md` |
-| GitHub CLI | `references/gh-cli-guide.md` |
-
-## Core Workflow
-
-### Step 1: Stage + Analyze
-```bash
-git add -A && git diff --cached --stat && git diff --cached --name-only
-```
-
-### Step 2: Security Check
-Scan for secrets before commit:
-```bash
-git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
-```
-**If secrets found:** STOP, warn user, suggest `.gitignore`.
-
-### Step 3: Split Decision
-
-**NOTE:**
-- Search for related issues on GitHub and add to body.
-- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
-
-**Split commits if:**
-- Different types mixed (feat + fix, code + docs)
-- Multiple scopes (auth + payments)
-- Config/deps + code mixed
-- FILES > 10 unrelated
-
-**Single commit if:**
-- Same type/scope, FILES ≤ 3, LINES ≤ 50
-
-### Step 4: Commit
-```bash
-git commit -m "type(scope): description"
-```
-
-## Output Format
-```
-✓ staged: N files (+X/-Y lines)
-✓ security: passed
-✓ commit: HASH type(scope): description
-✓ pushed: yes/no
-```
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| Secrets detected | Block commit, show files |
-| No changes | Exit cleanly |
-| Push rejected | Suggest `git pull --rebase` |
-| Merge conflicts | Suggest manual resolution |
-
-## References
-
-- `references/workflow-commit.md` - Commit workflow with split logic
-- `references/workflow-push.md` - Push workflow with error handling
-- `references/workflow-pr.md` - PR creation with remote diff analysis
-- `references/workflow-merge.md` - Branch merge workflow
-- `references/commit-standards.md` - Conventional commit format rules
-- `references/safety-protocols.md` - Secret detection, branch protection
-- `references/branch-management.md` - Naming, lifecycle, strategies
-- `references/gh-cli-guide.md` - GitHub CLI commands reference
+---
+name: ck:git
+description: "Manage git commits, pushes, PRs, branch merges, and PR review-and-merge automation. Use for commit, push, PR creation, PR merge, CI follow-up, and secret scanning."
+user-invocable: true
+when_to_use: "Invoke for commits, PRs, branch hygiene, or release git steps."
+category: dev-tools
+keywords: [git, commits, staging, PR, merge, merge-pr, ci]
+argument-hint: "cm|cp|pr|merge|merge-pr [args]"
+metadata:
+  author: claudekit
+  version: "1.0.0"
+---
+
+# Git Operations
+
+## Default (No Arguments)
+
+If invoked without arguments, use `AskUserQuestion` to present available git operations:
+
+| Operation | Description |
+|-----------|-------------|
+| `cm` | Stage files & create commits |
+| `cp` | Stage files, create commits and push |
+| `pr` | Create Pull Request |
+| `merge` | Merge branches |
+| `merge-pr` | Review, label, merge PRs, then watch/fix CI |
+
+Present as options via `AskUserQuestion` with header "Git Operation", question "What would you like to do?".
+
+Execute git workflows via `git-manager` subagent to isolate verbose output.
+Keep verbose git/gh output out of the main context: `references/context-efficiency.md`.
+
+**IMPORTANT:**
+- Sacrifice grammar for the sake of concision.
+- Ensure token efficiency while maintaining high quality.
+- Pass these rules to subagents.
+
+## Arguments
+- `cm`: Stage files & create commits
+- `cp`: Stage files, create commits and push
+- `pr`: Create Pull Request [to-branch] [from-branch]
+  - `to-branch`: Target branch (default: main)
+  - `from-branch`: Source branch (default: current branch)
+- `merge`: Merge [to-branch] [from-branch]
+  - `to-branch`: Target branch (default: main)
+  - `from-branch`: Source branch (default: current branch)
+- `merge-pr`: Review, label, merge, and post-merge verify PRs
+  - Usage: `/ck:git merge-pr <PR numbers or URLs>`
+  - Accepts one or more PR numbers or GitHub PR URLs
+  - Runs `/code-review <PR>` before any label or merge (findings only — no auto-fix, no GitHub replies)
+  - Adds label `ready to ship` only once the review is clean and checks are green
+  - Merges only reviewed-and-ready PRs, then watches target-branch CI to success
+
+## Quick Reference
+
+| Task | Reference |
+|------|-----------|
+| Commit | `references/workflow-commit.md` |
+| Push | `references/workflow-push.md` |
+| Pull Request | `references/workflow-pr.md` |
+| Merge | `references/workflow-merge.md` |
+| Merge PRs | `references/workflow-merge-pr.md` |
+| Standards | `references/commit-standards.md` |
+| Safety | `references/safety-protocols.md` |
+| Branches | `references/branch-management.md` |
+| GitHub CLI | `references/gh-cli-guide.md` |
+| Context efficiency | `references/context-efficiency.md` |
+
+## Core Workflow
+
+### Step 1: Stage + Analyze
+```bash
+git add -A && git diff --cached --stat && git diff --cached --name-only
+```
+
+### Step 2: Security Check
+Scan for secrets before commit:
+```bash
+git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
+```
+**If secrets found:** STOP, warn user, suggest `.gitignore`.
+
+### Step 3: Split Decision
+
+**NOTE:**
+- Search for related issues on GitHub and add to body.
+- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
+
+**Split commits if:**
+- Different types mixed (feat + fix, code + docs)
+- Multiple scopes (auth + payments)
+- Config/deps + code mixed
+- FILES > 10 unrelated
+
+**Single commit if:**
+- Same type/scope, FILES ≤ 3, LINES ≤ 50
+
+### Step 4: Commit
+```bash
+git commit -m "type(scope): description"
+```
+
+## Output Format
+```
+✓ staged: N files (+X/-Y lines)
+✓ security: passed
+✓ commit: HASH type(scope): description
+✓ pushed: yes/no
+```
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Secrets detected | Block commit, show files |
+| No changes | Exit cleanly |
+| Push rejected | Suggest `git pull --rebase` |
+| Merge conflicts | Suggest manual resolution |
+
+## References
+
+- `references/workflow-commit.md` - Commit workflow with split logic
+- `references/workflow-push.md` - Push workflow with error handling
+- `references/workflow-pr.md` - PR creation with remote diff analysis
+- `references/workflow-merge.md` - Branch merge workflow
+- `references/workflow-merge-pr.md` - PR review, ready label, merge, and CI convergence workflow
+- `references/commit-standards.md` - Conventional commit format rules
+- `references/safety-protocols.md` - Secret detection, branch protection
+- `references/branch-management.md` - Naming, lifecycle, strategies
+- `references/gh-cli-guide.md` - GitHub CLI commands reference
+- `references/context-efficiency.md` - Keeping verbose git/gh output out of context

package/template/.claude/skills/git/references/branch-management.md

@@ -1,88 +1,88 @@
-# Branch Management
-
-## Naming Convention
-
-**Format:** `<type>/<descriptive-name>`
-
-| Type | Purpose | Example |
-|------|---------|---------|
-| `feature/` | New features | `feature/oauth-login` |
-| `fix/` | Bug fixes | `fix/db-timeout` |
-| `refactor/` | Code restructure | `refactor/api-cleanup` |
-| `docs/` | Documentation | `docs/api-reference` |
-| `test/` | Test improvements | `test/integration-suite` |
-| `chore/` | Maintenance | `chore/deps-update` |
-| `hotfix/` | Production fixes | `hotfix/payment-crash` |
-
-## Branch Lifecycle
-
-### Create
-```bash
-git checkout main
-git pull origin main
-git checkout -b feature/new-feature
-```
-
-### During Development
-```bash
-# Regular commits
-git add <files> && git commit -m "feat(scope): description"
-
-# Stay current with main
-git fetch origin
-git rebase origin/main
-```
-
-### Before Merge
-```bash
-# Push final state
-git push origin feature/new-feature
-
-# Or after rebase (feature branches only)
-git push -f origin feature/new-feature
-```
-
-### After Merge
-```bash
-# Delete local
-git branch -d feature/new-feature
-
-# Delete remote
-git push origin --delete feature/new-feature
-```
-
-## Branch Strategies
-
-### Simple (small teams)
-```
-main (production)
-  └─ feature/* (development)
-```
-
-### Git Flow (releases)
-```
-main (production)
-develop (staging)
-  ├─ feature/*
-  ├─ bugfix/*
-  ├─ hotfix/*
-  └─ release/*
-```
-
-### Trunk-Based (CI/CD)
-```
-main (always deployable)
-  └─ short-lived feature branches
-```
-
-## Quick Commands
-
-| Task | Command |
-|------|---------|
-| List branches | `git branch -a` |
-| Current branch | `git rev-parse --abbrev-ref HEAD` |
-| Switch branch | `git checkout <branch>` |
-| Create + switch | `git checkout -b <branch>` |
-| Delete local | `git branch -d <branch>` |
-| Delete remote | `git push origin --delete <branch>` |
-| Rename | `git branch -m <old> <new>` |
+# Branch Management
+
+## Naming Convention
+
+**Format:** `<type>/<descriptive-name>`
+
+| Type | Purpose | Example |
+|------|---------|---------|
+| `feature/` | New features | `feature/oauth-login` |
+| `fix/` | Bug fixes | `fix/db-timeout` |
+| `refactor/` | Code restructure | `refactor/api-cleanup` |
+| `docs/` | Documentation | `docs/api-reference` |
+| `test/` | Test improvements | `test/integration-suite` |
+| `chore/` | Maintenance | `chore/deps-update` |
+| `hotfix/` | Production fixes | `hotfix/payment-crash` |
+
+## Branch Lifecycle
+
+### Create
+```bash
+git checkout main
+git pull origin main
+git checkout -b feature/new-feature
+```
+
+### During Development
+```bash
+# Regular commits
+git add <files> && git commit -m "feat(scope): description"
+
+# Stay current with main
+git fetch origin
+git rebase origin/main
+```
+
+### Before Merge
+```bash
+# Push final state
+git push origin feature/new-feature
+
+# Or after rebase (feature branches only)
+git push -f origin feature/new-feature
+```
+
+### After Merge
+```bash
+# Delete local
+git branch -d feature/new-feature
+
+# Delete remote
+git push origin --delete feature/new-feature
+```
+
+## Branch Strategies
+
+### Simple (small teams)
+```
+main (production)
+  └─ feature/* (development)
+```
+
+### Git Flow (releases)
+```
+main (production)
+develop (staging)
+  ├─ feature/*
+  ├─ bugfix/*
+  ├─ hotfix/*
+  └─ release/*
+```
+
+### Trunk-Based (CI/CD)
+```
+main (always deployable)
+  └─ short-lived feature branches
+```
+
+## Quick Commands
+
+| Task | Command |
+|------|---------|
+| List branches | `git branch -a` |
+| Current branch | `git rev-parse --abbrev-ref HEAD` |
+| Switch branch | `git checkout <branch>` |
+| Create + switch | `git checkout -b <branch>` |
+| Delete local | `git branch -d <branch>` |
+| Delete remote | `git push origin --delete <branch>` |
+| Rename | `git branch -m <old> <new>` |

package/template/.claude/skills/git/references/commit-standards.md

@@ -1,46 +1,46 @@
-# Commit Message Standards
-
-## Format
-```
-type(scope): description
-```
-
-## Types (priority order)
-- `feat`: New feature
-- `fix`: Bug fix
-- `docs`: Documentation only
-- `style`: Formatting (no logic change)
-- `refactor`: Restructure without behavior change
-- `test`: Tests
-- `chore`: Maintenance, deps, config
-- `perf`: Performance
-- `build`: Build system
-- `ci`: CI/CD
-
-## Rules
-- **<72 characters**
-- **Present tense, imperative** ("add" not "added")
-- **No period at end**
-- **Scope optional but recommended**
-- **Focus on WHAT, not HOW**
-- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
-
-## NEVER Include AI Attribution
-- ❌ "Generated with Claude"
-- ❌ "Co-Authored-By: Claude"
-- ❌ Any AI reference
-
-## Good Examples
-- `feat(auth): add login validation`
-- `fix(api): resolve query timeout`
-- `docs(readme): update install guide`
-- `refactor(utils): simplify date logic`
-
-## Bad Examples
-- ❌ `Updated files` (not descriptive)
-- ❌ `feat(auth): added login using bcrypt with salt` (too long, describes HOW)
-- ❌ `Fix bug` (not specific)
-
-## Special Cases
-- `.claude/` skill updates: `perf(skill): improve token efficiency`
-- `.claude/` new skills: `feat(skill): add database-optimizer`
+# Commit Message Standards
+
+## Format
+```
+type(scope): description
+```
+
+## Types (priority order)
+- `feat`: New feature
+- `fix`: Bug fix
+- `docs`: Documentation only
+- `style`: Formatting (no logic change)
+- `refactor`: Restructure without behavior change
+- `test`: Tests
+- `chore`: Maintenance, deps, config
+- `perf`: Performance
+- `build`: Build system
+- `ci`: CI/CD
+
+## Rules
+- **<72 characters**
+- **Present tense, imperative** ("add" not "added")
+- **No period at end**
+- **Scope optional but recommended**
+- **Focus on WHAT, not HOW**
+- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
+
+## NEVER Include AI Attribution
+- ❌ "Generated with Claude"
+- ❌ "Co-Authored-By: Claude"
+- ❌ Any AI reference
+
+## Good Examples
+- `feat(auth): add login validation`
+- `fix(api): resolve query timeout`
+- `docs(readme): update install guide`
+- `refactor(utils): simplify date logic`
+
+## Bad Examples
+- ❌ `Updated files` (not descriptive)
+- ❌ `feat(auth): added login using bcrypt with salt` (too long, describes HOW)
+- ❌ `Fix bug` (not specific)
+
+## Special Cases
+- `.claude/` skill updates: `perf(skill): improve token efficiency`
+- `.claude/` new skills: `feat(skill): add database-optimizer`

package/template/.claude/skills/git/references/context-efficiency.md

@@ -0,0 +1,54 @@
+# Context Efficiency for Git Workflows
+
+Git and `gh` emit some of the largest output in any workflow: full diffs, log
+walls, PR bodies, CI job logs. Left unfiltered they crowd out the reasoning that
+actually decides the commit or merge. Keep the main context small and high-signal.
+
+## Isolate
+
+Run verbose git/gh work in the `git-manager` subagent and return only what the
+decision needs — the file list, the verdict, the failing line. Never return a raw
+diff, a full `git log`, or a complete CI log to the main context.
+
+For a batch (several PRs), handle one PR per subagent pass so one noisy PR cannot
+crowd out the rest.
+
+## Select before you read
+
+Ask the command for the narrow answer instead of filtering a wide one afterwards:
+
+```bash
+git log --oneline -10              # not: git log
+git diff --name-only               # not: git diff, when you only need the files
+git diff --stat                    # size of change without the body
+gh pr view 123 --json title,mergeStateStatus,statusCheckRollup
+gh run view "$RUN_ID" --log-failed  # not: --log, which returns every job
+```
+
+`gh` has a built-in jq engine — `--json <fields> --jq '<filter>'` — so field
+selection needs no external tool.
+
+## Compress what you must keep
+
+When output has to survive into the main context, summarize it: the failing test
+name and assertion, not the whole runner output; the conflicting paths, not the
+conflict bodies. Cite `file:line` and drop the surrounding text.
+
+## Position what matters
+
+Put the decision-relevant facts at the start or end of a subagent report, never
+buried in the middle — attention degrades in the middle of long context.
+
+## Budget
+
+Watch context utilization: **70% is a warning** to start compacting, **90% is
+critical** — stop expanding scope and summarize what you have. On a long merge
+batch, checkpoint progress (which PRs are merged, which remain) to a file rather
+than carrying the whole history forward.
+
+## Anti-patterns
+
+- Pasting a full diff or CI log into the main context "for reference"
+- Re-running a wide command because the narrow output was discarded
+- One subagent accumulating every PR in a batch
+- Reading a file the command could have filtered for you