Feature Tracking

Overview

Feature Tracking maintains lightweight, repository-native memory for long-lived feature work. It gives AI coding agents a stable place to find the current status, authoritative documents, verified behavior, durable decisions, risks, and recent changes without treating chat history or stale plans as truth.

The workflow uses a global index plus one Markdown track per feature under docs/features/. It complements issue trackers, specifications, and source code by linking the evidence that still matters rather than duplicating it.

When to Use This Skill

• Use when starting or resuming work on a feature after a session, agent, or tool change.
• Use when feature knowledge is scattered across PRDs, API notes, plans, issues, and old commits.
• Use when a long-lived feature needs durable decisions, risks, rollout constraints, or migration notes.
• Use when reviewing or finishing feature work and recording the verified outcome for future agents.
• Use when adopting lightweight project memory in an existing repository without reorganizing all documentation.

Do not use this skill merely to log every code edit or replace an existing issue tracker. Use it when future contributors need a concise, current view of an entire feature.

How It Works

Step 1: Discover Existing Feature Memory

Before changing a feature:

1. Read docs/features/README.md if it exists.
2. Identify the feature id from the request, code module, route, domain, or existing documentation.
3. Read docs/features/<feature-id>/README.md if it exists.
4. Follow its current source-of-truth links before proposing or implementing changes.

Never assume an old plan is authoritative merely because it is detailed. Prefer current code, tests, accepted specifications, and recent verified decisions.

Step 2: Create the Minimal Structure When Missing

Use lowercase hyphen-case for feature ids:

docs/features/
├── README.md
└── <feature-id>/
    ├── README.md
    ├── prd/
    ├── api/
    ├── plans/
    └── archive/

For an existing repository, create only the directories needed now. Link useful documents where they already live before considering a migration.

The global index should remain a compact navigation and status surface:

# Feature Tracks

| Feature | Status | Track | Source of Truth | Updated | Notes |
|---|---|---|---|---|---|
| Checkout | active | `checkout/README.md` | `checkout/prd/checkout.md` | 2026-07-13 | Payment retry work in progress |

Use project-local status names when the repository already defines them. Otherwise prefer a small vocabulary such as planned, active, stable, paused, or deprecated.

Step 3: Maintain the Feature Track

Each docs/features/<feature-id>/README.md should summarize current truth and link to detailed evidence:

# Checkout Feature Track

## Current Status

Checkout supports one-time card payments. Automatic payment retry is in progress.

## Source of Truth

- Checkout PRD: `prd/checkout.md`
- Payments API: `api/payments.md`
- Current implementation plan: `plans/payment-retry.md`

## Current Behavior

- Customers can complete one-time card payments.
- Failed payments currently require a manual retry.

## Decisions

- Preserve idempotency keys across automatic retries.
- Keep retry policy in the payments service.

## Known Risks

- The provider sandbox does not reproduce every production decline code.

## Changelog

- 2026-07-13: Added the retry plan and recorded idempotency requirements.

Update the track when any of these change:

• user-visible or system-visible behavior,
• endpoints, data models, dependencies, or integrations,
• durable decisions and trade-offs,
• rollout constraints, migrations, risks, or follow-ups,
• tests, plans, specifications, or other source-of-truth links.

Keep detailed requirements and designs in their own documents. The feature track should explain what is true now and where to find the proof.

Step 4: Reconcile the Track Before Completion

Before claiming the feature work is complete:

1. Update the feature track with the actual verified outcome, not only the intended plan.
2. Update the global index when status, date, links, or notes changed.
3. Check that every relative Markdown link resolves.
4. Confirm the track contains current status, source-of-truth links, decisions, risks, and a dated changelog.
5. Record unresolved blockers or follow-ups explicitly.

…