playbooks

home / skills / oimiragieo / agent-studio / strategic-planning-with-pseudocode

strategic-planning-with-pseudocode skill

/.claude/skills/_archive/dead/strategic-planning-with-pseudocode

This skill helps developers ensure pseudocode is created before implementation, improving planning and code quality through structured guidance.

npx playbooks add skill oimiragieo/agent-studio --skill strategic-planning-with-pseudocode

Review the files below or copy the command above to add this skill to your agents.

Files (3)
SKILL.md
1.5 KB
---
name: strategic-planning-with-pseudocode
description: Rules that enforce to use pseudocode before implementation
version: 1.0.0
model: sonnet
invoked_by: both
user_invocable: true
tools: [Read, Write, Edit]
globs: /*.*
best_practices:
  - Follow the guidelines consistently
  - Apply rules during code review
  - Use as reference when writing new code
error_handling: graceful
streaming: supported
---

# Strategic Planning With Pseudocode Skill

<identity>
You are a coding standards expert specializing in strategic planning with pseudocode.
You help developers write better code by applying established guidelines and best practices.
</identity>

<capabilities>
- Review code for guideline compliance
- Suggest improvements based on best practices
- Explain why certain patterns are preferred
- Help refactor code to meet standards
</capabilities>

<instructions>
When reviewing or writing code, apply these guidelines:

- Begin each feature with detailed pseudocode.
- Example: Provide pseudocode for the weekly scoring process, detailing steps from game result input to entry status updates.
  </instructions>

<examples>
Example usage:
```
User: "Review this code for strategic planning with pseudocode compliance"
Agent: [Analyzes code against guidelines and provides specific feedback]
```
</examples>

## Memory Protocol (MANDATORY)

**Before starting:**

```bash
cat .claude/context/memory/learnings.md
```

**After completing:** Record any new patterns or exceptions discovered.

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.

Overview

This skill enforces a strategic planning workflow that requires authors to write detailed pseudocode before implementing features. It guides developers to think through logic, edge cases, inputs, and outputs so implementations are cleaner, safer, and easier to review. The goal is predictable, testable code produced from a clear plan.

How this skill works

Before any implementation, the skill inspects proposed changes and requests a step-by-step pseudocode outline that covers inputs, outputs, data transformations, and error paths. It reviews code for compliance with the pseudocode, suggests improvements, and recommends refactors when implementation deviates from the plan. After reviews, it prompts the author to record discovered patterns or exceptions for future planning.

When to use it

  • Starting a new feature or module that has business logic or complex workflows
  • Refactoring legacy code where behavior must be preserved and clarified
  • Preparing code for peer review or handoff to other developers
  • Designing scoring, aggregation, or multi-step processing pipelines
  • Onboarding contributors to ensure consistent planning discipline

Best practices

  • Always write pseudocode that names inputs, outputs, and side effects explicitly
  • Include failure modes and how the system should respond to each
  • Break processes into small, numbered steps or labeled blocks
  • Map pseudocode steps to implementation files and tests before coding
  • Capture any new patterns or exceptions discovered during the review

Example use cases

  • Drafting pseudocode for a weekly scoring pipeline before writing aggregation code
  • Documenting the sequence of validations and state changes for a user registration flow
  • Refactoring a reporting module by first outlining each transformation step in pseudocode
  • Reviewing a pull request and verifying implementation matches the proposed pseudocode

FAQ

Must pseudocode be formal or can it be plain language?

Pseudocode should be clear and structured but need not follow formal syntax; focus on unambiguous steps, data shapes, and decision points.

How detailed should pseudocode be for small fixes?

For small fixes, a concise 3–6 step plan that highlights input, output, and the change is sufficient; complex changes require more detail.