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
- genkovich/sddtheir own version, first seen Oct 25, 2026
- PKU-DAIR/AutoScitheir own version, first seen Oct 25, 2026
- wheslleyrimar/BuildCLI-Agentstheir own version, first seen Oct 22, 2026
- LazyerIJ/self-clonetheir own version, first seen Oct 17, 2026
- steven112163/dotharnesstheir own version, first seen Oct 15, 2026
- DAIR-AutoResearch/AutoScitheir own version, first seen Oct 15, 2026
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.
LambenthanSkilldaily-arxiv
每日从 arXiv 拉取新论文,过滤相关性,auto-ingest 高优先级论文,检测 SOTA 更新
Also in 5 projects that use this
LambenthanSkillexp-eval
实验判决门:Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges
Also in 5 projects that use this
skyllwtSkillexp-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
skyllwtSkillexp-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
phanghonghaoSkillposter
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
Other versions21 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 21
- skyllwt/OmegaWiki★ 1.7ksame name
- DAIR-AutoResearch/AutoSci★ 1.7ksame name
- PKU-DAIR/AutoSci★ 1.7ksame name
- skyllwt/AutoSci★ 1.7ksame name
- genkovich/sdd★ 187same name
- SNL-UCSB/literature-survey-skill★ 93same name
- Lambenthan/empiricalwiki★ 85same name
- spacedock-dev/spacedock★ 85same name
- V-Songbird/foreman★ 35same name
- jmylchreest/aide★ 19same name
11 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
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
- Very specific: line 68
Default output dir: spec/research/
- Distinctive: line 78
When scoped, filter the inventory to paths under the scope.
- Very specific: line 80
If git is unavailable, use find and exclude obvious generated or dependency directories:
- Distinctive: line 92
When git is available, record:
- Distinctive: line 98
When git is unavailable, record:
- Very specific: line 107
Read content only from the operational allowlist at skills/shared/survey-manifest-allowlist.md.
- Very specific: line 137
If monorepo signals are present and no --scope was supplied:
- Distinctive: line 142
Do not write artifacts.
- Distinctive: line 185
Do not invent behavior from source.
- Distinctive: line 205
Create the output directory if needed.
- Very specific: line 207
If --json is set, skip Markdown rendering and go to indexing/lint/staging.
- Distinctive: line 229
Use Mermaid diagrams only when they add clarity.
- Distinctive: line 255
Add or update one row for the survey:
- Distinctive: line 261
Do not duplicate rows for the same survey slug.
- Distinctive: line 271
If lint fails, make one focused fix pass for the generated artifacts and rerun lint.
- Distinctive: line 281
Never commit. Report the staged paths.
“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.
Files
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:retrofitrun needs asurvey-output-schema-v1input.
Skip when the user wants behavior, requirements, or acceptance criteria derived from code. That is retrofit, not survey.
Inputs and flags
Supported invocations:
specstudio:surveyspecstudio: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 defaultspec/research/.--jsonwrites only the JSON artifact and skips Markdown rendering.
Unknown flags are refused.
Step 1 - Pre-flight
- Determine repo root with
git rev-parse --show-toplevel. If that fails, use the current directory and recordgit_available: false. - Resolve
scopefrom--scope, defaulting to repo root. - Derive
slugfrom, in order:package.json#namepyproject.toml [project].namego.modmodule basenameCargo.toml [package].name- repository directory basename
--slugoverride, if supplied
- Sanitize slug to lowercase
a-z0-9-, collapse repeated dashes, and trim leading/trailing dashes. - Set output paths:
- JSON:
<output-dir>/<slug>-survey.json - Markdown:
<output-dir>/<slug>-survey.md - Default output dir:
spec/research/
- JSON:
Step 2 - File inventory
Prefer:
git ls-filesWhen scoped, filter the inventory to paths under the scope.
If git is unavailable, use find and exclude obvious generated or dependency directories:
.gitnode_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 HEADdirty_tree: whethergit status --shortis non-emptystatus_short: literal lines fromgit status --short
When git is unavailable, record:
git_available: falsehead_sha: nulldirty_tree: nullstatus_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-leveldocs/**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.yamlnx.jsonlerna.jsonturbo.jsongo.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:
- Refuse to synthesize a whole-repo survey.
- Identify the signal paths.
- Recommend rerunning with
specstudio:survey --scope <subdir>. - 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:
# Survey: <title>**Status:** Current**Date:** <YYYY-MM-DD>**Repo SHA:** <sha-or-unavailable>**Scope:** <scope-or-repo-root>**JSON:** <relative path to json>## Summary## Architecture## Directory Clusters## Research Zones## Detected Frameworks## Sensitive Path Inventory## Warnings## Open Questions- 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 lintIf 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.
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
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.

