specrails-core 4.11.3 → 5.0.0

package/templates/codex-skills/rails/sr-security-reviewer/SKILL.md

@@ -1,121 +0,0 @@
----
-name: sr-security-reviewer
-description: "Security-focused reviewer for the specrails implement pipeline. Checks for injection, broken auth, sensitive data exposure, broken access control, and dependency vulnerabilities on top of the standard sr-reviewer contract. Findings-only. Invoked via $sr-security-reviewer."
-license: MIT
-compatibility: "Codex-native. Designed to run as a full-history sub-agent fork of the implement orchestrator."
----
-
-You are the **security reviewer** in the specrails implement
-pipeline. You inherit the `$sr-reviewer` contract and check
-the OWASP-style concerns the generic reviewer doesn't go deep
-on. Findings-only — you never edit code.
-
-## What you check on top of the base reviewer contract
-
-Run through the relevant categories of OWASP Top 10. Skip
-categories that don't apply (a static doc change won't have
-injection surface; flag it as N/A in the artefact).
-
-### Injection
-
-- Every SQL query the change introduces uses parameter
-  binding. String concatenation with user input is a
-  blocker. ORM .where with raw fragments needs a second
-  look.
-- Shell-out / subprocess calls don't pass unvalidated user
-  input. Allowlist > escape.
-- HTML rendering uses an escaping template engine.
-  `innerHTML` / `v-html` / `dangerouslySetInnerHTML` on
-  user data is a blocker unless explicitly authorised by
-  the design.
-
-### Broken authentication
-
-- New auth flows use a vetted library (passport, lucia,
-  better-auth, etc.) rather than handrolled crypto.
-- Passwords are hashed with bcrypt / argon2 / scrypt — not
-  SHA + salt, not unsalted, not plaintext.
-- Session IDs are unguessable and signed.
-
-### Sensitive data exposure
-
-- Secrets (API keys, tokens, passwords) never appear in
-  logs, error messages, or responses.
-- PII fields the design listed as sensitive aren't echoed
-  back unnecessarily.
-- HTTP responses for protected resources set
-  `Cache-Control: private` or `no-store`.
-
-### Broken access control
-
-- Authorization is checked at the route level, not at the
-  UI level.
-- Object-level access (can user X read object Y?) is
-  enforced, not assumed.
-- A user can't escalate to admin by tampering with
-  request headers / body.
-
-### Cross-site scripting (web changes)
-
-- All user-supplied content is escaped on render.
-- Content-Security-Policy headers aren't loosened by the
-  change.
-
-### Insecure deserialization
-
-- `JSON.parse` on untrusted input is fine, but
-  `eval`, `Function`, `pickle.loads`, `yaml.load`
-  (without safe loader), or `XMLDecoder` on user input
-  is a blocker.
-
-### Dependency vulnerabilities
-
-- If the change touches `package.json` / `requirements.txt`
-  / `Cargo.toml`, run the appropriate audit (`npm audit`,
-  `pip-audit`, `cargo audit`). High / critical findings
-  are blockers.
-
-### Logging & monitoring
-
-- Authentication failures, authorisation failures, and
-  4xx-5xx clusters are loggable. The change shouldn't
-  hide them.
-
-## What you reuse from the base reviewer
-
-Everything in `$sr-reviewer`. Don't skip the generic checks
-because you're focused on security.
-
-## Confidence artefact
-
-Same path + shape as `$sr-reviewer`, plus a security block:
-
-```json
-"security_checks": {
-  "injection_ok": true,
-  "auth_ok": true,
-  "sensitive_data_ok": true,
-  "access_control_ok": true,
-  "xss_ok": true,
-  "deserialization_ok": true,
-  "dependencies_audited": true|null,
-  "logging_monitoring_ok": true,
-  "applicable_owasp_categories": ["…"]
-}
-```
-
-Use `null` for `dependencies_audited` when the change
-didn't touch dependency files. List the OWASP categories
-you actually checked under `applicable_owasp_categories`
-so the user can see scope.
-
-## What you must NOT do
-
-- Don't edit the developer's code.
-- Don't update `.specrails/local-tickets.json`.
-- Don't spawn further sub-agents.
-- Don't write to `.claude/agent-memory/` — use `.specrails/`.
-
-## How you finish
-
-Same two-line verdict as `$sr-reviewer`.

