Open source project

Skill bakerstreetco/skills/open-source-project

Reusable agent skills for real repository work: review, implementation, release, documentation, and project hygiene.

Install

npx -y skills add bakerstreetco/skills --skill open-source-project

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Convert an existing script or code directory into a standard open source project with repository metadata, license, README, gitignore, package configuration, contribution guide, changelog, initial commit, remote repository, and optional package publishing setup. Use when asked to turn local code into a reusable public project or prepare code for open source release.

SKILL.md

5.9 KB, as published. Nobody here has run it

Open Source Project

Use this skill to convert a script or code directory into a standard open source project. Inspect the code first, choose files that match the language and package ecosystem, and avoid generic placeholders in final artifacts.

Prerequisites

Confirm or infer:

Existing code file or directory.
Target project directory.
Project name.
License type, defaulting to MIT only when the user has not specified another license.
Primary language and package ecosystem.

Do not publish, push, or create a remote repository until the repository identity and hosting account have been verified.

Quick Checklist

Initialize git repository when needed.
Create LICENSE.
Create README.md with installation and usage.
Create .gitignore.
Create package metadata such as pyproject.toml, package.json, Cargo.toml, or equivalent when applicable.
Create CONTRIBUTING.md.
Create CHANGELOG.md.
Add tests or a test scaffold when the project has runnable behavior.
Make an initial commit when requested.
Create a remote repository when requested.
Push to the remote when requested.
Add README badges only when useful and accurate.

Project Files

LICENSE

For MIT, use the standard MIT text with the current year and the project owner:

MIT License

Copyright (c) [YEAR] [AUTHOR]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Other common choices: Apache-2.0, GPL-3.0, BSD-3-Clause.

README.md

Write a README that reflects the actual code. Include:

Project name.
Short description.
Features.
Installation.
Usage with real commands or API examples.
Development setup.
Test command.
License.

Use placeholders only while drafting; replace them before final delivery.

.gitignore

Include language-specific, editor, OS, build output, cache, virtual environment, and secret patterns. For Python projects, include:

__pycache__/
*.py[cod]
*$py.class
build/
dist/
*.egg-info/
.pytest_cache/
.mypy_cache/
.ruff_cache/
venv/
env/
.venv/
.vscode/
.idea/
*.swp
*.swo
.DS_Store
Thumbs.db
.env
.env.local

Python pyproject.toml

For Python packages, prefer pyproject.toml with modern build metadata:

[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "project-name"
version = "0.1.0"
description = "Brief description"
readme = "README.md"
requires-python = ">=3.10"
license = {text = "MIT"}
authors = [{name = "Author Name", email = "[email protected]"}]
classifiers = [
    "Development Status :: 3 - Alpha",
    "Intended Audience :: Developers",
    "License :: OSI Approved :: MIT License",
    "Programming Language :: Python :: 3.10",
    "Programming Language :: Python :: 3.11",
]
dependencies = []

[project.optional-dependencies]
dev = [
    "pytest>=7.0",
    "ruff>=0.1.0",
    "mypy>=1.0",
]

[project.scripts]
cli-name = "module:main"

[tool.ruff]
target-version = "py310"
line-length = 100

[tool.mypy]
python_version = "3.10"
strict = true

Only include CLI scripts, dependencies, classifiers, and URLs that match the actual project.

CONTRIBUTING.md

Keep contribution instructions short and accurate:

Development setup.
Branch and pull request workflow.
Test and lint commands.
Code style.
Issue reporting expectations.

CHANGELOG.md

Use a simple Keep a Changelog style:

# Changelog

All notable changes to this project will be documented in this file.

## [Unreleased]

## [0.1.0] - YYYY-MM-DD

### Added
- Initial release.

GitHub and Publishing

When asked to commit, create a remote, push, or publish:

Inspect git status --short, git diff, and recent commits.
Verify git and hosting identity before remote actions.
Stage only files created or changed for this project setup.
Commit with a natural descriptive message.
Create the remote with gh repo create owner/project --public --source=. --remote=origin only after confirming the intended owner and visibility.
Push with git push -u origin main.

For Python package publishing:

python -m build
twine upload --repository testpypi dist/*
twine upload dist/*

Use TestPyPI first unless the release process is already established.

Best Practices

Choose a license deliberately.
Make the README specific to the actual project.
Keep secrets and local files out of git.
Include installation, usage, development, and testing instructions.
Use semantic versioning when publishing releases.
Add badges only when the linked services exist.
Keep CHANGELOG.md updated as releases are made.