agentleFS
specscorespecscore/specstudio-skills/skills/survey/SKILL.md

survey

Skill0 starsChanged 5 months agoMITView on GitHub

Produces a fast architecture survey for an existing codebase without reading source implementation files. Scans the file tree, reads only allowlisted structural manifests, writes JSON-first survey artifacts under spec/research/, and stages the results. Use before retrofit or when the user wants a cheap architecture overview of an existing repo. Trigger: "specstudio:survey", "/survey", "/specstudio:survey", "survey this repo", "architecture survey", "map this repo".

  • Reads credentials

21 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use daily-arxiv, exp-eval and 10 more.

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.
  • LambenthanSkill

    daily-arxiv

    每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新

    Also in 5 projects that use this

  • LambenthanSkill

    exp-eval

    实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

    Also in 5 projects that use this

  • skyllwtSkill

    exp-pilot-eval

    Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.

    Also in 4 projects that use this

  • skyllwtSkill

    exp-pilot-run

    Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.

    Also in 4 projects that use this

  • phanghonghaoSkill

    poster

    HTML/CSS A4 海报生成。从沙龙/活动 Markdown 文件生成科技风 A4 海报 PDF/PNG。Use when user mentions: poster, 海报, 海报生成, make poster, generate poster, 活动海报, 沙龙海报.

    Also in 4 projects that use this

  • +6 more from Lambenthan
  • +1 more from skyllwt

The file

Show its rules and text

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

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

    Default output dir: spec/research/

    line 68
  2. Distinctive:

    When scoped, filter the inventory to paths under the scope.

    line 78
  3. Very specific:

    If git is unavailable, use find and exclude obvious generated or dependency directories:

    line 80
  4. Distinctive:

    When git is available, record:

    line 92
  5. Distinctive:

    When git is unavailable, record:

    line 98
  6. Very specific:

    Read content only from the operational allowlist at skills/shared/survey-manifest-allowlist.md.

    line 107
  7. Very specific:

    If monorepo signals are present and no --scope was supplied:

    line 137
  8. Distinctive:

    Do not write artifacts.

    line 142
  9. Distinctive:

    Do not invent behavior from source.

    line 185
  10. Distinctive:

    Create the output directory if needed.

    line 205
  11. Very specific:

    If --json is set, skip Markdown rendering and go to indexing/lint/staging.

    line 207
  12. Distinctive:

    Use Mermaid diagrams only when they add clarity.

    line 229
  13. Distinctive:

    Add or update one row for the survey:

    line 255
  14. Distinctive:

    Do not duplicate rows for the same survey slug.

    line 261
  15. Distinctive:

    If lint fails, make one focused fix pass for the generated artifacts and rerun lint.

    line 271
  16. Distinctive:

    Never commit. Report the staged paths.

    line 281

“Common” is measured: kept by at least 6 in 10 of the 16 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

Survey

Produce a fast architecture survey of the current repository without reading source implementation files.

Hard Gate

<HARD-GATE> This skill MUST NOT read source implementation file contents. It may list source file paths and count them, but it must not open implementation files such as `*.js`, `*.ts`, `*.py`, `*.go`, `*.rs`, `*.java`, `*.cs`, `*.rb`, `*.php`, `*.swift`, or `*.kt`, unless the file is explicitly allowed as a structural manifest below.

The output is research, not canonical Feature intent. Do not write Feature, Plan, or code artifacts from this skill. Do not invoke specstudio:retrofit automatically. </HARD-GATE>

When To Use

  • A user wants a cheap architecture overview of an existing repository.
  • A user is deciding whether retrofit is worth running.
  • A future specstudio:retrofit run needs a survey-output-schema-v1 input.

Skip when the user wants behavior, requirements, or acceptance criteria derived from code. That is retrofit, not survey.

Inputs and flags

Supported invocations:

  • specstudio:survey
  • specstudio:survey --scope <subdir>
  • specstudio:survey --slug <slug>
  • specstudio:survey --output-dir <path>
  • specstudio:survey --json

