agentleFS
Sign inStart free
mmaripanguecmmaripanguec/dev-sdd-kit/.claude/skills/as-is-learn/SKILL.md

as-is-learn

Skill2 starsChanged 4 months agoMITView on GitHub

Analyzes the REAL repos to learn how routes are defined and consumed, writes exact per-repo extractors and regenerates the as-is map. Use when the cross-repo graph comes out empty or incomplete, or when a repo's framework changes.

The file

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 5 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

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

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

    Read the registry (. scripts/repo-lib.sh && registry_repos and the role/entrypoint fields of repos.yaml): which repos exist and what role …

    line 11
  2. Very specific:

    If it EXPOSES an API (backend, service): where are its endpoints registered/defined?

    line 18
  3. Very specific:

    If it INTERMEDIATES (proxy/BFF/gateway): how does it define what it exposes and how does it call its providers?

    line 22
  4. Distinctive:

    If it CONSUMES (frontend, client): how does it build the URLs to its providers?

    line 26
  5. Very specific:

    Create scripts/as-is.d/<repo>.sh (executable) following the contract in that folder's README.

    line 31
  6. Distinctive:

    If the communication is gRPC: derive logical "routes" from the services/methods in the .proto (format /grpc/Service/Method) so the graph …

    line 34
  7. Distinctive:

    If the proxy routes by config: read THAT config file and emit its prefixes/paths — the config is more faithful than any grep of the code.

    line 37
  8. Very specific:

    Run ./scripts/generate-as-is.sh and review system.md.

    line 41
  9. Distinctive:

    Check every arrow (and every absence) against what was seen in step 1.

    line 42
  10. Very specific:

    Run ./scripts/generate-as-is.sh --check (it must end up green).

    line 45
  11. Distinctive:

    Do NOT modify code in the repos.

    line 51

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Goal: make the graph in knowledge/as-is/system.md reflect the REAL communication between repos, with evidence from the code — zero assumptions.

0. Declared topology

Read the registry (. scripts/repo-lib.sh && registry_repos and the role/entrypoint fields of repos.yaml): which repos exist and what role each one declares. The analysis in step 1 is done FOR EACH registered and cloned repo.

1. Investigate with the code in front of you (cite file:line in every finding)

For each repo in the registry, according to its role:

  • If it EXPOSES an API (backend, service): where are its endpoints registered/defined? (framework, struct table, config file, serverless.yml, dynamic handlers, gRPC via .proto, worker with no API — and why the generic extractor did not see it).
  • If it INTERMEDIATES (proxy/BFF/gateway): how does it define what it exposes and how does it call its providers? (HTTP with base URL + literal, reverse proxy by prefix/config, gRPC, message queue — the config is more faithful than any grep of the code).
  • If it CONSUMES (frontend, client): how does it build the URLs to its providers? (environment constants + literals, central HTTP service, endpoints in json).

2. Write the exact extractor for each repo that needs it

  • Create scripts/as-is.d/<repo>.sh (executable) following the contract in that folder's README. In comments: the evidence (files:lines) justifying each pattern. Shell compatible with bash 3.2: ${var} with braces, ASCII only.
  • If the communication is gRPC: derive logical "routes" from the services/methods in the .proto (format /grpc/Service/Method) so the graph can represent it.
  • If the proxy routes by config: read THAT config file and emit its prefixes/paths — the config is more faithful than any grep of the code.

3. Verify against reality, not against the script

  • Run ./scripts/generate-as-is.sh and review system.md.
  • Check every arrow (and every absence) against what was seen in step 1. An arrow without evidence gets investigated; an expected absence (e.g. worker with no API) gets documented in the repo's api-surface.md via the extractor.
  • Run ./scripts/generate-as-is.sh --check (it must end up green).

4. Wrap up

  • Summary: route mechanism per repo (with citations), resulting arrows, known limitations.
  • Remember to commit: knowledge/as-is/ + scripts/as-is.d/ to the workspace. Do NOT modify code in the repos. Do NOT invent routes without evidence.

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.

Check your setup, free