Srib identify

srib-identify

Role: Planning + intake. Reads a feature backlog, writes self-contained ticket files, routes each to the right SRIB skill.

This skill does NOT implement features. It produces the plan that srib-view, srib-model, and srib-integration execute.

---

Invocation

srib-identify <path-to-excel-or-csv>

Or: user uploads an Excel file and says "srib-identify" — find the most recently mentioned or uploaded file path.

If no file is provided, ask: "Please share the Excel or CSV file path. It should have columns: Feature Name, Desired Outcome, Acceptance Criteria."

---

Phase 1 — Parse the input file

Run the bundled parser to turn the spreadsheet into a Python list of feature dicts. The parser lives in this skill's own scripts/ folder — its absolute path is shown as "Base directory for this skill" when the skill launches. Use that base dir:

python "<skill-base-dir>/scripts/parse_excel.py" "<file-path>"

(When this skill is bundled inside a project, that resolves to .claude/skills/srib-identify/scripts/parse_excel.py; when installed personally, to ~/.claude/skills/srib-identify/scripts/parse_excel.py.)

The script prints JSON to stdout. Each entry has:

• feature_name — the feature title
• desired_outcome — what success looks like for the user
• acceptance_criteria — list of checkable conditions

If the script fails (missing dependency, wrong column names), read the file yourself and extract these three fields. Common column name variants:

• "Feature Name" / "Feature" / "Title" / "Name"
• "Desired Outcome" / "Outcome" / "Goal" / "Expected Result"
• "Acceptance Criteria" / "AC" / "Criteria" / "Done When"

---

Phase 2 — Classify each feature

For each feature, decide its concern based on the table below. A feature can be multi-concern — note all that apply.

Concern	Skill	What belongs here
view	srib-view	Shaders, materials, lighting, visual effects, 3D scene rendering, post-FX, the 3-tier shader system, particle effects, visual feedback
model	srib-model	Math, animation curves, tweens, easing, physics simulation, state machines, interpolation, GDScript computation logic, data processing
integration	srib-integration	Wiring view+model together, Android plugin/JNI bridge, autoload singletons, signal routing, SmartThings API connection, scene composition, export pipeline, on-device behavior

Classification rules:

• A feature is view-only if it purely changes how something looks with no new logic.
• A feature is model-only if it computes or transforms data with no visual output change.
• A feature is integration if it requires connecting Godot layers to each other or to Android/SmartThings.
• A mixed feature gets split into separate sub-tickets, one per concern — never collapse them.

---

Phase 3 — Generate ticket files

Finding the issues/ directory

Look for project.godot in current or parent directories to locate the Godot project root. Create <project-root>/issues/ if it does not exist.

If you cannot find project.godot, use git rev-parse --show-toplevel to find the repo root and create <repo-root>/issues/.

Ticket numbering

Check existing files in issues/ matching SRIB-*.md. The next ticket is SRIB-<max+1>. Zero-pad to three digits: SRIB-001, SRIB-042.

For a mixed-concern feature that splits into N sub-tickets, allocate N consecutive numbers and note the parent-child relationship in each file.

Ticket file format

Write one .md file per ticket to issues/SRIB-NNN.md. Use this exact template:

# SRIB-NNN — <Feature Name>

**Concern:** <view | model | integration | mixed>
**Skill:** `<srib-view | srib-model | srib-integration>`
**Status:** Open
**Parent:** <!-- SRIB-NNN if this is a sub-ticket, else omit -->
**Sub-tickets:** <!-- list if this is a parent ticket, else omit -->

---

## Goal

<One paragraph restating the Desired Outcome in implementation terms — what the Godot project will be able to do when this ticket is closed.>

## Context

<One paragraph connecting this feature to the existing SRIB architecture: which scene, node, script, or shader it touches, and why this change matters for the Android app.>

## Scope

<Bulleted list of what is IN scope. Be specific: which GDScript files, which shader files, which scenes, which Android layers.>

**Out of scope:** <What this ticket deliberately leaves for another ticket.>

## Technical Approach

<Numbered steps describing the implementation path. Reference existing files where known. For view tickets: which shader tier and what GLSL changes. For model tickets: which AnimationPlayer/Tween/script approach and what math. For integration tickets: which signal paths, autoloads, or Android plugin calls.>

## Acceptance Criteria

<Copy from the input file, then augment with technical checkpoints:>
- [ ] <original AC item 1>
- [ ] <original AC item 2>
- [ ] Tested in Godot editor (Play Scene, no errors in Output panel)
- [ ] Tested on Android device or emulator (no crashes, correct behavior)
- [ ] No regressions in existing scenes (run all scenes, verify nothing breaks)

## Skill Execution

To implement this ticket, run:

<srib-view | srib-model | srib-integration> SRIB-NNN

<If this ticket is part of a sequence, explain the order here.>

---

Phase 4 — Output the execution plan

After writing all ticket files, print a summary table and execution sequence. Format:

Created N tickets in issues/

| Ticket   | Feature                | Concern     | Skill            |
|----------|------------------------|-------------|------------------|
| SRIB-001 | ...                    | view        | srib-view        |
| SRIB-002 | ...                    | model       | srib-model       |
| SRIB-003 | ...                    | integration | srib-integration |

Execution sequence
──────────────────
Parallel (no dependencies between these — run in separate chats):
  srib-view SRIB-001
  srib-model SRIB-002

After both complete:
  srib-integration SRIB-003

Sequencing rules:

• srib-view and srib-model sub-tickets from the same parent feature run in parallel.
• srib-integration tickets that depend on view + model outputs run after both.
• Independent features (no shared code) run in parallel regardless of concern.
• If two features touch the same file, note it as a conflict and sequence them.

---

Operating rules

• Do not implement anything. Write specs only.
• If acceptance criteria are vague ("it should work well"), expand them into testable checkpoints.
• If a feature is ambiguous, write a ## Open Questions section at the bottom of the ticket rather than guessing.
• Always reference existing project files by name when known (from project.godot exploration).
• Ticket bodies must be self-sufficient — a Claude Code session opening SRIB-007.md tomorrow must be able to execute it cold without this conversation's context.