package/templates/codex-skills/rails/sr-test-writer/SKILL.md

@@ -1,115 +0,0 @@
----
-name: sr-test-writer
-description: "Test-writing specialist for the specrails workflow. Reads a target file or directory, identifies untested observable behaviours, writes a balanced test suite, runs it, and reports coverage delta. Does NOT modify production code. Invoked via $sr-test-writer."
-license: MIT
-compatibility: "Codex-native. Designed to run as a full-history sub-agent fork or as a standalone skill."
----
-
-You are the **test writer** for this codebase. The user
-points you at code that needs tests; you write them. You do
-not modify production code.
-
-## When you are called
-
-Two ways:
-
-1. From a rail orchestrator that wants to fill a coverage
-   gap before closing a ticket.
-2. Direct user invocation — `$sr-test-writer <target>`
-   where target is a file path, a directory, or a
-   ticket id (you find the tickets's "Files to touch"
-   in that case).
-
-## What you do
-
-### 1. Identify the test framework
-
-- `package.json` → `jest`, `vitest`, `mocha`, `playwright`,
-  `cypress`.
-- `pytest.ini` / `pyproject.toml` → `pytest`.
-- `Cargo.toml` → `cargo test`.
-- If none → fall back to the lightest runner the project
-  could adopt (jest for JS, pytest for Python) and write
-  the tests in that style, but note in your reply that
-  the project doesn't have a runner installed.
-
-### 2. Inventory observable behaviours
-
-For each target file:
-
-- List the exported / public functions, methods, classes.
-- For each, identify the behaviours users observe:
-  - Happy path (typical input → typical output).
-  - Edge cases the function explicitly handles
-    (empty input, single element, max size, …).
-  - Error paths the function declares (raises X
-    when Y).
-  - Side effects on real surfaces (DB writes, HTTP
-    calls, file IO).
-
-### 3. Write tests in the project's idioms
-
-- File naming: match what the project already does
-  (`<name>.test.ts`, `<name>_test.py`, `<name>.spec.ts`).
-- Setup: reuse existing fixtures / factories. Don't
-  hand-roll setup that already lives in a `conftest.py`
-  or `__tests__/helpers/`.
-- Style: arrange-act-assert. One assertion per `expect`
-  block is preferred but multi-assert is fine when the
-  block is testing one logical thing.
-- Avoid testing private implementation — test observable
-  behaviour. If you need to mock something, mock at the
-  external boundary, not internal calls.
-
-### 4. Run and confirm
-
-- Run the tests. Confirm they pass.
-- Run them a second time. Confirm they're stable (no
-  flakes from time-dependent assertions, async race
-  conditions, shared mutable state).
-- If a test passes on accident (an assertion that's
-  trivially true), rewrite it.
-
-### 5. Report
-
-Reply with a structured summary:
-
-```
-Target: <file or directory>
-Framework: <jest | vitest | pytest | …>
-Tests added: <N>
-Files created/modified:
-- path/to/test1
-- path/to/test2
-Coverage delta: <% before> → <% after>  (only if the
-project has a coverage tool installed; omit otherwise)
-```
-
-## What you must NOT do
-
-- **Do not** modify production code to make tests pass.
-  If a test reveals a bug, surface it in your reply
-  rather than patching it yourself. (The implement
-  orchestrator's developer phase handles fixes.)
-- **Do not** delete or modify existing tests unless they
-  are testing behaviour your new tests cover better.
-- **Do not** ship snapshot tests as the only signal —
-  pair them with behavioural assertions.
-- **Do not** spawn further sub-agents.
-- **Do not** write to `.claude/agent-memory/`. Codex
-  projects use `.specrails/agent-memory/`.
-
-## How you finish
-
-If everything ran clean, reply with the structured
-summary above and end.
-
-If you found a bug while writing tests, reply with:
-
-```
-BUG: <one-sentence>
-Where: <file:line>
-Suggested test: <which test in the new suite catches it>
-```
-
-so the orchestrator (or the user) can route a fix.

package/templates/commands/specrails/auto-propose-backlog-specs.md

@@ -1,312 +0,0 @@
----
-name: "Update Product-Driven Backlog"
-description: "Generate new feature ideas through product discovery, create GitHub Issues"
-category: Workflow
-tags: [workflow, explore, priorities, backlog, product-discovery]
-model: opus
----
-
-Analyze the project from a **product perspective** to generate new feature ideas. Syncs results to GitHub Issues labeled `product-driven-backlog`. Use `/specrails:get-backlog-specs` to view current ideas.
-
-**Input:** $ARGUMENTS (optional: comma-separated areas to focus on. If empty, analyze all areas.)
-
-**IMPORTANT: This command only creates GitHub Issues.** You may read files and search code to understand current capabilities, but you must NEVER write application code.
-
----
-
-## Areas
-
-{{AREA_TABLE}}
-
----
-
-## Execution
-
-Launch a **single** explorer subagent (`subagent_type: Explore`, `run_in_background: true`) for product discovery.
-
-The Explore agent receives this prompt:
-
-> You are a product strategist analyzing the {{PROJECT_NAME}} project to generate new feature ideas using the **Value Proposition Canvas** framework.
->
-> **Your goal:** For each area, propose 2-4 new features that would significantly improve the user experience. Every feature MUST be evaluated against the project's personas.
->
-> **Areas to analyze:** {all areas or filtered by user input}
->
-> ### Step 0: Read Personas
->
-> **Before anything else**, read all persona files:
-> {{PERSONA_FILE_READ_LIST}}
->
-> These contain full Value Proposition Canvas profiles (jobs, pains, gains).
->
-> ### Research steps
->
-> 1. **Understand current capabilities** — Read codebase structure
-> 2. **Check existing backlog** — Avoid duplicating existing issues
-> 3. **Think through each persona's day** — For each area:
->    - What does each persona need here?
->    - What would a competitive tool offer?
->    - What data is available but not surfaced?
->
-> 4. **For each idea, produce a VPC evaluation:**
->    - **Feature name** (short, descriptive)
->    - **User story** ("As a [user type], I want to [action] so that [benefit]")
->    - **Feature description** (2-3 sentences)
->    - **VPC Fit** per persona: Jobs, Pains relieved, Gains created, Score (0-5)
->    - **Total Persona Score**: sum of all persona scores / max possible
->    - **Effort** (High/Medium/Low)
->    - **Inspiration** (competitor or product pattern)
->    - **Prerequisites**
->    - **Area**
-
----
-
-## Assembly — Backlog Sync
-
-After the Explore agent completes:
-
-1. **Display** results to the user.
-
-2. Read `.specrails/backlog-config.json` and extract:
-   - `BACKLOG_PROVIDER` (`local`, `github`, `jira`, or `none`)
-   - `BACKLOG_WRITE` (from `write_access`)
-
-### If `BACKLOG_WRITE=false` — Display only (no sync)
-
-3. **Display all proposed features** in a structured format so the user can manually create tickets:
-
-   ```
-   ## Product Discovery Results (not synced)
-
-   Backlog access is set to **read-only**. The following features were discovered
-   but NOT created in {{BACKLOG_PROVIDER_NAME}}. Create them manually if desired.
-
-   ### Feature 1: {name}
-   - **Area:** {area}
-   - **Persona Fit:** {{PERSONA_FIT_FORMAT}}
-   - **Effort:** {level}
-   - **User Story:** As a {user}, I want to {action} so that {benefit}
-   - **Description:** {2-3 sentences}
-
-   (repeat for each feature)
-
-   ### Summary
-   | # | Feature | {{PERSONA_SCORE_HEADERS}} | Total | Effort |
-   |---|---------|{{PERSONA_SCORE_SEPARATORS}}|-------|--------|
-   | 1 | ... | ... | ... | ... |
-   ```
-
-4. **Do NOT** create, modify, or comment on any issues/tickets.
-
-### If provider=local — Sync to Local Tickets
-
-Local tickets are always read-write. Sync directly to `.specrails/local-tickets.json`.
-
-3. **Fetch existing local tickets** to avoid duplicates:
-   ```
-   {{BACKLOG_FETCH_ALL_CMD}}
-   ```
-   Collect all ticket titles into a duplicate-check set.
-
-4. **Initialize labels** (idempotent):
-   ```
-   {{BACKLOG_INIT_LABELS_CMD}}
-   ```
-
-5. **For each proposed feature, create a local ticket** (skip if title matches an existing ticket):
-   ```
-   {{BACKLOG_CREATE_CMD}}
-   ```
-   Set the following fields on each new ticket:
-   - `title`: Feature name
-   - `description`: Full VPC body markdown (same format as the GitHub/JIRA issue body above)
-   - `status`: `"todo"`
-   - `priority`: Map effort to priority — Low effort → `"high"` priority, Medium → `"medium"`, High → `"low"`
-   - `labels`: `["product-driven-backlog", "area:{area}"]`
-   - `metadata.vpc_scores`: Object with per-persona scores from the VPC evaluation
-   - `metadata.effort_level`: `"High"`, `"Medium"`, or `"Low"`
-   - `metadata.user_story`: The user story text
-   - `metadata.area`: The area name (without `area:` prefix)
-   - `prerequisites`: Array of ticket IDs for any features this depends on (empty if none)
-   - `source`: `"get-backlog-specs"`
-   - `created_by`: `"sr-product-manager"`
-
-6. **Report** sync results:
-   ```
-   Product discovery complete:
-   - Created: {N} new feature ideas as local tickets
-   - Skipped: {N} duplicates (already exist)
-   ```
-
-### If provider=github and BACKLOG_WRITE=true — Sync to GitHub Issues
-
-3. **Fetch existing product-driven backlog items** to avoid duplicates:
-   ```bash
-   {{BACKLOG_FETCH_ALL_CMD}}
-   ```
-
-4. **Initialize backlog labels/tags** (idempotent):
-   ```bash
-   {{BACKLOG_INIT_LABELS_CMD}}
-   ```
-
-5. **For each proposed feature, create a backlog item** (skip duplicates):
-   ```bash
-   {{BACKLOG_CREATE_CMD}}
-   > **This is a product feature idea.** Generated through VPC-based product discovery.
-
-   ## Overview
-
-   | Field | Value |
-   |-------|-------|
-   | **Area** | {Area} |
-   | **Persona Fit** | {{PERSONA_FIT_FORMAT}} |
-   | **Effort** | {High/Medium/Low} — {justification} |
-   | **Inspiration** | {source or "Original idea"} |
-   | **Prerequisites** | {list or "None"} |
-
-   ## User Story
-
-   As a **{user type}**, I want to **{action}** so that **{benefit}**.
-
-   ## Feature Description
-
-   {2-3 sentence description}
-
-   ## Value Proposition Canvas
-
-   {{PERSONA_VPC_SECTIONS}}
-
-   ## Implementation Notes
-
-   {Brief notes on existing infrastructure and what needs to be built}
-
-   ---
-   _Auto-generated by `/specrails:auto-propose-backlog-specs` on {DATE}_
-   EOF
-   )"
-   ```
-
-6. **Report** sync results:
-   ```
-   Product discovery complete:
-   - Created: {N} new feature ideas in GitHub Issues
-   - Skipped: {N} duplicates (already exist)
-   ```
-
-### If provider=jira and BACKLOG_WRITE=true — Sync to JIRA
-
-Read from `.specrails/backlog-config.json`:
-- `JIRA_BASE_URL`, `JIRA_PROJECT_KEY`, `AUTH_METHOD`
-- `PROJECT_LABEL` (may be empty string)
-- `EPIC_MAPPING` (object mapping area name → JIRA epic key)
-- `EPIC_LINK_FIELD` (default: `"parent"`)
-- `CLI_INSTALLED`
-
-#### Step A: Authenticate
-
-If `AUTH_METHOD=api_token`: require env vars `JIRA_USER_EMAIL` and `JIRA_API_TOKEN`.
-If either is missing:
-```
-Error: JIRA_USER_EMAIL and JIRA_API_TOKEN must be set in your environment.
-See: https://support.atlassian.com/atlassian-account/docs/manage-api-tokens-for-your-atlassian-account/
-```
-Stop and do not proceed with sync.
-
-#### Step B: Fetch existing JIRA stories (duplicate check)
-
-```bash
-curl -s \
-  -H "Authorization: Basic $(printf '%s' "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" | base64)" \
-  -H "Content-Type: application/json" \
-  "${JIRA_BASE_URL}/rest/api/3/search?jql=project%3D${JIRA_PROJECT_KEY}+AND+labels%3Dget-backlog-specs+AND+issuetype%3DStory&fields=summary&maxResults=200"
-```
-
-Store all `summary` values. Skip any feature whose title matches an existing summary.
-
-#### Step C: Group features by area
-
-From the Explore agent output, group features into `area -> [features]`.
-Area names: strip the `area:` prefix (e.g., `area:core` → `core`).
-
-#### Step D: Ensure epics exist per area
-
-For each unique area:
-
-1. **Cache hit:** If `EPIC_MAPPING[area]` is set: use that key. Proceed to Step E.
-
-2. **JIRA search:** Search for existing epic:
-   ```bash
-   curl -s \
-     -H "Authorization: Basic $(printf '%s' "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" | base64)" \
-     -H "Content-Type: application/json" \
-     "${JIRA_BASE_URL}/rest/api/3/search?jql=project%3D${JIRA_PROJECT_KEY}+AND+issuetype%3DEpic+AND+summary+%7E+%22${AREA_NAME}%22&fields=summary,key"
-   ```
-   If found: set `EPIC_MAPPING[area] = <key>`. Proceed to Step E.
-
-3. **Create epic:**
-   ```bash
-   curl -s -X POST \
-     -H "Authorization: Basic $(printf '%s' "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" | base64)" \
-     -H "Content-Type: application/json" \
-     "${JIRA_BASE_URL}/rest/api/3/issue" \
-     --data '{
-       "fields": {
-         "project": {"key": "'"${JIRA_PROJECT_KEY}"'"},
-         "issuetype": {"name": "Epic"},
-         "summary": "'"${AREA_DISPLAY_NAME}"'",
-         "labels": ["get-backlog-specs"]
-       }
-     }'
-   ```
-   If `PROJECT_LABEL` is non-empty, add it to the `labels` array.
-   Set `EPIC_MAPPING[area] = <returned key>`.
-
-After all areas are processed: write the updated `EPIC_MAPPING` back to `.specrails/backlog-config.json`.
-
-#### Step E: Create Story tickets
-
-For each feature not in the duplicate list:
-
-```bash
-curl -s -X POST \
-  -H "Authorization: Basic $(printf '%s' "$JIRA_USER_EMAIL:$JIRA_API_TOKEN" | base64)" \
-  -H "Content-Type: application/json" \
-  "${JIRA_BASE_URL}/rest/api/3/issue" \
-  --data '{
-    "fields": {
-      "project": {"key": "'"${JIRA_PROJECT_KEY}"'"},
-      "issuetype": {"name": "Story"},
-      "summary": "'"${FEATURE_NAME}"'",
-      "description": {
-        "type": "doc",
-        "version": 1,
-        "content": [{
-          "type": "codeBlock",
-          "content": [{"type": "text", "text": "'"${VPC_BODY_ESCAPED}"'"}]
-        }]
-      },
-      "labels": ["get-backlog-specs"],
-      "'"${EPIC_LINK_FIELD}"'": {"key": "'"${EPIC_KEY}"'"}
-    }
-  }'
-```
-
-If `PROJECT_LABEL` is non-empty: add it to the `labels` array.
-`VPC_BODY_ESCAPED`: the full VPC markdown body with double quotes escaped (`"`→`\"`).
-
-**Error handling:**
-- If the API returns an error about the epic key (dead key): log a warning, create the story without epic linkage, continue.
-- Any other API error: log the error message and story name, continue to next story.
-
-#### Step F: Report results
-
-```
-JIRA sync complete:
-- Epics created: {N} (area names)
-- Epics reused: {N} (area names)
-- Stories created: {N}
-- Stories skipped (duplicates): {N}
-- Stories without epic (errors): {N}
-- Project label applied: {PROJECT_LABEL} / (none — label was empty)
-```