---
name: multi-sub-project-awareness
description: "Formalizes a project root containing multiple genuinely separate sub-projects — sub-project table, self-contained per-sub-project folders, shared root-level layer, drop-folder routing, and file-naming extension; extends FTR-07/FTR-08 rather than replacing either. Use when a person asks to install or apply \"Multi-Sub-Project Awareness\" (FTR-38) in a project, or when working in a project that has it installed."
---

# Multi-Sub-Project Awareness (FTR-38, version 1.0)

> Generated from library record FTR-38 version 1.0, publish 20261102a. Review status: unreviewed. The complete specification is in references/spec.md and is the authority; this file is the operating procedure drawn from it.

## What this does

Formalizes a project root containing multiple genuinely separate sub-projects — sub-project table, self-contained per-sub-project folders, shared root-level layer, drop-folder routing, and file-naming extension; extends FTR-07/FTR-08 rather than replacing either

## When to use this skill

- A person asks to install, apply or update "Multi-Sub-Project Awareness" (FTR-38) in a project.
- A project's agent instructions list multi-sub-project-awareness as installed and the task touches what it covers.
- Requires first: FTR-07 (skill folder-structure), FTR-08 (skill file-naming-and-versioning).
- Works better with, if installed: FTR-15 (skill project-cache).

## Install procedure

Steps run in order. Assess comes first, every question in the Ask step is answered by the person before anything is written, and every write merges additively into the existing project files (read the file first, update an existing section in place, never overwrite).

### Assess first
- Confirm whether the project genuinely decomposes into multiple self-contained efforts, each substantial enough to warrant its own folder, document set, and (usually) its own track-ID prefix — versus a single project better served by FTR-08's ordinary multi-track convention alone. Ask the user directly if this is unclear; installing this feature where it isn't needed adds structural overhead a simpler project doesn't benefit from.
- Check whether `admin\AGENT_INSTRUCTIONS.md` already has a section covering multi-sub-project structure. If present, confirm and skip.
- Confirm how many sub-projects exist at install time, and get each one's short code (2-3 letters, matching FTR-08's track-code convention) and full name before writing anything — the structure depends on having this list complete and correct from the start, since renaming a sub-project after folders and trackers exist is real rework.

### Ask, only if needed
If the user's request implies multiple sub-projects but hasn't stated how many or what they're called, ask directly: "It sounds like this project covers more than one separate effort — can you list them, with a short code for each (2-3 letters), and a one-line description of what each one covers?" Do not guess sub-project boundaries or names from context alone.

Also ask, if not already stated: does every sub-project warrant its own drop-folder routing subfolder, or should incoming files land in one flat drop folder and be manually sorted? Both are legitimate; this is a genuine user preference, not something this feature should default silently.

### Write

The full Write payload is in references/write-payload.md. It is applied exactly as written, with the merge rule above.

### Confirm
Confirm: Multi-Sub-Project Awareness is installed — a MULTI-SUB-PROJECT STRUCTURE section now exists in `admin\AGENT_INSTRUCTIONS.md` naming every sub-project, its short code, its self-contained folder convention, and how the shared root layer (drop folder, admin, cache) is scoped across all of them. Want to install another, or is that everything for now?
## Other sections in the specification

- What this doesn't cover

These are in references/spec.md.

## Files in this skill

- references/spec.md: the complete specification, unabridged.
- references/write-payload.md: the Write step on its own.