# Feature Session

> Manages persistent session memory files per Asana task. Use when the user says "start session GC-123", "update session GC-123", "close session GC-123", "show session GC-123", or "list sessions". Files live at repo root and are safe to commit. Multiple team members can load the same session on their own machines. Session memory is opt-in per feature — not automatic.

- Skill: `miguelpecegueiro/feature-session` (Agent Skill)
- Install (CLI): `npx skillmds@latest add miguelpecegueiro/feature-session`
- Raw SKILL.md: https://api.skillmd.com/api/skills/miguelpecegueiro/feature-session/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: MiguelPecegueiro (https://skillmd.com/u/miguelpecegueiro)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/miguelpecegueiro/feature-session

---


# Feature Session

Persistent session memory tied to an Asana task ID. One file per feature.
Safe to commit. Never contains credential values — Key Vault names and DB
schema references only.

## File format

Files are named `SESSION_GC-{id}.md` and live at the repo root.

```markdown
# SESSION_GC-{id}

**Asana task:** GC-{id}
**Status:** IN PROGRESS | CLOSED
**Last updated:** YYYY-MM-DD HH:MM

## What this feature does
[One paragraph — what is being built and why]

## Decisions locked
- [Decision 1]
- [Decision 2]

## What has been done
- [Completed step 1]
- [Completed step 2]

## What is pending
- [Next step 1]
- [Next step 2]

## Blockers
- [Blocker if any, or "None"]

## Key references
- Files touched: [list]
- DB tables/schemas: [list — names only, no values]
- Key Vault secret names: [list — names only, no values]
- Confluence pages: [links if relevant]
```

---

## Commands

### START — `start session GC-123`
Triggered by: "start session GC-123", "open session for GC-123", "new session GC-123"

1. Check if `SESSION_GC-123.md` already exists at repo root
2. If it exists, load it and tell the user — do not overwrite
3. If it does not exist, ask the user:
   - What is this feature building?
   - Any decisions already locked?
4. Create the file with all sections populated from the answer
5. Confirm: "Session GC-123 started. File at SESSION_GC-123.md"

---

### UPDATE — `update session GC-123`
Triggered by: "update session GC-123", "save session GC-123", at natural pause
points during complex work when significant progress has been made.

**ID is required.** If the user says "update session" without an ID and multiple
session files exist, ask which one. If only one exists, use it.

1. Read the current `SESSION_GC-123.md`
2. Based on what has happened in the conversation since the last update:
   - Move completed items from "pending" to "done"
   - Add new pending steps if identified
   - Add any new decisions locked
   - Update blockers
   - Update "last updated" timestamp
3. Write the updated file
4. Confirm: "Session GC-123 updated."

Do not ask the user to narrate what changed — infer it from the conversation.

---

### CLOSE — `close session GC-123`
Triggered by: "close session GC-123", "finish session GC-123", "done with GC-123"

1. Read the current `SESSION_GC-123.md`
2. Set status to CLOSED
3. Fill in "What has been done" completely
4. Clear "What is pending" — if there are unresolved items, move them to a
   "Residual / carry-forward" section
5. Clear "Blockers" or mark as resolved
6. Write the final file
7. Confirm: "Session GC-123 closed. FILE: SESSION_GC-123.md"

---

### SHOW — `show session GC-123`
Triggered by: "show session GC-123", "what's in session GC-123", "load session GC-123"

1. Read `SESSION_GC-123.md`
2. Print the full contents in chat
3. No edits

---

### LIST — `list sessions`
Triggered by: "list sessions", "what sessions are open", "show all sessions"

1. Scan repo root for all files matching `SESSION_GC-*.md`
2. For each file, read the Status and Last updated fields
3. Output a table:

```
ID          Status       Last updated
GC-123      IN PROGRESS  2026-05-10 14:30
GC-115      CLOSED       2026-04-22 09:00
```

---

## Rules

- Never store credential values, passwords, tokens, or connection strings
- Key Vault secret names are fine (e.g. `Endesa--ApiKey`) — values are not
- DB schema references are fine (e.g. `endesa.ContractosAtivos`) — data is not
- Session files are safe to commit and should be committed alongside feature work
- One session per Asana task — if a task spawns subtasks, use the parent ID