@jaybeeuu/agent-cortex 1.20.0

package/skills/planning/write-a-ticket/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: write-a-ticket
+description: Write a well-structured ticket for an external issue tracker (e.g. Jira). Use when writing tickets intended for a human engineering audience — not for creating implementation tasks in a ralph/bd loop.
+---
+
+# Write a Ticket
+
+Tickets are for skilled engineers. They should be able to pick one up, understand the context immediately, know where to start, and deliver the right outcome — without having to ask questions or wade through noise.
+
+**Write for clarity, not coverage.** A ticket is not a specification. Prefer one well-chosen sentence over three that say the same thing.
+
+---
+
+## Process
+
+### 1. Gather context
+
+Before drafting, confirm you have:
+- The goal of the work
+- Which epic, RFC, or initiative this belongs to (if any)
+- Any known constraints or decisions already made
+- Relevant code locations, schemas, or prior art
+
+If anything is unclear, ask before writing.
+
+### 2. Draft the ticket
+
+Use the template below. Every section has a purpose — do not pad it, and do not omit a required section without good reason.
+
+### 3. Review against the checklist
+
+Before finalising, check:
+- [ ] Could a skilled engineer start this immediately with no follow-up questions?
+- [ ] Is every sentence earning its place? Remove anything that doesn't add information.
+- [ ] Are acceptance criteria verifiable, not vague?
+- [ ] Do technical notes point at the right things without over-prescribing the solution?
+
+---
+
+## Template
+
+```markdown
+## Context
+
+<1–3 sentences. Set the scene: why does this work exist, what larger initiative is it part of?
+Link to the relevant epic, RFC, ADR, or prior ticket — don't duplicate their content here.>
+
+## Description
+
+<What needs to be built or changed. Describe the outcome, not the implementation steps.
+Be specific about scope — what is in and what is explicitly out.>
+
+## Acceptance criteria
+
+- [ ] <Specific, verifiable criterion>
+- [ ] <Specific, verifiable criterion>
+- [ ] <Specific, verifiable criterion>
+
+## Technical notes
+
+<Links to relevant code, suggested request/response/document schemas, architectural decisions,
+or guidance the implementer should know. This is a pointer, not a design document —
+if a decision needs more space, it belongs in an ADR or RFC.>
+
+## Testing strategy
+
+<Optional. Agreed testing levels for this change: e.g. unit, integration, contract, E2E.
+Only include if there is something non-obvious to say.>
+
+## Monitoring strategy
+
+<Optional. How will this change be observed in production? e.g. new metrics, alerts, log events,
+dashboards, or feature flag rollout stages. Only include if the change has non-obvious observability
+requirements or a specific rollout approach was agreed.>
+
+## Notes
+
+<Optional. Anything else that is genuinely useful and doesn't fit above.>
+```
+
+---
+
+## Guidance per section
+
+**Context** — one job: explain *why*. A reader should understand the motivation without opening another tab. Link freely; copy-paste never.
+
+**Description** — describes *what*, not *how*. Avoid implementation steps. If scope boundaries matter, state them explicitly ("this ticket does not include X").
+
+**Acceptance criteria** — must be independently verifiable. Avoid "works correctly" or "is tested". Prefer "given X, the API returns Y" or "the migration runs without errors on staging".
+
+**Technical notes** — share what the implementer needs to know, not everything you know. Good candidates: a tricky code location, a schema that has already been agreed, a constraint from an upstream system. Bad candidates: a tutorial on the technology, decisions that haven't been made yet.
+
+**Testing strategy** — omit if the team's default testing conventions apply. Include only when this ticket has unusual testing requirements or a specific agreement was reached.
+
+**Monitoring strategy** — omit if the change has no meaningful observability footprint. Include when the ticket introduces new metrics, requires new alerts, involves a phased rollout, or has an agreed approach to validating success in production.
+
+**Notes** — a catch-all for genuinely relevant information that has no other home. If you're reaching for it often, the ticket probably needs restructuring.

