agentleFS
shyamsridhar123shyamsridhar123/kevin-copilot/.github/skills/observe/SKILL.md

observe

Skill7 starsChanged 3 months agoMITView on GitHub

Start a focused observation session to analyze specific patterns in the codebase. Watches a domain or file pattern and records findings for future /learn runs.

10 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use design and ship.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Microsoft AzureSkill

    design

    Design rules and conventions for the API Center Portal. Use when editing detail pages, card components, badges, layout, navigation, sidebars, or headers. Covers badge styling, metadata placement, page navigation patterns, and layout alignment.

    Also in 3 projects that use this

  • AWSSkill

    ship

    Finalize dev work on an issue branch — update docs, push, and open a PR.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 0 are common, 14 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 9 edited versions we read keep these.

  • 14

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run a focused observation session on a specific domain, file pattern, or question.

    line 8
  2. Distinctive:

    When you want to understand how a specific pattern is used across the codebase

    line 12
  3. Distinctive:

    When you suspect an inconsistency and want data

    line 13
  4. Distinctive:

    When onboarding to a new area of the code

    line 14
  5. Distinctive:

    When you want to document "how we do X here"

    line 15
  6. Distinctive:

    If the user provides a focus topic, use it.

    line 21
  7. Distinctive:

    Search for relevant code patterns using grep/glob

    line 36
  8. Distinctive:

    Look for consistency and deviations

    line 38
  9. Distinctive:

    Check git blame for when patterns were established

    line 39
  10. Distinctive:

    Read representative files for patterns

    line 44
  11. Distinctive:

    Check for README or documentation

    line 45
  12. Very specific:

    Read .atv/observations.jsonl for relevant tool use

    line 48
  13. Distinctive:

    Check git log for commit patterns

    line 49
  14. Distinctive:

    Look at CI/CD configuration

    line 50
  15. Distinctive:

    Check for scripts or Makefiles

    line 51
  16. Distinctive:

    Does NOT write to observations.jsonl

    line 126

“Common” is measured: kept by at least 6 in 10 of the 9 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/observe — Targeted Pattern Analysis

Run a focused observation session on a specific domain, file pattern, or question. Unlike /learn which broadly scans recent work, /observe lets you zoom in on a specific area.

When to Use

  • When you want to understand how a specific pattern is used across the codebase
  • When you suspect an inconsistency and want data
  • When onboarding to a new area of the code
  • When you want to document "how we do X here"

Execution Flow

Step 1: Determine Focus

If the user provides a focus topic, use it. Otherwise ask:

What should I observe? Examples:
  - "error handling" — how errors are wrapped, propagated, and reported
  - "test patterns" — how tests are structured and organized
  - "naming conventions" — variable, function, and file naming
  - "src/api/**" — patterns in a specific directory
  - "imports" — how dependencies are organized

Step 2: Gather Evidence

Based on the focus, run targeted analysis:

For code pattern focus:

  1. Search for relevant code patterns using grep/glob
  2. Sample 10-20 representative files
  3. Look for consistency and deviations
  4. Check git blame for when patterns were established

For directory focus:

  1. List all files in the target path
  2. Analyze file organization and naming
  3. Read representative files for patterns
  4. Check for README or documentation

For workflow focus:

  1. Read .atv/observations.jsonl for relevant tool use
  2. Check git log for commit patterns
  3. Look at CI/CD configuration
  4. Check for scripts or Makefiles

Step 3: Analyze Findings

For each observation, evaluate:

QuestionWhy
Is this pattern consistent?Consistency = high confidence instinct
How many files follow it?Volume = evidence strength
Are there deviations?Deviations = either evolution or mistakes
When was it established?Age = stability indicator
Is it documented anywhere?Documentation = intentional choice

Step 4: Record Results

Append findings to .atv/observations.jsonl with a special observation type:

{
  "ts": "2026-04-06T10:30:00Z",
  "hook": "manual-observe",
  "focus": "error handling",
  "findings": [
    "All errors wrapped with fmt.Errorf %w in 18/20 files",
    "Two files use bare error returns (legacy code from 2024)",
    "Custom error types in pkg/errors/ for domain errors",
    "No panic() usage found — errors always returned"
  ],
  "suggested_instincts": [
    {
      "id": "always-wrap-errors",
      "trigger": "when returning an error from a function",
      "behavior": "wrap with fmt.Errorf using %w verb"
    }
  ]
}

Step 5: Report

Observation: [focus topic]

Findings:
  1. [Pattern] — found in N/M files examined (X% consistent)
  2. [Pattern] — found in N/M files examined (X% consistent)
  3. [Deviation] — N files deviate from the dominant pattern

Suggested instincts (run /learn to formalize):
  + [instinct-id] — "[behavior]" (evidence: N files)
  + [instinct-id] — "[behavior]" (evidence: N files)

Existing instincts affected:
  ↑ [instinct-id] — additional evidence found (+N observations)
  ? [instinct-id] — contradictory evidence found (N deviations)

Next steps:
  - Run /learn to incorporate these findings into instincts
  - Run /observe "[related topic]" to dig deeper
  - Review deviations — they may be intentional or need fixing

Quick Observations

For rapid pattern checks without full analysis:

/observe --quick "how do we handle auth?"

Quick mode:

  1. Searches for relevant files (auth, middleware, session, token)
  2. Reads the most relevant 3-5 files
  3. Summarizes the pattern in 3-5 bullet points
  4. Does NOT write to observations.jsonl

Notes

  • Observations are raw data — run /learn to turn them into instincts
  • Manual observations have higher signal than automatic hook observations
  • The manual-observe hook type in observations.jsonl lets /learn weight these higher
  • Observations are additive — run multiple times on different topics

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.