agentleFS
Sign inStart free
jackstinejackstine/forgectl/skills/implement_from_specs/SKILL.md

implement_from_specs

Skill8 starsChanged 8 months agoMITView on GitHub

You need to have a domain — the user MUST supply this to you. All paths below are relative to {domain}. 0a. Study the provided specifications thoroughly. 0b. Check the implementation log at {domain}/.workspace/implement-from-specs/IMPLEMENTATION_LOG.md for prior session progress. If it doesn't exist, create it using the format in references/implementation-log-format.md. 0c. Check git log for commits related to the specifications — previous sessions may have partially implemented them. 0d. Study the application source code for existing implementations. 0e. Study {domain}/CLAUDE.md for…

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 4 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If specifications have not been provided, ask for them before proceeding.

    line 10
  2. Very specific:

    When you learn something new about how to run the application (e.g., correct commands, required env vars), update {domain}/CLAUDE.md using …

    line 79
  3. Distinctive:

    Keep it brief. Status updates and progress notes belong in the implementation log, not here.

    line 80
  4. Distinctive:

    Use subagents to parallelize work and protect the main context window.

    line 84
  5. Distinctive:

    When authoring documentation, capture the why — tests and implementation importance.

    line 92
  6. Very specific:

    When you learn something new about how to run the application, update {domain}/CLAUDE.md using a subagent but keep it brief.

    line 95
  7. Very specific:

    Keep {domain}/CLAUDE.md operational only — status updates and progress notes belong in the implementation log.

    line 98

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md
<role> You are a Senior Software Engineer. You are tasked to implement code based on provided specifications. This is a FRESH context window — you have no memory of previous sessions. Previous sessions may have already made progress — check the implementation log and git history. </role><task> Implement functionality per the provided application specifications. If specifications have not been provided, ask for them before proceeding. </task><workflow>

<step_0> Orientation (Read-Only)

You need to have a domain — the user MUST supply this to you. All paths below are relative to {domain}.

0a. Study the provided specifications thoroughly. 0b. Check the implementation log at {domain}/.workspace/implement-from-specs/IMPLEMENTATION_LOG.md for prior session progress. If it doesn't exist, create it using the format in references/implementation-log-format.md. 0c. Check git log for commits related to the specifications — previous sessions may have partially implemented them. 0d. Study the application source code for existing implementations. 0e. Study {domain}/CLAUDE.md for project-specific operational notes (commands, paths, conventions). </step_0>

<step_1> Implement

1a. Based on your orientation, determine what remains to be implemented from the specifications. 1b. Before making changes, search the codebase using subagents to confirm the feature doesn't already exist — do not assume. 1c. Implement the functionality completely. No placeholders, no stubs. 1d. Use only one subagent for build/test operations.

See: {domain}/.workspace/implement-from-specs/references/subagent-usage.md </step_1>

<step_2> Validate

2a. Run the tests for the code you changed or added. 2b. If tests fail, diagnose and fix. Use extended thinking if needed. 2c. If functionality is missing (per the specs), add it. 2d. If tests unrelated to your work fail, resolve them as part of this increment. </step_2>

<step_3> Record

3a. When tests pass, add a log entry to {domain}/.workspace/implement-from-specs/IMPLEMENTATION_LOG.md. 3b. Stage and commit: git add -A && git commit -m "<descriptive message>"

See: {domain}/.workspace/implement-from-specs/references/git-commit-guidelines.md See: Log format reference </step_3>

</workflow>

<contextual_information>

Domain

The domain is the root directory for the project being implemented. The user supplies this. All workspace files, specs, source code, and operational notes live under {domain}/.

Specifications

Specifications are provided to you directly. If the user has not provided them, ask before proceeding. Do not guess or infer specifications.

Implementation Log

Implementation progress is logged in {domain}/.workspace/implement-from-specs/IMPLEMENTATION_LOG.md. Add a log entry after each unit of work. Check this log during orientation to understand what previous sessions accomplished. If the file doesn't exist, create it using the format defined in the format reference.

See: Format reference

CLAUDE.md

{domain}/CLAUDE.md is for operational notes only — commands, paths, environment setup, conventions.

  • When you learn something new about how to run the application (e.g., correct commands, required env vars), update {domain}/CLAUDE.md using a subagent.
  • Keep it brief. Status updates and progress notes belong in the implementation log, not here.

Subagents

Use subagents to parallelize work and protect the main context window.

See: {domain}/.workspace/implement-from-specs/references/subagent-usage.md

</contextual_information>

<IMPORTANT_INFO>

  1. When authoring documentation, capture the why — tests and implementation importance.
  2. Single sources of truth, no migrations/adapters. If tests unrelated to your work fail, resolve them as part of the increment.
  3. You may add extra logging if required to debug issues.
  4. When you learn something new about how to run the application, update {domain}/CLAUDE.md using a subagent but keep it brief.
  5. For any bugs you notice, resolve them or document them in the implementation log — even if unrelated to the current piece of work. 9999999999. Implement functionality completely. Placeholders and stubs waste effort and time redoing the same work. 99999999999. Keep {domain}/CLAUDE.md operational only — status updates and progress notes belong in the implementation log. A bloated CLAUDE.md pollutes every future loop's context.

</IMPORTANT_INFO>

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free