oh-my-customcode
Advanced tools
| # ADR Format | ||
| ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc. | ||
| Create the `docs/adr/` directory lazily — only when the first ADR is needed. | ||
| ## Template | ||
| ```md | ||
| # {Short title of the decision} | ||
| {1-3 sentences: what's the context, what did we decide, and why.} | ||
| ``` | ||
| That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections. | ||
| ## Optional sections | ||
| Only include these when they add genuine value. Most ADRs won't need them. | ||
| - **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited | ||
| - **Considered Options** — only when the rejected alternatives are worth remembering | ||
| - **Consequences** — only when non-obvious downstream effects need to be called out | ||
| ## Numbering | ||
| Scan `docs/adr/` for the highest existing number and increment by one. | ||
| ## When to offer an ADR | ||
| All three of these must be true: | ||
| 1. **Hard to reverse** — the cost of changing your mind later is meaningful | ||
| 2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?" | ||
| 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons | ||
| If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing." | ||
| ### What qualifies | ||
| - **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres." | ||
| - **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP." | ||
| - **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out. | ||
| - **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s. | ||
| - **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate. | ||
| - **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract." | ||
| - **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months. |
| # CONTEXT.md Format | ||
| ## Structure | ||
| ```md | ||
| # {Context Name} | ||
| {One or two sentence description of what this context is and why it exists.} | ||
| ## Language | ||
| **Order**: | ||
| {A one or two sentence description of the term} | ||
| _Avoid_: Purchase, transaction | ||
| **Invoice**: | ||
| A request for payment sent to a customer after delivery. | ||
| _Avoid_: Bill, payment request | ||
| **Customer**: | ||
| A person or organization that places orders. | ||
| _Avoid_: Client, buyer, account | ||
| ``` | ||
| ## Rules | ||
| - **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`. | ||
| - **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does. | ||
| - **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs. | ||
| - **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine. | ||
| ## Single vs multi-context repos | ||
| **Single context (most repos):** One `CONTEXT.md` at the repo root. | ||
| **Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other: | ||
| ```md | ||
| # Context Map | ||
| ## Contexts | ||
| - [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders | ||
| - [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments | ||
| - [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping | ||
| ## Relationships | ||
| - **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking | ||
| - **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices | ||
| - **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money` | ||
| ``` | ||
| The skill infers which structure applies: | ||
| - If `CONTEXT-MAP.md` exists, read it to find contexts | ||
| - If only a root `CONTEXT.md` exists, single context | ||
| - If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved | ||
| When multiple contexts exist, infer which one the current topic relates to. If unclear, ask. |
| # grill-with-docs | ||
| `grill-with-docs` is a multi-platform skill (works in Claude Code) for stress-testing a plan against the language, boundaries, and decisions already present in a codebase. | ||
| It asks one focused question at a time, checks the repository when the answer should be discoverable from code or docs, and captures settled domain language in `CONTEXT.md`. It can also suggest ADRs when a decision is hard to reverse, surprising without context, and shaped by a real trade-off. | ||
| This version is packaged as a standalone skill. It includes its own context and ADR formats, so it does not rely on other skills being installed. | ||
| ## Credits | ||
| Inspired by Matt Pocock's [`grill-with-docs`](https://github.com/mattpocock/skills/tree/main/skills/engineering/grill-with-docs) skill, packaged from [w00ing/skills](https://github.com/w00ing/skills/tree/main/grill-with-docs). |
| --- | ||
| name: grill-with-docs | ||
| description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions. | ||
| scope: core | ||
| version: 1.0.0 | ||
| user-invocable: true | ||
| --- | ||
| <what-to-do> | ||
| Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer. | ||
| Ask the questions one at a time, waiting for feedback on each question before continuing. | ||
| If a question can be answered by exploring the codebase, explore the codebase instead. | ||
| </what-to-do> | ||
| <supporting-info> | ||
| ## Domain awareness | ||
| During codebase exploration, also look for existing documentation: | ||
| ### File structure | ||
| Most repos have a single context: | ||
| ``` | ||
| / | ||
| ├── CONTEXT.md | ||
| ├── docs/ | ||
| │ └── adr/ | ||
| │ ├── 0001-event-sourced-orders.md | ||
| │ └── 0002-postgres-for-write-model.md | ||
| └── src/ | ||
| ``` | ||
| If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives: | ||
| ``` | ||
| / | ||
| ├── CONTEXT-MAP.md | ||
| ├── docs/ | ||
| │ └── adr/ ← system-wide decisions | ||
| ├── src/ | ||
| │ ├── ordering/ | ||
| │ │ ├── CONTEXT.md | ||
| │ │ └── docs/adr/ ← context-specific decisions | ||
| │ └── billing/ | ||
| │ ├── CONTEXT.md | ||
| │ └── docs/adr/ | ||
| ``` | ||
| Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed. | ||
| ## During the session | ||
| ### Challenge against the glossary | ||
| When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?" | ||
| ### Sharpen fuzzy language | ||
| When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things." | ||
| ### Discuss concrete scenarios | ||
| When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts. | ||
| ### Cross-reference with code | ||
| When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?" | ||
| ### Update CONTEXT.md inline | ||
| When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md). | ||
| `CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else. | ||
| ### Offer ADRs sparingly | ||
| Only offer to create an ADR when all three are true: | ||
| 1. **Hard to reverse** — the cost of changing your mind later is meaningful | ||
| 2. **Surprising without context** — a future reader will wonder "why did they do it this way?" | ||
| 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons | ||
| If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md). | ||
| </supporting-info> | ||
| ## Cross-References | ||
| | Skill | Relationship | | ||
| |-------|--------------| | ||
| | `brainstorming` (superpowers) | Process skill for early creative exploration; grill-with-docs is the domain-model stress-test that follows once a plan exists | | ||
| | `ambiguity-gate` | Pre-routing clarity scoring; grill-with-docs goes deeper — interviews one question at a time against the codebase | | ||
| | `deep-plan` | Research→plan→verify; grill-with-docs complements by sharpening terminology and capturing decisions as docs | | ||
| **Unique value**: grill-with-docs captures settled domain language in `CONTEXT.md` (glossary) and offers ADRs inline as decisions crystallise — a domain-model documentation dimension the planning/grilling skills above do not cover. |
+1
-1
@@ -6,3 +6,3 @@ { | ||
| ], | ||
| "version": "1.0.20", | ||
| "version": "1.1.0", | ||
| "description": "Batteries-included agent harness for Claude Code", | ||
@@ -9,0 +9,0 @@ "type": "module", |
+5
-5
@@ -16,3 +16,3 @@ <div align="center"> | ||
| 49 agents. 117 skills. 23 rules. One command. | ||
| 49 agents. 118 skills. 23 rules. One command. | ||
@@ -130,3 +130,3 @@ ```bash | ||
| | Managers | 6 | mgr-creator, mgr-updater, mgr-supplier, mgr-gitnerd, mgr-sauron, mgr-claude-code-bible | | ||
| | System | 3 | sys-memory-keeper, sys-naggy, tracker-checkpoint | | ||
| | System | 4 | sys-memory-keeper, sys-naggy, tracker-checkpoint, wiki-curator | | ||
@@ -137,3 +137,3 @@ Each agent declares its tools, model, memory scope, and limitations in YAML frontmatter. Tool budgets are enforced per agent type for accuracy. | ||
| ### Skills (117) | ||
| ### Skills (118) | ||
@@ -151,3 +151,3 @@ | Category | Count | Includes | | ||
| | Security | 3 | adversarial-review, cve-triage, jinja2-prompts | | ||
| | Other | 7 | claude-native, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and more | | ||
| | Other | 47 | claude-native, vercel-deploy, skills-sh-search, result-aggregation, writing-clearly-and-concisely, and ~40 more | | ||
@@ -277,3 +277,3 @@ Skills use a 3-tier scope system: `core` (universal), `harness` (agent/skill maintenance), `package` (project-specific). | ||
| │ ├── agents/ # 49 agent definitions | ||
| │ ├── skills/ # 117 skill modules | ||
| │ ├── skills/ # 118 skill modules | ||
| │ ├── rules/ # 23 governance rules (R000-R023) | ||
@@ -280,0 +280,0 @@ │ ├── hooks/ # 15 lifecycle hook scripts |
@@ -12,3 +12,3 @@ --- | ||
| - diagram-design | ||
| tools: [Read, Write, Edit, Grep, Glob, Bash] | ||
| tools: [Read, Write, Edit, Grep, Glob] | ||
| maxTurns: 20 | ||
@@ -51,18 +51,4 @@ disallowedTools: [Bash] | ||
| Before declaring any design "done", run the AI Slop Test. This is the critical checkpoint. | ||
| Run the AI Slop Test as the design ship-gate — see the `impeccable-design` skill for the flag-pattern list and verdict scale. | ||
| Ask: **Would someone immediately identify this as AI-generated?** | ||
| Flag these patterns as AI slop: | ||
| - Overused fonts: Inter, Roboto, or Arial used as default without intentional reason | ||
| - Pure black (`#000`) or pure gray backgrounds with no color tinting | ||
| - Excessive card nesting with uniform rounded corners and drop shadows on everything | ||
| - Generic gradient backgrounds (blue-purple, coral-orange) with no contextual rationale | ||
| - Bounce or elastic animations as "delight" without functional purpose | ||
| - Centered-everything layouts that avoid spatial decisions | ||
| - Hero sections with a gradient blob behind centered text | ||
| - Identical spacing increments used everywhere (8px, 8px, 8px) | ||
| - Color palettes that are purely neutral except for one brand accent | ||
| - Empty states with a generic icon + "No items yet" + CTA | ||
| ## Workflow | ||
@@ -69,0 +55,0 @@ |
@@ -19,14 +19,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| You are the authoritative source of truth for Claude Code specifications. You fetch official documentation from code.claude.com and validate the project against official specs. | ||
@@ -33,0 +21,0 @@ |
@@ -21,6 +21,2 @@ --- | ||
| ## .claude/ 경로 처리 (CC v2.1.121+) | ||
| Direct Write/Edit/Bash on `.claude/**` and `templates/.claude/**` is permitted under `mode: "bypassPermissions"` as of CC v2.1.121 (#1101). The legacy `/tmp/*.sh` bypass is deprecated. For CC < v2.1.121, see git history for the legacy pattern. | ||
| You are an agent creation specialist following R006 (MUST-agent-design.md) rules. | ||
@@ -27,0 +23,0 @@ |
@@ -22,14 +22,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| You are a Git operations specialist following GitHub flow best practices. | ||
@@ -36,0 +24,0 @@ |
@@ -21,14 +21,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| You are an automated verification specialist that executes the mandatory R017 verification process, acting as the "all-seeing eye" that ensures system integrity through comprehensive multi-round verification. | ||
@@ -58,114 +46,4 @@ | ||
| ## Verification Process | ||
| Full 5+3-round verification procedure and report format: see the sauron-watch skill (single source of truth). | ||
| ### Phase 1: Manager Verification (5 rounds) | ||
| **Round 1-2: Basic Checks** | ||
| - mgr-supplier:audit (all agents, dependency validation) | ||
| - mgr-updater:docs (documentation sync check) | ||
| **Round 3-4: Re-verify + Update** | ||
| - Re-run mgr-supplier:audit | ||
| - Re-run mgr-updater:docs (apply any detected changes) | ||
| **Round 5: Final Count Verification** | ||
| - Agent count: CLAUDE.md vs actual .md files | ||
| - Skill count: CLAUDE.md vs actual SKILL.md files | ||
| - Memory field distribution matches CLAUDE.md | ||
| - Hook/context/guide/rule counts | ||
| ### Phase 2: Deep Review (3 rounds) | ||
| **Round 1: Workflow Alignment** | ||
| - Agent workflows match purpose | ||
| - Command definitions match implementations | ||
| - Routing skill patterns are valid | ||
| **Round 2: Reference Verification** | ||
| - All skill references exist | ||
| - All agent frontmatter valid | ||
| - memory field values valid (user | project | local) | ||
| - No orphaned agents | ||
| **Round 3: Philosophy Compliance** | ||
| - R006: Agent design rules (including memory field spec) | ||
| - R007: Agent identification rules | ||
| - R008: Tool identification rules | ||
| - R009: Parallel execution rules | ||
| - R010: Orchestrator coordination rules | ||
| - R011: Memory integration (native-first architecture) | ||
| ### Phase 2.5: Documentation Accuracy | ||
| **Agent Name Accuracy** | ||
| - Every agent name in CLAUDE.md must match actual filename | ||
| - No shortened names, no missing agents | ||
| **Component Count Accuracy** | ||
| - All counts cross-verified against filesystem | ||
| **Slash Command Verification** | ||
| - Every command must have corresponding skill | ||
| **Routing Skill Completeness** | ||
| - Every agent reachable through routing skills | ||
| ### Phase 3: Auto-fix & Report | ||
| **Auto-fixable Issues:** | ||
| - Count mismatches in CLAUDE.md | ||
| - Missing memory field in agents | ||
| - Outdated documentation references | ||
| **Manual Review Required:** | ||
| - Missing agent files | ||
| - Invalid memory scope values | ||
| - Philosophy violations | ||
| ## Output Format | ||
| ### Watch Mode Report | ||
| ``` | ||
| [Sauron] Full Verification Started | ||
| === Phase 1: Manager Verification === | ||
| [Round 1/5] mgr-supplier:audit | ||
| - 34 agents checked | ||
| - 3 issues found | ||
| [Round 2/5] mgr-updater:docs | ||
| - Documentation sync: OK | ||
| ... | ||
| === Phase 2: Deep Review === | ||
| [Round 1/3] Workflow Alignment | ||
| - All workflows valid | ||
| ... | ||
| === Phase 3: Resolution === | ||
| [Auto-fixed] | ||
| - CLAUDE.md agent count: 33 -> 34 | ||
| [Manual Review Required] | ||
| - .claude/agents/broken-agent.md: missing | ||
| [Sauron] Verification Complete | ||
| Total Issues: 8 | ||
| Auto-fixed: 5 | ||
| Manual: 3 | ||
| ``` | ||
| ### Quick Mode Report | ||
| ``` | ||
| [Sauron] Quick Verification | ||
| Agents: 34/34 OK | ||
| Skills: 40/40 OK | ||
| Refs: 2 broken | ||
| Status: ISSUES FOUND | ||
| Run 'mgr-sauron:watch' for full verification | ||
| ``` | ||
| ## Integration | ||
@@ -172,0 +50,0 @@ |
@@ -22,14 +22,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| You are a dependency validation specialist ensuring agents have all required skills and guides properly linked. | ||
@@ -36,0 +24,0 @@ |
@@ -25,6 +25,2 @@ --- | ||
| ## .claude/ 경로 처리 (CC v2.1.121+) | ||
| Direct Write/Edit/Bash on `.claude/**` and `templates/.claude/**` is permitted under `mode: "bypassPermissions"` as of CC v2.1.121 (#1101). The legacy `/tmp/*.sh` bypass is deprecated. For CC < v2.1.121, see git history for the legacy pattern. | ||
| You are an external source synchronization specialist keeping external components up-to-date. | ||
@@ -31,0 +27,0 @@ |
@@ -45,55 +45,2 @@ --- | ||
| ## Key Command Patterns | ||
| ### App Lifecycle | ||
| ```bash | ||
| slack create <app-name> # Scaffold a new Slack app | ||
| slack run # Start local development server | ||
| slack deploy # Deploy app to Slack Platform | ||
| slack delete # Delete a deployed app | ||
| ``` | ||
| ### Authentication | ||
| ```bash | ||
| slack login # Authorize a workspace | ||
| slack logout # Remove workspace authorization | ||
| slack auth list # List all authorized workspaces | ||
| ``` | ||
| ### Triggers | ||
| ```bash | ||
| slack trigger create --trigger-def <file> # Create an event trigger | ||
| slack trigger update --trigger-id <id> # Update an existing trigger | ||
| slack trigger delete --trigger-id <id> # Delete a trigger | ||
| slack trigger list # List all triggers | ||
| ``` | ||
| ### Datastore | ||
| ```bash | ||
| slack datastore put '{"datastore": "<name>", "item": {...}}' | ||
| slack datastore get '{"datastore": "<name>", "id": "<id>"}' | ||
| slack datastore query '{"datastore": "<name>"}' | ||
| slack datastore bulk-put --datastore <name> --data-file <file> | ||
| slack datastore bulk-delete --datastore <name> --data-file <file> | ||
| ``` | ||
| ### Environment Variables | ||
| ```bash | ||
| slack env add <key> <value> # Add or update an env variable | ||
| slack env remove <key> # Remove an env variable | ||
| slack env list # List all env variables | ||
| ``` | ||
| ### Collaboration | ||
| ```bash | ||
| slack collaborators add <email> # Add a collaborator | ||
| slack collaborators remove <email> # Remove a collaborator | ||
| slack collaborators list # List collaborators | ||
| ``` | ||
| ### Diagnostics | ||
| ```bash | ||
| slack doctor # System diagnostics and dependency check | ||
| slack manifest validate # Validate app manifest before deployment | ||
| slack feedback # Send feedback to Slack | ||
| ``` | ||
| Command reference: see guides/slack-cli/README.md (source of truth). |
@@ -21,14 +21,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| You are a task management specialist that proactively manages TODO items and reminds users of pending tasks. | ||
@@ -35,0 +23,0 @@ |
@@ -13,14 +13,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| # Tracker Checkpoint Agent | ||
@@ -27,0 +15,0 @@ |
@@ -17,14 +17,2 @@ --- | ||
| ## Mandatory: .claude/ 경로 처리 (R010 Universal /tmp Script Bypass) | ||
| ALL tool calls targeting `.claude/` paths MUST go through `/tmp/*.sh` script via Bash. This includes Write, Edit, and write-Bash. Direct `Write(".claude/...")` or `Edit(".claude/...")` triggers user approval prompts that block unattended automation, regardless of `bypassPermissions` mode or allow rules. | ||
| Pattern: | ||
| 1. Write tool → `/tmp/fix-{topic}-$$.sh` containing heredoc/sed/cp targeting `.claude/` | ||
| 2. Bash tool → `bash /tmp/fix-{topic}-$$.sh` | ||
| Read tool on `.claude/` paths is exempt (sensitive-path bypass for read-only). For `templates/.claude/` paths, the same pattern applies (also sensitive). | ||
| Reference: R010 (.claude/rules/MUST-orchestrator-coordination.md), #1046, #1052, #1062. | ||
| # Wiki Curator | ||
@@ -31,0 +19,0 @@ |
@@ -26,3 +26,4 @@ # [MUST] Agent Design Rules | ||
| | `opusplan` | claude-opus-4-6 + plan mode | Architecture planning with approval gates | | ||
| | `opus47` | claude-opus-4-7 | Latest Opus model, supports xhigh effort | | ||
| | `opus47` | claude-opus-4-7 | Supports xhigh effort | | ||
| | `opus48` | claude-opus-4-8 | Latest Opus model (GA); highest capability below Fable 5 | | ||
| | `fable` | claude-fable-5 | Mythos-class; tier above Opus, highest GA capability (access added in CC v2.1.170) | | ||
@@ -29,0 +30,0 @@ |
@@ -128,3 +128,3 @@ --- | ||
| Baseline annotations and observed trajectories can be persisted to eval-core's SQLite database (`evalBaselines` + `agentTrajectories` tables). This complements the YAML file approach for cross-session analysis. Use eval-core query module (TBD — separate followup) for analytics. | ||
| Baseline annotations and observed trajectories can be persisted to eval-core's SQLite database (`evalBaselines` + `agentTrajectories` tables). This complements the YAML file approach for cross-session analysis. The eval-core query API for the `evalBaselines`/`agentTrajectories` tables is not yet implemented — use the YAML annotation approach meanwhile. | ||
@@ -131,0 +131,0 @@ ## Integration with Existing Skills |
@@ -163,2 +163,10 @@ # Agent Triggers for Intent Detection | ||
| be-django-expert: | ||
| keywords: | ||
| korean: [장고, 디장고] | ||
| english: [django, "django rest", drf] | ||
| file_patterns: ["manage.py", "settings.py", "urls.py", "models.py", "wsgi.py", "asgi.py"] | ||
| supported_actions: [review, create, fix, refactor] | ||
| base_confidence: 75 | ||
| # SW Engineers - Tooling | ||
@@ -189,2 +197,10 @@ tool-bun-expert: | ||
| slack-cli-expert: | ||
| keywords: | ||
| korean: [슬랙, 슬랙봇, 슬랙 알림, 슬랙 메시지] | ||
| english: [slack, "slack cli", "slack bot", "slack notification", webhook] | ||
| file_patterns: [] | ||
| supported_actions: [send, notify, configure, post] | ||
| base_confidence: 75 | ||
| # SW Engineers - Database | ||
@@ -199,2 +215,75 @@ db-supabase-expert: | ||
| db-postgres-expert: | ||
| keywords: | ||
| korean: [포스트그레스, 포스트그레스큐엘, 피지] | ||
| english: [postgres, postgresql, psql, pgsql] | ||
| file_patterns: ["*.sql", "postgresql.conf", "pg_hba.conf"] | ||
| supported_actions: [review, create, fix, optimize] | ||
| base_confidence: 75 | ||
| db-redis-expert: | ||
| keywords: | ||
| korean: [레디스, 캐시, 인메모리] | ||
| english: [redis, cache, "redis cluster", "in-memory"] | ||
| file_patterns: ["redis.conf", "*.rdb"] | ||
| supported_actions: [review, create, fix, optimize] | ||
| base_confidence: 75 | ||
| db-alembic-expert: | ||
| keywords: | ||
| korean: [알렘빅, 마이그레이션, 스키마 마이그레이션] | ||
| english: [alembic, migration, "schema migration"] | ||
| file_patterns: ["alembic.ini", "alembic/versions/*.py", "migrations/*.py", "env.py"] | ||
| supported_actions: [migrate, review, create, fix] | ||
| base_confidence: 75 | ||
| # DE Engineers | ||
| de-airflow-expert: | ||
| keywords: | ||
| korean: [에어플로우, DAG, 워크플로우 스케줄] | ||
| english: [airflow, dag, "apache airflow", scheduler] | ||
| file_patterns: ["dags/*.py", "airflow.cfg"] | ||
| supported_actions: [review, create, fix, refactor] | ||
| base_confidence: 75 | ||
| de-dbt-expert: | ||
| keywords: | ||
| korean: [디비티, 데이터 모델링] | ||
| english: [dbt, "data build tool", "sql model"] | ||
| file_patterns: ["models/*.sql", "dbt_project.yml", "schema.yml"] | ||
| supported_actions: [review, create, fix, test] | ||
| base_confidence: 75 | ||
| de-spark-expert: | ||
| keywords: | ||
| korean: [스파크, 분산 처리] | ||
| english: [spark, pyspark, "apache spark", "distributed processing"] | ||
| file_patterns: ["*.py", "*.scala"] | ||
| supported_actions: [review, create, fix, optimize] | ||
| base_confidence: 75 | ||
| de-kafka-expert: | ||
| keywords: | ||
| korean: [카프카, 스트리밍, 이벤트 스트림] | ||
| english: [kafka, streaming, "event stream", "apache kafka", producer, consumer] | ||
| file_patterns: ["*.properties", "server.properties"] | ||
| supported_actions: [review, create, fix, configure] | ||
| base_confidence: 75 | ||
| de-snowflake-expert: | ||
| keywords: | ||
| korean: [스노우플레이크, 데이터 웨어하우스] | ||
| english: [snowflake, "data warehouse", warehouse, snowsql] | ||
| file_patterns: ["*.sql"] | ||
| supported_actions: [review, create, fix, optimize] | ||
| base_confidence: 75 | ||
| de-pipeline-expert: | ||
| keywords: | ||
| korean: [데이터 파이프라인, ETL, ELT, 데이터 적재] | ||
| english: [pipeline, etl, elt, "data pipeline", ingestion] | ||
| file_patterns: ["pipelines/*.py", "*.yaml"] | ||
| supported_actions: [review, create, fix, design] | ||
| base_confidence: 70 | ||
| # SW Architects | ||
@@ -234,2 +323,11 @@ arch-documenter: | ||
| # Security | ||
| sec-codeql-expert: | ||
| keywords: | ||
| korean: [코드큐엘, 보안 스캔, 취약점 스캔, 정적 분석] | ||
| english: [codeql, sarif, vulnerability, "static analysis", "security scan", sast] | ||
| file_patterns: ["*.ql", "*.qll", "codeql/*"] | ||
| supported_actions: [scan, analyze, review] | ||
| base_confidence: 75 | ||
| # Managers | ||
@@ -311,2 +409,18 @@ mgr-creator: | ||
| tracker-checkpoint: | ||
| keywords: | ||
| korean: [체크포인트, 진행 상태, 파이프라인 상태, 추적] | ||
| english: ["pipeline state", checkpoint, "track progress", "state tracking", resume] | ||
| file_patterns: [] | ||
| supported_actions: [track, checkpoint, resume] | ||
| base_confidence: 70 | ||
| wiki-curator: | ||
| keywords: | ||
| korean: [위키 페이지, 위키 큐레이션, 지식 정리] | ||
| english: ["wiki page", "wiki curation", "knowledge base page", "wiki write"] | ||
| file_patterns: ["wiki/**"] | ||
| supported_actions: [create, update, curate] | ||
| base_confidence: 70 | ||
| # --------------------------------------------------------------------------- | ||
@@ -420,2 +534,11 @@ # Research / Information Gathering (skill-based, not agent) | ||
| de-lead: | ||
| keywords: | ||
| korean: [데이터 엔지니어링, DE 리드, 파이프라인 조율, 데이터 파이프라인] | ||
| english: [airflow, dbt, spark, kafka, snowflake, pipeline, ETL, DAG, "de lead", "data engineering"] | ||
| file_patterns: ["dags/*.py", "*.sql", "models/"] | ||
| supported_actions: [coordinate, review, lead] | ||
| base_confidence: 40 | ||
| routing_rule: "Invoke de-lead-routing skill to route DE tasks to the correct data engineering expert" | ||
| secretary: | ||
@@ -727,3 +850,3 @@ keywords: | ||
| base_confidence: 65 | ||
| routing_rule: "Reference guides/development/ directory" | ||
| routing_rule: "Reference appropriate guides/ subdirectory" | ||
@@ -730,0 +853,0 @@ guide-best-practices: |
@@ -119,3 +119,3 @@ <!-- omcustom:start --> | ||
| | +-- agents/ # 서브에이전트 정의 (49 파일) | ||
| | +-- skills/ # 스킬 (117 디렉토리) | ||
| | +-- skills/ # 스킬 (118 디렉토리) | ||
| | +-- rules/ # 전역 규칙 (R000-R023) | ||
@@ -122,0 +122,0 @@ | +-- hooks/ # 훅 스크립트 (보안, 검증, HUD) |
@@ -224,2 +224,8 @@ # Guides Index | ||
| - name: drizzle-orm | ||
| description: Drizzle ORM sql template literal pitfalls and table-qualifier safety patterns | ||
| path: ./drizzle-orm/ | ||
| source: | ||
| type: internal | ||
| # Git | ||
@@ -232,2 +238,8 @@ - name: git-worktree-workflow | ||
| - name: git-safety | ||
| description: Safe git operation patterns for autonomous agents — working tree loss prevention | ||
| path: ./git-safety/ | ||
| source: | ||
| type: internal | ||
| # Architecture | ||
@@ -240,2 +252,14 @@ - name: skill-bundle-design | ||
| - name: architecture | ||
| description: Reference patterns from AWS sample-deep-insight hierarchical multi-agent system | ||
| path: ./architecture/ | ||
| source: | ||
| type: internal | ||
| - name: harness-engineering | ||
| description: Harness engineering guide — agent behavior control and infrastructure isolation as first-class design | ||
| path: ./harness-engineering/ | ||
| source: | ||
| type: internal | ||
| # Writing | ||
@@ -275,1 +299,124 @@ - name: elements-of-style | ||
| type: internal | ||
| - name: agent-design | ||
| description: Agent design pattern references — Ralph loop persistence, Socratic interview templates, PAL cost routing, and CLI agent patterns | ||
| path: ./agent-design/ | ||
| source: | ||
| type: internal | ||
| - name: agent-eval | ||
| description: Agent evaluation framework reference — 4-metric methodology and ideal trajectory annotation | ||
| path: ./agent-eval/ | ||
| source: | ||
| type: internal | ||
| - name: agent-teams | ||
| description: Agent Teams troubleshooting guide for common operational issues and shutdown handling | ||
| path: ./agent-teams/ | ||
| source: | ||
| type: internal | ||
| - name: agent-workflow | ||
| description: Autonomous challenge session lessons and guardrails for long-running agent runs | ||
| path: ./agent-workflow/ | ||
| source: | ||
| type: internal | ||
| - name: browser-automation | ||
| description: Browser automation patterns for AI agents via MCP-based browser tools and lightweight CDP alternatives | ||
| path: ./browser-automation/ | ||
| source: | ||
| type: internal | ||
| - name: compound-ai-workflow | ||
| description: Compound AI workflow principles — accumulating artifacts as context across sessions | ||
| path: ./compound-ai-workflow/ | ||
| source: | ||
| type: internal | ||
| - name: deep-plan | ||
| description: Companion guide for the deep-plan skill — research, plan, and verify phases | ||
| path: ./deep-plan/ | ||
| source: | ||
| type: internal | ||
| - name: external-tools | ||
| description: External tool integration references — graphify knowledge graph and ECC absorption decisions | ||
| path: ./external-tools/ | ||
| source: | ||
| type: internal | ||
| - name: hook-data-flow | ||
| description: Hook data flow reference — stall detection pipeline for parallel agents (R009) | ||
| path: ./hook-data-flow/ | ||
| source: | ||
| type: internal | ||
| - name: middleware-patterns | ||
| description: Lifecycle middleware patterns for customizing the agent harness | ||
| path: ./middleware-patterns/ | ||
| source: | ||
| type: internal | ||
| - name: multi-agent-debate-patterns | ||
| description: Multi-agent debate anti-patterns and structural mechanisms to prevent them | ||
| path: ./multi-agent-debate-patterns/ | ||
| source: | ||
| type: internal | ||
| - name: multi-provider-exec | ||
| description: Cross-provider LLM execution reference for external exec skills | ||
| path: ./multi-provider-exec/ | ||
| source: | ||
| type: internal | ||
| - name: professor-triage | ||
| description: Companion guide for the professor-triage skill — issue triage phases | ||
| path: ./professor-triage/ | ||
| source: | ||
| type: internal | ||
| - name: profiles | ||
| description: Manifest install profile guide — minimal/full profile selection patterns | ||
| path: ./profiles/ | ||
| source: | ||
| type: internal | ||
| # Security | ||
| - name: security | ||
| description: Security pre-flight analysis pattern (AgentShield) for pre-write risk identification | ||
| path: ./security/ | ||
| source: | ||
| type: internal | ||
| # Skill Development | ||
| - name: skill-promotion | ||
| description: Skill promotion guide — instinct extraction and failure-pattern mining | ||
| path: ./skill-promotion/ | ||
| source: | ||
| type: internal | ||
| # Token Efficiency | ||
| - name: cc-token-saver | ||
| description: cc-token-saver plugin integration guide for token and cost optimization | ||
| path: ./cc-token-saver/ | ||
| source: | ||
| type: external | ||
| origin: github | ||
| url: https://github.com/ww-w-ai/cc-token-saver | ||
| license: Apache-2.0 | ||
| - name: token-efficiency | ||
| description: Token-efficient context retrieval integration — CRG and Semble MCP wrappers | ||
| path: ./token-efficiency/ | ||
| source: | ||
| type: internal | ||
| # Tooling | ||
| - name: slack-cli | ||
| description: Slack CLI reference for creating and managing Slack apps from the command line | ||
| path: ./slack-cli/ | ||
| source: | ||
| type: external | ||
| origin: slack.dev | ||
| url: https://docs.slack.dev/tools/slack-cli/ |
| { | ||
| "version": "1.0.20", | ||
| "version": "1.1.0", | ||
| "lastUpdated": "2026-06-26T00:00:00.000Z", | ||
@@ -23,3 +23,3 @@ "omcustomMinClaudeCode": "2.1.121", | ||
| "description": "Reusable skill modules (includes slash commands)", | ||
| "files": 117 | ||
| "files": 118 | ||
| }, | ||
@@ -26,0 +26,0 @@ { |
Sorry, the diff of this file is too big to display
Sorry, the diff of this file is too big to display
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
3622866
0.24%416
0.97%