<!--
IndexTitle: Goals Ideas Plans Capabilities Model
IndexDescription: Planning model for how Goals, Ideas, Plans, and Capabilities relate and mature in a learning repository.
IndexType: Project
IndexStatus: Active
LastEdited: 2026-06-08
-->

# Goals Ideas Plans Capabilities Model

## Purpose

Define the formal repository model for how **Goals**, **Idea**, **Ideas**,
**Plans**, and **Capabilities** relate in a **learning repository** that helps
the owner achieve **their goals**—and how indexing and cross-repository
harmonization keep the layers discoverable and improving.

**Quick Startup** (`Capabilities/GettingStarted/`) is where **Owner Goals**
are first captured and put into effect; they refine as the owner works.
**Repository Goals** (`Plans/RepositoryGoals.md`) are the core durable Goals set
for the repository itself.

This is a planning model only. It does not create folders, move files, or
promote any specific Idea into a Capability.

## Working Model

```text
Goals decide what matters.
Repository Goals are the core durable set for the learning repository.
Owner Goals are the owner's practical outcomes—Quick Startup, then refined as they work.
Chats become Markdown; a Markdown note can become one or more Ideas.
An Idea is one tracked possibility; Ideas is the folder and register layer.
Plans shape selected Ideas into action toward Owner Goals and Repository Goals.
Some Plans produce one-time work.
Some Plans produce repeatable work.
Repeatable work can become a Capability.
Some Capabilities may own optional Skills.
Capabilities help future agents serve Goals.
Indexing keeps Goals, Ideas, Plans, Capabilities, and Skills discoverable.
CapabilityHarmonize blends improvements from like repositories into the shared set.
```

The learning repository helps the owner achieve **their goals** by providing
the easiest path: capture **Ideas**, nurture selected Ideas into **Plans**,
implement outcomes, and promote repeatable work into **Capabilities**. Owner
Goals route early work; Repository Goals keep the repository organized and
improving. **Indexing** and search maps reduce orientation cost;
**CapabilityHarmonize** lets peer repositories contribute to a continuously
improving, enlarging Capability and Skill set.

A Capability may later own one or more **Skills** when a deterministic,
repeatable part of the Capability becomes executable. Skills are subordinate to
Capabilities; they do not create a new planning tier.

## Owner Goal Operating Loop

Owner Goals are achieved through **repeated cycles**, not a single pass:

```text
Ideas → Plans → Work → Outcome → closer to Owner Goals → (repeat)
→ some Owner Goals realized → more realized → Primary Owner Goal achieved
```

Repeat work becomes **Capabilities** (and optional **Skills**), lowering
friction on each lap. Outcomes count only when **disk matches the claim**.

User-facing diagram and walkthrough:
[OwnerGoalOperatingLoop.md](../Capabilities/GettingStarted/OwnerGoalOperatingLoop.md).
Current goals register: [Workspace/OwnerGoals.md](../Workspace/OwnerGoals.md).

## Formal Term Guidance

Use these as formal repository terms with different weights. This keeps the
model useful without making every thought into a Capability.

| Term | Formality | Guidance |
| --- | --- | --- |
| Goals | Strong formal term | Umbrella term for what matters. Use **Repository Goals** for the core durable set; **Owner Goals** for the owner's practical outcomes. |
| Repository Goals | Strong formal term | Core north-star outcomes for the learning repository. Source: `Plans/RepositoryGoals.md`. |
| Owner Goals | Medium formal term | Three to five practical outcomes the owner wants from setup; captured in **Quick Startup**, refined as they work. Not stored in Capability files. |
| Idea | Light formal term | One tracked possibility—not yet a Plan. Register row in `Plans/Ideas.md`. |
| Ideas | Light formal term | The folder (`Ideas/`), register file (`Plans/Ideas.md`), and collective layer for possibilities. |
| Plans | Medium formal term | Structured path from selected Ideas toward Owner Goals and Repository Goals. |
| Capabilities | Strong operational term | Reusable operational knowledge that should be registry-routable. |
| Skills | Strong operational term (subordinate) | Optional executable packages owned by a Capability; discover via `Capabilities/SkillRegistry.md`. |

Prefer **Repository Goals** when referring to the formal north-star file.
Use **Goals** when describing the full chain (Goals → Ideas → Plans → …).
Use **Owner Goals** for owner-specific outcomes from Quick Startup.
Use **Idea** for a single entry; use **Ideas** for the register or folder.

## Term Definitions

