reins-method 0.1.0

package/core/workflow/1_orchestrator.md

@@ -0,0 +1,224 @@
+---
+scope: always
+role: master — read first every session, defines stack detection and routing
+---
+
+# REINS Orchestrator
+
+This file defines how the agent and the user work together on every task, in every project, regardless of stack or AI agent.
+
+**Read this file first, every session.** It detects the project's stack, loads the right adapter (if one is installed), locates the active task context, and routes to the correct workflow phase.
+
+---
+
+## 0 — Where REINS lives
+
+REINS Method is installed once, globally, at `~/.reins/`. **No REINS files ever live inside a project repository.**
+
+```
+~/.reins/
+├── core/                     ← this engine (updated via `reins update`)
+│   ├── workflow/             ← phase files (this file + 2/3/4)
+│   ├── templates/            ← context, current_task, adapter, skill templates
+│   ├── evaluation/           ← historic mode templates
+│   └── skills/               ← meta-skills (e.g. skill-creator)
+├── user/                     ← user-owned, never touched by `reins update`
+│   ├── config.yaml           ← name, agent, active adapter, historic mode
+│   ├── standards/            ← company.md (floor) + personal.md
+│   ├── adapters/             ← installed adapter packs
+│   ├── skills/               ← user's custom skills
+│   ├── projects/             ← per-project state (contexts, specs)
+│   │   └── <project-slug>/
+│   │       ├── contexts/
+│   │       └── specs/
+│   │           └── <type>_<slug>/
+│   │               ├── step-01-spec.md
+│   │               ├── step-01-plan.md
+│   │               └── ...
+│   └── historic/             ← optional monthly tracking (if historic mode is on)
+└── agents/                   ← generated bridge files per AI agent
+```
+
+---
+
+## 1 — Identify the project
+
+1. Determine the project root (nearest ancestor directory containing `.git`, or the current working directory if none).
+2. Compute `<project-slug>` — a stable, filesystem-safe identifier for this project (e.g. derived from the repo name, or the git remote URL if available, or the absolute path with `/` replaced by `-`).
+3. All state for this project lives under `~/.reins/user/projects/<project-slug>/`. Create this directory (with `contexts/` and `specs/`) if it does not exist yet.
+
+---
+
+## 2 — Stack detection
+
+Inspect the project root for marker files to detect the stack(s) in play:
+
+| Marker | Stack |
+|---|---|
+| `Gemfile` | `ruby` |
+| `package.json` | `node` (inspect `dependencies`/`devDependencies` for framework hints, e.g. React, Angular, Vue) |
+| `pyproject.toml`, `requirements.txt`, `setup.py` | `python` |
+| `go.mod` | `go` |
+| `pom.xml`, `build.gradle` | `jvm` |
+| `Cargo.toml` | `rust` |
+| `composer.json` | `php` |
+| More than one marker present | multi-stack (e.g. `ruby` + `node` = backend + frontend) |
+| Nothing recognizable | ask the user explicitly |
+
+If the active context file (see §4) already declares a `stack`, trust it instead of re-detecting — but flag a mismatch if detection now disagrees.
+
+---
+
+## 2.5 — Project map (optional)
+
+Check the project root for `graphify-out/GRAPH_REPORT.md` (generated by the
+external [graphify](https://github.com/safishamsi/graphify) tool — a knowledge graph
+of the codebase, docs, and more).
+
+- If it exists, read it at session start for an architecture overview before diving
+  into the task — it's cheaper and broader than re-reading raw files. `graph.json`
+  and `wiki/` are also available for deeper queries if needed.
+- If it doesn't exist, skip silently. REINS does not require graphify; it only uses its
+  output when present. See "Companion tools" in the repo `README.md` for how to
+  generate it.
+
+---
+
+## 3 — Load the adapter (if any)
+
+1. Read `~/.reins/user/config.yaml` for `adapters:` — a list of installed adapter packs, each with an `ADAPTER.md` declaring which stack(s) it applies to.
+2. Match the detected stack(s) against installed adapters.
+3. If a match is found, load (in this order):
+   - `<adapter>/standards/floor.md` — non-negotiable conventions (precedence 1)
+   - `<adapter>/standards/*.md` — any additional adapter standards (precedence 2, must never conflict with the floor)
+   - `<adapter>/workflow/3_implement.md` — if present, **overrides** `core/workflow/3_implement.md` for the development phase
+4. If no adapter matches, proceed with the generic conventions in `~/.reins/user/standards/company.md` and `~/.reins/user/standards/personal.md` (if the user has filled them in), and the generic `core/workflow/3_implement.md`.
+5. If multiple stacks are detected (e.g. `ruby` + `node`), load every matching adapter. Steps in the breakdown are then labeled by which adapter/stack they belong to.
+
+**Standards precedence rule:** if `personal.md` (or an adapter's secondary standards) contradicts the floor (`company.md` or `<adapter>/standards/floor.md`), **stop immediately** and ask the user to resolve the conflict before proceeding.
+
+---
+
+## 4 — Active context
+
+Context files track the state of every work item for this project, under `~/.reins/user/projects/<project-slug>/contexts/`.
+
+### Naming
+
+```
+<type>_<slug>.md
+```
+- `type`: `feature`, `hotfix`, `bugfix`, `chore`, `spike`
+- `slug`: kebab-case short title
+
+### Frontmatter
+
+```yaml
+---
+type: feature        # feature | hotfix | bugfix | chore | spike
+stack: <detected>    # e.g. ruby, node, ruby+node, python...
+status: active       # active | paused
+branches:            # map of component -> branch name, e.g. { backend: feature/123-x, frontend: feature/123-y }
+prs:                 # map of component -> PR URL (null until opened)
+title: <title>
+updated_at: YYYY-MM-DD
+---
+```
+
+### Invariant
+
+**Exactly one context file per project may have `status: active` at any time.**
+
+- On session start: glob `~/.reins/user/projects/<project-slug>/contexts/*.md`, read frontmatter, find the file with `status: active`.
+- On interrupt (new task arrives while one is active): set the current active file to `status: paused`, create a new file with `status: active` (see `2_new_task.md`).
+- On close: delete the closed file, list all `status: paused` files, ask which to resume.
+
+### Branch guard (multi-component tasks)
+
+When `branches` has more than one entry, before proceeding:
+
+1. Run `git branch --show-current` in each relevant repo/worktree.
+2. Compare with the corresponding entry in `branches`.
+3. If any mismatch: present options (switch branch, update context, cancel). Do not proceed until aligned.
+
+---
+
+## 5 — Routing
+
+### Always loaded (every session)
+
+| File | When |
+|---|---|
+| `core/workflow/1_orchestrator.md` | Session start (this file) |
+| Active context file (§4) | Session start |
+| Adapter standards (§3), or `~/.reins/user/standards/*.md` | Session start |
+| `graphify-out/GRAPH_REPORT.md` (§2.5) | Session start, only if present |
+
+### Phase-specific
+
+| Phase | File |
+|---|---|
+| **New task** | `core/workflow/2_new_task.md` |
+| **Development** | `<adapter>/workflow/3_implement.md` if present, else `core/workflow/3_implement.md` |
+| **Close task** | `core/workflow/4_close_task.md` |
+
+### On-demand (skills)
+
+Skills in `~/.reins/core/skills/`, `<adapter>/skills/`, and `~/.reins/user/skills/` are **never loaded proactively**. Invoke them only when the user explicitly requests, or when the task clearly calls for it.
+
+---
+
+## 6 — The full workflow
+
+```
+New task arrives
+      ↓
+2_new_task.md
+  → identify project + detect stack(s) (§1, §2)
+  → load project map if present (§2.5)
+  → load adapter standards, or generic standards (§3)
+  → understand task + epic
+  → optional: party-mode discussion (core/skills/party-mode/SKILL.md)
+  → propose breakdown (per component if multi-stack)
+  → flag architecture decisions
+  → wait for confirmation
+  → create context file
+      ↓
+For each confirmed step:
+  → 3_implement.md (adapter override or generic)
+     SPEC/PLAN saved to specs/<type>_<slug>/step-NN-{spec,plan}.md
+      ↓
+User gives close order:
+4_close_task.md
+  → run tests (if applicable)
+  → summarize what was done
+  → assess epic impact
+  → identify next step
+  → optional: code review (core/skills/code-review/SKILL.md)
+  → review PR comments
+  → propose commit message(s)
+  → record historic entry (if historic mode is on)
+  → clean specs/<type>_<slug>/ + delete context file
+  → ask which paused context to resume
+```
+
+---
+
+## 7 — General rules (permanent — never override)
+
+- Never write or modify a SPEC — that step belongs to the user
+- Never implement before the SPEC is provided and confirmed
+- Never make architecture decisions silently — surface trade-offs and wait for input
+- Never modify approved tests
+- Apply adapter and user standards at all times — they are not optional
+- If standards conflict, flag immediately and wait for a decision
+- When in doubt about which file applies, ask
+- When a PR is opened, record its URL in the context frontmatter (`prs`) and in every SPEC under `~/.reins/user/projects/<project-slug>/specs/` that belongs to this task
+- When a task requires more than one agent, run them in parallel whenever there are no dependencies
+- At session start, always glob `~/.reins/user/projects/<project-slug>/contexts/*.md` and read frontmatter to identify the active context
+
+---
+
+## Next steps
+
+See `core/workflow/2_new_task.md` to start a new task, or continue with the active context using the development phase file (`3_implement.md`, adapter override if present).

package/core/workflow/2_new_task.md

@@ -0,0 +1,133 @@
+---
+scope: phase-specific
+phase: new-task
+trigger: when a new task or ticket is handed to the agent
+---
+
+# New Task — Start Procedure
+
+This file defines how we start working on any new task. Follow this procedure before writing any code, any test, or any SPEC.
+
+---
+
+## Step 1 — Understand the task
+
+Read everything I give you: the task description, acceptance criteria, comments, linked tickets. Then answer these questions back to me:
+
+- What is the **direct goal** of this task? (one sentence)
+- What **existing behavior** does it touch or depend on?
+- What **services, modules, or components** are likely involved?
+- Are there any **ambiguities or missing information** that would block a clean implementation?
+
+Do not assume. If something is unclear, ask before moving on.
+
+---
+
+## Step 2 — Understand the Epic (if provided)
+
+If I give you an Epic or broader context, answer:
+
+- What is the **overall goal** of the Epic?
+- What **role does this task play** in the Epic? Is it a foundation, a step, or a finishing piece?
+- Are there **adjacent tasks** in the Epic that this task must not break or must align with?
+
+This context shapes every decision we make — architecture, naming, scope.
+
+---
+
+## Optional — Party Mode discussion
+
+If the user asks for a multi-perspective discussion ("party mode", "discuss this
+first", or the task has real ambiguity, multiple stakeholders, or an unclear "why"),
+invoke `core/skills/party-mode/SKILL.md` now, before proposing the breakdown. Its
+synthesis informs Step 3 and Step 4 below — it does not replace them.
+
+---
+
+## Step 3 — Break down the task
+
+Before any implementation, propose a breakdown of the task into clear, ordered steps.
+
+Rules for the breakdown:
+- Each step must have a **single, well-defined responsibility**
+- Steps must be **ordered by dependency** — foundational changes come first
+- Each step should be **independently testable or verifiable**
+- If a step feels large, split it further
+- If the project is multi-stack (see `1_orchestrator.md` §2), label each step by component (e.g. `(backend)`, `(frontend)`, `(integration)`)
+
+Present the breakdown as a numbered list with a one-line description per step. Wait for my confirmation before proceeding.
+
+---
+
+## Step 4 — Flag architecture decisions
+
+Before we write the SPEC, identify if any step requires an **architecture decision** — a choice between two or more valid approaches with different trade-offs.
+
+For each decision point:
+- Describe the options concisely
+- State the trade-offs for each
+- Give me your recommendation and why
+
+I will make the final decision. Once decided, the rationale goes into the SPEC under `## Architecture decision`.
+
+---
+
+## Step 5 — Create the context file
+
+After I confirm the breakdown and any architecture decisions, create the context file for this task at `~/.reins/user/projects/<project-slug>/contexts/<type>_<slug>.md` (see `1_orchestrator.md` §1 and §4 for how `<project-slug>` is determined).
+
+1. **Check for an active context** — glob `contexts/*.md` and read frontmatter. If a file already has `status: active`, follow the interrupt procedure in `1_orchestrator.md` §4 before continuing.
+
+2. **Determine the slug** — kebab-case short version of the task title (e.g. `invoice-by-supplier`).
+
+3. **Create `<type>_<slug>.md`** using `core/templates/context.md` as base. Fill in:
+
+```yaml
+---
+type: feature  # or hotfix / bugfix / chore / spike
+stack: <detected stack(s)>
+status: active
+branches: { <component>: <current git branch> }
+title: <task title>
+updated_at: <today>
+---
+```
+
+4. Fill in `## Task` and `## Epic` from what I provided
+5. Fill in `## Breakdown` with the confirmed steps as unchecked items
+6. Fill in `## Current step` with the first pending step
+7. Fill in `## Decisions made` with any architecture decisions I confirmed
+8. Leave `## Objective` and `## My notes` untouched — those are mine
+
+Do not infer or summarize my intent in any of these fields. Write only what was explicitly stated.
+
+---
+
+## Step 6 — Begin development
+
+Once the context file exists and architecture decisions are resolved, proceed to the development phase for the first step, following `3_implement.md` (or the active adapter's override of it — see `1_orchestrator.md` §3).
+
+Do not start writing tests or code until I have provided the SPEC for that step.
+
+---
+
+## Permanent constraints
+
+- Do not start any implementation before the full procedure above is complete
+- Do not collapse the breakdown into a single step to move faster
+- Do not make architecture decisions silently — surface them explicitly in step 4
+- Do not modify `## Objective` or `## My notes` in the context file — those fields are mine only
+- Do not infer my intent when filling the context file — write only what was explicitly stated
+- The breakdown is a proposal — I confirm it before we proceed
+
+---
+
+## Start prompt
+
+When I hand you a new task, begin by:
+
+1. Summarizing your understanding of the task (step 1)
+2. Summarizing the Epic context if provided (step 2)
+3. Proposing the breakdown (step 3)
+4. Flagging any architecture decisions (step 4)
+5. Waiting for my confirmation before anything else

package/core/workflow/3_implement.md

@@ -0,0 +1,118 @@
+---
+scope: phase-specific
+phase: implement
+trigger: for every development step confirmed in the breakdown
+---
+
+# Implement — Generic Development Phase
+
+This is the **default** development phase. If the active adapter provides its own
+`workflow/3_implement.md`, that file overrides this one entirely for stacks it covers
+(see `1_orchestrator.md` §3) — typical adapter overrides implement Test-Driven
+Development (TDD/STDD) or Spec-Driven Development (SDD) variants suited to that stack.
+
+This generic version makes no assumption about whether the stack uses automated tests.
+
+---
+
+## The process
+
+Always follow this order. Do not move to the next step without explicit confirmation.
+
+```
+1. SPEC      — I write the expected behavior, purpose, edge cases, and concerns
+2. PLAN      — You confirm understanding and state how this step will be verified
+               (automated tests, manual/visual review, or both)
+3. IMPLEMENT — You implement based on the SPEC
+4. VERIFY    — Tests are run and/or I perform manual/visual review
+5. CONFIRM   — I confirm the step is done or request adjustments
+```
+
+Do not write any implementation before the SPEC is provided for that step.
+
+---
+
+## What you do at each step
+
+### Step 1 — Spec
+
+Once I give you the SPEC for this step, save it verbatim to:
+
+```
+~/.reins/user/projects/<project-slug>/specs/<type>_<slug>/step-NN-spec.md
+```
+
+— `<type>_<slug>` matches the active context file's name, `NN` is this step's
+two-digit number in `## Breakdown`. Create the `specs/<type>_<slug>/` directory if
+this is the first step. See `core/templates/spec.md` for the structure.
+
+### Step 2 — Plan
+
+- Read the entire SPEC before writing any line of code
+- Restate the guarantees you will cover
+- State explicitly how this step will be verified — if the project/adapter has tests, propose which test files will be added or changed; if not, describe what manual verification looks like
+- If the SPEC conflicts with existing code, stop and ask before deciding
+- Save your plan to `step-NN-plan.md` alongside the SPEC, following
+  `core/templates/plan.md`
+- If no adapter override defines a TDD/SDD process for this stack, the
+  `core/skills/reins-senior-engineer/SKILL.md` lens (test-first, red/green/refactor) applies
+  by default for Step 3
+
+### Step 3 — Implement
+
+- Cover the main flow, all listed edge cases, and every listed guarantee
+- Apply the active adapter's standards (or `~/.reins/user/standards/*.md` if no adapter) throughout
+- Do not modify any approved test
+- If existing code contradicts the SPEC, stop and ask before deciding
+
+### Step 4 — Verify
+
+- If automated tests exist for this change, run them and report pass/fail
+- If verification is manual, describe clearly what I should see and interact with, and list the specific behaviors to check (happy path, edge cases, error states)
+- Report any failure unrelated to this step (flag it, do not fix it silently)
+
+### Step 5 — Adjustments
+
+- Minor corrections (naming, style, small logic fix) → apply directly
+- Significant changes (new behavior, different architecture) → request a SPEC update first
+
+---
+
+## After confirmation — update the context file
+
+Once the step is confirmed done, update `~/.reins/user/projects/<project-slug>/contexts/<active-context>.md`:
+
+- Mark the current step as done in `## Breakdown`
+- Update `## Current step` to the next pending step
+- Update `## SPEC status` for the completed step to `implemented` (referencing
+  `specs/<type>_<slug>/step-NN-{spec,plan}.md`)
+- If a new decision was confirmed during this step, add it to `## Decisions made`
+- Leave `## Objective` and `## My notes` untouched
+
+---
+
+## SPEC and PLAN structure
+
+See `core/templates/spec.md` for the SPEC structure (written by me, saved by you to
+`step-NN-spec.md`) and `core/templates/plan.md` for the PLAN structure (written by
+you, saved to `step-NN-plan.md`).
+
+---
+
+## Permanent constraints
+
+- Do not modify tests to make the implementation pass — modify the implementation instead
+- Do not write the SPEC — that step is mine
+- Do not move to step 4 without completing step 3 as scoped by the SPEC
+- Do not modify `## Objective` or `## My notes` in the context file — those fields are mine only
+- Apply the active adapter's standards and conventions at all times — they are not optional and do not require a task to be active
+
+---
+
+## Start prompt
+
+When I hand you a SPEC, always begin by:
+
+1. Confirming you read the SPEC and summarizing the guarantees you will cover
+2. Stating how this step will be verified
+3. Waiting for my explicit approval before any implementation

package/core/workflow/4_close_task.md

@@ -0,0 +1,166 @@
+---
+scope: phase-specific
+phase: close-task
+trigger: when the user gives the order to close a task
+---
+
+# Close Task — Procedure
+
+This file defines what you do when I give the order to close a task. Execute every step in order without skipping.
+
+---
+
+## Step 1 — Run the test suite (if applicable)
+
+If the project has automated tests, run the full suite — not just the ones related to this task. Use the test command documented in the active adapter's standards, or ask me if none is documented.
+
+Report back:
+- Total passing / failing / pending
+- Any failure unrelated to this task that was already present (flag it, do not fix it silently)
+- Any test that was modified after my approval (this must not have happened — flag it immediately if it did)
+
+If the project has no automated tests, skip to Step 2 and note that verification was manual (per `3_implement.md`).
+
+Do not proceed to step 2 if there are unexpected failures.
+
+---
+
+## Step 2 — Summary of what was done
+
+Write a clear, concise summary covering:
+
+- **What changed** — which services, components, modules, or endpoints were added or modified
+- **Why** — the problem this solves or the behavior it introduces, in plain language
+- **How** — the approach taken and any architecture decision that shaped it
+
+Keep it readable by someone who wasn't in this task. No implementation details unless they are essential to understand the decision.
+
+---
+
+## Step 3 — Task objective and Epic impact
+
+Answer explicitly:
+
+- Does the implementation fulfill the task's stated goal? If not entirely, what is missing?
+- How does this task contribute to the Epic's overall objective?
+- Does this change anything that adjacent tasks in the Epic depend on?
+
+---
+
+## Step 4 — Next step
+
+If there is a natural next step in the Epic or a follow-up that this task makes possible or necessary, state it clearly:
+
+- What is the next step?
+- Why does it follow from this task?
+- Any dependency or prerequisite to be aware of?
+
+If there is no clear next step, say so explicitly.
+
+---
+
+## Optional — Code review
+
+On request, invoke `core/skills/code-review/SKILL.md` against the full diff for this
+task before proposing the commit message in Step 5. Its findings are presented to
+the user, who decides whether to address anything before proceeding.
+
+---
+
+## Step 5 — Commit message
+
+Propose the final commit message following these rules:
+
+- One subject line — short, imperative, informative
+- Describes **what the change does**, not what files were touched
+- If the task title is already a good description, use it as the base
+- If the task title is too vague, implementation-specific, or ticket-code-only, write a better one
+- Optionally: one blank line followed by 2–3 lines of body if the change needs brief context
+
+Format:
+```
+<subject line>
+
+<optional short body>
+```
+
+Present one primary suggestion and one alternative if the scope could be described differently.
+
+---
+
+## Step 6 — Link the PR in the SPEC
+
+Add the PR link to this task's spec directory at
+`~/.reins/user/projects/<project-slug>/specs/<type>_<slug>/`:
+
+1. Identify the highest-numbered `step-NN-spec.md` for this task.
+2. Add the PR URL under a `## PR` section at the bottom of that file.
+3. Also record it in the context file's frontmatter (`prs`).
+4. This link is required for Step 9 to determine whether the PR has merged and the
+   `specs/<type>_<slug>/` directory can be deleted.
+
+---
+
+## Step 7 — PR comment review
+
+When I give the order to review PR comments:
+
+1. If a GitHub (or equivalent) MCP/CLI tool is available, use it to fetch all review comments and inline comments from the PR.
+2. Analyze the comments in the context of this task, the Epic, and the codebase decisions made.
+
+For each comment, respond with:
+
+- **Valid** — the comment identifies a real problem or improvement that aligns with the task goals and existing architecture
+- **Partially valid** — the comment has merit but misses context (explain what it's missing)
+- **Not valid** — the comment is incorrect, irrelevant, or conflicts with a deliberate decision made during this task (explain why)
+
+For every **Valid** or **Partially valid** comment, propose how to address it — a code change, a clarification, or a documented decision.
+
+Do not act on any comment before I confirm which ones to address. Comments marked **Not valid** are ignored unless I say otherwise.
+
+---
+
+## Step 8 — Record historic entry (if historic mode is on)
+
+Check `~/.reins/user/config.yaml` for `historic_mode: on`. If it is off, skip this step entirely.
+
+If on, follow `~/.reins/core/evaluation/README.md` (Mode A — record task entry at close), using:
+- `~/.reins/core/evaluation/templates/monthly.md` to create the current month's file if it doesn't exist
+- `~/.reins/core/evaluation/templates/task-entry.md` to build the entry
+
+This step runs while the task context is still active — that context is the source of data for the entry.
+
+Do not skip this step (when historic mode is on) unless I explicitly say to.
+
+---
+
+## Step 9 — Close context file and resume
+
+After the PR comments are reviewed and I confirm the task is closed:
+
+1. Check `~/.reins/user/projects/<project-slug>/specs/<type>_<slug>/` for this task:
+   - If the highest-numbered `step-NN-spec.md` has a `## PR` link, check if the PR is merged (via available tooling).
+   - **Before deleting anything**, list every file that would be deleted and explain why (PR merged, or explicitly authorized by you). Wait for your confirmation.
+   - Delete only the files (or the whole `specs/<type>_<slug>/` directory) you confirm.
+
+2. Delete the active context file (`<type>_<slug>.md`) for this task.
+
+3. Glob `~/.reins/user/projects/<project-slug>/contexts/*.md` for any files with `status: paused`:
+   - If none exist: confirm the workspace is clean and stop.
+   - If any exist: list them (type, title, branches, updated_at) and ask: "Which context do you want to resume?"
+   - On selection: set the chosen file to `status: active`, update `updated_at`, then run the branch guard (`1_orchestrator.md` §4) before proceeding.
+
+4. If a SPEC has no PR link yet, keep it until the PR is opened and linked.
+
+---
+
+## Permanent constraints
+
+- Do not close a task with a failing test suite unless I explicitly say to proceed anyway
+- Do not write a commit message that references internal ticket codes only — it must be human-readable
+- Do not skip the Epic impact section if an Epic was provided at task start
+- Do not silently fix unrelated failures — flag them and wait for my instruction
+- Do not act on any PR comment before I confirm which ones to address
+- Do not mark a comment as valid solely because it follows a general best practice — evaluate it against the specific decisions made in this task
+- Do not delete the context file before I explicitly confirm the task is closed
+- Do not skip the historic entry step (Step 8) when historic mode is on — it must run before context cleanup

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "reins-method",
+  "version": "0.1.0",
+  "description": "REINS Method — agent-agnostic AI pair-programming workflow. Interactive installer.",
+  "license": "MIT",
+  "homepage": "https://github.com/gustavodiasp/reins-method",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/gustavodiasp/reins-method.git"
+  },
+  "bin": {
+    "reins-method": "tools/installer/cli.js"
+  },
+  "files": [
+    "tools/installer",
+    "bin",
+    "core",
+    "agents",
+    "*.md",
+    "LICENSE"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "dependencies": {
+    "@clack/prompts": "^0.8.2",
+    "commander": "^12.1.0",
+    "picocolors": "^1.1.1"
+  }
+}