package/skills/productivity/bd-tool/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: bd-tool
+description: Load project context and task state using the beads (bd) task tracker. Use when asked to work on a bead, pick up a task, or check what is available — or when the user mentions "beads", "bd", "bead", or "prime".
+---
+
+# bd-tool
+
+This project uses **bd (beads)** for task tracking. This doc covers how we use it.
+
+## First thing: `bd prime`
+
+Always run this at the start of a session — it loads project context, conventions, and open tasks.
+
+```bash
+bd prime
+```
+
+Hold the full output for your own context. Subagents can run `bd prime` themselves if they need project context.
+
+## Finding and claiming work
+
+```bash
+bd ready          # list unblocked tasks
+bd show <id>      # view full description, labels, dependencies
+bd update <id> --claim
+```
+
+## Labels
+
+We use labels to track state. Key patterns:
+
+| Label | Purpose | Example |
+|---|---|---|
+| `stage:<id>` | Pipeline stage for chore beads | `stage:code`, `stage:verify` |
+| `implementation-type:<type>` | Who works it | `afk`, `hitl` |
+| `lifecycle:<phase>` | Lifecycle gate | `feature-pr` |
+| `epic:<id>` | Parent epic link | `epic:abc-123` |
+| `priority:<level>` | Priority (0-3) | `priority:1` |
+
+## Creating work
+
+For new tasks with pipeline expansion:
+
+```bash
+# use the create-task skill, or manually:
+bd create "<title>" -d "<description>" -p <0-3>
+```
+
+For parent-child relationships (create with `--parent`):
+
+```bash
+bd create "<title>" --parent <parent-id>
+```
+
+For blocking dependencies between beads:
+
+```bash
+bd dep add <id> <blocked-by-id> --type blocks
+```
+
+## Completing work
+
+```bash
+bd close <id> --reason="Description of what was done"
+```
+
+Always add a reason (e.g. PR link).
+
+## Syncing
+
+```bash
+bd dolt push
+```
+
+Optional — beads work locally. Sync at session end when it's convenient.
+
+## Key conventions
+
+- **Priority**: 0 = critical, 1 = high, 2 = medium, 3 = low, 4 = backlog. Aliased as P0-P4.
+- **HITL beads**: require human action — do not claim or implement them. Inform the user.
+- **Chore beads** (`--type chore`): auto-created pipeline stages. Do not create them manually — use `create-task`. Not ephemeral — they must stay visible to plain `bd ready` for ralph to discover them.
+
+## Cross-skill references
+
+| When you need… | Use this skill |
+|---|---|
+| Creating a new task with pipeline expansion | `create-task` |
+| Executing a single pipeline stage | `run-pipeline-stage` |
+| Running the full end-to-end pipeline | `ralph` |
+| Classifying a bead's implementation type | `classify-bead` |

package/skills/productivity/grill-me/SKILL.md

@@ -0,0 +1,10 @@
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.

package/skills/productivity/handoff/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: handoff
+description: Compact the current conversation into a handoff document for another agent to pick up.
+argument-hint: "What will the next session be used for?"
+---
+
+Write a handoff document summarising the current conversation so a fresh agent can continue the work. Save to the temporary directory of the user's OS - not the current workspace.
+
+Include a "suggested skills" section in the document, which suggests skills that the agent should invoke.
+
+Do not duplicate content already captured in other artifacts (PRDs, plans, ADRs, issues, commits, diffs). Reference them by path or URL instead.
+
+Redact any sensitive information, such as API keys, passwords, or personally identifiable information.
+
+If the user passed arguments, treat them as a description of what the next session will focus on and tailor the doc accordingly.

