---
name: rsde-log
description: "This skill should be used when the user asks to log RS&DE work, documenter du travail R&D, ajouter une entrée RS&DE, créer un projet RS&DE, check rsde status, or mentions anything related to R&D tax credits, crédit d'impôt RS&DE, journal de bord, or T661. Also triggers when the user says 'rsde-log', 'rsde status', 'log R&D', or describes technical work they want documented for CRA purposes. Even if the user just says they worked on something technical and wants to track it — this skill applies."
---

# RS&DE Journal de Bord — Interactive Logging Skill

Guided interview for documenting RS&DE (SR&ED) R&D tax credit work. Captures daily/weekly work in a format that maps directly to the CRA's T661 form (lines 242, 244, 246).

## Before Starting

Read these to understand the file formats and CRA criteria:
- **`references/t661-structure.md`** — entry/project file formats, CRA tag definitions
- **CLAUDE.md** at the repo root — CRA guidelines overview

The reference report at the repo root (`reference/RT-2026-VF.pdf`) shows the target writing style — dense, technical French with specific metrics. Entries should build toward that quality level.

## Core Approach

The goal is to make logging feel like a casual conversation, not a bureaucratic form. The user just finished some R&D work and wants to capture it before it fades from memory. Your job is to draw out the CRA-relevant details through natural follow-up questions, then write a well-structured entry.

**Conversation style:**
- Ask one question at a time — logging should feel lightweight
- Match the user's language (if they write in English, converse in English) but write entries in French (matching the T661 report format)
- When the user gives a vague answer, ask a concrete follow-up rather than accepting it. "J'ai amélioré les résultats" → "De combien? Tu as des chiffres avant/après?"
- Be conversational, not interrogative. You're a colleague helping document work, not an auditor.

## Interview Flow

### 1 — Project Selection

Read existing projects from `projects/*/README.md`. Present the list and ask the user to pick a project or create a new one (use AskUserQuestion if available, otherwise ask conversationally).

**New project creation** — ask for:
1. Project title (descriptive, in French)
2. Technological objective (non-monetary — the CRA cares that the goal is advancing knowledge, not making money)
3. Start date (default: current month)
4. Linear project link (optional)

Create `projects/<slug>/README.md` with YAML frontmatter and `projects/<slug>/entries/` directory. See `references/t661-structure.md` for the exact format.

### 2 — Open-ended Context

