Claude Cursor Skill

source-driven

Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Not for remote, credential, publish, deploy, or irreversible changes.

LLM Mart · 0 points · 7 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download outlinedriven-odin-claude-plugin-plugins_odin-code_skills_source-driven-b05a1e3.zip · 3 KB

outlinedriven/odin-claude-plugin 37 0 forks Apache-2.0 Updated 12d ago

Part of outlinedriven/odin-claude-plugin — 120 skills

Install

skills CLI npx skills add https://github.com/OutlineDriven/odin-claude-plugin/tree/main/plugins/odin-code/skills/source-driven

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install outlinedriven-odin-claude-plugin@llmmart

Git git clone https://github.com/OutlineDriven/odin-claude-plugin.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole outlinedriven/odin-claude-plugin collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Source-driven development

Contract

Field	Bound contract
Trigger	The current task is writing or verifying framework-specific code, boilerplate, or a documented, correct implementation.
Authority	Reversible local: writes only framework-specific code plus full-URL citations; rollback is version control (revert to last commit on failure). No remote mutation.
Side effect	Local writes with explicit UNVERIFIED flags for unverifiable patterns.
Done	Every framework-specific decision is backed by a cited official source and unverified patterns are explicitly flagged.

Inputs

Framework context (required): the framework, language, or library.
Dependency file (required): package.json, requirements.txt, go.mod, Cargo.toml, Gemfile, composer.json, or pyproject.toml.
Stack examples (optional): examples supplied by the caller. This skill has no bundled stack-reference dependency.

Procedure

Read the project's dependency file and state the exact pinned versions. Done when: every dependency in the file has its pinned version stated.
For each dependency about to be written against, read the latest stable release from the release channel (registry, releases page, official download page). Report pinned and latest versions side by side. Name the gap when they differ. Done when: each touched dependency shows pinned and latest side by side, with the gap named when they differ.
Fetch the official documentation page for the exact feature being implemented. Use the source hierarchy: (1) official docs, (2) official blog/changelog, (3) web standards references (MDN, web.dev), (4) runtime compatibility references. Never use Stack Overflow, blog posts, tutorials, or training data as primary sources. Done when: the fetched page for each feature comes from the highest available tier of the hierarchy and no banned source is cited.
Extract the implementation patterns shown in the fetched docs. Use those exact API signatures. If the docs show a newer approach, use the newest one the pinned version supports. Do not use deprecated forms. Done when: every written API signature matches the fetched docs for the pinned version and no deprecated form remains.
When official sources contradict each other, report the discrepancy. Do not silently choose one. Done when: each contradiction surfaces as a CONFLICT DETECTED report rather than a silent pick.
Write code that follows the documented patterns. Every non-obvious decision gets a full-URL citation in a code comment. Quote the relevant passage when it supports a non-obvious decision. Done when: each non-obvious decision carries a full-URL citation, quoting the supporting passage where one exists.
Flag any pattern that could not be verified against official documentation with an explicit UNVERIFIED marker rather than a hedged disclaimer or confident guess. Done when: every unverified pattern carries an UNVERIFIED marker and none is presented as confirmed.

Failure and recovery

UNSPECIFIED_FRAMEWORK: user did not provide framework, language, or library context; stop and ask.
UNVERIFIABLE_DEPENDENCY: a dependency version cannot be determined and the user has not supplied it; stop and ask.
UNVERIFIABLE_PATTERN: no official documentation found for a required pattern; emit UNVERIFIED flag, do not write unverified code as confirmed.
SOURCE_CONFLICT: official sources contradict each other or contradict existing project code; surface the conflict without picking a side.
Non-converged: procedure cannot complete; write nothing, do not claim the done predicate holds.

Output

STACK DETECTED block first (pinned versions, latest versions, version gaps), then the verified code with full-URL citations in comments, UNVERIFIED flags on anything unverifiable, and CONFLICT DETECTED blocks for each surfaced contradiction.

Files (odin-claude-plugin)

agents

openai.yaml 175 B

interface:
  display_name: "Source Driven"
  short_description: "Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation."

references

stack-examples.md 2.4 KB

# Stack-specific examples for source-driven

These worked illustrations provide one set of examples per step. They show one shape rather than dividing stacks into fixed categories. Read the closest match and generalize; stacks without their own block are expected.

**Grounded: 2026-08-26**

## Step 1: stack-detection report shape

```
STACK DETECTED:
- React 19.2.8 (package.json)
- Vite 8.2.2
→ Fetch official docs for the patterns in scope.
```

```
STACK DETECTED:
- Django 5.2 (pyproject.toml)
- Python 3.14
→ Fetch official docs for the patterns in scope.
```

## Step 2: fetch precisely

```
BAD:  Fetch the React homepage
GOOD: Fetch react.dev/reference/react/useActionState

BAD:  Search "django authentication best practices"
GOOD: Fetch docs.djangoproject.com/en/5.2/topics/auth/
```

## Step 3: conflict-detected dialogue