Flag behavior:

  • --scope <subdir> limits the file inventory and manifest reads to that subtree, while repo state still records the whole-repo HEAD.
  • --slug <slug> overrides slug derivation.
  • --output-dir <path> overrides the default spec/research/.
  • --json writes only the JSON artifact and skips Markdown rendering.

Unknown flags are refused.

Step 1 - Pre-flight

  1. Determine repo root with git rev-parse --show-toplevel. If that fails, use the current directory and record git_available: false.
  2. Resolve scope from --scope, defaulting to repo root.
  3. Derive slug from, in order:
    • package.json#name
    • pyproject.toml [project].name
    • go.mod module basename
    • Cargo.toml [package].name
    • repository directory basename
    • --slug override, if supplied
  4. Sanitize slug to lowercase a-z0-9-, collapse repeated dashes, and trim leading/trailing dashes.
  5. Set output paths:
    • JSON: <output-dir>/<slug>-survey.json
    • Markdown: <output-dir>/<slug>-survey.md
    • Default output dir: spec/research/

Step 2 - File inventory

Prefer:

git ls-files

When scoped, filter the inventory to paths under the scope.

If git is unavailable, use find and exclude obvious generated or dependency directories:

  • .git
  • node_modules
  • .venv, venv, __pycache__
  • dist, build, target, .next, .turbo
  • .cache, .pytest_cache

Record the scan method as git-ls-files or find-fallback.

Step 3 - Repo state

When git is available, record:

  • head_sha: git rev-parse HEAD
  • dirty_tree: whether git status --short is non-empty
  • status_short: literal lines from git status --short

When git is unavailable, record:

  • git_available: false
  • head_sha: null
  • dirty_tree: null
  • status_short: []

Step 4 - Allowed manifest reads only

