Install
$ agentstack add skill-jlong-quiddity-q-which-tools ✓ 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-which-tools
You are interviewing the user about the tools their project uses. Your job is to ask about each requested category and write the results to .quiddity/tools.json.
Arguments
$ARGUMENTS contains space-separated category names. Supported categories:
- issues — Issue/task tracker (Linear, GitHub Issues, Jira, etc.)
- source-control — Source control host (GitHub, GitLab, Bitbucket, etc.)
- ci — Continuous integration (GitHub Actions, CircleCI, etc.)
- pr — Pull request conventions (merge strategy, review requirements, etc.)
- deploy — Deployment target (Vercel, AWS, Fly, manual, etc.)
- notifications — Notification channels (Slack, Discord, email, etc.)
If no arguments are provided, ask the user which categories they'd like to configure.
Process
- Read process context. Check if
.quiddity/process.mdexists. If it does,
read it to understand the user's SDLC. Use this context to inform your questions and pre-fill answers where possible (e.g., if the process doc mentions "we use GitHub flow", you already know the source-control platform).
- Read existing config. Check if
.quiddity/tools.jsonexists. If it does,
read it and note which categories are already configured.
- For each requested category:
- If the category already exists in tools.json, tell the user it's already
configured and show the current value. Ask if they want to reconfigure it. If not, skip it.
- If the category is new, ask the user what tool they use.
- Ask follow-up questions specific to the tool they selected. See the
category reference below for what to ask.
- Write the results. Merge the new category data into
.quiddity/tools.json.
Create the .quiddity/ directory if it doesn't exist. Preserve any existing categories that weren't reconfigured.
Category reference
issues
Ask:
- Which issue tracker? (Linear, GitHub Issues, Jira, Shortcut, etc.)
- Team or project name?
- What states/statuses do issues move through? (e.g., Todo → In Progress → Done)
- How is priority represented? (priority field, labels, columns, etc.)
- Any label conventions?
Example output:
{
"issues": {
"tool": "linear",
"team": "ENG",
"states": {
"backlog": "Backlog",
"todo": "Todo",
"inProgress": "In Progress",
"done": "Done",
"cancelled": "Cancelled"
},
"priorities": ["Urgent", "High", "Medium", "Low", "None"],
"labels": ["bug", "feature", "chore", "improvement"]
}
}
source-control
Ask:
- Which platform? (GitHub, GitLab, Bitbucket, etc.)
- Default/base branch name? (main, master, develop, etc.)
- Branch naming convention? (e.g.,
feat/LIN-{{id}}-{{slug}},feature/JIRA-{{id}}) - Commit message format? (conventional commits, free-form, etc.)
Example output:
{
"source-control": {
"tool": "github",
"baseBranch": "main",
"branchFormat": "feat/LIN-{{id}}-{{slug}}",
"commitFormat": "conventional"
}
}
ci
Ask:
- Which CI system? (GitHub Actions, CircleCI, Jenkins, etc.)
- What checks run on PRs? (tests, linting, type checking, build, etc.)
- How to run those checks locally? (e.g.,
npm test,make check)
Example output:
{
"ci": {
"tool": "github-actions",
"checks": ["tests", "lint", "typecheck", "build"],
"localChecks": ["npm test", "npm run lint", "npm run typecheck", "npm run build"]
}
}
pr
Ask:
- Merge strategy? (squash, merge commit, rebase)
- Delete branch after merge?
- Required number of approvals?
- Any PR template in the repo?
- PR title format?
Example output:
{
"pr": {
"mergeStrategy": "squash",
"deleteBranch": true,
"requiredApprovals": 1,
"hasTemplate": true,
"titleFormat": "conventional"
}
}
deploy
Ask:
- Where does the project deploy? (Vercel, AWS, Fly.io, Heroku, manual, etc.)
- Is deployment automatic on merge to the base branch?
- Any manual steps?
Example output:
{
"deploy": {
"tool": "vercel",
"automatic": true,
"trigger": "merge-to-main"
}
}
notifications
Ask:
- Where should notifications go? (Slack, Discord, email, none)
- Which channel/room?
- What events should trigger notifications?
Example output:
{
"notifications": {
"tool": "slack",
"channel": "#engineering",
"events": ["pr-merged", "deploy-complete"]
}
}
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.