**When the docs conflict with existing project code:**

```
CONFLICT DETECTED:
The existing codebase uses useState for form loading state,
but React 19 docs recommend useActionState for this pattern.
(Source: react.dev/reference/react/useActionState)

Options:
A) Use the modern pattern (useActionState): matches current docs
B) Match existing code (useState): matches the codebase
→ Which do you prefer?
```

The same conflict shape applies in any stack:

```
CONFLICT DETECTED:
The codebase wraps ORM calls in sync_to_async, but Django 5.2
documents native async ORM methods (aget, acreate) for this path.
(Source: docs.djangoproject.com/en/5.2/topics/db/queries/#async-queries)

Options:
A) Use the documented pattern (native async ORM): matches current docs
B) Match existing code (sync_to_async wrappers): matches the codebase
→ Which do you prefer?
```

## Step 4: citation formats

```typescript
// React 19 form state via useActionState (replaces manual isPending/setIsPending)
// Source: https://react.dev/reference/react/useActionState#usage
const [state, formAction, isPending] = useActionState(submitOrder, initialState);
```

```go
// Go 1.22+ method-aware routing patterns in net/http ServeMux
// Source: https://pkg.go.dev/net/http#hdr-Patterns
mux.HandleFunc("GET /orders/{id}", getOrder)
```

**In conversation:**

```
I'm using useActionState instead of manual useState for the form
submission state. React 19 replaced the manual isPending/setIsPending
pattern with this hook.

Source: https://react.dev/blog/2024/12/05/react-19#actions
"useTransition now supports async functions [...] to handle
pending states automatically"
```

SKILL.md 4 KB

---
name: source-driven
description: 'Use when writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. Not for remote, credential, publish, deploy, or irreversible changes.'
---

# Source-driven development

## Contract

| Field | Bound contract |
|---|---|
| Trigger | The current task is writing or verifying framework-specific code, boilerplate, or a documented, correct implementation. |
| Authority | Reversible local: writes only framework-specific code plus full-URL citations; rollback is version control (revert to last commit on failure). No remote mutation. |
| Side effect | Local writes with explicit UNVERIFIED flags for unverifiable patterns. |
| Done | Every framework-specific decision is backed by a cited official source and unverified patterns are explicitly flagged. |

## Inputs

- Framework context (required): the framework, language, or library.
- Dependency file (required): `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, `Gemfile`, `composer.json`, or `pyproject.toml`.
- Stack examples (optional): examples supplied by the caller. This skill has no bundled stack-reference dependency.

## Procedure

1. Read the project's dependency file and state the exact pinned versions. Done when: every dependency in the file has its pinned version stated.
2. For each dependency about to be written against, read the latest stable release from the release channel (registry, releases page, official download page). Report pinned and latest versions side by side. Name the gap when they differ. Done when: each touched dependency shows pinned and latest side by side, with the gap named when they differ.
3. Fetch the official documentation page for the exact feature being implemented. Use the source hierarchy: (1) official docs, (2) official blog/changelog, (3) web standards references (MDN, web.dev), (4) runtime compatibility references. Never use Stack Overflow, blog posts, tutorials, or training data as primary sources. Done when: the fetched page for each feature comes from the highest available tier of the hierarchy and no banned source is cited.
4. Extract the implementation patterns shown in the fetched docs. Use those exact API signatures. If the docs show a newer approach, use the newest one the pinned version supports. Do not use deprecated forms. Done when: every written API signature matches the fetched docs for the pinned version and no deprecated form remains.
5. When official sources contradict each other, report the discrepancy. Do not silently choose one. Done when: each contradiction surfaces as a CONFLICT DETECTED report rather than a silent pick.
6. Write code that follows the documented patterns. Every non-obvious decision gets a full-URL citation in a code comment. Quote the relevant passage when it supports a non-obvious decision. Done when: each non-obvious decision carries a full-URL citation, quoting the supporting passage where one exists.
7. Flag any pattern that could not be verified against official documentation with an explicit UNVERIFIED marker rather than a hedged disclaimer or confident guess. Done when: every unverified pattern carries an UNVERIFIED marker and none is presented as confirmed.

## Failure and recovery
- UNSPECIFIED_FRAMEWORK: user did not provide framework, language, or library context; stop and ask.
- UNVERIFIABLE_DEPENDENCY: a dependency version cannot be determined and the user has not supplied it; stop and ask.
- UNVERIFIABLE_PATTERN: no official documentation found for a required pattern; emit UNVERIFIED flag, do not write unverified code as confirmed.
- SOURCE_CONFLICT: official sources contradict each other or contradict existing project code; surface the conflict without picking a side.
- Non-converged: procedure cannot complete; write nothing, do not claim the done predicate holds.

## Output
STACK DETECTED block first (pinned versions, latest versions, version gaps), then the verified code with full-URL citations in comments, UNVERIFIED flags on anything unverifiable, and CONFLICT DETECTED blocks for each surfaced contradiction.