<!--
IndexTitle: Repository Goals
IndexDescription: Core durable Goals set for the GetEstablished learning repository.
IndexType: Project
IndexStatus: Active
LastEdited: 2026-06-09
-->

# Repository Goals

This file is the single source of truth for **Repository Goals**: the core,
durable **Goals** set for this **learning repository**.

**Goals** is the first formal repository term. **Repository Goals** (this file)
define how GetEstablished stays organized, indexed, and reusable. **Owner
Goals** are the owner's practical outcomes—captured in **Quick Startup**
(`Capabilities/GettingStarted/`), refined in `Workspace/OwnerGoals.md`, and
kept separate from this file.

See [GoalsIdeasPlansCapabilitiesModel.md](GoalsIdeasPlansCapabilitiesModel.md)
for how Goals, Ideas, Plans, and Capabilities relate. These goals are durable,
not a task list. Phase work lives in [Roadmap.md](Roadmap.md); current tasks
live in [AgentTaskBacklog.md](AgentTaskBacklog.md).

## North Star

GetEstablished should remain a lightweight, **indexed learning repository**
that helps the owner achieve **their goals** through Quick Startup and
`Workspace/OwnerGoals.md`, provides the **easiest path** to capture **Ideas**,
turn them into **Plans**, and carry selected work through to implemented
outcomes, **learns** repeatable work into Capabilities and Skills, **indexes**
Goals through Skills for agent efficiency, **harmonizes** with like
repositories to enlarge the shared set, and **orients** every pass with
Situational Awareness. Owner Goals route early work; Repository Goals keep the
repository itself honest and reusable.

## Goals

### 1. Help the owner define and refine Owner Goals

Make **Quick Startup** the default first path. Capture three to five Owner
Goals, route the next task from them, and keep a durable register at
`Workspace/OwnerGoals.md` (owner-owned—not in Capabilities or Repository
Goals). Welcome beginners with a read-first path (`GettingStarted`, `README.md`,
`Plans/RepositorySearchMap.md`) before expertise is required. Refine Owner
Goals as work progresses without merging them into Repository Goals.

**Environment-adaptive, GitHub-primary collaboration:** The repository adapts
to the owner's device and comfort; GitHub is the universal collaboration
surface; local clone is optional; instructions follow **device-appropriate
paths**. Terminology:
[NamingStandard.md](../Standards/NamingStandard.md) §Environment-Adaptive Model;
plan:
[CloudOnlyPlanningAndMeasurementDevicePlan.md](CloudOnlyPlanningAndMeasurementDevicePlan.md)
(Draft).

### 2. Capture Ideas before they are lost

Support low-friction capture from chat, notes, and mobile workflows into
`Ideas/` and `Plans/Ideas.md` through routable Capabilities such as
**ChatToMarkdown** and **ChatMemoryCapture**—without forcing premature Plans
or Capabilities.

### 3. Provide the easiest path from Ideas through Plans into reality

Shape selected **Ideas** into **Plans** and implement outcomes in the right
destination folders—`Capabilities/`, `Standards/`, `Content/`, `Workspace/`,
`Automation/`, and elsewhere—while keeping a clear trail from Idea to finished
work tied to **Owner Goals** and **Repository Goals**. Keep planning,
decisions, prompts, and workflow history in GitHub as the durable record, not
in chat alone.

### 4. Keep the owner in control

Favor small reviewable changes, clear handoffs, batched non-blocking questions
(`Plans/OpenQuestions.md`), and explicit stop conditions. Use AI as a practical
collaborator through clear prompts and routable Capabilities—the owner decides;
AI assists.

### 5. Orient agents quickly with Situational Awareness

At the start of every pass, recognize the active repository, task type,
connector or environment, and destination folder so agents spend less time
orienting and more time on useful work.

### 6. Index Goals, Ideas, Plans, Capabilities, and Skills for agent efficiency

Keep **Repository Goals**, the **Owner Goals** register, the Ideas register,
Plans, Capabilities, Skills, and search maps **optimally indexed**—consistent
metadata, registry files, and refresh through the **Indexing** Capability when
provisioned—so agents find the right context quickly instead of re-scanning the
tree each pass.

### 7. Learn workflows into Capabilities and Skills

When work repeats, capture durable lessons through **RepositoryLearning**,
Capability changelogs, and promotion guidance so the repository gets better at
routing and executing similar tasks over time—not by adding complexity for its
own sake, but by packaging what already proved useful into Capabilities and,
when appropriate, **Skills**.

### 8. Harmonize and serve as a template host for like repositories

Use **CapabilityHarmonize**, **RepositoryLearning**, and **CapabilityAudit** to
compare, blend, and adopt improvements from peer repositories so the shared
Capability and Skill set continuously improves and enlarges. Package universal
Capabilities and Standards so commissioned repositories can inherit them per
[RepositoryArchetypeAndCapabilityTiers.md](../Standards/RepositoryArchetypeAndCapabilityTiers.md)
without overwriting owner-owned content.

**Release core into the product repository:** Keep **GetEstablishedOnTheWeb**
current via documented core release passes
([GEOTWCoreReleaseWorkflow.md](GEOTWCoreReleaseWorkflow.md)). Website Markdown
and Phase 4 publishing are canonical on the product repo
(`C:\Repositories\GetEstablishedOnTheWeb`), not on this method host.

GEOTW public-site outcomes are executed on the product repository; this host
develops the shared method and Capabilities that feed it.

## Goal Boundaries

Repository-native boundaries—what this learning repository will not do
prematurely:

- Do not merge Owner Goals into Repository Goals or Capability files.
- Do not promote every Idea to a Plan or every Plan to a Capability.
- Do not add automation, Skills, or platform choices without a repeated need.
- Do not create large generated files that make the project harder to inspect.
- Do not add abstract strategy documents that do not guide future work.

### GEOTW outcome boundaries (when that track is active)

When the selected Owner Goal path includes GetEstablishedOnTheWeb public-site
work:

- No full website before the content plan is ready.
- No framework or platform choice before deployment needs are clear.

## How We Know It Is Working

- The owner can name Owner Goals and find the next task in one Quick Startup
  pass.
- Ideas land in the register without chat-only loss.
- Agents boot from `AGENTS.md` and the search map without re-deriving
  placement.
- Repeat work routes to a Capability; lessons appear in changelogs.
- Harmonize passes produce adopted improvements, not one-off reports.

## Related

- [GoalsIdeasPlansCapabilitiesModel.md](GoalsIdeasPlansCapabilitiesModel.md)
- [IdentityAndMission.md](IdentityAndMission.md)
- [Workspace/OwnerGoals.md](../Workspace/OwnerGoals.md)
- [Roadmap.md](Roadmap.md)
- [AgentTaskBacklog.md](AgentTaskBacklog.md)
- [GettingStarted Capability](../Capabilities/GettingStarted/README.md) — Quick Startup
- [OpenQuestions.md](OpenQuestions.md)
- [PrimeExamplePlan.md](PrimeExamplePlan.md) — GEOTW-era positioning; superseded by this file
