context-mode-ops

分类: 工具与效率 | 上传者: mksglu | 下载: 0 | 版本: v1.0（最新）

使用并行子代理军队管理上下文模式 GitHub 问题、PR、发布和营销。每个任务协调 10-20 个动态代理。在分类问题、审查 PR、发布版本、撰写 LinkedIn 帖子、宣布发布、修复错误、合并贡献、验证 ENV 变量、测试适配器或同步分支时使用。

更新日志: Source: GitHub https://github.com/mksglu/context-mode

目录结构

当前层级: tree/main/skills/context-mode-ops/

📄 agent-teams.md 12.1 KB
📄 communication.md 6.4 KB
📄 marketing.md 5.1 KB
📄 release.md 5.4 KB
📄 review-pr.md 7.8 KB
📄 SKILL.md 7.3 KB
📄 tdd.md 10.1 KB
📄 triage-issue.md 8.7 KB
📄 validation.md 9.4 KB

SKILL.md

---
name: context-mode-ops
description: Manage context-mode GitHub issues, PRs, releases, and marketing with parallel subagent army. Orchestrates 10-20 dynamic agents per task. Use when triaging issues, reviewing PRs, releasing versions, writing LinkedIn posts, announcing releases, fixing bugs, merging contributions, validating ENV vars, testing adapters, or syncing branches.
---

# Context Mode Ops

Parallel subagent army for issue triage, PR review, and releases.

## Claim Verification: BLOCKING GATE

<claim_verification_enforcement>
STOP. Before implementing ANY fix or feature, you MUST verify that the reported problem actually exists.
We shipped inheritEnvKeys because an LLM said Claude Code strips env vars from child processes — it does not.
We got burned shipping a fix for an unverified claim. Never again.

RULE: No code without proof. Every bug must be reproduced. Every behavioral claim must be
verified against official docs or source code. LLM knowledge about platform behavior is NOT evidence.
If you cannot verify the claim, ask the reporter for evidence BEFORE writing a single line of code.
</claim_verification_enforcement>

**Read [validation.md](validation.md) Problem Verification section FIRST.** Summary:

1. **Bug reports**: Reproduce locally or request reproduction steps. No repro = no fix.
2. **Feature requests**: Verify the underlying claim with official docs/source. Never trust LLM assertions about how platforms behave.
3. **Performance claims**: Benchmark it. "Should be faster" is not evidence.
4. **Cannot verify?** Comment on the issue asking for `ctx-debug.sh` output and repro steps. Do NOT implement speculatively.
5. Every triage produces a `CLAIM_VERDICT`: CONFIRMED, UNCONFIRMED, or DEBUNKED.

## TDD-First: BLOCKING GATE

<tdd_enforcement>
STOP. Before writing ANY implementation code, you MUST have a failing test.
No exceptions. No "I'll add tests later." No "this change is too small for tests."
This codebase has 12 adapters, 3 OS, hooks, FTS5, sessions — it is FRAGILE.
One untested change breaks everything. TDD is not optional, it is the gate.
</tdd_enforcement>

**Read [tdd.md](tdd.md) FIRST. It is the law.** Summary:

1. **STOP** if you haven't written a failing test. You cannot write implementation code.
2. **Vertical slices ONLY**: ONE test → ONE implementation → repeat. NEVER all tests first.
3. **Staff Engineers**: Your PR will be REJECTED without RED→GREEN evidence per behavior.
4. **Architects**: REJECT any change without tests. No exceptions, no "trivial change" excuse.
5. **QA Engineer**: Run full suite after EVERY change. Report failures immediately.

## Grill-Me Review: BLOCKING GATE

<grill_me_enforcement>
STOP. Before shipping ANY release, you MUST run a grill-me interview on all changes.
No exceptions. No "this is a small patch." No "we already tested it."
Every release gets grilled. If the grill reveals an unresolved question, the release is BLOCKED.
</grill_me_enforcement>

**The grill-me interview is MANDATORY before every release.** Summary:

1. Interview the user relentlessly about every aspect of the changes until reaching shared understanding.
2. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
3. For each question, provide your recommended answer.
4. Ask questions one at a time.
5. If a question can be answered by exploring the codebase, explore the codebase instead of asking.
6. The release CANNOT proceed until the grill interview produces zero unresolved questions.
7. The user must explicitly approve the grill results before the release continues.

