AGENT SKILL

ground-first

Produce a code-grounded analysis before any edit is proposed. Triggers on: "analyze", "understand behavior", "how does this work".

适用职业开发工程师
License 许可
MIT
最近更新
2026-10-26
Stars
★ 0
Forks
0

01 前言 Front Matter

name
ground-first
description
Produce a code-grounded analysis before any edit is proposed. Triggers on: "analyze", "understand behavior", "how does this work".
allowed-tools
Read Grep Glob Bash
argument-hint
[subject]

03 SKILL.md 正文

Produce a code-grounded analysis of a subject before any edits are proposed.

Trigger: when the user asks for a fix, change, or investigation on non-trivial code and has not yet confirmed you understand current behavior. Also triggered directly via /ground-first.

Arguments: $ARGUMENTS — a description of what to analyze (e.g. "auth token refresh race condition", "why ingest job retries forever", "issue #140").

Steps

  1. Parse the subject from $ARGUMENTS. If empty or vague, infer from recent conversation. If still unclear, ask the user what they want analyzed.

  2. Locate the relevant code. Use these tools, in this order:

    • Glob to find candidate files by name pattern
    • Grep to find candidate files by symbol/string
    • Read every candidate file that survives the first two steps. Read the actual file — do not infer from its name.
  3. Produce the analysis in this format:

    ## Subject
    
    <one-line restatement of the subject>
    
    ## Current behavior
    
    - <claim>. `path/to/file.go:42`
    - <claim>. `path/to/other.ts:120–140`
    
    ## Relevant entry points
    
    - `path/to/handler.go:15` — `HandleIngest()`
    - `path/to/config.yaml:8` — `retries: 3`
    
    ## What I do not yet know
    
    - <specific unknown, e.g. "whether the retry limit is overridden at runtime">
    - <specific unknown>
    
    ## Proposed next steps (not yet actioned)
    
    1. <step>
    2. <step>
    
  4. STOP. Do not call Edit, Write, or any other mutation tool. Wait for the user to confirm the analysis matches reality or to correct it.

Rules

  • Every claim must cite a file:line or file:line–line reference from a file you actually read in this session.
  • If you cannot find a file that supports a claim, list the claim under "What I do not yet know" instead of asserting it.
  • Do not propose edits. Do not run tests. Do not make changes. This command is read-only by design.
  • Keep the analysis under ~30 lines. Cite more, narrate less.
  • If the subject turns out to be trivial (e.g., a typo fix), say so and hand control back — don't pad.

04 同仓库更多 Skills

kaiohenricunha
kaiohenricunha/dotbabel

yolo

Start temporary autonomy for the current task or an explicit scope with a required --for expiry. Codex permits scoped pushes, merges, deploys, and releases after strict testing and validation; Full access is a separate runtime setting. Claude Code uses a session permission hook with a protected-action denylist.

开发工程师
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

veracity-audit

Audit a data pipeline for Veracity and Value. Dispatches data-scientist, compliance-auditor, and data-engineer agents with project context injected at dispatch time. All source paths are supplied via flags — no defaults, no project assumptions. Subcommands: audit (full pipeline walk), score-check (scoring math only), gate-check (gate coverage only), source-trace <label> (single source end-to-end). Invoke when: "audit pipeline", "veracity check", "scoring math correct?", "check gates", "trace source", "verify quality gates", "formula correct?".

律师与法务Skill与智能体开发
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

validate-spec

Audit an already-implemented spec against the codebase. Walks each constraint (ARCH-N, PERF-N, KD-N, etc.) and acceptance criterion, grounds findings in file:line evidence, runs the spec.json acceptance_commands, and writes a single audit doc to docs/audits/. Use whenever the user asks to "validate a spec", "audit a spec", "check if spec is implemented", "verify the spec is done", "is this spec really done", or otherwise wants closure on spec-driven work. Read-only against the spec — produces an audit, never modifies the spec itself.

★ 0
kaiohenricunha
kaiohenricunha/dotbabel

terragrunt-specialist

Deep-dive Terragrunt hierarchy review, DRY pattern audits, and run-all orchestration analysis. Use for structured investigations of multi-environment Terragrunt layouts, dependency graphs, remote state config, and hook correctness. Triggers on: "Terragrunt audit", "run-all review", "dependency block", "DRY pattern review", "env hierarchy audit", "mock_outputs", "terragrunt hooks".

运维与部署
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

terraform-specialist

Deep-dive Terraform architecture review, module design, state management, and migration. Use for structured investigations of Terraform workspaces, provider configuration, module coupling, import workflows, and test coverage. Triggers on: "Terraform audit", "module review", "state management", "Terraform import", "workspace design", "provider config review", "Terraform testing".

测试与质量运维与部署
★ 0
kaiohenricunha
kaiohenricunha/dotbabel

spec

Create structured engineering specs through interactive pairing. Use when the user wants to create a spec, design doc, technical specification, architecture document, RFC, or engineering plan. Triggers on "let's spec this out", "create a spec", "design doc", "write a technical plan", "plan the architecture". Works for greenfield and brownfield projects. Outputs to docs/specs/.

设计师视觉设计
★ 0