| Term | Definition |
| --- | --- |
| Goals | What matters—split into Repository Goals (core durable set) and Owner Goals (owner's practical outcomes). |
| Repository Goals | Durable outcomes the learning repository is trying to achieve. Source: `Plans/RepositoryGoals.md`. |
| Owner Goals | Practical outcomes the owner wants from setup (for example website, leads, credibility). Captured in Quick Startup; refined as the owner works. |
| Idea | One tracked possibility, improvement, insight, or future work that is not yet a Plan. Lives as a row in `Plans/Ideas.md` when mature enough to track. |
| Ideas | The collective register and folder layer for possibilities (`Plans/Ideas.md`, `Ideas/`). Raw capture may start in `Ideas/FutureIdeas.md`. |
| Plans | Structured approaches for moving selected Ideas toward Owner Goals and Repository Goals. Plans may create one-time work, decisions, drafts, tasks, prompts, or candidate Capabilities. |
| Capabilities | Reusable units of operational knowledge that help the repository perform repeated work. |
| Skills | Optional executable packages subordinate to a Capability; enlarge the shared set when a repeatable path benefits from a `SKILL.md` package. |

## Placement Model

Active **GetEstablished** clean-root homes (2026-06-04):

| Information type | Active home | Notes |
| --- | --- | --- |
| Repository Goals | `Plans/RepositoryGoals.md` | Core durable Goals set for the learning repository. |
| Owner Goals | Quick Startup capture; `Workspace/OwnerGoals.md` when durable | First captured in `Capabilities/GettingStarted/`; refined as owner works. |
| Quick Startup | `Capabilities/GettingStarted/` | First-session path: orient, capture Owner Goals, route next task. |
| Idea (tracked) | `Plans/Ideas.md` | One row per mature possibility; promotes to Plans or Capabilities. |
| Ideas (folder) | `Ideas/` | Curated capture area; see `Ideas/README.md`. |
| Ideas (raw) | `Ideas/FutureIdeas.md` | Low-friction parking lot feeding `Plans/Ideas.md`. |
| Plans | `Plans/` | Structured work, reviews, backlog, maps, preserved prompts. See `Plans/README.md`. |
| Capabilities | `Capabilities/<CapabilityName>/` | Registry: `Capabilities/README.md`; routing: `Capabilities/AgentCapabilityGuide.md`. |
| Skills | `Capabilities/<CapabilityName>/Skills/<SkillName>/` | Optional; discover via `Capabilities/SkillRegistry.md`. No root Skills migration approved. |
| Agent search / boot | `Plans/RepositorySearchMap.md` | Stable map for placement and Capability routing. |
| Navigation indexes | `Indexes/` when provisioned | Refresh via **Indexing** Capability; metadata per `Standards/MarkdownIndexMetadataStandard.md`. |
| Open questions | `Plans/OpenQuestions.md` | Non-blocking owner decisions. |
| Standards | `Standards/` | Cross-cutting rules agents follow across folders. |
| Owner working files | `Workspace/` | Project-specific; not reusable Capabilities. |
| Housekeeping notes | `Plans/` or `Archive/` | Log confusion and proposed moves; see `Plans/PlansFolderCleanupActivePlan.md`. |

Historical **GetEstablishedOnTheWeb** paths (`Docs/Project`, `Docs/Capabilities`,
etc.) appear in older Plans files and in `Intake/GetEstablishedOnTheWeb/`.
Do not use them as write destinations in the active repository.

Owner-specific goals, ideas, and plans belong in `Owner/` or in the planning
area of a commissioned repository. They should not be stored inside reusable
Capability modules unless they are short examples or pointers.

## Promotion Guidance

Runnable artifacts: [PromotionChecklist.md](../Standards/PromotionChecklist.md),
[IdeaCaptureTemplate.md](../Standards/IdeaCaptureTemplate.md),
[PlanTemplate.md](../Standards/PlanTemplate.md),
[ArchiveAndDeprecationRules.md](../Standards/ArchiveAndDeprecationRules.md).
Capture workflow: [InstructionCapture](../Capabilities/InstructionCapture/README.md).

### Idea Becomes Plan

Promote an Idea into a Plan when:

- It supports a Repository Goal.
- It has enough shape to act on.
- It needs steps, decisions, or sequencing.

The output is usually a focused planning file in `Plans/`, a backlog
item, or a worker prompt.

### Plan Becomes Capability Candidate

Not every Plan becomes a Capability. A Plan may end in a one-time edit, a
decision, a draft, a backlog item, a review, a documentation update, or a
prompt.

Promote a Plan into a Capability candidate when all of these hold (codified
rule, resolved 2026-05-28):

- **Repeatable:** the same kind of task recurs. Repetition is the main
  detection signal - when an agent notices it is doing the same task again,
  that is a candidate Capability.
- **Reusable:** future agents or repositories could reuse it.
- **Worth routing:** it should be discoverable in the Capability registry.

Supporting indicator: it needs rules, prompts, examples, or setup guidance.

Use **CapabilityCreate** for this promotion only when the workflow is
repeatable, reusable, and worth routing through the Capability registry. Do not
put owner information, content drafts, inbox files, or broad planning notes
inside the Capability.

### Capability Becomes Active

Make a Capability Active when:

- It has a clear purpose.
- It has an entry prompt or procedure.
- It has rules or guardrails as needed.
- It is registered and routable.

Active Capabilities should live under `Capabilities/<CapabilityName>/`
and be discoverable through `Capabilities/README.md` and, when useful,
`Capabilities/AgentCapabilityGuide.md`.

### Capability Gains A Skill

Add a Skill only when a Capability has a deterministic, repeatable execution
path that benefits from a `SKILL.md` package. The Capability keeps governing
the purpose, rules, tier, provisioned structure, and data boundaries.

Skill addition rules:

- Keep the canonical Skill under the owning Capability.
- Add or update `Capabilities/SkillRegistry.md`.
- Do not add runtime adapter folders until a runtime is adopted.
- Do not add scripts, generated indexes, or helper folders unless the Skill's
  scoped task or `SetupPrompt.md` approves them.

## Example From CapabilityDefinition

| Stage | Example |
| --- | --- |
| Idea | Define what a Capability means. |
| Plan | Create a CapabilityDefinition plan and decide where the files belong. |
| Capability | `Capabilities/CapabilityDefinition/`. |
| Repository Goal | Make the repository easier for agents and humans to understand, extend, and reuse. |

The important lesson is separation: the Capability defines reusable operational
knowledge, while owner facts, content files, inbox files, and planning decisions
stay in their own repository areas.

## Commissioned Repositories

Commissioned repositories (such as US1Movers) inherit this same
Goals-Ideas-Plans-Capabilities model. The difference is ownership and location:

- Their **Repository Goals**, **Ideas**, and **Plans** are owner- and
  business-specific and live in the commissioned repository's own project and
  owner areas, not in the parent template.
- **Universal Capabilities** flow down from the parent template; **Commissioned**
  Capabilities are specific to that repository. See
  `Standards/RepositoryArchetypeAndCapabilityTiers.md`.

Keep owner-specific goals, ideas, and plans out of reusable Capability modules
except as short examples or pointers.

## Indexing For Agent Efficiency

Repository Goals, Ideas, Plans, Capabilities, and Skills should stay **easy for
agents to find**:

- **Search maps:** `Plans/RepositorySearchMap.md`, `Plans/RepositoryMap.md`,
  and boot chain in `AGENTS.md`.
- **Registries:** `Capabilities/README.md`, `Capabilities/AgentCapabilityGuide.md`,
  `Capabilities/SkillRegistry.md`, and `Plans/Ideas.md`.
- **Metadata:** index frontmatter on durable files per
  `Standards/MarkdownIndexMetadataStandard.md`.
- **Navigation indexes:** when `Indexes/` is provisioned, refresh through the
  **Indexing** Capability without moving source material.

Indexing is not decoration—it reduces repeated orientation work and supports
Situational Awareness.

## Cross-Repository Harmonization

Like repositories (template hosts, commissioned repos, and peer projects) may
each improve the same Capability or Skill differently. Use **CapabilityHarmonize**
to compare versions, name strengths, and recommend best-of-both blends. Pair
with **RepositoryLearning** and **CapabilityAudit** when the goal is a
continuously improving, enlarging shared Capability and Skill set—not a one-time
copy.

Harmonization respects tier and ownership rules in
`Standards/RepositoryArchetypeAndCapabilityTiers.md`. Owner-specific Ideas and
Plans stay in the commissioned repository; universal improvements flow through
harmonize passes into the shared registry.

## Open Questions

- Resolved 2026-05-28: Repository Goals, Ideas, Plans, and Capabilities are
  formal repository terms, named in `Standards/NamingStandard.md` (Core
  Planning Terms) with this model and the source files as their definitions.
- Resolved 2026-05-28: Repository Goals now have a dedicated source-of-truth
  file at `Plans/RepositoryGoals.md`.
- Resolved 2026-05-28: Ideas now have a dedicated tracked register at
  `Plans/Ideas.md`. `Ideas/FutureIdeas.md` remains the
  low-friction raw parking lot that feeds it.
- Resolved 2026-05-28: A Plan is promoted into **CapabilityCreate** when the
  work is repeatable (recurs), reusable by future agents or repositories, and
  worth routing through the registry. See Plan Becomes Capability Candidate.
- Resolved 2026-05-28: Commissioned repositories inherit this model; see
  Commissioned Repositories above.
- Resolved 2026-05-30: Capabilities may own optional Skills as an executable
  implementation layer. Skills are subordinate to Capabilities and are
  discovered through `Capabilities/SkillRegistry.md`.

No open questions remain for this model. Keep using the placement model above
until a future standards pass proposes a change.

## Related

- [RepositoryGoals.md](RepositoryGoals.md)
- [Ideas.md](Ideas.md)
- [IdentityAndMission.md](IdentityAndMission.md)
- [PrimeExamplePlan.md](PrimeExamplePlan.md)
- [Roadmap.md](Roadmap.md)
- [RepositoryOrganizationPlan.md](RepositoryOrganizationPlan.md)
- [OpenQuestions.md](OpenQuestions.md)
- [../Ideas/FutureIdeas.md](../Ideas/FutureIdeas.md)
- [../Capabilities/CapabilityHarmonize/README.md](../Capabilities/CapabilityHarmonize/README.md)
- [../Capabilities/Indexing/README.md](../Capabilities/Indexing/README.md)
- [../Capabilities/CapabilityDefinition/README.md](../Capabilities/CapabilityDefinition/README.md)
- [../Capabilities/CapabilityCreate/README.md](../Capabilities/CapabilityCreate/README.md)
