CtrlK
BlogDocsLog inGet started
Tessl Logo

spec-generator

Prompt template and output format for the Repository OS /spec command — generates structured specification summaries of indexed source files using retrieved code context from ChromaDB.

63

Quality

72%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tile-source/skills/spec-generator/SKILL.md
SKILL.md
Quality
Evals
Security

Spec Generator

Use this skill when implementing or modifying the /spec [filepath] command in the Oracle. The spec generator produces structured summaries of source files that serve as a prototype for Tessl's spec tiles.

How /spec Works

  1. User invokes /spec src/auth/handler.py
  2. Oracle retrieves all chunks for that file from ChromaDB (not a query search — a direct metadata filter)
  3. Chunks are assembled in order (by chunk_index) to reconstruct the full file context
  4. The assembled context is passed to Claude with the spec generation prompt below
  5. Claude returns a structured specification
  6. The spec is returned to the user and optionally saved to data/specs/{file_path}.spec.md

Retrieval Method

The spec generator does NOT use search_codebase (which is query-based). Instead, it fetches directly by file path:

chunks = collection.get(
    where={"file_path": file_path},
    include=["documents", "metadatas"]
)
# Sort by chunk_index to reconstruct file order
sorted_chunks = sorted(
    zip(chunks["documents"], chunks["metadatas"]),
    key=lambda x: x[1]["chunk_index"]
)

If no chunks are found for the file path, respond: "File {filepath} is not indexed. Run the indexer or check if the file path is correct."

Spec Generation Prompt

Send this to Claude with the assembled file context:

You are generating a structured specification for a source code file. The code is provided below. Produce a specification in the exact format shown, with no preamble or commentary.

## File
{file_path}

## Source Code
{assembled_chunks}

---

Generate the specification in this exact format:

# {filename} — Specification

## Purpose
[1–2 sentences: what this file does and why it exists in the codebase]

## Key Functions/Classes

### {name}
- **Type:** function | class | method
- **Purpose:** [1 sentence]
- **Parameters:** [list with types, or "None"]
- **Returns:** [return type and description, or "None"]
- **Side Effects:** [any side effects, or "None"]

[Repeat for each significant function/class. Skip trivial helpers unless they are part of the public API.]

## Dependencies

### Internal
[List internal imports — modules from within this repository]

### External
[List external package imports with brief purpose]
- `package_name` — [what it's used for in this file]

## Architectural Patterns
[1–3 bullet points describing design patterns, notable conventions, or architectural decisions visible in this file. Examples: "Uses dependency injection via constructor parameters", "Implements the Repository pattern for data access", "Guards all public methods with input validation"]

## Notes
[Anything unusual, important, or worth flagging: TODOs, known limitations, performance considerations, or coupling to other components. If nothing notable, write "None."]

Output Format

The spec is returned as markdown. Example output:

# handler.py — Specification

## Purpose
Handles JWT token validation and session management for the authentication subsystem. Called by the auth middleware on every protected route.

## Key Functions/Classes

### validate_token
- **Type:** function
- **Purpose:** Validates a JWT token string and returns the decoded payload
- **Parameters:** `token: str`, `secret: str`
- **Returns:** `TokenPayload` dataclass with `user_id`, `expires_at`, `scopes`
- **Side Effects:** None

### AuthManager
- **Type:** class
- **Purpose:** Manages authentication sessions and token lifecycle
- **Parameters:** `config: AuthConfig`, `store: SessionStore`
- **Returns:** N/A
- **Side Effects:** Writes to session store on login/logout

### AuthManager.refresh_session
- **Type:** method
- **Purpose:** Extends an existing session if the refresh token is valid
- **Parameters:** `refresh_token: str`
- **Returns:** `Session` with updated expiry, or raises `SessionExpiredError`
- **Side Effects:** Updates session record in store

## Dependencies

### Internal
- `src.models.user` — `User`, `TokenPayload` dataclasses
- `src.config` — `AuthConfig` settings
- `src.store.sessions` — `SessionStore` interface

### External
- `jwt` — JWT encoding/decoding
- `datetime` — Token expiry calculations
- `hashlib` — Session ID generation

## Architectural Patterns
- Uses constructor injection for `SessionStore`, enabling test doubles
- All public methods validate inputs before processing (fail-fast pattern)
- Token validation is stateless; session management is stateful

## Notes
- TODO on line 67: rate limiting for failed validation attempts is not yet implemented
- The `secret` parameter should be loaded from environment, not passed directly — this is a security consideration for production

Quality Criteria

A good spec should:

  • Be readable without the source code — a developer can understand what the file does from the spec alone
  • Not repeat the code verbatim — it summarizes and explains, not transcribes
  • Identify real dependencies — only list imports that actually appear in the code
  • Flag genuine concerns — the Notes section should call out real issues, not pad with boilerplate
  • Be concise — aim for 200-400 words total. If the file is small (< 30 lines), the spec should be proportionally shorter

Saving Specs

Generated specs are optionally saved to data/specs/ with the path structure mirroring the source:

  • /spec src/auth/handler.pydata/specs/src/auth/handler.py.spec.md

This creates a browsable spec directory that can be used for team review and as a prototype for Tessl spec tile format.

Repository
tombrewsviews/repository-os-mvp
Last updated
First committed

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.