@martinffx/atelier 1.0.2 → 1.1.0

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # Changelog
 
+## [1.1.0](https://github.com/martinffx/atelier/compare/v1.0.2...v1.1.0) (2026-05-23)
+
+
+### Features
+
+* **skills:** add oracle-grillme socratic interrogation skill ([6ad5ce5](https://github.com/martinffx/atelier/commit/6ad5ce52428863b51fec83880ce8083bb80aa3a0))
+* **skills:** add oracle-grillme socratic interrogation skill ([fd21606](https://github.com/martinffx/atelier/commit/fd2160639b82ba335963bec3128d9c6a5b5801b6))
+* **skills:** add PR creation workflow to code-commit ([25bb826](https://github.com/martinffx/atelier/commit/25bb8264364cb1c5ee843baea0127eaba3935c78))
+
 ## [1.0.2](https://github.com/martinffx/atelier/compare/v1.0.1...v1.0.2) (2026-05-23)
 
 

package/README.md

@@ -29,7 +29,7 @@ That's it. Your project is now configured for spec-driven development.
 
 Atelier sets up three things in your project:
 
-### 1. Skills (34 available)
+### 1. Skills (30 available)
 
 Specialized knowledge modules that auto-invoke based on context. Install them via the CLI (`--all` flag) or separately:
 
@@ -194,10 +194,6 @@ Task-specific tools you invoke when you need them.
 - `code-review` — Multi-agent code review with specialized reviewers
 - `code-debug` — Systematic debugging workflow
 - `code-docs` — README, API docs, changelog generation
-- `code-security` — Security audit and vulnerability detection
-- `code-perf` — Performance profiling and optimization
-- `code-git-worktrees` — Isolated git worktrees for feature work
-- `code-stacked-commit` — Manage stacked commits with Graphite
 - `code-subagents` — Dispatch patterns for parallel implementation
 
 Skills are auto-invoked based on their description when you work with relevant technologies. No commands needed—just install and AI agents will use them when appropriate.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@martinffx/atelier",
-  "version": "1.0.2",
+  "version": "1.1.0",
   "description": "Personal development toolkit - spec-driven development, code quality, deep thinking, and ecosystem patterns",
   "type": "module",
   "bin": {

package/skills/{code-conventional-commit → code-commit}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: code-conventional-commit
+name: code-commit
 description: Generate and validate conventional commit messages following the conventionalcommits.org spec. Use whenever the user wants to commit code, mentions commit messages, git commit, or asks to create a commit. Triggers on "commit", "git commit", "conventional", or when reviewing commit message format.
 user-invocable: true
 ---
@@ -76,6 +76,21 @@ When user asks to validate or check a commit message:
 4. Check subject follows rules (lowercase, imperative, no period)
 5. Flag any issues found
 
+### 3. Create Pull Request
+
+When user wants to open a PR or after finishing commits on a feature branch:
+
+1. Verify on a feature branch (not main): `git branch --show-current`
+2. Check for project PR template: `ls .github/PULL_REQUEST_TEMPLATE.md`
+3. Push branch if needed: `git push -u origin <branch>`
+4. Create PR via `gh pr create`:
+   - Use `--fill` if commits are clean (auto-populates title/body)
+   - Use `--draft` for work-in-progress
+   - Use interactive mode if body needs custom content
+5. Show the PR URL to the user
+
+See [references/pr-workflow.md](references/pr-workflow.md) for full workflow details.
+
 ## Input Methods
 
 | Input | Action |

package/skills/code-commit/references/pr-workflow.md

@@ -0,0 +1,145 @@
+# Pull Request Workflow
+
+Creating GitHub pull requests via the `gh` CLI.
+
+## Prerequisites
+
+- `gh` CLI installed and authenticated: `gh auth status`
+- Remote `origin` points to GitHub: `git remote -v`
+- On a feature branch (not main): `git branch --show-current`
+
+## Check for Project Template
+
+Before creating a PR, check if the project has its own PR template:
+
+```bash
+# Check for PR template in .github/
+ls .github/PULL_REQUEST_TEMPLATE.md 2>/dev/null || echo "No project template found"
+```
+
+**If found:** Use it. The `gh pr create` command will automatically pick it up.
+
+**If not found:** Use the minimal template below.
+
+---
+
+## Create Pull Request
+
+### Option 1: Auto-fill from commits (recommended)
+
+```bash
+gh pr create --fill
+```
+
+This uses the commit messages as the PR title and body. Best when commits are clean and conventional.
+
+### Option 2: Interactive
+
+```bash
+gh pr create
+```
+
+Opens an editor with the template. Fill in title and body interactively.
+
+### Option 3: Inline (for simple PRs)
+
+```bash
+gh pr create --title "feat(auth): add JWT authentication" --body "Implements token-based auth with refresh support."
+```
+
+---
+
+## PR Title Format
+
+Follow conventional commit style for PR titles:
+
+```
+<type>(<scope>): <description>
+```
+
+Examples:
+- `feat(api): add user profile endpoint`
+- `fix(db): resolve connection pool leak`
+- `docs(readme): update installation instructions`
+
+---
+
+## PR Body Template (fallback if no project template)
+
+```markdown
+## Description
+<!-- What does this PR do? -->
+
+## Changes
+<!-- What changed? -->
+
+## Testing
+<!-- How was this tested? -->
+
+## Checklist
+- [ ] Tests pass
+- [ ] Commits follow conventional format
+- [ ] Documentation updated (if needed)
+```
+
+---
+
+## Linking Issues
+
+Add issue references in the PR body:
+
+```markdown
+Closes #123
+Fixes #456
+Relates to #789
+```
+
+This auto-closes linked issues when the PR merges.
+
+---
+
+## Draft PRs
+
+For work-in-progress PRs:
+
+```bash
+gh pr create --draft
+```
+
+Mark as ready later:
+
+```bash
+gh pr ready <pr-number>
+```
+
+---
+
+## Review Requests
+
+Request reviewers after creating the PR:
+
+```bash
+gh pr edit <pr-number> --add-reviewer username
+```
+
+Or add via the GitHub web UI.
+
+---
+
+## Verify PR Created
+
+```bash
+gh pr view --web  # Open in browser
+gh pr status      # Show PR status
+```
+
+---
+
+## Common Mistakes
+
+| Mistake | Fix |
+|---------|-----|
+| PR from main branch | Switch to feature branch first |
+| No remote | `git remote add origin <url>` |
+| Unpushed commits | `git push -u origin <branch>` |
+| PR body is empty | Use `--fill` or write a description |

package/skills/code-debug/SKILL.md

@@ -240,16 +240,12 @@ const name = user.profile.name;
 2. Identify hot paths
 3. Optimize the bottleneck
 
-**See code-perf skill for detailed performance debugging.**
-
 ---
 
 ## Skill Loading
 
 Check available skills for additional debugging support:
 
-- If dealing with performance issues → load code-perf
-- If security vulnerability suspected → load code-security
 - If debugging tests → load oracle-testing
 
 ---

package/skills/code-review/references/reviewers.md

@@ -97,8 +97,6 @@ Output findings in this format:
 - **Pre-existing**: Yes/No (check if existed before this PR)
 ```
 
-Loads: `code-security` (if exists)
-
 ---
 
 ### Performance Reviewer
@@ -128,8 +126,6 @@ Output findings in this format:
 - **Pre-existing**: Yes/No
 ```
 
-Loads: `code-perf` (if exists)
-
 ---
 
 ### Correctness Reviewer
@@ -532,8 +528,6 @@ Each reviewer should load relevant skills before reviewing:
 
 | Reviewer Type | Skills to Load |
 |---------------|----------------|
-| Security | `code-security` |
-| Performance | `code-perf` |
 | Correctness | Language-specific (`typescript-testing`, `python-testing`, etc.) |
 | Maintainability | Testing skills |
 | Architecture | `oracle-architect` |
@@ -580,10 +574,9 @@ prompt: |
 
   YOUR FIRST TASK - LOAD SKILLS:
   As a Security Reviewer, you should load relevant skills before reviewing:
-  1. Load `skill: code-security` - Use the `skill` tool
-  2. Load `skill: typescript-testing` (if available) - Use the `skill` tool
+  1. Load `skill: typescript-testing` (if available) - Use the `skill` tool
 
-  These skills contain security patterns and TypeScript testing guidance that will help you identify issues.
+  This skill contains TypeScript testing guidance that will help you identify issues.
 
   Focus areas after loading skills:
   - Authentication and authorization flaws
@@ -663,8 +656,7 @@ prompt: |
 
   YOUR FIRST TASK - LOAD SKILLS:
   As a PerformanceOperator Reviewer, you should load relevant skills before reviewing:
-  1. Load `skill: code-perf` (if available) - Use the `skill` tool
-  2. Load `skill: typescript-testing` (if available) - Use the `skill` tool
+  1. Load `skill: typescript-testing` (if available) - Use the `skill` tool
 
   Focus areas after loading skills:
   - Performance issues that matter in prod

package/skills/code-review/references/rq.md

@@ -62,8 +62,7 @@ prompt: |
   4. **Identify skills to load** based on detected language/framework:
      - TypeScript → typescript-testing, typescript-fastify (if fastify framework)
      - Python → python-testing, python-fastapi (if fastapi framework)
-     - Security concerns → code-security
-     - Performance concerns → code-perf
+     
 
   Return ONLY valid JSON (no markdown, no code blocks):
   {
@@ -73,7 +72,7 @@ prompt: |
       "domain": "web-api|frontend|database|..."
     },
     "reviewers": ["Security", "Correctness"],
-    "skills_to_load": ["typescript-testing", "code-security"]
+    "skills_to_load": ["typescript-testing"]
   }
 ```
 
@@ -83,7 +82,7 @@ prompt: |
 {
   "context": { "language": "typescript", "framework": "fastify", "domain": "web-api" },
   "reviewers": ["Security", "Correctness", "PerformanceOperator"],
-  "skills_to_load": ["typescript-testing", "code-security"]
+  "skills_to_load": ["typescript-testing"]
 }
 ```
 
@@ -102,7 +101,7 @@ prompt: |
 Before dispatching reviewers, the detected skills are passed to each reviewer:
 ```json
 {
-  "skills_to_load": ["typescript-testing", "code-security"]
+  "skills_to_load": ["typescript-testing"]
 }
 ```
 

package/skills/oracle-grillme/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: oracle-grillme
+description: >
+  Socratic interrogation of plans against the project's domain model and documented decisions.
+  Use when the user wants to stress-test a plan, clarify terminology, or validate assumptions
+  against existing domain language. Updates CONTEXT.md and ADRs inline as decisions crystallise.
+user-invocable: true
+---
+
+# Grill Me
+
+Relentless questioning of your plan against the project's domain model, sharpening terminology and updating documentation (CONTEXT.md, ADRs) inline as decisions crystallise.
+
+## When to Use
+
+- **Stress-testing a plan** — "I want to add a refund flow to the Order service"
+- **Clarifying fuzzy language** — "We're calling it 'account' but is that a Customer or a User?"
+- **Onboarding to a domain** — "Walk me through how the Billing context relates to Ordering"
+- **Before writing specs** — Ensuring the domain language is solid before `spec-research` begins
+- **After code review** — "The PR introduces 'cancellation' but our glossary says..."
+
+## When NOT to Use
+
+- **Simple implementation questions** — Use `oracle-challenge` or `oracle-architect` instead
+- **Debugging** — Use `code-debug`
+- **Testing strategy** — Use `oracle-testing`
+- **Already in spec workflow** — Use `spec-research` + `oracle-architect` for domain discovery during the spec process
+
+---
+
+## How It Works
+
+<interview-loop>
+
+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, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+</interview-loop>
+
+---
+
+## Domain Awareness
+
+### Discovering Context
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+### During the Session
+
+#### Challenge Against the Glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately.
+
+> "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+#### Sharpen Fuzzy Language
+
+When the user uses vague or overloaded terms, propose a precise canonical term.
+
+> "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+#### Discuss Concrete Scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+#### Cross-Reference With Code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it:
+
+> "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+#### Update CONTEXT.md Inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [references/CONTEXT-FORMAT.md](./references/CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+#### Offer ADRs Sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [references/ADR-FORMAT.md](./references/ADR-FORMAT.md).
+
+---
+
+## Usage Examples
+
+### Stress-Test a New Feature
+```
+/grillme "I want to add a refund flow to the Order service"
+```
+> "Before we go further — your glossary defines 'Order' as a completed purchase. A refund implies the Order is no longer complete. Is 'refund' a state on Order, or a new concept entirely?"
+
+### Clarify Ambiguous Terms
+```
+/grillme "We need to handle 'account' deletions"
+```
+> "You said 'account' — your CONTEXT.md has both Customer and User. Which one are we deleting, and what happens to their Orders?"
+
+### Validate Against Existing Decisions
+```
+/grillme "I'm switching the write model from Postgres to DynamoDB"
+```
+> "ADR-0002 says we chose Postgres for the write model because of ACID requirements. Have those requirements changed, or is this a new trade-off?"
+
+### Onboard to a Domain
+```
+/grillme "Explain how Billing relates to Ordering"
+```
+> "Ordering emits OrderPlaced events. Billing consumes them to create Invoices. But your CONTEXT.md says Invoice is a request for payment — who decides when payment is actually processed?"
+
+---
+
+## Relationship to Other Skills
+
+| Skill | Use When |
+|-------|----------|
+| **oracle-grillme** | Questioning domain assumptions, sharpening terminology, updating docs inline |
+| **oracle-challenge** | Critically evaluating a technical approach or decision |
+| **oracle-architect** | Designing components, data models, API contracts during spec-research |
+| **spec-research** | Structured discovery + architecture → spec.md (use grillme before this to solidify language) |
+
+**Key distinction:**
+- `oracle-challenge` = "Is this approach valid?" (critical evaluation)
+- `oracle-grillme` = "What do we mean by these words?" (domain interrogation)

package/skills/oracle-grillme/references/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional Sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to Offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What Qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

package/skills/oracle-grillme/references/CONTEXT-FORMAT.md

@@ -0,0 +1,63 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
+- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Show relationships.** Use bold term names and express cardinality where obvious.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+- **Write an example dialogue.** A conversation between a dev and a domain expert that demonstrates how the terms interact naturally and clarifies boundaries between related concepts.
+
+## Single vs Multi-Context Repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

package/skills/spec-finish/SKILL.md

@@ -84,12 +84,10 @@ Use the Skill tool to invoke code-review skill for comprehensive code review.
 
 ## Step 3: Stack Commits
 
-Use the Skill tool to invoke code-stacked-commit skill.
-
 ### Workflow
-1. Review current stack: `gt stack`
+1. Review current commits: `git log --oneline`
 2. Ensure commits are organized logically
-3. Restack if needed: `gt branch restack`
+3. Rebase if needed: `git rebase -i <base-branch>`
 4. Ensure each commit is clean and functional
 
 ### Commit Guidelines
@@ -147,7 +145,6 @@ Optional - use code-docs skill if needed.
 This skill orchestrates other skills:
 
 - Invokes code-review for quality check
-- Invokes code-stacked-commit for commit management
 - Invokes code-docs if documentation needs updates
 
 ---

package/skills/spec-implement/SKILL.md

@@ -117,7 +117,7 @@ criteria before writing implementation.
 3. Run them — verify they fail for the RIGHT reason
 4. Implement minimal code to make tests pass
 5. Refactor if needed (tests stay green)
-6. Commit (use code-conventional-commit for commit message)
+6. Commit (use code-commit for commit message)
 ```
 
 Do NOT write implementation before tests. Do NOT skip "verify it fails." Do NOT write

package/skills/code-conventional-commit/evals/evals.json

@@ -1,23 +0,0 @@
-{
-  "skill_name": "conventional-commit",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "Generate a commit message for these changes: Added a new user profile page component that displays user name, email, and avatar. Also added a settings modal for updating preferences.",
-      "expected_output": "Should produce a feat commit with proper scope, imperative subject, and optional body",
-      "files": []
-    },
-    {
-      "id": 2,
-      "prompt": "Validate this commit message: 'feat: added new login page' - is it valid conventional commit format?",
-      "expected_output": "Should identify issues: subject should be lowercase, imperative (add not added), possibly missing scope",
-      "files": []
-    },
-    {
-      "id": 3,
-      "prompt": "I made breaking changes to the API - the old /v1/users endpoint now returns different JSON structure. Create a commit message that properly indicates this is a breaking change.",
-      "expected_output": "Should produce a commit with ! in type (e.g., feat! or fix!) and BREAKING CHANGE footer",
-      "files": []
-    }
-  ]
-}

package/skills/code-conventional-commit/workspace/iteration-1/eval-0/with_skill/outputs/commit-message.txt

@@ -1,4 +0,0 @@
-feat(profile): add user profile page with settings modal
-
-Adds new profile page component displaying user name, email, and
-avatar. Includes settings modal for updating user preferences.

package/skills/code-conventional-commit/workspace/iteration-1/eval-0/with_skill/outputs/eval_metadata.json

@@ -1,6 +0,0 @@
-{
-  "eval_id": 0,
-  "eval_name": "generate-commit",
-  "prompt": "Generate a commit message for these changes: Added a new user profile page component that displays user name, email, and avatar. Also added a settings modal for updating preferences.",
-  "assertions": []
-}

package/skills/code-conventional-commit/workspace/iteration-1/eval-1/with_skill/outputs/eval_metadata.json

@@ -1,6 +0,0 @@
-{
-  "eval_id": 1,
-  "eval_name": "validate-commit",
-  "prompt": "Validate this commit message: 'feat: added new login page' - is it valid conventional commit format?",
-  "assertions": []
-}