Read content only from the operational allowlist at skills/shared/survey-manifest-allowlist.md. The current v1 categories are:

  • JavaScript / TypeScript: package.json, pnpm-workspace.yaml, lerna.json, nx.json, turbo.json, tsconfig*.json, next.config.*, vite.config.*, nuxt.config.*, astro.config.*, package-lock.json, pnpm-lock.yaml, yarn.lock
  • Python: pyproject.toml, setup.py, setup.cfg, requirements*.txt, poetry.lock, Pipfile, Pipfile.lock, tox.ini
  • Go: go.mod, go.sum, go.work
  • Rust: Cargo.toml, Cargo.lock
  • Other languages: Gemfile, composer.json, *.csproj, *.sln, pom.xml, build.gradle*
  • Infra and ops: docker-compose*.yml, Dockerfile, terraform/*.tf, serverless.yml, helm/Chart.yaml, kustomization.yaml
  • CI and tooling: .github/workflows/*.yml, .gitlab-ci.yml, .circleci/config.yml, Makefile, justfile, Taskfile.yml
  • Release and packaging: .goreleaser.yml, .goreleaser.yaml, release-please-config.json, .release-please-manifest.json, .releaserc, .releaserc.json, .changeset/config.json
  • Runtime pinning: .tool-versions, .nvmrc, .python-version, .ruby-version
  • SpecScore: specscore.yaml
  • Docs: root README*, ARCHITECTURE*, CONTRIBUTING*; top-level docs/** filenames only unless a doc file is small enough to read under the size cap

Generated release outputs remain excluded. Do not read dist/**, packaged archives, generated checksums, generated changelogs, or binary artifacts as release manifests.

Size cap for any single text read: 80 KB. If an allowlisted file exceeds the cap, do not read it. Record a warning: skipped due to size.

Step 5 - Monorepo detection

Detect monorepo signals before synthesis:

  • pnpm-workspace.yaml
  • nx.json
  • lerna.json
  • turbo.json
  • go.work
  • Cargo workspace members in root Cargo.toml
  • multiple root package directories indicated by manifests

If monorepo signals are present and no --scope was supplied:

  1. Refuse to synthesize a whole-repo survey.
  2. Identify the signal paths.
  3. Recommend rerunning with specstudio:survey --scope <subdir>.
  4. Do not write artifacts.

Step 6 - Build the structured survey

Construct a JSON object with this minimum shape:

{
  "schema": "survey-output-schema-v1",
  "slug": "<slug>",
  "scope": "<scope-or-null>",
  "scan_method": "git-ls-files",
  "repo_state": {
    "git_available": true,
    "head_sha": "<sha>",
    "dirty_tree": false,
    "status_short": []
  },
  "file_inventory_summary": {
    "total_files": 0,
    "by_extension": {},
    "top_level_dirs": []
  },
  "manifest_inventory": [],
  "detected_frameworks": [],
  "architecture_summary": "",
  "directory_clusters": [],
  "research_zones": [],
  "sensitive_path_inventory": [],
  "warnings": []
}

Populate:

  • file_inventory_summary: counts by extension, top-level directory counts, test path counts, docs path counts.
  • manifest_inventory: allowlisted files read, skipped, or absent.
  • detected_frameworks: framework/tool signals inferred from manifests and filenames.
  • directory_clusters: hierarchical directory groups, max depth 3, max 12 children per parent.
  • research_zones: proposed bounded zones for retrofit researchers, each with path roots, file counts, and one-line purpose.
  • sensitive_path_inventory: filename-pattern hints only.
  • warnings: dirty tree, skipped oversized manifests, monorepo refusal signals when scoped, ambiguous slug signals.

Do not invent behavior from source. If a conclusion depends only on file names or manifests, phrase it as inferred.

Step 7 - Sensitive path inventory

Flag filename-pattern hints for:

  • .env*
  • secrets/**
  • *.pem
  • *.key
  • **/fixtures/**
  • git-crypt markers
  • submodule entries
  • LFS pointer-looking files
  • lockfile mismatch hints, such as multiple package-manager lockfiles

Label the section explicitly: "Filename-pattern hints only; not a content secret scan."

Step 8 - Write JSON first

Create the output directory if needed. Write the JSON artifact first. Sort object keys where practical and keep arrays in deterministic path order.

If --json is set, skip Markdown rendering and go to indexing/lint/staging.

Step 9 - Render Markdown from JSON

Render Markdown from the JSON artifact. The Markdown must contain:

  1. # Survey: <title>
  2. **Status:** Current
  3. **Date:** <YYYY-MM-DD>
  4. **Repo SHA:** <sha-or-unavailable>
  5. **Scope:** <scope-or-repo-root>
  6. **JSON:** <relative path to json>
  7. ## Summary
  8. ## Architecture
  9. ## Directory Clusters
  10. ## Research Zones
  11. ## Detected Frameworks
  12. ## Sensitive Path Inventory
  13. ## Warnings
  14. ## Open Questions
  15. Footer: *This document follows the https://specscore.md/research-artifact-specification*

Use Mermaid diagrams only when they add clarity. Always include text lists so the artifact remains useful without Mermaid rendering.

Step 10 - Research index

For default output under spec/research/, ensure spec/research/README.md exists.

If absent, create:

# Research

Research artifacts produced by SpecStudio skills.

## Contents

| Artifact | Description |
|---|---|

## Open Questions

None at this time.

---
*This document follows the https://specscore.md/index-specification*

Add or update one row for the survey:

| [<slug>-survey](<slug>-survey.md) | Architecture survey for `<scope-or-repo>`. |

Do not duplicate rows for the same survey slug.

Step 11 - Lint and fix once

Run:

specscore spec lint

If lint fails, make one focused fix pass for the generated artifacts and rerun lint. If violations remain, surface them with paths and stop.

Step 12 - Stage

Stage all generated or updated files:

git add <json> <markdown-if-written> <research-index-if-updated>

Never commit. Report the staged paths.

Output summary

End with:

  • JSON path
  • Markdown path, unless --json
  • Research index path, if updated
  • Lint result
  • Staged paths
  • Any warnings, especially dirty tree and sensitive-path hints

Relationship to retrofit

specstudio:retrofit consumes the JSON artifact. Survey does not invoke retrofit automatically. If the user wants to continue, recommend running retrofit with the generated JSON path once retrofit ships.

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.