Simple Code

Plan and build small, readable coding projects with a strict workflow: think first, make a short plan, then delegate implementation/testing/bug-fixing/docume...

Security Scan

The skill's instructions and requirements are internally consistent with its stated purpose (planning and producing small readable code) and it does not request extra credentials or install code; the main runtime concern is that it delegates work to sub-agents that will create files and commit them in the workspace.

Purpose & Capability

The name/description (plan and build small code projects) matches the SKILL.md: it instructs creating a project folder, using git, adding tests, running builds, and delegating implementation. There are no unrelated env vars, binaries, or install steps requested. The only notable capability requirement is that it expects the platform to spawn a 'sub-agent' using an OAuth-backed Codex model, which aligns with delegating heavy coding work.

Instruction Scope

Instructions direct the agent to create files under agent_code/<project-name> (including a .steps/ directory), initialize and use git in that folder, run build/test commands, and have a sub-agent perform the coding/testing/fixing. These actions are consistent with the task but do grant the executing agent write and commit access to the workspace. The SKILL.md does not instruct reading unrelated system files or exfiltrating data, but delegating to sub-agents increases the area of effect (they will have the same workspace access).

Install Mechanism

No install spec or code files are present — this is instruction-only, so nothing is downloaded or written by an installer step. Lowest install risk.

Credentials

The skill declares no required env vars or credentials, which is proportionate. However, it explicitly prefers an OAuth-backed OpenAI Codex model for sub-agents (and disallows API-key models); that implicitly relies on platform OAuth/session credentials to invoke those models. This is a platform-level requirement rather than an unexpected credential request from the skill itself.

Persistence & Privilege

always:false and user-invocable:true (default) — the skill is not force-included. It does rely on the ability to spawn sub-agents (runtime="subagent"), which is an autonomous capability; that increases the operational blast radius compared to purely interactive instructions because sub-agents will run independently and write files/commits. The skill does not request global config changes or cross-skill credentials.

Assessment

This skill is coherent and appears to do what it says: plan small projects, create files under agent_code/, run tests, and commit results. Before installing or using it, consider: (1) the skill will create and commit files in your workspace — review diffs/commits it makes; (2) it delegates heavy work to sub-agents that run using your platform session/OAuth (so ensure you trust the agent and your OpenAI OAuth/session policies); (3) inspect generated code and tests for secrets or unsafe operations before running in production; (4) if you prefer tighter control, run requests in an isolated project folder or a disposable workspace and restrict which models/sub-agent runtimes are allowed in your environment. If any of these are unacceptable, do not enable or invoke the skill until you can enforce those safeguards.

Overview

Follow a lightweight project workflow for small coding tasks where readability matters more than cleverness.

Workflow

1. If the task is project-like, create a properly named project folder under agent_code/<project-name> first.
2. When creating that project folder, also create a .steps/ folder inside it.
3. Initialize .gitignore in the project folder if needed, and make sure it ignores .steps/ and everything under it from the start.
4. Do all further work inside that project folder.
5. Think through the request before coding.
6. Make a short plan and state the chosen approach briefly.
7. Spawn a coding sub-agent through OpenClaw (runtime="subagent") using an OAuth-backed OpenAI Codex model (preferred); do not use an API-key-based model.
8. Sub-agent work must run without blocking the current active channel session; delegate heavy coding first, then continue channel interaction normally.
9. After delegation, all following execution work must be done by the sub-agent inside the project folder: coding, testing, bug-fixing, documentation, and .steps/ tracking.
10. Keep the implementation simple, readable, and standard-library-first unless the user asks otherwise.
11. Add tests for the most important functionality inside the same project folder.
12. Verify the project by running the relevant build/test commands from the project folder.
13. If tests fail, fix the issues and re-run until the final code passes and runs.
14. Use git inside the project folder, not at the whole-workspace level, unless the user explicitly wants workspace-level git.
15. For each request that results in a commit, create one concise tracking note in .steps/ after the commit, named <YYYYMMDD-HHMM>-<abbr>-<commit-hash>.md.
16. In that tracking note, record only: request summary, short plan, and execution outcome against plan. Keep it concise and brief.
17. When the sub-agent session finishes, send a short ping that the code is ready and briefly state what was done.

Coding Rules

• Prefer clear names over compact tricks.
• Prefer fewer files and a smaller API when possible.
• Prefer standard tools for the language ecosystem.
• Avoid unnecessary dependencies.
• Handle invalid input and obvious failure cases clearly.
• Do not leave the code unverified if a local build/test command is available.

Project Layout Rules

For project-like requests, create this structure first and work only inside it by default:

• agent_code/<project-name>/
• agent_code/<project-name>/.steps/
• source files in that folder root unless there is a good reason to add subdirectories
• tests in the same folder if the project is very small
• add a simple build file when appropriate, such as CMakeLists.txt for C++
• add or update .gitignore early so .steps/ is ignored before commits start

Git Rules

• Initialize git in the project folder if needed.
• Add .steps/ to .gitignore before the first commit in a new project when possible.
• Commit meaningful milestones after verification.
• After each such commit, create a matching .steps/<YYYYMMDD-HHMM>-done-<abbr>-<commit-hash>.md note.
• Keep each .steps note short: request, plan, and outcome only.
• If the workspace root has temporary bootstrap git history and the user asks to remove it, remove only that root-level history.
• Do not rewrite git history unless the user explicitly asks.

Response Style

When reporting back to the user after sub-agent completion:

• start with a short ping that the code is ready
• briefly state what was built
• include where it lives
• briefly mention verification status
• include the latest relevant commit hash if git was used