Ask what they worked on — e.g. **"Sur quoi as-tu travaillé?"** (adapt to the user's language).

Let the user describe freely. This is where you listen and figure out what kind of work session this was, which determines which follow-up questions matter.

### 3 — Adaptive Follow-up Questions

Not every work session involves a full hypothesis-test-result cycle. Adapt based on the type of work described:

**Exploration / setup work** (setting up infrastructure, collecting data, building tooling):
- "Quel problème technique est-ce que ça prépare?"
- "Quelles sont les prochaines étapes?"
- Skip hypothesis/result questions — they don't apply yet

**Experimentation** (testing an approach, running benchmarks, comparing methods):
- "Quelle hypothèse as-tu testée?" — push for a clear, falsifiable statement
- "Comment as-tu testé? (méthode, nombre d'exécutions, conditions contrôlées)"
- "Quels résultats?" — push hard for numbers: percentages, latency, error rates, before/after comparisons
- "Validée ou rejetée?" — if rejected, this is gold for the CRA. Capture clearly what was tried and why it didn't work.

**Analysis / decision-making** (choosing between approaches, interpreting results):
- "Quelle décision technique as-tu prise et pourquoi?"
- "Quelles alternatives as-tu considérées?"
- "Quels critères ont guidé le choix?"

**Why the CRA cares about rejected hypotheses:** The CRA wants to see genuine experimentation where outcomes are uncertain. A project where everything works on the first try looks like routine engineering, not R&D. Rejected hypotheses prove real uncertainty existed. When the user mentions something that didn't work, dig into it — that's often the most valuable part of the entry.

**Why measurable results matter:** The reference report uses specific numbers throughout: "précision de base de 75 %", "passe de 76 % à 89 %", "entre 50 % et 60 %". Vague results ("it got better") weaken the claim. Always ask for the numbers, even rough ones.

### 4 — Hours and References

Ask about hours: **"Combien d'heures?"**

Then ask about linked references: **"Des issues Linear, PRs, ou commits liés?"** Accept "non" without pressing — this is optional context.

### 4.5 — Enrich from Issue Tracker (MCP)

When the user provides issue tracker links (Linear, GitHub, Jira, etc.), **use MCP tools to fetch issue details** before writing the entry. This provides richer context with minimal effort from the user.

**How to do it:**
1. When a Linear URL is provided (e.g. `https://linear.app/.../issue/E-4257/...`), extract the issue identifier (e.g. `E-4257`)
2. Use `ToolSearch` to find relevant MCP tools (e.g. `+linear get issue`) and fetch the issue details
3. Use the returned data (title, description, status, labels, assignee, related issues) to enrich the entry

**What to extract from issue tracker data:**
- **Issue title and description** — often contains technical context the user forgot to mention verbally
- **Labels/tags** — can indicate the type of work (bug, feature, infrastructure)
- **Status** — confirms the work is ongoing vs completed
- **Related/blocking issues** — reveals scope and dependencies worth mentioning in the entry

**Important:** The MCP-fetched data is supplementary. The user's verbal description takes priority — they know which details are CRA-relevant. Use the issue data to fill gaps, not to override what the user said.

**Fallback:** If no MCP tools are available for the user's issue tracker, just record the URLs as-is in the entry frontmatter. Don't ask the user to copy-paste issue descriptions manually.

### 5 — Write Entry

Based on the conversation:

1. **Select CRA tags** — see `references/t661-structure.md` for the full tag list. Apply tags based on what the conversation actually covered, not aspirationally.

2. **Write the entry** to `projects/<project>/entries/YYYY-MM-DD.md` (append `-2`, `-3` if an entry for today exists). Only include sections that are relevant — a setup session shouldn't have an "Hypothèse testée" section with filler.

3. **Writing quality matters.** Entries are raw material for the final T661 report. Write in the same register as the reference report: technical French, specific, citing concrete methods and metrics. Avoid filler and generalities.

   **Strong:** "L'hypothèse de validation des enregistrements MX pour filtrer les domaines invalides est testée. Les résultats montrent que plus de 99 % des domaines extraits sont déjà valides, rendant cette vérification non contributive à l'amélioration de la précision."

   **Weak:** "On a testé la validation MX. Ça n'a pas beaucoup aidé."

4. **Update `total_hours`** in the project's `README.md`.

5. **Display a summary:**
   - What was logged (1-2 sentence recap)
   - CRA tags applied
   - Cumulative hours for the project
   - Which T661 lines this entry feeds (242 = uncertainties, 244 = work done, 246 = advancements)
   - Coverage gaps: which CRA tags the project still lacks overall (check all existing entries). Flag missing `hypothese_rejetee` and `resultat_mesurable` specifically — these are the most common gaps.

## Status Mode

When the user asks for status ("rsde status", "état des projets"), read all projects and entries to build a dashboard:

**Per project:**
- Title, date range, total hours, number of entries
- CRA tag coverage as a checklist (which of the 10 tags have been covered across all entries)
- Missing tags highlighted, with actionable suggestions (e.g., "Aucune hypothèse rejetée documentée — lors de ta prochaine session, essaie de documenter une approche qui n'a pas fonctionné")

**Overall readiness:**
- For each project, estimate how well-covered lines 242, 244, 246 are based on existing entries
- Flag projects that need more material before the T661 can be written
- Show total hours across all projects (feeds into the Compilation Financière)