Install
$ agentstack add skill-jlong-quiddity-q-scan-project ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
/q-scan-project
You are scanning the user's project to understand its structure and document what you find. Your job is to explore the codebase and write a useful summary that other skills can reference.
Process
- Check for existing project.md. If
.quiddity/project.mdalready exists,
read it and ask the user if they want to update it or start fresh.
- Scan the project. Look for the following and note what you find:
### Key documentation files
- README, README.md
- ARCHITECTURE.md, DESIGN.md
- CONTRIBUTING.md
- CHANGELOG.md
- ROADMAP.md
- CLAUDE.md, .cursorrules, or other agent configuration
- Any docs/ or documentation/ directory
### Project configuration
- package.json, Cargo.toml, pyproject.toml, go.mod, Gemfile, etc.
- What language(s) and framework(s) does the project use?
- What package manager? (npm, pnpm, yarn, bun, cargo, pip, etc.)
- Monorepo structure? (workspaces, lerna, turborepo, etc.)
### Source structure
- Where does source code live? (src/, lib/, app/, etc.)
- Entry points (main files, index files, etc.)
- Test directory structure (tests/, __tests__/, spec/, etc.)
### CI/CD and configuration
- .github/workflows/, .circleci/, Jenkinsfile, etc.
- Docker files (Dockerfile, docker-compose.yml)
- Deployment configuration (vercel.json, fly.toml, etc.)
### Existing conventions
- .editorconfig, .prettierrc, .eslintrc, etc.
- PR templates (.github/pullrequesttemplate.md)
- Issue templates (.github/ISSUE_TEMPLATE/)
- CODEOWNERS
### Plans and specs
- Any planning documents, RFCs, ADRs (architecture decision records)
- Spec files or design documents
- TODO files
- Ask clarifying questions. If anything is ambiguous, ask the user:
- Is there anything important about the project structure not captured above?
- Are there any conventions or patterns that aren't obvious from the files?
- Set up architecture reference. Other skills (like
/next-task) read
.quiddity/architecture.md to understand the technical architecture before implementing changes. This document may describe things not yet built — it's a reference for where the project is going, not just where it is now.
- If an architecture doc already exists in the repo (e.g., ARCHITECTURE.md,
docs/architecture.md), create a symlink: .quiddity/architecture.md → the existing file. Tell the user about the symlink.
- If the user has an architecture doc outside the repo (a URL, a Google
Doc, a local file), ask them to share it. Copy the contents into .quiddity/architecture.md.
- If no architecture doc exists, ask the user if they'd like to create
one. If yes, interview them about the high-level technical architecture and write .quiddity/architecture.md. If no, skip this step — the file is optional but recommended.
- Write the results. Create
.quiddity/project.mdwith a clear summary.
Create the .quiddity/ directory if it doesn't exist. Write in second person ("Your project uses...") so other skills can reference it as context.
- Confirm with the user. Show them the generated project.md and ask if
anything needs to be adjusted.
Output format
.quiddity/project.md should follow this general structure:
# Project Summary
## Overview
[Brief description of what the project is, based on README or package metadata]
## Tech stack
- Language: [e.g., TypeScript]
- Framework: [e.g., Next.js]
- Package manager: [e.g., pnpm]
## Project structure
[Key directories and their purposes]
## Key files
| File | Purpose |
|---|---|
| README.md | Project overview and setup instructions |
| ARCHITECTURE.md | System design and architecture decisions |
| ... | ... |
## Configuration
[Linting, formatting, editor config, etc.]
## CI/CD
[What CI runs, where it's configured]
## Conventions
[Any patterns or conventions discovered]
Not all sections need to be present — only include what's relevant.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: jlong
- Source: jlong/quiddity
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.