package/skills/productivity/init-beads/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: init-beads
+description: Install and initialise the beads (bd) task-tracker in the current project using stealth mode. Use when the user wants to set up beads, install bd, initialise beads, or mentions "bd init".
+---
+
+# Init Beads
+
+Install and initialise the `bd` CLI task tracker in the current project. Prefer stealth mode — minimise commits to the main repo and questions to the user.
+
+## Quick start
+
+```bash
+# Install bd if missing
+brew install beads          # macOS/Linux (preferred)
+npm install -g @beads/bd    # fallback
+
+# Initialise in the project (stealth)
+bd init --quiet --stealth
+```
+
+## Workflow
+
+### 1. Check if `bd` is installed
+
+```bash
+which bd || bd version
+```
+
+If missing, install silently:
+
+| Platform | Command |
+|----------|---------|
+| macOS / Linux (Homebrew) | `brew install beads` |
+| npm available | `npm install -g @beads/bd` |
+| Go available | `go install github.com/steveyegge/beads/cmd/bd@latest` |
+| Any (script) | `curl -fsSL https://raw.githubusercontent.com/steveyegge/beads/main/scripts/install.sh \| bash` |
+
+Prefer Homebrew → npm → script. Do NOT ask the user which method to use — detect and decide.
+
+### 2. Check if beads is already initialised
+
+```bash
+bd version 2>/dev/null && ls .beads/ 2>/dev/null
+```
+
+If `.beads/` already exists, skip `bd init` and tell the user.
+
+### 3. Initialise beads
+
+Always use `--quiet --stealth`:
+
+```bash
+bd init --quiet --stealth
+```
+
+`--stealth` keeps everything local — no git hooks, no commits to the main repo.  
+`--quiet` suppresses the interactive wizard.
+
+### 4. Update AGENTS.md
+
+If `AGENTS.md` exists, append the beads quick-reference block if it isn't already there.  
+If it doesn't exist, create it.
+
+```markdown
+## Task tracking
+
+This project uses **bd (beads)** for task tracking.
+
+Run `bd prime` at the start of each session for context.
+
+Quick reference:
+- `bd ready` — list unblocked work
+- `bd create "Title" -p <0-3>` — create a task (P0 = critical)
+- `bd update <id> --claim` — claim a task
+- `bd close <id>` — complete a task
+- `bd dolt push` — sync to remote at session end
+```
+
+### 5. Report
+
+Print a brief summary:
+- Whether `bd` was installed or already present
+- Whether beads was initialised or already set up
+- Whether AGENTS.md was created or updated
+
+Do NOT ask the user to confirm before any of these steps. Just do it.
+
+## Stealth mode rules
+
+- Always pass `--stealth` and `--quiet` to `bd init`
+- Never install git hooks unless the user explicitly asks
+- Never commit `.beads/` to the repo (it's local-only in stealth mode)
+- Prefer non-interactive install methods at every step

package/skills/productivity/teach/GLOSSARY-FORMAT.md

@@ -0,0 +1,35 @@
+# GLOSSARY.md Format
+
+`GLOSSARY.md` is the canonical language for this teaching workspace. All explainers, exercises, and learning records should adhere to its terminology. Building it is itself part of learning: compressing a concept into a tight definition is evidence the user understands it.
+
+## Structure
+
+```md
+# {Topic} Glossary
+
+{One or two sentence description of the topic this glossary covers.}
+
+## Terms
+
+**Hypertrophy**:
+Muscle growth driven by mechanical tension and metabolic stress over repeated training sessions.
+_Avoid_: Bulking, getting big
+
+**Progressive overload**:
+Systematically increasing the demand on a muscle over time — via load, volume, or intensity.
+_Avoid_: Pushing harder, levelling up
+
+**RPE (Rate of Perceived Exertion)**:
+A 1–10 self-rating of how hard a set felt, where 10 is failure and 8 means two reps left in the tank.
+_Avoid_: Effort score, intensity rating
+```
+
+## Rules
+
+- **Add a term only when the user understands it.** The glossary is a record of compressed knowledge, not a dictionary the user reads to learn. If the user has just been introduced to a concept, wait until they can use it correctly before promoting it here.
+- **Be opinionated.** When several words exist for the same concept, pick the best one and list the rest as aliases to avoid. This is how language compresses.
+- **Keep definitions tight.** One or two sentences. Define what the term IS, not what it does or how to do it.
+- **Use the glossary's own terms inside definitions.** Once a term is in the glossary, prefer it everywhere — including inside other definitions. This is what makes complex terms easier to grasp later.
+- **Group under subheadings** when natural clusters emerge (e.g. `## Anatomy`, `## Programming`). A flat list is fine when terms cohere.
+- **Flag ambiguities explicitly.** If a term is used loosely in the wider field, note the resolution: "In this workspace, 'set' always means a working set — warm-ups are tracked separately."
+- **Revise as understanding deepens.** A definition the user wrote in week one may be wrong by week six. Update in place; do not leave stale entries.

package/skills/productivity/teach/LEARNING-RECORD-FORMAT.md

@@ -0,0 +1,46 @@
+# Learning Record Format
+
+Learning records live in `./learning-records/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc. Create the directory lazily — only when the first record is written.
+
+They are the teaching equivalent of ADRs: they capture non-obvious lessons, key insights, and stated prior knowledge that will steer future sessions. They are used to calculate the zone of proximal development.
+
+## Template
+
+```md
+# {Short title of what was learned or established}
+
+{1-3 sentences: what was learned (or what prior knowledge was established), and why it matters for future sessions.}
+```
+
+That is the whole format. A learning record can be a single paragraph. The value is recording _that_ this is now known and _why_ it changes what to teach next — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most records won't need them.
+
+- **Status** frontmatter (`active | superseded by LR-NNNN`) — useful when an earlier understanding turns out to be wrong and is replaced.
+- **Evidence** — how the user demonstrated the understanding (a question answered, an exercise completed, prior experience cited). Useful when the claim might be revisited.
+- **Implications** — what this unlocks or rules out for future sessions. Worth recording when non-obvious.
+
+## Numbering
+
+Scan `./learning-records/` for the highest existing number and increment by one.
+
+## When to write a learning record
+
+Write one when any of these is true:
+
+1. **The user demonstrated genuine understanding of something non-trivial** — not just exposure, but evidence they can use the concept correctly. This sets a new floor for what to teach next.
+2. **The user disclosed prior knowledge** — "I already know X." Record it so future sessions don't re-teach it. Also record the _depth_ claimed.
+3. **A misconception was corrected** — the user previously believed something wrong and now sees why. These are high-value: they predict future stumbling blocks for related topics.
+4. **The mission shifted in response to learning** — the user discovered they cared about something different than they thought. Cross-link to [[MISSION.md]] and update it.
+
+### What does _not_ qualify
+
+- Material that was merely covered. Coverage is not learning. Wait for evidence.
+- Anything already captured tersely in [[GLOSSARY.md]] as a term definition. Don't duplicate.
+- Session-by-session activity logs. Learning records are not a journal — they are decision-grade insights.
+
+## Supersession
+
+When a later record contradicts an earlier one (the user's understanding deepened or corrected), mark the old record `Status: superseded by LR-NNNN` rather than deleting it. The history of how understanding evolved is itself useful signal.

package/skills/productivity/teach/MISSION-FORMAT.md

@@ -0,0 +1,31 @@
+# MISSION.md Format
+
+`MISSION.md` lives at the workspace root. It captures the _reason_ the user is learning this topic. Every teaching decision — what to teach next, which resources to surface, which exercises to design — should trace back to this document.
+
+## Template
+
+```md
+# Mission: {Topic}
+
+## Why
+{1-3 sentences. The concrete real-world goal the user is chasing. What changes in their life or work when they have this skill? Avoid abstract framings like "to understand X" — push for the underlying outcome.}
+
+## Success looks like
+- {A specific, observable thing the user will be able to do}
+- {Another specific thing}
+- {…}
+
+## Constraints
+- {Time, budget, prior commitments, learning preferences, anything that bounds the approach}
+
+## Out of scope
+- {Adjacent topics the user explicitly does not want to chase right now — protects the zone of proximal development}
+```
+
+## Rules
+
+- **One mission per workspace.** If the user wants to learn two unrelated things, that is two workspaces.
+- **Concrete over abstract.** "Run a half marathon by October" beats "get fitter." "Ship a Rust CLI to my team" beats "learn Rust."
+- **Push back on vagueness.** If the user cannot articulate why, interview them before writing anything. A bad mission is worse than no mission.
+- **Revise when reality shifts.** Missions change. When the user's goal moves, update this file — don't leave a stale mission steering future sessions.
+- **Keep it short.** If `MISSION.md` runs past a screen, it has stopped being a compass and started being a plan.

package/skills/productivity/teach/RESOURCES-FORMAT.md

@@ -0,0 +1,32 @@
+# RESOURCES.md Format
+
+`RESOURCES.md` is the curated set of trusted sources for this topic. Knowledge for explainers should be drawn from here, not from parametric guesses. Wisdom comes from the communities listed here.
+
+## Structure
+
+```md
+# {Topic} Resources
+
+## Knowledge
+
+- [Book: _The Science and Practice of Strength Training_ — Zatsiorsky & Kraemer](https://example.com)
+  Foundational text on programming and adaptation. Use for: anything to do with periodisation, recovery, intensity zones.
+- [Article: "How Much Should I Train?" — Greg Nuckols (Stronger By Science)](https://example.com)
+  Evidence-based review of volume landmarks. Use for: weekly set targets per muscle group.
+
+## Wisdom (Communities)
+
+- [r/weightroom](https://reddit.com/r/weightroom)
+  High-signal subreddit, moderated against bro-science. Use for: programme critique, plateau troubleshooting.
+- Local: Tuesday strength class at {gym name}
+  Use for: real-time coaching feedback on lifts.
+```
+
+## Rules
+
+- **High-trust only.** Prefer primary sources, recognised experts, peer-reviewed work, and communities with strong moderation. If a resource is marketing dressed as education, leave it out.
+- **Annotate every entry.** A bare link is useless in three months. Add one line: what it covers and when to reach for it.
+- **Group by Knowledge / Wisdom.** Mirrors the philosophy in [SKILL.md](./SKILL.md). It is fine for a resource to appear in only one group.
+- **Surface gaps explicitly.** If no good resource exists for an area the mission needs, write a `## Gaps` section listing what is missing. This drives future search.
+- **Prune ruthlessly.** A resource that turned out to be wrong, shallow, or off-mission should be removed, not buried. Better five sharp sources than thirty mediocre ones.
+- **Record community preferences.** If the user has opted out of joining communities, note it here so future sessions don't keep proposing them.

package/skills/productivity/teach/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: teach
+description: Teach the user a new skill or concept, within this workspace.
+disable-model-invocation: true
+argument-hint: "What would you like to learn about?"
+---
+
+The user has asked you to teach them something. This is a stateful request - they intend to learn the topic over multiple sessions.
+
+## Teaching Workspace
+
+Treat the current directory as a teaching workspace. The state of their learning is captured in this directory in several files:
+
+- `MISSION.md`: A document capturing the _reason_ the user is interested in the topic. This should be used to ground all teaching. Use the format in [MISSION-FORMAT.md](./MISSION-FORMAT.md).
+- `./reference/*.html`: A directory of reference materials. These are the compressed learnings from the lessons - cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference.
+- `RESOURCES.md`: A list of resources which can be explored to ground your teaching in contextual knowledge, or to acquire knowledge and wisdom. Use the format in [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md).
+- `./learning-records/*.md`: A directory of learning records, which capture what the user has learned. These are loosely equivalent to architectural decision records in software development - they capture non-obvious lessons and key insights that may need to be revised later, or drive future sessions. These should be used to calculate the zone of proximal development. They are titled `0001-<dash-case-name>.md`, where the number increments each time. Use the format in [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md).
+- `./lessons/*.html`: A directory of lessons. A **lesson** is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in this workspace.
+- `NOTES.md`: A scratchpad for you to jot down user preferences, or working notes.
+
+## Philosophy
+
+To learn at a deep level, the user needs three things:
+
+- **Knowledge**, captured from high-quality, high-trust resources
+- **Skills**, acquired through highly-relevant interactive lessons devised by you, based on the knowledge
+- **Wisdom**, which comes from interacting with other learners and practitioners
+
+Before the `RESOURCES.md` is well-populated, your focus should be to find high-quality resources which will help the user acquire knowledge. Never trust your parametric knowledge.
+
+Some topics may require more skills than knowledge. Learning more about theoretical physics might be more knowledge-based. For yoga, more skills-based.
+
+## Lessons
+
+A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html` where the number increments each time.
+
+A lesson should be **beautiful** — clean, readable typography and layout — since the user will return to these later to review.
+
+The lesson should teach ONE THING only. It should be completable very quickly - but give the user a tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development.
+
+Make opening a lesson as easy as possible — ideally a single CLI command the user can run to open the HTML file in their browser.
+
+## The Mission
+
+Every lesson should be tied into the mission - the reason that the user is interested in learning about the topic.
+
+If the user is unclear about the mission, or the `MISSION.md` is not populated, your first job should be to question the user on why they want to learn this.
+
+Failing to understand the mission will mean knowledge acquisition is not grounded in real-world goals. Lessons will feel too abstract. You will have no way of judging what the user should do next.
+
+## Zone Of Proximal Development
+
+Each lesson, the learner should always feel as if they are being challenged 'just enough'.
+
+The user may specify an exact thing they want to learn. If they don't, figure out their zone of proximal development by:
+
+- Reading their `learning-records`
+- Figuring out the right thing to teach them based on their mission
+- Teach the most relevant thing that fits in their zone of proximal development
+
+A user may tell you that they already know about that topic. If so, record it in their `learning-records`.
+
+## Acquiring Knowledge & Skills
+
+Lessons should be designed around a skill the user is going to learn. The knowledge in the lesson should be only what's required to acquire that skill. You teach the knowledge first, then get the user to practice the skills via an interactive feedback loop.
+
+Knowledge should first be gathered from trusted resources. Use `RESOURCES.md` to keep track of them. Lessons should be littered with citations - links to external resources to back up any claim made. This increases the trustworthiness of the lesson, and gives the user a path to acquire more knowledge if they want to go deeper.
+
+Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear.
+
+### Skills
+
+Skills should be taught through interactive lessons. There are several tools at your disposal:
+
+- Interactive lessons, using quizzes and light in-browser tasks
+- Lessons which guide the user through a list of real-world steps to take (for instance, yoga poses)
+- In-agent quizzes, where you ask the user scenario-based questions about what they've learned
+
+Each of these should be based on a **feedback loop**, where the user receives feedback on their performance. This feedback loop should be as tight as possible, giving feedback immediately - and ideally automatically.
+
+## Acquiring Wisdom
+
+Wisdom comes from true real-world interaction - testing your skills outside the learning environment.
+
+When the user asks a question that appears to require wisdom, your default posture should be to attempt to answer - but to ultimately delegate to a **community**.
+
+A community is a place (online or offline) where the user can test their skills in the real world. This might be a forum, a subreddit, a real-world class (budget permitting) or a local interest group.
+
+You should attempt to find high-reputation communities the user can join. If the user expresses a preference that they don't want to join a community, respect it.
+
+## Reference Documents
+
+While creating lessons, you should also create reference documents. Lessons can reference these documents - they are useful for tracking raw units of knowledge useful across lessons.
+
+Lessons will rarely be revisited later - reference documents will be. They should be the compressed essence of the lesson, in a format designed for quick reference.
+
+Some learning topics lend themselves to reference:
+
+- Syntax and code snippets for programming
+- Algorithms and flowcharts for processes
+- Yoga poses and sequences for yoga
+- Exercises and routines for fitness
+- Glossaries for any topic with its own nomenclature
+
+Glossaries, in particular, are an essential reference. Once one is created, it should be adhered to in every lesson.
+
+## `NOTES.md`
+
+The user will sometimes express preferences of how they want to be taught, or things you should keep in mind. This is the place to record those preferences, so you can refer back to them when designing lessons or working with the user.

package/skills/productivity/validate-agent-dir/scripts/package.json

@@ -0,0 +1,15 @@
+{
+  "name": "@agent-cortex/validate-agent-dir",
+  "version": "1.0.0",
+  "private": true,
+  "type": "module",
+  "scripts": {
+    "test": "node --test --import tsx/esm validate-agent-dir.test.ts",
+    "typecheck": "tsc --noEmit"
+  },
+  "devDependencies": {
+    "@types/node": "^22.20.1",
+    "tsx": "^4.23.0",
+    "typescript": "^5.0.0"
+  }
+}