# Chart Course

> Interactive strategic compass builder. Guides the user through mapping all possible project directions with progressive codebase analysis, web research, and architectural diagrams at every step. Produces a machine-readable compass document for downstream alignment tracking.

- **Type:** Skill
- **Install:** `agentstack add skill-talont-org-autoskillit-chart-course`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [TalonT-Org](https://agentstack.voostack.com/s/talont-org)
- **Installs:** 0
- **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [TalonT-Org](https://github.com/TalonT-Org)
- **Source:** https://github.com/TalonT-Org/AutoSkillit/tree/main/.claude/skills/chart-course

## Install

```sh
agentstack add skill-talont-org-autoskillit-chart-course
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Chart Course — Interactive Strategic Compass Builder

## When to Use

- Starting a new project phase and mapping all possible directions
- Project has grown enough that strategic coherence needs explicit tracking
- Understanding how near-term work relates to long-term options
- Updating an existing compass after significant project changes
- Preparing for a planning session and need a current landscape assessment

This is an **interactive** skill. The user provides vision and priorities;
the skill provides codebase analysis, external research, and visualization.
The compass is built collaboratively through conversation, not generated
autonomously.

## Arguments

```
/chart-course {focus_or_question} [compass_path=]
```

- `{focus_or_question}` — Required. A broad strategic question or focus area.
  Examples: "Map all possible directions for the research platform",
  "What are our options for distributed compute?",
  "Where should we invest for compliance readiness?"
- `compass_path=` — Optional. Path to an existing compass document.
  When provided, the skill loads the existing compass as the starting point
  and the conversation focuses on updating, adding, or retiring directions.

### GitHub Issue Detection

Scan ARGUMENTS for GitHub issue references (full URL, `owner/repo#N`, bare `#N`).
If detected, call `fetch_github_issue(issue_url, include_comments: true)` and
incorporate the issue content as additional strategic context.

## Critical Constraints

**NEVER:**
- Modify any source code files — this is a read-only analysis skill
- Create files outside `{{AUTOSKILLIT_TEMP}}/chart-course/`
- Dismiss directions the user raises — every direction gets honest assessment
- Use implementation difficulty as a reason to exclude a direction
- Include cost estimates or timelines — map what IS, not what it costs
- Skip diagrams — progressive visualization is the core value of this skill
- Generate the compass document without user review and approval
- Write the final compass to disk until the user confirms (plan-apply pattern)
- Proceed past a checkpoint without user response

**ALWAYS:**
- Use `model: "sonnet"` for all Task tool subagent calls
- Initialize code-index via `set_project_path` before exploration (Phase 1)
- Ask the user before moving to the next phase
- Generate at least one diagram per direction explored
- Ground readiness assessments in actual file paths, protocols, and code patterns
- Include source URLs for all external research claims
- Invoke arch-lens and mermaid skills via the Skill tool (see Skill Loading Checklist)
- Emit output tokens as literal plain text at the end (no markdown formatting on token names)

## Skill Loading Checklist

When generating architectural diagrams at any point during the conversation:
- [ ] Determine which arch-lens best fits the aspect being visualized
- [ ] LOAD the corresponding `/autoskillit:arch-lens-*` via the Skill tool
- [ ] The arch-lens skill will LOAD `/autoskillit:mermaid` for styling
- [ ] Diagram uses ONLY classDef styles from the mermaid skill (no invented colors)
- [ ] Color legend table included
- [ ] Every new or proposed component is wired into the call chain

If the Skill tool cannot invoke a sub-skill (disable-model-invocation or
unavailable), produce the diagram directly using mermaid syntax with the
standard classDef palette and note the fallback.

For custom diagrams not covered by an arch-lens (timelines, dependency
graphs, comparison matrices), LOAD `/autoskillit:mermaid` directly via
the Skill tool and produce the diagram using its styling conventions.

## Workflow

The workflow is organized into phases. Each phase ends with a user
checkpoint. Do not proceed to the next phase until the user responds.

---

### Phase 1: Codebase Survey (automated)

#### Step 1.1: Code-Index Initialization

```
mcp__code-index__set_project_path(path="{PROJECT_ROOT}")
```

Fall back to native Glob/Grep if unavailable.

#### Step 1.2: Load Existing Compass (if compass_path provided)

If `compass_path` was provided:
1. Verify file exists with Glob
2. Read the document
3. Extract the `---compass-data---` YAML block
4. Parse existing directions — these become the baseline
5. Present to user: "Found existing compass with N directions. I'll
   re-evaluate each against the current codebase."

#### Step 1.3: Launch Parallel Exploration Subagents

Launch ALL concurrently in a single message. Every subagent uses `model: "sonnet"`.

**Subagent A: Architecture & Extension Points**
Explore protocol definitions, plugin points, layering (L0/L1/L2/L3),
TODO/PLANNED/FIXME comments, stub implementations, and configuration
points. Return: extension points with file paths and what capability
each is designed to support.

**Subagent B: Current Capability Inventory**
Catalog all MCP tools, skills (by tier and category), recipes, hooks,
CLI commands, and run_python callables. Note dependencies between them.
Return: structured capability list.

**Subagent C: Growth Limitations & Technical Debt**
Find hardcoded values, platform assumptions, scaling bottlenecks, tight
coupling, missing abstractions, and test gaps. Return: categorized
limitations with which areas of growth they would affect.

**Subagent D: External Landscape Research (Web Search)**
Research the domain indicated by `focus_or_question`: competitors,
adjacent tools, industry trends, emerging standards, regulations.
Return: landscape summary with source URLs.

**Subagent E: Dependency & Coupling Map**
Map import graph between top-level packages, co-change coupling from
git history, cross-layer violations, circular dependencies.
Return: dependency map with coupling scores.

**Subagent F: Existing Strategic Context**
Search `{{AUTOSKILLIT_TEMP}}/` and `docs/` for existing strategy docs,
research reports, roadmaps. Read last 50 git commits for thematic
patterns. Check GitHub issues for strategic labels.
Return: summary of existing context and themes.

**Additional subagents** may be launched for any other dimensions the
focus question or codebase warrants. The above are the mandatory minimum.

#### Step 1.4: Present Initial Landscape

After all subagents complete, synthesize findings into a concise briefing:

1. **Architecture snapshot** — key layers, extension points, what's flexible
   vs. rigid. Generate a **C4 Container diagram** using:
   ```
   LOAD /autoskillit:arch-lens-c4-container via Skill tool
   ```

2. **Capability map** — what the project can do today

3. **Growth edges** — where the architecture is designed for extension
   vs. where it would resist change. Generate a **Module Dependency diagram**:
   ```
   LOAD /autoskillit:arch-lens-module-dependency via Skill tool
   ```

4. **External landscape highlights** — what others are doing, key trends

5. **Existing strategic context** — what prior work tells us about direction

#### Checkpoint 1

Present the landscape briefing with both diagrams and ask:

> "Here's where the project stands architecturally. What directions are
> you thinking about? What's your vision for where this could go?
> I'll analyze each direction you describe against the codebase."

Wait for user response before proceeding.

---

### Phase 2: Direction Exploration (interactive loop)

This phase repeats for each direction the user describes. The user may
describe one direction at a time or several at once.

#### Step 2.1: Capture the Direction

From the user's description, extract:
- A short name for the direction
- What it would entail (capability, architecture change, domain expansion, etc.)
- Any stated dependencies or prerequisites

#### Step 2.2: Analyze Fit

For each direction, launch targeted analysis:

**Subagent: Codebase Fit Analysis** (`model: "sonnet"`)
- Where in the architecture would this connect?
- What existing protocols, abstractions, or extension points support it?
- What would need to change to accommodate it?
- What existing capabilities does it build on?
- What would it conflict with or make harder?

**Subagent: External Research** (`model: "sonnet"`, web search)
- How do other projects in this space handle this?
- Are there standards, libraries, or patterns to adopt?
- What pitfalls have others encountered?

Launch additional subagents as needed for any other aspects the direction
requires — regulatory implications, performance profiling, integration
patterns, etc.

#### Step 2.3: Generate Direction Diagram

Select the most appropriate arch-lens for this direction and LOAD it:

| Direction type | Arch-lens to use |
|----------------|------------------|
| New execution path or workflow | `arch-lens-process-flow` |
| Data pipeline or storage | `arch-lens-data-lineage` |
| New module or component | `arch-lens-c4-container` |
| API or integration boundary | `arch-lens-security` |
| Parallel execution / scaling | `arch-lens-concurrency` |
| Infrastructure / deployment | `arch-lens-deployment` |
| State management / lifecycle | `arch-lens-state-lifecycle` |
| Error handling / resilience | `arch-lens-error-resilience` |
| Developer tooling / CI | `arch-lens-development` |
| Operational / monitoring | `arch-lens-operational` |
| Data access patterns | `arch-lens-repository-access` |
| Cross-component scenarios | `arch-lens-scenarios` |
| Coupling / dependency | `arch-lens-module-dependency` |

Mark proposed/new components distinctly in the diagram (use the `newComponent`
classDef from the mermaid skill palette and the `★` symbol).

If the direction involves experimental or research aspects, also consider
loading an appropriate exp-lens for dimensional analysis.

#### Step 2.4: Present Direction Analysis

Present to the user:
1. **Fit assessment** — how this direction connects to existing architecture
2. **Readiness score** — ready / partial / planned / concept, with evidence
3. **Architecture diagram** — showing where this plugs in (new components highlighted)
4. **External landscape** — what others do, relevant standards
5. **Dependencies** — what must exist first
6. **Tensions** — what this would make harder or conflict with

#### Step 2.5: Refine with User

Ask:

> "Here's how [direction name] would fit. Does this match your thinking?
> Any aspects I should dig deeper into? Or shall we explore the next direction?"

The user may:
- Refine the direction (re-analyze with updated description)
- Ask to dig deeper into a specific aspect (launch focused subagents)
- Ask for additional diagrams from different perspectives
- Move to the next direction
- Go back and revise a previous direction

Adapt to whatever the user needs. Repeat Steps 2.1–2.5 for each new direction.

#### Checkpoint 2

After the user has described all directions they want to explore (or says
they're ready to proceed), ask:

> "We've explored N directions so far. Ready for me to map the
> relationships between them — what enables what, what conflicts,
> and where the strategic fork points are?"

Wait for user response.

---

### Phase 3: Relationship Mapping (automated with user review)

#### Step 3.1: Build Direction Catalog

From all explored directions, compile the full catalog. For each direction:

| Field | Source |
|-------|--------|
| `id` | Assign `D{NNN}` IDs (preserve existing IDs in update mode) |
| `name` | From user description (confirmed in Phase 2) |
| `category` | One of: `architecture`, `capability`, `domain-expansion`, `compliance`, `performance`, `developer-experience`, `integration`, `infrastructure` |
| `description` | 2-3 sentences from Phase 2 analysis |
| `readiness` | `ready` / `partial` / `planned` / `concept` — from Phase 2 fit assessment |
| `readiness_evidence` | Specific file paths and code patterns from Phase 2 |
| `dependencies` | Direction IDs that must come first |
| `enables` | Direction IDs that become easier after this |
| `conflicts` | Direction IDs that become harder after this |
| `signals` | Files, grep patterns, modules relevant to this direction |
| `priority` | `high` / `medium` / `low` / `exploratory` — ask user if not clear |

#### Step 3.2: Map Dependencies and Conflicts

For each pair of directions, assess:
- Does pursuing A make B easier? (enables)
- Does pursuing A require B first? (depends-on)
- Does pursuing A make B harder? (conflicts)

Use codebase evidence — shared protocols, module boundaries, test
infrastructure, configuration coupling.

#### Step 3.3: Generate Path Dependency Graph

LOAD `/autoskillit:mermaid` via the Skill tool and produce a custom
flowchart showing all directions and their relationships:

- **Nodes** = directions, colored by readiness (ready=green, partial=yellow,
  planned=blue, concept=gray)
- **Green solid edges** = enables
- **Blue dashed edges** = depends-on
- **Red dotted edges** = conflicts
- Label each node with ID + short name

Annotate the diagram with:
- **Bottleneck directions** — high fan-out of enables edges (mark with `★`)
- **Fork points** — conflicting direction pairs (mark with `⚡`)
- **Clusters** — mutually-reinforcing groups (visual grouping via subgraph)

#### Step 3.4: Generate Timeline / Sequencing Diagram

LOAD `/autoskillit:mermaid` via the Skill tool and produce a Gantt-style
or swim-lane diagram showing a natural sequencing of directions based on
dependency order:

- Foundations first (directions others depend on)
- Independent directions shown in parallel
- Late-stage directions that depend on many prerequisites shown last
- Fork points shown as decision nodes

This is NOT a timeline with dates — it is a dependency-ordered sequence
showing what COULD come before what.

#### Step 3.5: Present Relationship Map

Present to the user:
1. **Direction catalog table** — all directions with readiness and priority
2. **Path dependency graph** — mermaid diagram
3. **Sequencing diagram** — dependency-ordered view
4. **Bottleneck analysis** — which directions unlock the most others
5. **Fork points** — where strategic choices must be made
6. **Cluster analysis** — groups of mutually-reinforcing directions

#### Checkpoint 3

Ask:

> "Here's how all the directions relate to each other. Do these
> relationships look right? Any dependencies or conflicts I missed?
> Any priorities you want to adjust before I assemble the compass?"

Wait for user to review and confirm or request adjustments.
If adjustments needed, revise and re-present.

---

### Phase 4: Current Trajectory Assessment

#### Step 4.1: Analyze Recent Work

Using git log and any available PR/issue data:
1. Read last 30-50 commits
2. Map commits to directions (which directions does recent work advance?)
3. Identify drift — work that moves away from stated priorities
4. Identify any inadvertent path narrowing

#### Step 4.2: Generate Trajectory Overlay

LOAD `/autoskillit:mermaid` via the Skill tool and produce a variant of
the path dependency graph with trajectory annotations:

- Directions being actively advanced: bold border
- Directions with no recent movement: dashed border
- Directions being drifted from: red highlight

#### Step 4.3: Present Trajectory

Present the trajectory assessment with the annotated diagram and a brief
narrative about where the project is currently headed vs. where the
compass says it could go.

#### Checkpoint 4

Ask:

> "This is where recent work has been heading. Ready for me to
> assemble the full compass document?"

---

### Phase 5: Compass Assembly (plan-apply pattern)

#### Step 5.1: Draft the Compass

Assemble the full compass document in memory with these sections:

1. **Strategic Focus** — the question that drove this compass
2. **Executive Summary** — 3-5 bullets on current state + trajectory
3. **Direction Catalog** — full table + detailed per-direction subsections
4. **Path Dependency Graph** — mermaid diagram from Phase 3
5. **Sequencing Diagram** — from Phase 3
6. **Trajectory Overlay** — from Phase 4
7. **Cluster Analysis** — mutually-reinforcing direction groups
8. **Fork Points** — strategic choices requiring decisions
9. **Bottleneck Directions** — high-leverage unlock points
10. **Current Traject

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [TalonT-Org](https://github.com/TalonT-Org)
- **Source:** [TalonT-Org/AutoSkillit](https://github.com/TalonT-Org/AutoSkillit)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-talont-org-autoskillit-chart-course
- Seller: https://agentstack.voostack.com/s/talont-org
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.