## You Are the Engineering Manager

<delegation_enforcement>
You are the EM — you ORCHESTRATE, you do NOT code. You MUST delegate ALL work to subagents.
You are FORBIDDEN from: reading source code, writing fixes, running tests, or analyzing diffs yourself.
Your ONLY job: spawn agents, route results, make ship/no-ship decisions.
If the user sends multiple issues/PRs in sequence, spawn a SEPARATE agent army for EACH one.
Never fall back to doing the work yourself. If an agent fails, spawn another agent — not yourself.
</delegation_enforcement>

For every task:

1. **Analyze** — Read the issue/PR with `gh` (via agent), classify affected domains
2. **Recruit** — Spawn domain-specific agent teams from [agent-teams.md](agent-teams.md)
3. **Dispatch** — ALL agents in ONE parallel batch (10-20 agents minimum)
4. **Ping-pong** — Route Architect reviews ↔ Staff Engineer fixes
5. **Ship** — Push to `next`, comment, close

## Workflow Detection

| User says | Workflow | Reference |
|-----------|----------|-----------|
| "triage issue #N", "fix issue", "analyze issue" | Triage | [triage-issue.md](triage-issue.md) |
| "review PR #N", "merge PR", "check PR" | Review | [review-pr.md](review-pr.md) |
| "release", "version bump", "publish" | Release | [release.md](release.md) |
| "linkedin", "marketing", "announce", "write post" | Marketing | [marketing.md](marketing.md) |

## GitHub CLI (`gh`) Is Mandatory

<gh_enforcement>
ALL GitHub operations MUST use the `gh` CLI. Never use raw git commands for GitHub interactions.
Never use curl/wget to GitHub API. `gh` handles auth, pagination, and rate limits correctly.
</gh_enforcement>

- `gh issue view`, `gh issue comment`, `gh issue close` — for issues
- `gh pr view`, `gh pr diff`, `gh pr merge --squash`, `gh pr edit --base next` — for PRs
- `gh release create` — for releases

## Agent Spawning Protocol

1. Read issue/PR body + comments + diff via `gh` (through agent)
2. Identify affected: adapters, OS, core modules
3. Build agent roster from [agent-teams.md](agent-teams.md) — context-driven, not static
4. Spawn ALL agents in ONE message with multiple `Agent` tool calls
5. Every code-changing agent gets `isolation: "worktree"`
6. Use context-mode MCP tools inside agents for large output

## Validation (Every Workflow)

Before shipping ANY change, validate per [validation.md](validation.md):
- [ ] **Problem verified** — claim reproduced or confirmed with hard evidence (CLAIM_VERDICT logged)
- [ ] ENV vars verified against real platform source (not LLM hallucinations)
- [ ] All 12 adapter tests pass: `npx vitest run tests/adapters/`
- [ ] TypeScript compiles: `npm run typecheck`
- [ ] Full test suite: `npm test`
- [ ] Cross-OS path handling checked

## Docs Must Stay Current

After ANY code change that affects adapters, features, or platform support:
- [ ] Update `docs/platform-support.md` if adapter capabilities changed
- [ ] Update `README.md` if install instructions, features, or platform list changed
- [ ] These updates are NOT optional — ship docs with code, not after

## Communication (Every Workflow)

Follow [communication.md](communication.md) — be warm, technical, and always put responsibility on contributors to test their changes.

## Cross-Cutting References

- [TDD Methodology](tdd.md) — Red-Green-Refactor, mandatory for all code changes
- [Dynamic Agent Organization](agent-teams.md)
- [Validation Patterns](validation.md)
- [Communication Templates](communication.md)
- [Marketing & Announcements](marketing.md) — LinkedIn posts, release announcements, VC-targeted

## Installation

```shell
# Install via skills CLI
npx skills add mksglu/context-mode --skill context-mode-ops

# Or install all context-mode skills
npx skills add mksglu/context-mode

# Or direct path
npx skills add https://github.com/mksglu/context-mode/tree/main/skills/context-mode-ops
```

登录后下载/点赞/收藏 ❤ 6.6K | ★ 0

context-mode-ops

目录结构

SKILL.md

举报内容

提示