opencode-skills-collection 4.1.1 → 4.1.3

package/bundled-skills/remote-work-tracker/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: remote-work-tracker
+description: 'Remote work register: employee, location, week start, HQ versus remote days, core-hours compliance and manager approval. Use for hybrid work tracking.'
+category: business
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-26"
+author: WHOISABHISHEKADHIKARI
+tags: [sme, business, operations, database, csv, notion, sql, operate]
+tools: []
+source_repo: WHOISABHISHEKADHIKARI/sme-ops-system-builder
+---
+
+# Remote Work Tracker
+
+**What it is:** Location management.
+
+## Overview
+
+Works out the smallest useful **Remote Work Tracker** setup for the business in front of it, then
+builds it only when asked. The default output is a short recommendation, not a
+spreadsheet. Artifacts - CSV, SQL DDL, JSON Schema, Notion mapping - are produced on
+request, from one field list so they cannot drift apart.
+
+Layer: Layer 8: Operate. Fits: Scale stage. Table code: n/a.
+
+## When to Use This Skill
+
+- remote work tracker
+- hybrid work log
+- work from home register
+- location tracker
+
+Also use it when the user says "location management", or describes the same process happening in a
+spreadsheet, a document or someone inboxes.
+
+Do not use it for: payroll calculation, tax filing, or legal advice. This skill produces
+empty templates only - it never holds or processes real employee or customer data.
+
+## How It Works
+
+Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.
+
+### Step 1 - Identify intent
+
+Read the request and pick the intent before asking anything.
+
+- "set up" or "build" or "create" -> the user wants artifacts; go to Step 2.
+- "our process is ..." or "it is in a sheet" -> the user wants to move an existing process; capture it, then Step 2.
+- "is this right" or "review" or "audit" -> the user wants a check, not a build; answer from what they share.
+- "how do I ..." -> advice question; answer directly and offer the build only if it helps.
+
+Ask only if this is the highest-value missing fact; otherwise proceed without an opener:
+
+> **Q:** How many people work remotely?
+
+### Step 2 - Ask only what is missing
+
+Skip anything the user already answered, in any earlier message. Ask the rest one at a
+time, and stop as soon as the remaining answers would not change the output.
+
+- **People** - How many remote? / Fully or hybrid? / Any location changes?
+- **Availability** - Core hours? / Overlap required? / How communicated?
+- **Equipment** - Equipment provided? / Who approves? / Any cost to the company?
+- **Current process** - Is it tracked now? / Sheet or nothing? / What gets missed?
+- **Outcome** - What do you need? / A roster, a policy record or both?
+
+Never invent an answer. If the user does not know, record it as unknown and carry on.
+
+### Step 3 - Hold the internal context
+
+Hold the answers in this shape. It stays internal - it is not shown to the user unless
+they ask, and it never carries a value the user did not give.
+
+```yaml
+module: remote-work-tracker
+intent: null            # setup | advice | review | fix | build | convert | export
+scale: null             # Starter | Growth | Scale, only if the answer changes it
+areas:
+  "People": null
+  "Availability": null
+  "Equipment": null
+  "Current process": null
+  "Outcome": null
+requested_outputs: []   # csv | sql | json | notion | xlsx - requested formats only
+confirmed_facts: []     # only what the user actually said
+open_questions: []      # the unanswered ones, in the order worth asking
+```
+
+### Step 4 - Recommend the smallest workflow
+
+If an artifact was requested, build it after resolving essential missing facts. Otherwise give a short recommendation and offer the relevant artifact.
+
+**Recommended approach:** Track the roster and the agreement, not daily presence. If you need working hours, record the agreed window per person.
+
+**Why this one:** Remote tracking degrades into monitoring and stops being trusted. Record agreements and the roster, and leave presence out of it.
+
+**Workflow:** Person recorded → Location and agreement → Equipment issued → Review
+
+### Step 5 - Build only on request
+
+Once the user asks for it, derive the fields from the confirmed context and emit the
+requested artifacts. For machine-readable text, keep prose outside the data; for files,
+provide a usable link. Report material validation failures or limitations separately.
+
+**A selected Notion output is rendered by `notion-manual-import`, so route the
+Notion step there.** When the user selects Notion, hand that step to
+@notion-manual-import: it holds the CSV, the property
+mapping, the import steps and the verification checklist, and it renders the Field
+Reference below instead of defining a table of its own. Do not restate the mapping
+here and do not improvise the import steps. Manual CSV and mapping outputs need no
+connection. For requested workspace changes, follow the shared contract: verify actual
+tool access and the target before writing. A user saying "connected" is not tool evidence.
+Never ask for a Notion password or token.
+
+For an Excel-compatible CSV, use UTF-8 with a byte order mark so Excel opens the
+text correctly. A CSV is not an `.xlsx` workbook; create `.xlsx` only when the user
+requests a workbook.
+A CSV carries no types, so after it, name the columns
+that need a number, date or currency format applied.
+
+```csv
+Remote Work Entry,Employee Name,Department,Work Location,Week Start,HQ Days,Remote Days,Core Hours Met,Manager,Approved,Notes,Remote ID
+"Home, Tue 3 Mar",Aarav Sharma,Delivery,Bengaluru,2026-01-05,3,2,TRUE,Sneha Iyer,TRUE,"February shows two split-location weeks; the travel policy needs a decision either way.",
+```
+
+```sql
+CREATE TABLE remote_work_tracker (
+  remote_work_entry VARCHAR(255),
+  employee_name VARCHAR(255),
+  department VARCHAR(255),
+  work_location VARCHAR(255),
+  week_start DATE NOT NULL,
+  hq_days NUMERIC NOT NULL,
+  remote_days NUMERIC NOT NULL,
+  core_hours_met BOOLEAN NOT NULL,
+  manager VARCHAR(255),
+  approved BOOLEAN NOT NULL,
+  notes TEXT,
+  remote_id SERIAL PRIMARY KEY,
+  created_at TIMESTAMP DEFAULT NOW(),
+  updated_at TIMESTAMP DEFAULT NOW()
+);
+```
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Remote Work Tracker",
+  "type": "object",
+  "additionalProperties": false,
+  "properties": {
+      "Remote Work Entry": { "type": "string" },
+      "Employee Name": { "type": "string" },
+      "Department": { "type": "string" },
+      "Work Location": { "type": "string" },
+      "Week Start": { "type": "string", "format": "date" },
+      "HQ Days": { "type": "number" },
+      "Remote Days": { "type": "number" },
+      "Core Hours Met": { "type": "boolean" },
+      "Manager": { "type": "string" },
+      "Approved": { "type": "boolean" },
+      "Notes": { "type": "string" },
+      "Remote ID": { "type": "integer" }
+  },
+  "required": [
+      "Week Start",
+      "HQ Days",
+      "Remote Days"
+  ]
+}
+```
+
+```markdown
+| CSV column | Notion property | Set after import |
+|---|---|---|
+| Remote Work Entry | Title | Use as the database title |
+| Employee Name | Text | Leave as Text |
+| Department | Text | Leave as Text |
+| Work Location | Text | Leave as Text |
+| Week Start | Date | Convert to Date |
+| HQ Days | Number | Convert to Number |
+| Remote Days | Number | Convert to Number |
+| Core Hours Met | Checkbox | Convert to Checkbox |
+| Manager | Text | Leave as Text |
+| Approved | Checkbox | Convert to Checkbox |
+| Notes | Text | Leave as Text |
+| Remote ID | Text (preserve source ID) | Keep imported IDs as Text; optionally add a separate Unique ID property |
+```
+
+The rows above are documentation examples only. Emit empty templates unless the user explicitly requests examples. Money stays `currency`, dates stay `date`,
+and anything pointing at another table stays `relation`.
+
+## Field Reference
+
+| # | Field | Type | SQL | JSON Schema | Notion | CSV example |
+|---:|---|---|---|---|---|---|
+| 1 | Remote Work Entry | `text` | `VARCHAR(255)` | `string` | Text | `Home, Tue 3 Mar` |
+| 2 | Employee Name | `text` | `VARCHAR(255)` | `string` | Text | `Aarav Sharma` |
+| 3 | Department | `text` | `VARCHAR(255)` | `string` | Text | `Delivery` |
+| 4 | Work Location | `text` | `VARCHAR(255)` | `string` | Text | `Bengaluru` |
+| 5 | Week Start | `date` | `DATE` | `string, format: date` | Date | `2026-01-05` |
+| 6 | HQ Days | `number` | `NUMERIC` | `number` | Number | `3` |
+| 7 | Remote Days | `number` | `NUMERIC` | `number` | Number | `2` |
+| 8 | Core Hours Met | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `TRUE` |
+| 9 | Manager | `text` | `VARCHAR(255)` | `string` | Text | `Sneha Iyer` |
+| 10 | Approved | `checkbox` | `BOOLEAN` | `boolean` | Checkbox | `TRUE` |
+| 11 | Notes | `long_text` | `TEXT` | `string` | Text | `February shows two split-location weeks; the travel policy needs a decision either way.` |
+| 12 | Remote ID | `id` | `SERIAL PRIMARY KEY` | `integer` | Text (preserve source ID) | `(blank)` |
+
+## Select Options
+
+_No Select fields._
+
+## Relations
+
+Link fields: none
+
+## Examples
+
+**Prompt**
+
+```
+We have remote staff across four cities and no record of who is where.
+```
+
+**Context first** - one question per message, nothing already answered:
+
+> **Q:** How many remote?
+> **A:** Nine.
+>
+> **Q:** Fully or hybrid?
+> **A:** Hybrid.
+>
+> **Q:** Core hours?
+> **A:** Four hours overlap.
+
+**Recommended next step** - offered, not built:
+
+> Track the roster and the agreement, not daily presence. If you need working hours, record the agreed window per person.
+>
+> Workflow: Person recorded → Location and agreement → Equipment issued → Review
+>
+> Want the CSV, SQL, JSON Schema and Notion mapping for this?
+
+## Best Practices
+
+- Build when requested; recommend and offer a build for advice-only requests.
+- One question per message. A batched intake reads as a form and gets guessed at.
+- Keep display names identical across CSV and JSON; document normalized SQL identifiers.
+- Use `relation` for anything that points at another table, `text` only for free text.
+- Money fields are `currency`, never `text`. Dates are `date`, never free text.
+- If the user requests an example row, keep it obviously fake so nobody imports it as real data.
+
+## Limitations
+
+- Empty template only. It does not compute payroll, tax, leave balances or KPIs.
+- Notion relations need both databases imported before the link column resolves.
+- Select options are a starting set. Rename them to match how the business talks.
+- No automation, reminders or sync. Those need the integration layer.
+- Does not monitor activity, track location automatically or set policy for you.
+- Legal, tax and HR review is still required before this drives real decisions.
+
+## Security & Safety Notes
+
+- Never fill in real names, salaries, medical or banking data. Placeholders only.
+- Label example rows as synthetic, and keep bank details masked.
+- Local reads, generation commands, and validation are part of a requested artifact build.
+  External writes, messages, provisioning, and publication require authorization for that
+  action and target; existing explicit authorization does not need to be repeated.
+- If sensitive data is supplied, avoid repeating unnecessary identifiers. Use only what
+  the requested review needs; keep generated templates empty. Do not claim deletion
+  from the conversation or service storage.
+- Privacy, legal and disciplinary cases need a qualified human reviewer before anything
+  is acted on.
+
+## Common Pitfalls
+
+- **Problem:** a static mapping is described as a completed workspace build.
+  **Solution:** deliver manual mappings without a connection; claim a live change only
+  after the authorized tool operation succeeds.
+- **Problem:** asked all six questions in one message.
+  **Solution:** ask one, wait, and drop any the first answer already covered.
+- **Problem:** built a full system when one table was asked for.
+  **Solution:** build what was requested; mention the parent skill separately.
+- **Problem:** all four artifacts drift apart.
+  **Solution:** derive all four from the field list in this file, never by hand.
+- **Problem:** Notion import shows every column as Text.
+  **Solution:** that is expected. Apply the property mapping table once, after import.
+
+## Related Skills
+
+- [Module Catalog](https://github.com/sickn33/agentic-awesome-skills/blob/main/CATALOG.md) - find the relevant module, then read its skill.
+- @people-directory - the employee master record most modules link to.
+- @notification-reminder-hub - turns due dates in this module into reminders.
+
+## Reusable Prompt
+
+```
+I want to set up location management for my company.
+Ask me one short question at a time, and only about what I have not already told you.
+Then recommend the smallest setup that fits, and wait for me to ask before you build it.
+When I ask, output CSV, SQL DDL, JSON Schema, a Notion property mapping or an Excel workbook. Data only.
+```
+

package/bundled-skills/repo-foundation/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: repo-foundation
+description: "Implement features, fixes, modules, contract migrations, and resumed work while preserving user edits and authorized public contracts."
+category: development
+risk: critical
+source: https://github.com/Natchannnn/repository-engineering-skills
+source_repo: Natchannnn/repository-engineering-skills
+source_type: community
+date_added: "2026-09-30"
+author: Natchannnn
+tags: [repository-engineering, feature-development, contract-migration, continuity]
+tools: [codex]
+license: MIT
+license_source: https://github.com/Natchannnn/repository-engineering-skills/blob/e55b378158d5134a77af3b8dace4a2a1b17e41e2/LICENSE
+metadata:
+  version: "0.3.0"
+  license: "MIT"
+---
+
+# Repo foundation
+
+## When to Use
+
+- Use when the user asks to add a feature, fix a bug, or start a module in an existing project.
+- Use when establishing the minimum foundation for a new repository or subsystem.
+- Use when requirements authorize a schema, public-contract, ownership, or architecture migration.
+- Use when resuming unfinished work or reconciling stale notes with repository evidence.
+
+Build on a foundation that's just big enough, add features on top of it, and change the architecture only when requirements force it. Aim for the least total rework.
+
+---
+
+## Core principles
+
+- **No universal dogma:** don't impose a layout, error pattern, or framework the project doesn't need. Plain standard library is fine.
+- **Scope, baseline, and user work:**
+  - Establish a clean baseline before mutating code: use the pre-existing revision/commit when Git exists; use a file inventory or snapshot when uninitialized or greenfield.
+  - In a dirty workspace, protect pre-existing uncommitted user modifications. You may edit distinct parts of the same file as long as user work is preserved. Stop and ask only if there is an actual collision or ambiguous intent.
+  - Never create commits or force Git initialization solely for handoff or tracking.
+  - Reuse conventions only with healthy repository precedent. Don't treat accidental patterns or temporary workarounds as precedent, and don't expand into out-of-scope cleanup.
+  - Don't push, publish, deploy, change branch protection, install system hooks, or buy anything unless the user asks.
+- **Prose, naming, and restraint:**
+  - Names reflect business domain concepts and ownership.
+  - Add comments only for information code cannot express: grounded rationale, non-obvious invariants, units, rounding, ordering, protocol quirks, or compatibility.
+  - Do not narrate syntax; do not invent tickets, incidents, owners, or production histories.
+  - Treat error and CLI text as contract surface: check callers and parsers before rewording.
+  - Never invent ticket, PR, or incident references. An inaccessible or unverified reference is not evidence of fabrication. Preserve existing references unless repository evidence establishes that they are incorrect or obsolete; report material uncertainty instead of deleting them.
+  - Do not strip valuable comments merely for cosmetic brevity; do not enforce arbitrary comment ratios.
+  - Do not add abstractions, wrappers, or factory layers without concrete ownership, contract, or test seam needs.
+- **Preserve consumed public contracts** as defined in `references/shared-contracts.md` §1: keep documented types, values, errors, and serialization. Change a contract only when the task clearly authorizes it, then update callers, tests, and docs in scope.
+- **Verification rigor & proportionate testing:**
+  - Record baseline failures and distinguish: (1) pre-existing failures outside scope, (2) in-scope failures to fix, (3) regressions from current changes, and (4) environment errors.
+  - Verify the final code state; never use pre-cleanup test results to certify modified code.
+  - Add or update persistent tests when a change introduces behavior, fixes a defect, alters a contract, or exposes a meaningful coverage gap. Prefer the repository's existing test framework and structure. Do not add tests solely for file-count or coverage optics. For documentation-only or mechanically verified changes, use the relevant lightweight checks and explain any material verification gap.
+  - Check every requirement before you say you're done. Say what you verified, what you only read, and what you assumed. A command that exits 0 doesn't count if the file it should make isn't there.
+- **Failure invariants & state preservation:** if an operation can fail halfway, decide what must stay untouched. Validate inputs and ownership first, build the replacement on the side, keep the old state until the new one is ready, and test the failure boundary.
+
+---
+
+## Mode selection
+
+| Mode | Trigger | Core Actions | Exit Criteria |
+|---|---|---|---|
+| **Bootstrap** | New repository from scratch or an area lacking minimal foundation (no build/test/run commands, conventions, or boundaries). | Elicit critical constraints, choose just-enough design, set up minimal tooling/checks, implement and verify the first representative slice. Read [bootstrap](references/bootstrap.md). | Representative slice works and is verified; run/build commands are documented; repo is stable for subsequent work. |
+| **Continue** | Adding a feature, bugfix, or improvement on an existing, fitting foundation. | Determine owning domain and boundary, implement changes, run proportionate checks, and review diff. Executable directly from core. | Task requirements are met; diff is reviewed; intentional contract changes are verified (or existing contracts preserved); remaining limitations are stated. |
+| **Evolve** | New requirements alter core contracts, ownership, boundaries, or architecture; or adopting a repo with conflicting conventions. | Assess blast radius, execute controlled migration, update evidence, tests, and documentation. Read [evolution](references/evolution.md). | Transition is verified; new contracts are operational; instructions and documentation align with code. |
+
+Adopting an existing repository begins with mode selection; do not default to re-bootstrapping. If the repository already has working instructions, tooling, and conventions, reuse them. If a specific subsystem lacks a foundation, establish only what that subsystem requires.
+
+---
+
+## Continue workflow (Core)
+
+Routine feature work runs straight from the mode above plus core principles, no extra reference needed:
+
+### 1. Scope and baseline
+Confirm the user's objective, observable consequences, affected boundaries, baseline revision/inventory, and any uncommitted user changes to preserve.
+
+### 2. Implement just enough
+- **Assumptions vs. product decisions:** choose conventional, reversible defaults (directory layout, helper naming, standard library choices) on your own. Bundle product and architectural decisions (external dependencies, data schema changes, new auth schemes) into one question before breaking anything.
+- **Intentional contract changes** occur when a task explicitly requires changing a contract, so verify that callers and tests reflect the new contract rather than forcing deprecated behavior.
+
+### 3. Verify proportionately
+- **Lightweight path (low risk):** routine bug fixes and localized edits inside established boundaries. Keep scope tight and run relevant mechanical checks (syntax, linter, affected unit tests). Skip automatic secondary review passes unless concrete unresolved concerns warrant one; an explicit review request still applies.
+- **High-risk changes:** a single line touching authorization, permissions, data migrations, cryptography, persistence lifecycles, or concurrency can do serious damage. Read [verification](references/verification.md) before designing checks.
+
+### 4. Continuity and state
+- **Implementation vs. requirements:** existing code shows current behavior. That is not proof of meeting requirements, and passing tests don't guarantee completeness if acceptance was never tested.
+- **Reconciliation:** use the evidence hierarchy to guide investigation, not to settle contradictions for you. If requirements, docs, callers, and tests disagree, reconcile them before changing the contract. If notes and code disagree, check requirements and tests; don't edit the notes to match the code.
+- **Tracking:** reuse issue trackers and project notes. Don't create handoff files for routine features.
+
+---
+
+## Companion Coordination (`repo-native-refactor`)
+
+Use at most one companion pass when the user requests review, concrete unresolved concerns remain, or a substantial contract, ownership, or semantic change warrants a scoped audit. Lightweight fixes do not trigger an automatic pass. Read [references/companion.md](references/companion.md) when a pass is warranted; finish normally if the companion is unavailable. Rerun affected checks after its edits; same-agent self-review is not independent review.
+
+---
+
+## Reference routing
+
+Read supporting references only when the corresponding trigger occurs:
+
+- **[references/bootstrap.md](references/bootstrap.md):** Read in **Bootstrap mode** to establish a new repository, set up minimal tooling, and build the first representative slice.
+- **[references/evolution.md](references/evolution.md):** Read in **Evolve mode** to assess blast radius, handle breaking contract changes, or reconcile conflicting conventions.
+- **[references/continuity.md](references/continuity.md):** Read when resuming work across sessions, taking over a repository, or reconciling stale notes with code reality.
+- **[references/verification.md](references/verification.md):** Read when designing checks for greenfield code, high-risk boundaries (auth, data loss, concurrency), or weak test suites.
+- **[references/shared-contracts.md](references/shared-contracts.md):** Canonical contract + evidence hierarchy + final-state rule. Read when touching any public interface, reconciling conflicting requirements, or certifying completion.
+- **[references/migration-examples.md](references/migration-examples.md):** Atomic vs transitional migration patterns. Read in Evolve mode before mutating persisted state.
+- **[references/companion.md](references/companion.md):** Full companion coordination (roles, handoff, loop limits). Read when planning a refactor pass with `repo-native-refactor`.
+
+---
+
+## Examples
+
+### Add a feature on an existing foundation
+
+```text
+Use repo-foundation to add pagination to this project's existing search endpoint.
+Preserve the current default response and my uncommitted changes. Reuse the
+project's conventions, add relevant regression coverage, and verify the final diff.
+```
+
+Select Continue mode, inspect the endpoint's callers and baseline checks, implement
+the smallest compatible change, and report the checks actually performed.
+
+### Migrate an authorized persisted contract
+
+```text
+Use repo-foundation to migrate our local JSON store from schema v1 to v2.
+Update the in-scope callers and tests. A failed migration must leave the existing
+store intact; verify that failure boundary before reporting completion.
+```
+
+Select Evolve mode and read the migration and verification references before
+changing persisted state. Establish the authorized target schema and verify the
+transition, including failure-state preservation.
+
+## Limitations
+
+- Repository instructions and actual callers are required to establish local contracts; the skill cannot infer missing product requirements reliably.
+- Atomic replacement examples depend on the target filesystem and do not establish crash durability on every platform.
+- Relevant passing checks establish only their exercised scope; they do not prove that all requirements or failure modes are covered.
+- Companion review is optional when unavailable; same-agent self-review is not independent review.
+
+## Security & Safety Notes
+
+This skill can edit source files and guide state migrations, so its declared risk
+is `critical` under this collection's state-modification classification. Work only
+within the user's authorized repository and task scope, preserve existing user
+changes, and establish failure invariants before changing persisted data. Routine
+implementation authority does not authorize pushing, publishing, deploying,
+changing branch protection, installing system hooks, or purchases.
+
+---
+
+## When NOT to Use
+
+- **Trivial edits:** Skip this skill for typos, isolated script adjustments, or formatting-only changes: the overhead is not worth it.
+
+
+## Source & License
+
+Adapted from [Natchannnn/repository-engineering-skills](https://github.com/Natchannnn/repository-engineering-skills/tree/e55b378158d5134a77af3b8dace4a2a1b17e41e2).
+The original MIT copyright notice and license are retained in [references/LICENSE.md](references/LICENSE.md).
+Collection adaptations add metadata, explicit triggers, interaction examples, limitations, and safety notes; the core workflow and supporting reference instructions are retained.

package/bundled-skills/repo-foundation/references/LICENSE.md

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Natchannnn
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/bundled-skills/repo-foundation/references/bootstrap.md

@@ -0,0 +1,63 @@
+# Bootstrap: establishing foundation and initial slice
+
+> Field note: I used to scaffold full layered dirs on day one. Deleted most of it. Now I ship one slice first.
+
+Use this reference when starting a new repository from scratch or when setting up an area of an existing repository that lacks minimal tooling, conventions, or architecture.
+
+---
+
+## 1. Minimal inputs and scoping
+
+Before generating code or directory structures, establish the critical constraints.
+First: what should the software actually do for an outside observer (CLI command, HTTP endpoint, UI component, library export, worker process)? Second: hard constraints (language, runtime, frameworks, persistence, external services, anything operational the user asked for). Third, sort decisions into two piles.
+Reversible assumptions cover directory structure, utility naming, standard library picks, and helper layout. Choose conventionally on your own. Don't ask permission for every folder or variable name.
+Product decisions cover persistence store, auth architecture, vendors, and breaking domain rules. Bundle missing product decisions into one short question before implementing.
+
+---
+
+## 2. The first representative slice
+
+Avoid horizontal layering without working behavior. Do not generate empty directories, unused interfaces, speculative repositories, or generic wrappers that serve no active flow.
+
+Build a single, real, end-to-end slice that crosses the system's primary architectural boundaries. The shapes below are illustrative examples, not mandatory architectures:
+
+| Project Type | Example Slice Shape (Illustrative) |
+|---|---|
+| **CLI Tool** | Input parsing (flags/arguments) → core logic → observable output and exit status. (A simple tool does not require multiple internal layers). |
+| **API / Service** | Request intake → route handler → domain logic/validation → response. (Persistence is included only if the service actually requires state; stateless services, proxies, and aggregators do not need persistence layers). |
+| **Web / UI** | User interaction/event → state transition/store update → observable UI rendering (including empty/loading/error states). |
+| **Library / Package** | Public API export → core implementation → return value / error handling. (Libraries do not need an app server or startup daemon). |
+| **Worker / Job** | Task intake/deserialization → business processing → outcome persistence, acknowledgment, or retry handling. |
+
+Verify both the successful path and meaningful domain failure modes (e.g., validation failure, not found, unauthenticated).
+
+If external integrations cannot be run locally, simulated stubs are permitted only when explicitly acknowledged; never describe a mock integration as real.
+
+---
+
+## 3. Tooling and instructions setup
+
+Establish the minimal commands necessary for an agent or developer to run and verify the project using stack-native configuration:
+
+1. **Native configuration:** Place commands in standard stack files (`package.json`, `pyproject.toml`, `Makefile`, `Cargo.toml`, `go.mod`, etc.).
+2. **Commands fit the project type:**
+   - Run/start command for local execution (only when applicable; libraries and utility packages do not need a start command).
+   - Test command executing automated checks.
+   - Lint/format command if idiomatic to the stack.
+3. **Instructions handling:**
+   - If the repository already has an instructions file (e.g., `AGENTS.md` or `README.md`), update it minimally only if needed to record new commands or invariants. Never overwrite or recreate existing instructions just because you are in Bootstrap mode.
+   - If no instructions file exists and the host/workflow uses one, create a concise file (around 300–700 tokens) pointing to commands and noting key constraints.
+
+---
+
+## 4. Establishing reference code
+
+Code created during bootstrap serves as precedent for future development only when it satisfies all of the following:
+
+1. **Traceable:** Directly satisfies a concrete user requirement or contract.
+2. **Observable verification:** Accompanied by automated checks whose expected values reflect business outcomes rather than copying internal implementation details.
+3. **Appropriate ownership and dependencies:** Modules have clear responsibilities and dependency directions suited to the chosen architecture and actual project requirements, without forcing unnecessary layers (e.g., transport/domain/persistence separation is not required for a small CLI, library, or script).
+4. **No unexplained debt:** Contains no unexplained workarounds, commented-out dead code, or temporary hacks.
+5. **Bounded scope:** If a convention applies only to a specific module, document it as module-local rather than an overarching repository standard.
+
+No code pattern is permanently "golden." When requirements change or architecture evolves, update reference paths rather than maintaining obsolete conventions.

package/bundled-skills/repo-foundation/references/companion.md

@@ -0,0 +1,9 @@
+# Companion Coordination (`repo-native-refactor`)
+
+Read this when a meaningful checkpoint is done and you consider one cleanup pass.
+
+- **Complementary roles:** Foundation builds, implements, and adapts; Refactor audits, tightens prose, removes residue, and aligns conventions within scope. Foundation does not reimplement refactor's taxonomy or risk bands; Refactor does not revert intentional, requested behavioral changes.
+- **Discovery and fallback:** Locate companion through host-supported discovery only; do not hardcode paths, download, or assume mentioning the name triggers execution. Foundation operates fully without companion. Mention its absence only when that leaves a requested review incomplete. Same-agent self-review is not independent review.
+- **Invocation timing:** Use a pass when the user requests review or a substantial contract, ownership, or semantic change warrants a scoped audit. Skip automatic passes for lightweight fixes unless concrete unresolved concerns warrant one; an explicit review request still applies.
+- **Minimal handoff contract:** Transfer objective/scope/intentional changes, baseline & user changes, contracts & precedents, check status & limitations from existing context without creating handoff files.
+- **Post-cleanup and loop limits:** Rerun affected checks on final code state after refactor edits. Perform at most one refactor pass per checkpoint by default; iterate only on concrete findings or failing checks. If a product decision is missing, ask the user; do not guess or unilaterally redesign.

package/bundled-skills/repo-foundation/references/continuity.md

@@ -0,0 +1,50 @@
+# Continuity: session handover and reconciling state
+
+Use this reference when resuming work in a new session, taking over a repository, or when recorded notes disagree with the actual codebase.
+
+---
+
+## 1. Reconciling notes with code reality
+
+When taking over an ongoing project, compare documented status with the actual state of the working tree.
+
+Code shows what the software does right now. That alone doesn't prove it meets the requirements or acceptance criteria.
+
+When notes and code conflict, cross-check requirements and tests first.
+Go back to the user's original requirements, preserved contracts, and actual test coverage.
+Passing tests are not a rubber stamp.
+Green tests don't declare a feature complete if acceptance criteria or edge cases were never tested.
+Don't edit notes just to legitimize whatever code happens to be there.
+Investigate before updating.
+Notes say pending but code looks done? Verify against the requirement and run or add acceptance checks.
+If truly complete and verified, update the notes.
+If partial or defective, fix the code.
+Don't rubber-stamp the notes.
+Never do a blind rollback.
+Don't delete working code just because some stale note doesn't mention it.
+If intent is ambiguous, ask the user.
+
+---
+
+## 2. Working in dirty workspaces
+
+Users often call agents into workspaces with uncommitted work. Inspect `git status` (or directory state when not using Git) before modifying files; inventory comes first only in the sense that mutation must wait for it.
+Identify uncommitted changes belonging to the user and do not discard or clobber them.
+Protecting user changes does *not* forbid editing the entire file.
+You may modify distinct, relevant parts of the same file as long as the user's uncommitted changes remain intact and functional.
+Only stop and ask if there is an actual conflict or if the user's intent cannot be determined.
+The baseline for verification and diffing includes the base commit plus the pre-existing uncommitted modifications.
+Your changes must stay distinguishable from earlier user changes.
+Never execute `git commit`, `git stash`, or `git reset` automatically to create a clean slate unless the user explicitly commands it.
+No forced commits.
+
+---
+
+## 3. Handing over a session
+
+When ending a session or preparing a handoff for another agent or developer, reuse existing channels.
+Record state in existing project tracking mechanisms (e.g., project issue trackers, `TODO` lists, or brief handover notes).
+Do not create ad-hoc handoff files for routine features.
+A concise handoff says what got done and verified, the working tree status, remaining limits or next steps, and which verification commands ran with what outcome.
+Do not append ongoing session logs or raw conversation transcripts to permanent repository instruction files (like `AGENTS.md`).
+Keep instructions focused on lasting architecture and workflows.