onboard
Skill9 starsChanged 8 months agoMITView on GitHub
Analyze an existing project and bootstrap SubFrame-compatible output files: .subframe/STRUCTURE.json, .subframe/PROJECT_NOTES.md, and initial sub-tasks. Root directory listing: !ls -la Package manifest: !cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null || cat Cargo.toml 2>/dev/null || echo "No package manifest found" Project overview: !head -100 README.md 2>/dev/null || echo "No README found" AI configuration (Claude): !head -50 CLAUDE.md 2>/dev/null || echo "No CLAUDE.md found" AI configuration (Gemini): !head -50 GEMINI.md 2>/dev/null || echo "No GEMINI.md found" Source file survey: !find . -maxdepth 2…
165 other projects use a version of this.
Adopted by
Most recently taken up by
- ggoosen/Digital-Workforcetheir own version, first seen Nov 8, 2026
- joeldevz/skynex-pitheir own version, first seen Nov 8, 2026
- eggs-gd/career-spacetheir own version, first seen Nov 8, 2026
- passion4it-gmbh/passionfruit-sitetheir own version, first seen Nov 5, 2026
- striderZA/OpenCodeGameStudiostheir own version, first seen Nov 4, 2026
- ChadPapineau/espn-fantasy-football-mcptheir own version, first seen Nov 1, 2026
Used with
Projects with it also use soak-test, team-live-ops 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.
lilangMaxSkillsoak-test
Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.
Also in 9 projects that use this
lilangMaxSkillteam-live-ops
Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update.
Also in 9 projects that use this
HK-hubSkillteach-impeccable
One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
Also in 19 projects that use this
CoralGameSkillproject-stage-detect
Automatically analyze project state, detect stage, identify gaps, and recommend next steps based on existing artifacts.
Also in 15 projects that use this
CoralGameSkillteam-level
Orchestrate level design team: level-designer + narrative-director + world-builder + art-director + systems-designer + qa-tester for complete area/level creation.
Also in 11 projects that use this
- +5 more from lilangMax
- +2 more from CoralGame
Other versions165 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 165
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- parcadei/Continuous-Claude★ 3.9ksame name
- parcadei/Continuous-Claude-v2★ 3.9ksame name
- parcadei/Continuous-Claude-v3★ 3.9ksame name
- nateherkai/AIS-OS★ 1.4ksame name
- poshan0126/dotclaude★ 871same name
- talesofai/cohub★ 585same name
- me2resh/apexyard★ 542same name
- nexmoe/DayBee★ 424same name
- nexmoe/eve★ 424same name
155 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
We split this skill into the rules it gives an agent
11 rules. 0 are common, 2 are distinctive, and 9 are very specific to this project.
0
Common
Most of the 153 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 44
If \$ARGUMENTS\ contains \--dry-run\, do not write any files.
- Very specific: line 95
If a \STRUCTURE.json\ already exists, merge new data into it.
- Very specific: line 96
If no \STRUCTURE.json\ exists, create a fresh one.
- Very specific: line 149
If a \PROJECT_NOTES.md\ already exists, do not overwrite it.
- Very specific: line 150
If no \PROJECT_NOTES.md\ exists, create a fresh one from the template above.
- Distinctive: line 158
Test coverage gaps (if a test framework is configured but few tests exist)
- Very specific: line 175
If the task CLI script (\scripts/task.js\) does not exist in the target project, skip sub-task creation and inform the user that the …
- Very specific: line 179
Before writing any files, ensure the \.subframe/\ directory and its subdirectories exist:
- Distinctive: line 187
Write the generated content:
- Very specific: line 211
Run \npm run structure\ if available to enrich STRUCTURE.json with line numbers
- Very specific: line 212
Start working on the created sub-tasks \\\`
“Common” is measured: kept by at least 6 in 10 of the 153 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
<!-- @subframe-version 0.14.0-beta --><!-- @subframe-managed -->name: onboard description: Analyze project intelligence files and bootstrap SubFrame's STRUCTURE.json, PROJECT_NOTES.md, and initial sub-tasks from existing codebase context. disable-model-invocation: false argument-hint: [--dry-run] allowed-tools: Bash, Read, Write, Glob, Grep
SubFrame Onboard
Analyze an existing project and bootstrap SubFrame-compatible output files: .subframe/STRUCTURE.json, .subframe/PROJECT_NOTES.md, and initial sub-tasks.
Dynamic Context
Root directory listing:
!ls -la
Package manifest:
!cat package.json 2>/dev/null || cat pyproject.toml 2>/dev/null || cat Cargo.toml 2>/dev/null || echo "No package manifest found"
Project overview:
!head -100 README.md 2>/dev/null || echo "No README found"
AI configuration (Claude):
!head -50 CLAUDE.md 2>/dev/null || echo "No CLAUDE.md found"
AI configuration (Gemini):
!head -50 GEMINI.md 2>/dev/null || echo "No GEMINI.md found"
Source file survey:
!find . -maxdepth 2 -name "*.ts" -o -name "*.tsx" -o -name "*.py" -o -name "*.rs" -o -name "*.go" -o -name "*.java" -o -name "*.rb" 2>/dev/null | head -50
Existing SubFrame state:
!cat .subframe/STRUCTURE.json 2>/dev/null || echo "No STRUCTURE.json yet"
Instructions
Argument: `$ARGUMENTS`
Dry-Run Mode
If `$ARGUMENTS` contains `--dry-run`, do not write any files. Instead, show the full output that would be written for each file, clearly labeled with the target path. Then stop.
Step 1: Analyze the Project
Using the gathered dynamic context, determine:
- Project type — What kind of project is this? (web app, CLI tool, library, monorepo, etc.)
- Language and framework — Primary language, framework, and build tooling
- Architecture — Entry points, module structure, process model (single, client-server, microservices, etc.)
- Key modules — Identify the most important source files and their purposes (scan up to 3 directory levels deep)
- Existing documentation — What context already exists in README, CLAUDE.md, GEMINI.md, or other docs?
- Dependencies — Key runtime and dev dependencies from the package manifest
Step 2: Generate STRUCTURE.json
Build a SubFrame-compatible `STRUCTURE.json` following this schema:
```json
{
"version": "1.0",
"description": "<project-name> - Module structure and communication map",
"lastUpdated": "<YYYY-MM-DD>",
"architecture": {
"type": "<project-type>",
"entryPoint": "<main-entry-file>",
"notes": "<brief architecture description>"
},
"modules": {
"<module-key>": {
"file": "<relative-path>",
"description": "<what this module does>",
"exports": ["<exported-function-or-class>"],
"depends": ["<dependency-module-key>"],
"functions": {
"<function-name>": {
"line": 0,
"params": ["<param>"],
"purpose": "<what it does>"
}
},
"loc": 0
}
},
"conventions": {
"naming": "<file/variable naming conventions observed>",
"patterns": "<architectural patterns used (MVC, hooks, modules, etc.)>"
}
}
```
Rules:
- If a `STRUCTURE.json` already exists, merge new data into it. Do not overwrite user-supplied descriptions or manually curated content. Only fill in empty fields and add newly discovered modules.
- If no `STRUCTURE.json` exists, create a fresh one.
- Scan source files to populate the `modules` section. For each module, read the first ~50 lines to identify exports and purpose.
- Set `lastUpdated` to today's date.
Step 3: Generate PROJECT_NOTES.md
Build a SubFrame-compatible `PROJECT_NOTES.md` following this structure:
```markdown
<Project Name> - Project Documentation
Project Vision
Problem: <What problem does this project solve?>
Solution: <Brief description of the solution>
Target User: <Who is this for?>
Project Summary
<1-2 paragraph summary of the project, its purpose, and current state.>
Tech Stack
Core
<Technology>(<version>): <Why it's used>
Why These Technologies?
<Technology>:<Rationale>
Architecture
<Description of the project's architecture, module layout, and data flow.>
Key Decisions
<Any architecture or technology decisions discoverable from the codebase.>Session Notes
<Empty section — to be filled during future development sessions.> ```
Rules:
- If a `PROJECT_NOTES.md` already exists, do not overwrite it. Instead, show a diff of suggested additions and ask the user before applying changes.
- If no `PROJECT_NOTES.md` exists, create a fresh one from the template above.
- Fill in as much detail as the codebase context allows. Leave sections with `
<placeholder>` text if insufficient information is available.
Step 4: Suggest Initial Sub-Tasks
Analyze the project's current state and suggest 3 to 5 initial sub-tasks. Good candidates include:
- Missing documentation that should exist
- Test coverage gaps (if a test framework is configured but few tests exist)
- TODO/FIXME comments found in the source code
- Configuration improvements (linting, formatting, CI)
- Architecture improvements visible from the structure analysis
For each suggested sub-task, show:
- Title — concise imperative description
- Description — what needs to be done and why
- Priority — `low`, `medium`, or `high`
- Category — `feature`, `fix`, `docs`, `refactor`, `test`, `chore`
Ask the user to confirm which sub-tasks to create before writing any. Then create the approved ones using the task CLI:
```bash
node scripts/task.js add --title "<title>" --description "<description>" --priority <priority> --category <category>
```
If the task CLI script (`scripts/task.js`) does not exist in the target project, skip sub-task creation and inform the user that the SubFrame task CLI is not available.
Step 5: Ensure Directory Structure
Before writing any files, ensure the `.subframe/` directory and its subdirectories exist:
```bash mkdir -p .subframe/tasks ```
Step 6: Write Files
Write the generated content:
- `.subframe/STRUCTURE.json` — the module map
- `.subframe/PROJECT_NOTES.md` — the project documentation
Step 7: Summary
Show a summary of what was created or updated:
```
Onboard Summary
Project: <name> (<type>)
Language: <primary language> + <framework>
Files Written
- `.subframe/STRUCTURE.json` —
<N>modules mapped - `.subframe/PROJECT_NOTES.md` — project documentation bootstrapped
Sub-Tasks Created
- [ST-XXX]
<title>(priority, category) - ...
Next Steps
- Review the generated files and refine descriptions
- Run `npm run structure` if available to enrich STRUCTURE.json with line numbers
- Start working on the created sub-tasks ```
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.

